mob/proc Problem description: I'm sure I'm doing something that will be obvious to most, but I just don't see it. When I load the character, nothing happens and the screen is just black. Any help would be appreciated ^.^ | |
|
Mar 8 2016, 6:55 pm
|
|
Nadrew
  |
You're not showing the part of the code that's actually loading the data, I'd assume that's in SetLoadStuff().
|
Oh right, my apologies.
mob/player/proc/SetLoadStuff(var/savefile/F) | |
I think it may have something to do with the line:
del(old_mob)
in the Load_Player proc. If you want to load the client's mob use: client You also want your save proc to have something like this in it to save the mob: var/savefile/F = new(SAVEFILE_PATH(slot_number)) Atleast I tried something like that and it seemed to work. When you are deleting the old mob I think you are actually deleting the player because the old mob is just a reference to the player's mob, that's why you have a black screen. Doing it this way it will save the player's list and the objects in the list so you shouldn't have to worry about resetting the screen locs for them (I think :S). | |
if(K.name==slot1)The logic center of my brain just turned right off. | |
Is there a better way to do it that you could explain to me? I'm always wanting to learn
| |
If you can explain what it's supposed to do, I sure can.
| |
It's just checking to see if the techniques in your technique list are saved to one of your hotslots, if it is, add it to your screen.
| |
Actually, I'm having a lot of trouble getting my saving and loading to work, and I've long known you're the guy to go to if help is needed in that area. May I have some assistance? I've tried everything I can think of lol
| |
I recently wrote quite a system that handles this for someone else. This isn't it, but this is the gist of what you need to do.
Basically, when the client logs in, add however many hotbars to their screen. Store these hotbar objects in a list. client Now, these objects belong to the client, but the attacks bound to the bars belong to the mob. mob Things I fixed: 1) You don't need to loop through the client's screen. If you are ever looping through client.screen, you are doing something wrong. You should NEVER do it. 2) You don't need to loop through every attack the player knows to update 16 graphics. In this example, you need to loop through 16 positions. That is all. 3) You don't need to do anything special on save. This all should be managed appropriately during a save. Also, your loading function is completely wrong because your saving function is completely wrong. You are doing way more work than you should ever have to do and it may be completely unfixable because the source code you are using is probably unfixable. When your game is structured correctly, saving should look like this: var/savefile/F = new/savefile("herpderp.sav") And loading should look like this: var/savefile/F = new/savefile("herpderp.sav") Because you are trying to micromanage what the savefile does, you have actually wasted a lot of energy and introduced quite a lot of problems in your code. Unfortunately, much of this was done for you before you even started modifying this source code. | |
It was my understanding that the way it was done is poor and I was attempting to improve it. The only problems I'm having with my saving at this point, is it's calling Login() twice for some reason. I've fixed most of the other problems.
mob/proc This is the current load proc I have. Do you see any reason why it'd call Login() twice? Please try to understand that not everyone is as experienced as you. When we come on the forums attempting to learn, and then we're shot down and criticized for the effort, it makes us want to quit. That isn't how it should be. I do appreciate that you've taken the time to reply, as does everyone else you've helped. | |
var/mob/player/T = new/mob/player() | |
But I have to make a new player there, don't I?
| |
No, not really. Ideally, you should be checking to see if a savefile exists with the client's ckey; not creating a new mob, using that mob to read the savefile(you should never be using Read() directly either), and then setting the client to that mob. That's just a big mess.
| |
Well, no. The beauty of BYOND's built in savefile management, is that it does everything you are already doing.
mob Any variable that is: 1) Marked tmp, const, or static 2) The same value as the default will not be saved when you pass an object into a savefile. Read() and Write() are automatically called when you output an object to a savefile, and when you read an object from a savefile. You should never have to call these functions manually, and further, you should never call them manually because doing so is dangerous as it can cause object duplication and all kinds of other messes. Also, by default, mob.key is saved in the savefile. When the savefile reads the old key value of the mob, it will automatically switch the client to that mob. That means there's no reason to create a new mob to read from the savefile, and there's no reason to set the mob's client after loading from the savefile. This is your new saving code: var/savefile/F = new/savefile("herp.sav") And this is your new loading code: var/saveilfe/F = new/savefile("herp.sav") You best start digging through your source code and start marking variables you don't want to save as tmp. A few rules for saving: 1) If you have a variable that ever points to another player, mark it tmp. You don't want to save multiple players in one savefile. When you load the savefile, everything attached to it comes with it. If they had another player stored in a variable somewhere, and that player is currently logged in, that player's client will switch to the old saved copy that got stuffed into the other player's savefile. This will potentially cause rollbacks, meaning they lose progress in the game. 2) You should never put anything in the player's contents that doesn't log out with them. Most rip source codes do something like this: Login() This is dangerous, because the first argument for atom/New() is always the location argument. You are inadvertently creating a new screen object that's saved with the player every time they log out. A quick fix would be to pass the client as the first argument, or pass null as the first argument. That way the screen objects won't be saved. This will cause leaks that will require player wipes to get rid of. Login() Or, my preferred method: Login() 3) You will want to make sure that you don't save things that may change in the future. So if you remove an item from the game, or remove a skill from the game, it doesn't necessitate a wipe. It's usually best to save unique ids instead of the objects themselves to prevent the need to wipe out old savefiles when you update the game. 4) You also want to make sure that any references to global objects are tmp or are properly managed. Saving global objects can cause portions of the map to be overwritten when a player logs in, or cause object duplication that can result in massive leaks. | |
Thank you guys. You've been a great help. I also appreciate the help with the hotslots. It really goes a long way that you take the time to actually explain these things.
| |
