ID:1682502
 
Save & Load Players
Here you'll find two processes to load and save players.

savePlayer()
Always creates a savefile or writes to the existing one

loadPlayer()
Returns 0 if the player couldn't be loaded
Returns 1 if the player was loaded

You'll also find that I've edited Read() and Write() to save the location of the player as this is not done automatically.

Worked Example
This will automatically save players when they log out and load them when they log in.

mob
// Attempts to load the player. If it can't, spawns them like normal. Replace ..() with what you
// would like to happen when there's no save file to load.

Login()
if(!loadPlayer())
..()

// Saves the player to a file such as "Savefiles/alexpeterson.sav"

Logout()
savePlayer()
del src


// The processes themselves you'll want to use

proc
loadPlayer()
if(fexists("Savefiles/[ckey].sav"))
var/savefile/F = new("Savefiles/[ckey].sav")
Read(F)
return 1
else
return 0

savePlayer()
var/savefile/F = new("Savefiles/[ckey].sav")
Write(F)
return 1


// Here's an edit to Read and Save allowing them to save the player's coordinate variables.

Read(var/savefile/F)
..()
Move(locate(F["x"],F["y"],F["z"]))

Write(var/savefile/F)
..()
F["x"] << x
F["y"] << y
F["z"] << z


Extra Note #1
If you have a mob variable you don't want this to save then define it in the format:
mob
var/tmp/dontSaveThis = 20


Extra Note #2
You may want to instead place loading and saving under: client/new() and client/Del() if the worked example isn't quite what you wanted.

From my experiences or from what I was told was that you should not be calling Read() or Write() directly. You would essentially get the same results of checking whether x file exists by using fexists(). And one more concern is, I was under the impression that things like this would be better handled under client/New() and client/Del() rather Login() and Logout(). I'm not too sure, I haven't programmed in awhile but just wanted to throw a couple cents out there if you don't mind.

:) :)
this would be better handled under client/New() and client/Del()

Loading variables into a mob causes a call to Login() in some cases. I believe this is one of them, but I haven't tested the code.
Read() doesn't call Login(). Login happens when you load a new mob object from the save file and its key matches your key, causing a client.mob change.
In response to Neimo
Neimo wrote:
From my experiences or from what I was told was that you should not be calling Read() or Write() directly. You would essentially get the same results of checking whether x file exists by using fexists(). And one more concern is, I was under the impression that things like this would be better handled under client/New() and client/Del() rather Login() and Logout(). I'm not too sure, I haven't programmed in awhile but just wanted to throw a couple cents out there if you don't mind.

:) :)

So that's a good question, why login/logout and not client/new|client/Del? The reason is that most people who read this will just want it for login/logout and they'll understand what it does.

There's no reason why you can't call them under client, it's just a worked example. You can use the processes wherever you like and I definitely think in some cases client would be a better solution.

As for not calling read/write directly. I don't understand what you mean sorry. This is how saving is said to be done in the DM Guide. I know you can manually do your own savefiles but why do that when this works already and saves you a lot of work?
In response to Alex Peterson
Some people prefer savefile << mob to save and savefile >> new_mob to load. This causes a client.mob change (which always calls mob.Logout() and new_mob.Login()) but it just depends how you manage your login system. If you set world.mob to some mob type specific to title screens to save memory by not giving it all the in-game player variables, then you'd have to change mobs eventually anyway.

I've never had a problem with calling Read() and Write() directly. Some people have claimed that it is bad to do so without giving a reason, and others say so because others say so. Evidence is important. It's not like the usr vs src problem.