ID:179326
 Jan 19 2002, 8:55 pm
|
|
For some reason, saving a character doesn't save their location with it. But if I try to create a file called '(playername).loc', then when they log in say F >> usr.loc, it creates a new user! Is there a way to automate this? A simple yes or no would work. If not, I'll just use arrays...
| |
Yeah I know what you mean, I'm a newbie in linux gtq design too ;) But yeah i've looked at the F1 guide a lot. Since theres no generaic way to do it, i'll just store the locs in an var like UsrStart = usr.loc... F << UsrStart and just load that and use F >> UsrStart... usr.locate(UsrStart). Do you think that would work? (people are online so I can't just try and retry right now :D)
| |
Well, if F is your savefile, F >> variable is saying "Take the file F, and cram it into this variable." Going with a dummy variable is a simple solution, but the way to implement it is: set the dummy variable right before the normal saving process, and set location based on the dummy variable right after the normal loading process.
Also, you probably don't want to save usr.loc, in any form, under any variable... unless you do want to bring back along the spider and the bird and all their friends. It'll bring the mob back, but it'll also bring back the (possibly outdated) turf that mob occupied, overwriting any changes that have occured within that turf in the intervening time. How about dummy variables named X, Y, and Z? src.X = src.x src.Y = src.y src.Z = src.z //save the mob now. Then, after the code where you load the mob, Move(locate(X,Y,Z)) | |
It looks like that should work, you've got to make sure you do your directories right though, that's what messed me up for a while. I suggest you read Deadron's Tutorial on Savefiles, it took me some effort to wade through it but it was worth it in the end.
By the way, I think it's suggested that you create one save file and call it players.sav, characters.sav, or whatever you want instead of a save file for each player. That way you can just assign each player a directory in that file based upon their ckey. The other way, if you had over 100 different players who've visited your game you could end up with over a hundred save files, I don't think that could be a good thing. | |
On the other hand, if you're planning on doing anything fancy with the savefiles (like communication between multiple servers), having a separate one for each player certainly simplifies things. The use of embedded tags in savefile names makes it easy to do some basic directory sorting.
Point of fact, a lot of my games do more than create a separate file for each player, they create a separate literal directory for them, so I can have "[key].save","[key].log", and so forth. If players are allowed multiple characters on one account, I make the key the directory, the character name the save file. | |
Well, now we have to save the spider's loc, as well, and the loc of that loc, and the loc of that loc, until it gets to the point that when the fly logs back in, it brings with it a copy of the spider, the bird, the cat, the dog, and the poor old woman that swallowed the fly to begin with!
There's a thousand and one ways around this... but none that fit the default savefile-writing scheme, and it seems a poor solution to have one exception to such an elegantly simple mechanism, when the specifics of location saving will likely differ from game to game anyway. Study the mechanics of how savefiles actually work a little... read up on the Read and Write procs, the << and >> operator, and so on, and you'll come up with your own solution that fits your own game.
My general advice to you: stop what you're doing in your game and just read a whole lot of the material presented on this site. Read it again, if you've already read it. I tell this to everyone, but it has special meaning aimed to you. You obviously know a great deal about programming in general. This is to your advantage, but also to your detrminent, if you don't stop and learn a bit more about how the system you're using works and just proceed on your general knowledge of programming.