The point of my dirty flag approach is that you're saving an overall state. Either you save me and the room before I drop the 100 potions (in which case after the crash I'll have 100 potions, and there will be none on the floor) or you save me and the room after I drop the 100 potions (in which case after the crash I'll have no potions, but there will be 100 on the floor). Regardless of when the crash occurs, there will still be 100 potions.
Out of curiosity, how does your system handle crashes that occur during the saving of "dirty" data?
Lol. Next time I'll remember the sarcasm tags. I'd really recommend this thread have a disclaimer that informs people to NOT take anything Rarva says with any kind of seriousness. Actually, can that just be a site wide disclaimer?
Out of curiosity, how does your system handle crashes that occur during the saving of "dirty" data?
A fair point. I was thinking more in the context of players deliberately causing crashes, but if you wanted to handle mid-save crashes as well I suppose you could save everything into a temporary directory and then move the files after you've successfully saved them all.
27 Jul, 2011, Rarva.Riendf wrote in the 66th comment:
This is baffling… the notion that making your code safe is a waste of time because you'll fix all bugs ahead of time is simply unrealistic at best and foolish, shortsighted at worse.
It really depends on quite a few things. Definition of "making your code safe", for example… My MUD is at the stage where there are no "unsafe" bugs, just those funny, inconvenient, unrealistic, etc. Therefore, concentrating on fixing causes of crashes is making my code safe, while adding another system (storing objects in a database, or unique ID system, or anything else) may add more complexity (thus, bugs) than safety. And, even if implemented flawlessly, it wouldn't bring too much safety to my MUD, where duplicated items - while unexpected - are completely harmless.
In my case, it would indeed be a waste of time to implement anything with purpose of preventing item duplication. But I'm not foolish enough or shortsighted enough to claim that my case is the only case in the world.
27 Jul, 2011, David Haley wrote in the 68th comment:
Votes: 0
Not sure what your point is. Code safety isn't a terribly complicated concept: it means having basic safeguards in place in the case of crashes. It means fixing root causes of bugs. It means fixing bugs in general. Code safety is more than just item duplication…
I thought by saying "making your code safe" you had "implementing an item duplication prevention" in your mind. My point was that not everyone needs it, for some people it would be a waste of time.
I thought by saying "making your code safe" you had "implementing an item duplication prevention" in your mind. My point was that not everyone needs it, for some people it would be a waste of time.
The problem isn't really item duplication. It's a serious problem associated with state rewind. But make no mistake, the problem is state rewind. Given the state in the game which interacts with each other is all as it should be at time X. If you introduce state from X-t for some parts of the game, while the rest is still time X, then without a doubt you're going to introduce errors that transcend item duplication. What if your game doesn't have items? Does that means state rewind is fine? Not at all. It's just as bad if you have state at all that must be consistent.
We need examples, so: Do you have gold? Quest points? Do you have anything transferable? Slot machines? Poker? Any time of risk/reward at all? Do you have abilities with only a chance to activate? Do you have quests with rewards that should be only obtained once? Do you have a fortune cookie mechanic where players can spin a wheel for a random daily reward? Maybe boosted experience? Do you have anything that can only be done once per amount of time? Do you have consequences for dying? Do you have rewards for killing? Do you have punishments such as revoking chat privs?
I don't know if you have any of these things, but I hope imagination could get us from here to there as to why a mud admin might have a little stake in ensuring state-rewind will not happen for *any* structure, including players.
I don't mean to be off topic with this but really? this thread is teh lulz. I do some dumb shit when I'm drunk but I don't think that is the case here. lol
By that, I mean Rarva or whatever talking teh shizzzzzzzzzzz.
Seriously, this information is so misleading it borders on trolling.
Please.
P.S. When will there be a mudbytes ignore option?