Well, considering the socket code isn't open source (and for good reason), I would like Dantom to implement a 'client lagging' feature. I've talked about this before, but nothing came about for 3 months, so I'm back again.
Client lagging, a proceedure, target.ClientLag(30), would prevent the client from _executing_ any commands for 3 seconds, all commands they sent during that time would be queued up, and executed one at a time after the 3 seconds. This would be used primarily in muds, to simulate the diku/merc/rom lagging, where you cast spells, use skills, etc., and would be lagged a certain amount of battle rounds.
Varibles for a thing so widely used as this just have too many loopholes, Trinity Star, my 'major' game at this point in time, has a variable system for skills and spells, and I am the only coder (for a few good reasons), and attempting to keep all the variables active is really hard, especially when the player can disconnect and erase temp variables, and stuff like that. Anyways, enough blabber, lemme hear what you guys think.
Polatrite, Assassin of the Sun
ID:136867
 Apr 24 2002, 4:27 am
|
|
On the other hand, if Dantom were to add queued lagging, it would be a potential disaster, with a bunch of commands coming in at once, and you processing them at a time when they no longer apply to the current game situation. This is not to mention that a soft-coded queue is easy to make and, at times, can even help *improve* lag. Haven has one. Since none of the commands in Haven use explicit targets (it's all just based on who or what's in front of you), there's no chance for error. ...Hmm, but I didn't think about saving before. I'd better rectify that at some point. =P | |
As far as saving goes, just make sure everything's a tmp variable, so it will clear. Despite what Polatrite says, unless we're talking about delays measured in minutes, players logging out and back in shouldn't be a problem... can you actually imagine a situation where this would improve a player's combat speed?
| |
Lesbian Assassin wrote:
As far as saving goes, just make sure everything's a tmp variable, so it will clear. Despite what Polatrite says, unless we're talking about delays measured in minutes, players logging out and back in shouldn't be a problem... can you actually imagine a situation where this would improve a player's combat speed? The other thing to keep in mind is that it's often better to store a "ticks left" value that is decremented rather than a time value. That way people can log back in and their delays are exactly the same as they were before. In Living&Dead, many items have a recharge time after being used. If you log out and back in, the recharge continues on with the exact same amount of time left. | |
If any of you have played an old-fashioned textmud, you'll know what I'm talking about. We are talking a real-time swinging combat system like in Dan, of Dantom's mud starting kit.
I managed to incorporate skills and spells in, but I have quite a few problems (Please, check out Trinity sometime, it will give you a better idea of what's going on). First off, a player can be in a battle, and logout in the middle, and rather than 'deadlinking' the player, so they continue fighting. Instead it does the deletion process, which means the character gets saved, and since battle is a temporary variable, the player gets put out of battle. This means they can be getting totally railed and escape at any time. This is really nasty, especially in player killing. By adding an actual lagging function, which I assume wouldn't be too complicated, you could better achieve a mudding feel, and simplify things. I am very concerned about CPU usage, and running loops for every command for every online character is going to tear your ram apart. Whereas a simple proceedure that would lag them only when called, would be so much simpler. Also, I could use a little help on how to fix up my logout, basically to change the PC into an NPC if he/she/it doesn't use the proper 'quit' verb. Polatrite, Assassin of the Sun | |
/Polatrite wrote:
If any of you have played an old-fashioned textmud, you'll know what I'm talking about. We are talking a real-time swinging combat system like in Dan, of Dantom's mud starting kit. Yes, I know what you're talking about. Do you? I really don't think so... I mean, you know in regards to the external effect upon a game, but as far as what goes on between the scenes, you're obviously confused. 'deadlinking' the player, so they continue fighting. You're describing the default behavior! The difference between a "PC" and an "NPC" is that an "NPC" has no player connected to it... if a player disconnects, nothing happens except that the player's mob loses its client. Anything else, deleting/saving, happens only because YOU have got coded functions in that tell it to happen. If you only want deletion and saving to occur when the player types the "quit" verb, move that behavior out of mob/Logout() and into the quit verb. You might consider adding something that makes "deadlinked" players delete/save after a certain delay, or if no one's engaging them in combat, but that's really all you need. As far as action delays go... this is something best (and quite easily) handled in an individual game's code. The way your game handles "actions" is going to be quite different from the way my game handles them, even if they're both stock-style text MUDs and even if the end result printed on the screen looks the same, because we're going to have different behind the scenes mechanics. A hard-coded system is going to be inflexible by its very nature, which is contrary to the concept of BYOND. If you just want all actions to be delayed X ticks (Why, I might ask? I don't think you've really thought this scenario through...), just add sleep(X) to the beginning of your verbs. If what you mean is like making a verb called kick() that can only be used every three seconds, make an associative list, called var/tmp/list/action_delays For every combat verb that has a delay between uses, at the start of the code, check to see if action_delays[name of action] <= world.time If not, stop or wait until it is. If so, continue with the verb, and set action_delays[name_of_action] = world.time + desired delay. It's really not that hard, and adds next to nothing to your CPU use. Your concern falls under the same heading as those people who ask for "macro protection". It's your job as coder to decide how the server will interpret commands from players... that includes how fast and how often it will accept them. | |
Polatrite wrote:
I am very concerned about CPU usage, and running loops for every command for every online character is going to tear your ram apart. No, it will *save* you time if implemented properly. Check out the simple loop demo: byond://Deadron.SimpleLoop Everything you are talking about is easily handled on your side, with the proper architecture. BYOND cannot save you from a bad architecture by some scheme of lagging commands. From your description, it sounds like you need to step back and think about your architecture more, and learn how the systems you are using work (such as whichever saving/logout system you are using). You having a promising start on your game, so I'm sure you'll be willing to take a couple of days to learn some improved approaches and find out more about how logout works and such. Either way, we can't tell you how to fix things like your saving/logout system unless you say which library you are using, or post the code you are using. | |
CPU usage. I've had this problem. Try runnin' any loops outside the porc ie. Don't have the loop runnin' itself, use while to run it outside (where it was called from the first place)
Da_Rushyo | |
Da_Rushyo wrote:
Try runnin' any loops outside the porc ie. Don't have the loop runnin' itself, use while to run it outside (where it was called from the first place) I have no idea what that says. Seriously. | |
It says:
"Don't place the loop in the target proc. Instead, place the loop in an outside proc that calls the targeted proc." Essentially your event loop...lol | |
You need to do it yourself...and there aren't too many loopholes if all player actions are controlled by a central event loop. This is very simple to do...if it weren't, people wouldn't be able to control movement speed or anything else central like that.
At the top of an event loop, you just check the last time they did something compared to the current time, and skip that tick if it's too soon.
On the other hand, if Dantom were to add queued lagging, it would be a potential disaster, with a bunch of commands coming in at once, and you processing them at a time when they no longer apply to the current game situation.