26 Jul, 2011, Runter wrote in the 21st comment:
Votes: 0
http://en.wikipedia.org/wiki/Software_bu...

http://en.wikipedia.org/wiki/Software_bu... said:
A software bug is the common term used to describe an error, flaw, mistake, failure, or fault in a computer program or system that produces an incorrect or unexpected result, or causes it to behave in unintended ways.


How is something a player does a bug? Are they part of the software you're writing? The fact it can still happen by accident makes it clearly a bug. The fact it can happen at all makes it clearly a bug. Do you really want to argue against the understood semantics of a long-standing term like a "bug" in software to make your point? Cause you haven't once said the downside to making your system bulletproof from duping. You just keep going back to a tired argument about what is or isn't to be considered a bug.
26 Jul, 2011, Vatiken wrote in the 22nd comment:
Votes: 0
If I toss all my equipment to an alternate storage character and after he saves and quits a hurricane knocks out the server's host and ends up duplicating the gear, would you not consider that a bug?
26 Jul, 2011, Rarva.Riendf wrote in the 23rd comment:
Votes: 0
You can call it whatever you want, the bug is the crash, the rest of the code works fine. A character save, give item the other save, game crash.
Were there ANY bug in item giving or saving method ? nope. Was there any unexpected result ? nope it was totally expected, hence why the player can do it….
So not there is no duplication bug at all.

Quote
Cause you haven't once said the downside to making your system bulletproof from duping.

Yep I did, but it flied way over your head.
Anytime you produce code, you can produce bug, so producing code to prevent something that can only happen when SOMETHING ELSE is not behaving properly is the best way to produce even more way to it to happen. And you then you have to maintain it. (and read logs, cause hey, I suppose you have log to actually check when your band aid code kicks in to actually fix where it belong RIGHT ?)
Sure you can say I ignore the 'bug' so it may happen even with me not knowing it…. (well maybe just maybe that if eq got duplicated, I woudl have a hint since I can know exactly how many instance of any items is present…(be it online/offline)) but I do not have this tool because of duplicating items 'bugs'….
But I cannot win against that argument. It is like a linux user saying every windows user that dont have any anti virus is virused while HE is virus free because he is on linux.
26 Jul, 2011, Rarva.Riendf wrote in the 24th comment:
Votes: 0
Vatiken said:
If I toss all my equipment to an alternate storage character and after he saves and quits a hurricane knocks out the server's host and ends up duplicating the gear, would you not consider that a bug?

Are we talking about a ROM game, free to play with few players, or a banking system ? I would say there are more important stuff to do in a ROM code than to take time to fix this 'problem'.
But you are free to consider this problem more important than fixing the fact that a player can crash your game whenever he wants without waiting:
1:for the hurricane
2:pray to do it at the right moment….
26 Jul, 2011, Runter wrote in the 25th comment:
Votes: 0
Are you going to write code that prevents the server from shutting down unexpected? How do you fix that "bug"? This was a thread with someone pointing out that item duplication is a serious problem, and that they don't even know how it's occurring. You're giving people bad advice on this forum over and over. I don't know why you find you have to defend whatever you happen to think is most convenient for yourself as best practices, but there's a basic assertion here with regard to the design of the program: State should not be rewindable through crash, shutdown, reboot, or any other means other than perhaps immortal intervention. You're making a ridiculous claim that it should be policed after the fact instead of absolutely upholding that assertion to be absolutely true with code. When you can't even ensure you know how/when it will occur in the future. Yes, we all know you write perfect code, but did you not read the original post? It's not just items. It's values. It's state of the player. That stuff doesn't have "id numbers" to test against. Frankly, nothing you have said here has been advanced enough to have "flied way over" my head.
26 Jul, 2011, Zeno wrote in the 26th comment:
Votes: 0
Quote
Are you going to write code that prevents the server from shutting down unexpected?

I played on a MUD where the code would catch a crash and do a copyover instead of letting it crash.

Horrible idea though.
26 Jul, 2011, Runter wrote in the 27th comment:
Votes: 0
Zeno said:
Quote
Are you going to write code that prevents the server from shutting down unexpected?

I played on a MUD where the code would catch a crash and do a copyover instead of letting it crash.

Horrible idea though.


