I've been working on my battle system for quite some time, and I have one constantly recurring problem - people logging out during the middle of battle. What’s even worse is when two or more players are in battle (with or against each other) and then one of the players logs out. I tried modifying the Logout() proc, but once a player logs out, I can’t modify any of the variables that belong to the player. This includes finding out who is part of the players party and which battle area the player is fighting in (if applicable). Does anyone know how to handle this problem? Thanks.
- Gakumerasara
ID:178689
 Apr 17 2002, 10:01 am
|
|
Anytime in your battle code, after you sleep() or spawn() (these are the only cases where it's possible for anything to have changed, aside from what goes on in the current proc), you can put in a check to make sure that none of the objects you refer to have been nullified.
Look at this code for an example: mob/verb/attack(mob/m as mob in oview(1)) src << "You get ready to attack [m]!" sleep(10) m.HP -= 5 src << "You attack [m]!" If m is deleted in that 10 tick interval, you'll get a "cannot modify null.HP" error. Adding this line: if (!m) return //if there is no m, stop right after the sleep() will prevent this. If you want to prevent players from logging out to cheat death in a losing battle, you can make it so that logging out doesn't instantly remove their mob from the game... make it linger for 15 or 30 seconds (unprotected), then save and delete. This way, anyone who's got attacks pending against them can still get their shots in. This is the approach I'm taking in Imperial Realms, which is more-or-less turn based, and attacks take are resolved the turn after they're initiated. When a player logs out, their mob remains completely in the world for one turn (so, you can't attack and then log out before anyone has a chance to counterattack), and then remains in the world but "off screen" for another turn, then is deleted and saved. The purpose of the second turn is to allow any attacks started in the first turn to be resolved. | |
I am also using deadron's character handling library; I don't know if that makes any difference. I had already added something like what you said about returning procs after sleeping if the player logs out, but I still need to modify the player's stats. You'd talked of a way to make it so that a player doesn't immediately log out; does this work with deadron's library? I tried modifying the Logout() proc once before, but by the time it executed, the player was no longer present.
I also want to "prevent players from logging out to cheat death in a losing battle," but I want to do it by making them lose exp, gold, etc depending on when and where they log out; they can leave if they like, but they'll pay if they ever come back. I'm also trying to find a way to account for those who leave by deleting them from party lists and to end battles when the player is the only one left in a group. - Gakumerasara | |
I looked back at my code and considered the alternatives. It doesn't seem like deadron's character handling library will work well in my case. I have very little experience with saving and loading in byond; I was wondering if anyone had some block of code similar to deadron's that I could use and modify as needed for my game. If not, any other suggestions would be appreciated. Thanks, again.
- Gakumerasara | |
This is pretty rough stuff to get around, especially if you are using save files, and want to save after logout in some cases. Solving this gave me many headaches in my game.
A starting place is to keep track of the client's key name in your mobs, so that it will persist after logout.
mob/Login()
tag = client.ckey
Then in your client.logout() procedure, you want to make sure that you don't delete the mob, until you are done with it. You should still be able to manipulate the mob in any way you like. If you have a save file you need to save to, you can construct a reference to it, since you can get the client's key through the tag variable, even after they're gone.
It's not easy... good luck!