27 Jul, 2011, Tonitrus wrote in the 61st comment:
Votes: 0
kiasyn said:
!voteban Ravra?

Seriously, this information is so misleading it borders on trolling.


Please.

P.S. When will there be a mudbytes ignore option?
27 Jul, 2011, Runter wrote in the 62nd comment:
Votes: 0
Tonitrus said:
kiasyn said:
!voteban Ravra?

Seriously, this information is so misleading it borders on trolling.


Please.

P.S. When will there be a mudbytes ignore option?


Heh, hopefully he's joking about the ban. I don't think Rarva is trolling.
27 Jul, 2011, Tonitrus wrote in the 63rd comment:
Votes: 0
KaVir said:
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?
27 Jul, 2011, Kayle wrote in the 64th comment:
Votes: 0
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?

Tonitrus said:
kiasyn said:
!voteban Ravra?

Seriously, this information is so misleading it borders on trolling.


Please.


Seconded.
27 Jul, 2011, KaVir wrote in the 65th comment:
Votes: 0
Tonitrus said:
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:
Votes: 0
27 Jul, 2011, Vigud wrote in the 67th comment:
Votes: 0
David Haley said:
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…
27 Jul, 2011, Vigud wrote in the 69th comment:
Votes: 0
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.
27 Jul, 2011, Runter wrote in the 70th comment:
Votes: 0
Vigud said:
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.
28 Jul, 2011, Kjwah wrote in the 71st comment:
Votes: 0
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.
28 Jul, 2011, Dean wrote in the 72nd comment:
Votes: 0
On any MUD I was running with a playerbase, I'd be wanting to look into what was causing item duplication (if it were happening) lickety split.
60.0/72