I'm more talking about the hardware-server actually just shutting off unexpectedly. By Rarva's logic the bug is the server turning off (which isn't even part of the code) and the consequence to this bug may be state duplication regression.

edit: Duplication isn't really the issue. It's rewinding state. Imagine trying to set up an automated system to catch a player who bets a lot of gold on a casino game and regresses his state (maybe accidentally!) when he loses. Then he tries again. Nothing was duped, but the consequence of not having a bulletproof system where rewinds can't happen is a huge problem, with no gain for letting it stand, really. Other than maybe you can be lazier and roll the dice that it never happens.
26 Jul, 2011, Rarva.Riendf wrote in the 28th comment:
Votes: 0
Quote
Are you going to write code that prevents the server from shutting down unexpected? How do you fix that "bug"?

Are you going to code a way for a database to not be screwed over while in the middle of IO and a disk crashing, the server being hit by an electric surge etc?
Yes ? Oh wait…doubt it…you cannot as ROM is not something you can distribute on many servers (and that use flat files per default anyway).

So stop giving me crap for something you cannot handle right with a ROM anyway, at best you can mitigate the effect at the cost of time that should be better spent elsewhere. (like learning how to use gdb to fix the goddam REAL bug)

Quote
this was a thread with someone pointing out that item duplication is a serious problem, and that they don't even know how it's occurring.

Err wait they do know: game crashes at will from a player…that is how the items got duplicated…(did you forget that part ?)

Quote
You're giving people bad advice on this forum over and over.

I would say the same from you, as I find your advices usually inadequate to the context, though very true in other fields. But I am not as childish as you to call them wrong. It is all about ROI with time spent coding something instead of another. You are mostly always thinking 'it worth it in the long run' without ever thinking that this long run may never happen because you change of paradigm. In the long run your code should be so stable anything you did about item duplication have any use.
26 Jul, 2011, Runter wrote in the 29th comment:
Votes: 0
Quote
Are you going to code a way for a database to not be screwed over while in the middle of IO and a disk crashing


Yeap. I'd say that's a minimal goal. Is that not a problem you've solved? Figures.

So are you going to write code that prevents the bug of the server shutting down unexpectedly from happening or not? Since you insist that something outside of the programs control is the real bug.
26 Jul, 2011, Rarva.Riendf wrote in the 30th comment:
Votes: 0
At this point I just laugh when you just said you implemented a totally fool proof way of storing data without any corruption even in case of hardware failure (on a single server even)….I admit I cannot piss that far, you win.
26 Jul, 2011, Runter wrote in the 31st comment:
Votes: 0
Rarva.Riendf said:
At this point I just laugh when you just said you implemented a totally fool proof way of storing data without any corruption even in case of hardware failure (on a single server even)….I admit I cannot piss that far, you win.


I guess you aren't going to answer my questions that I keep asking over and over. I hope other readers can see that you have absolutely no basis in reality for your argument you're making other than perhaps defending the superiority of your own bad practices.

Well, it's no surprise, really, that you'd hand wave here some more without even answer the questions I ask you directly. Since you were the one arguing against a proper database in other threads, and here discounting the appealing properties of using a proper database. Like transactions. Lol, what if the earth gets hit by a meteor, how is your data going to be saved?!?!. There's a big difference between losing the physical property where the database is saved in preventing IO errors from corrupting the store. I'll leave the readers to figure out which one is very common.

Is it that you just think the status quo of diku is the holy grail of design? Or is it that you are just that ignorant of the way other people are solving these problems?
26 Jul, 2011, Vatiken wrote in the 32nd comment:
Votes: 0
The problem with the MUD in question is not that players are crashing it to take advantage of item duplication, but the fact that the mud features a DUPE bug through an abrubt server halt, that in this case is caused by players. It could however be caused by numerous other ways which may significantly alter the game experience intended for the players. If you run a game of any type which can be signifacantly impacted by an event out of your control, then it is your responsibility to do all you can to eliminate or reduce the damage. Whether that be through bug fixes, back ups, unique ids, or one of many other possibilities. Turning a blind eye to a known problem because it "shouldn't"happen, even though it can is just bad coding practice.
26 Jul, 2011, Rarva.Riendf wrote in the 33rd comment:
Votes: 0
Quote
Is it that you just think the status quo of diku is the holy grail of design? Or is it that you are just that ignorant of the way other people are solving these problems?

I am the one smart enough to realise that people that have problem finding how to solve an easily replicated bug better start learning using gdb before adding even more code they do not really understand how it works in the first place. And smart enough to not compare a Diku context to an online store context. And since it is not the first time we have this discussion, I also guess it will not be the last. You can keep your 'I have better code practice than you' or 'holier than you' crusade if you wish so. I do not have the time to do so, best luck to you if you also have the time to apply them to the code you do as a hobby.
26 Jul, 2011, Rarva.Riendf wrote in the 34th comment:
Votes: 0
Vatiken said:
The problem with the MUD in question is not that players are crashing it to take advantage of item duplication,

Yeah right the fact a player can prevent other to play at will, or forever by just triggering his client to do it even when not in front of his computer is not the main problem….at all….and that you should take time to prevent duplicating items first cause well, THAT is what matters….(when the mud cannot even be played since a player can still make the game crash since you did not solved the crash bug)….

Sorry I cannot understand this kind of screwed priorities…..
26 Jul, 2011, Runter wrote in the 35th comment:
Votes: 0
Rarva.Riendf said:
Vatiken said:
The problem with the MUD in question is not that players are crashing it to take advantage of item duplication,

Yeah right the fact a player can prevent other to play at will, or forever by just triggering his client to do it even when not in front of his computer is not the main problem….at all….and that you should take time to prevent duplicating items first cause well, THAT is what matters….(when the mud cannot even be played since a player can still make the game crash since you did not solved the crash bug)….

Sorry I cannot understand this kind of screwed priorities…..


Crashes will happen.
They shouldn't result in inconsistent state when they do.
What's screwed up about that?
26 Jul, 2011, Vatiken wrote in the 36th comment:
Votes: 0
As previously stated "crashes happen", fixing this one crashes' cause will only temporarily fix the problem since the underlying issue still exists and the next time a player finds a crash bug, EXPLOIT!
26 Jul, 2011, Rarva.Riendf wrote in the 37th comment:
Votes: 0
How often do your game crashes, and even better how often in an easily replicated by player cases ? That baffles me if you think it is more important toput band aid to fix a side effect than to make the game stable …
26 Jul, 2011, Rarva.Riendf wrote in the 38th comment:
Votes: 0
Heh which of you is Marrik ;p. Wonder what kind exploit you could do with that, if any. Thanks for noticing.
26 Jul, 2011, Vatiken wrote in the 39th comment:
Votes: 0
Rarva.Riendf said:
How often do your game crashes, and even better how often in an easily replicated by player cases ? That baffles me if you think it is more important toput band aid to fix a side effect than to make the game stable …


I think you're missing the point, of course you fix the crash bug, that's obvious, but the duping opprotunity is the bigger issue. What if I discovered a crash bug on your mud at 2am and exploited it repeatedly to produce 100 "unique sword of kills everything", then sold them to players in your game? Ban me, sure, but now are you going to through your entire pbase and strip the weapons from everyone? Will you be able to refund them the money they paid me? What about the original that someone had got in a legal way? Can you tell that one from the rest? Etc.. Etc.. Etc..

A crash would result in a minor inconvience.
A duping scenario could end in a major clusterf***.
26 Jul, 2011, Rarva.Riendf wrote in the 40th comment:
Votes: 0
Quote
I think you're missing the point,

I think you miss mine heh.

Quote
What if I discovered a crash bug on your mud at 2am and exploited it repeatedly to produce 100 "unique sword of kills everything",

It means some crashes in a row..at this point I log every player action per default. But for debugging purpose in general. Eq duping is a minor problem at this point.

Quote
then sold them to players in your game? Ban me, sure, but now are you going to through your entire pbase and strip the weapons from everyone?

See above, not a real problem a simple grep on any player name complaining about it would give me all I need. And for grinning pleasure, I tend to dislike people who willingly take advantage of a bug even if indirectly…that is a simple policy that led to the mud being relatively bug free as they know I know.

BTW Runter (probably) just discovered a bug :p Someone created a char with the same name twice, as my check_reconnect method had a flaw. As I said better fix the problem where it belongs.
20.0/72