26 Jul, 2011, Kellendros wrote in the 1st comment:
Votes: 0
Okay, this isn't something I'm trying to do myself, I'm just wondering .. I play a mud where when the mud crashes it loads player files from a backup.. and there's a certain player, that if I could tell the Immortals how he's doing it, keeps crashing the mud and duplicating items, quest points, gold, everything. The mud also has a crafting system that has random output variables for things like hitroll, average damage, and damroll on weapons and armor, it's sort of obvious that he's duplicating them because at one point he had 13 weapons with the exact same stats. If I knew how, or even could figure it out myself, we could get the Immortals to fix it.. wherever it is. Does anyone here have any ideas on how it could be done?
26 Jul, 2011, plamzi wrote in the 2nd comment:
Votes: 0
Hi,

If the mud doesn't have a coder on-board who is capable of tracking down and fixing crash bugs, that's bad news. If there's anyone capable enough to edit the code, they can try to put a few lines that will log everything that a player types in. Then, based on the last player input before crash, they can try to reproduce the crash (if it's indeed malicious), post details here, and maybe get more assistance. But really, this takes (as a bare minimum) some coding skills and code access. It doesn't sound like you have either.

Of course, the proper way to do this is for a coder to examine a core dump file using a debugger like "gdb". You can try to pass this information on to one, but they either already know it, or (since this has been happening for a while) debugging is beyond their present ability.
26 Jul, 2011, KaVir wrote in the 3rd comment:
Votes: 0
The more serious problem here isn't the crash bug, but the fact that equipment can be duplicated. The crash bug obviously needs to be fixed as well, but as long as it's possible to duplicate equipment when the mud crashes, the player will continue looking for other ways to exploit it.

This was once a fairly common problem, but I believe most modern muds have addressed it. It usually works like this:

Character A saves, then gives all his equipment to character B. Character B saves. One of the characters then causes the mud to crash. After the crash, both characters are restored to their last saved state - therefore they each have a copy of the same equipment.

The easiest solution is to autosave both characters whenever equipment is transferred. Assigning a unique ID to each item would also allow you to identify duplicates.
26 Jul, 2011, Rarva.Riendf wrote in the 4th comment:
Votes: 0
As Plamzi said the more serious problem is there is not a coder willing to fix the bug in the first place. Especially when the bug is easy to replicate. So I doubt your proposed solution ever get to them KaVir.
26 Jul, 2011, KaVir wrote in the 5th comment:
Votes: 0
He said he could get the immortals to fix it if he knew how it was done. All he has to do is point the immortals at this thread.
26 Jul, 2011, Rarva.Riendf wrote in the 6th comment:
Votes: 0
Quote
He said he could get the immortals to fix it if he knew how it was done. All he has to do is point the immortals at this thread.

And suddenly they will be able to code your proposition while they cannot even use gdb to find the bug in the first place. Yeah right :p

obj_to_char and obj_from_char should be where the save method is implemented. But I think this is as a poor solution as it makes a lot of disk access. Same for implementing a unique id for items. Make so it does not crash is way more efficient. Not like it is impossible to achieve with a mud. All the rest is band aid on a wood leg because
1:it adds code, thus add possibilities for bugs
2:use diskIO for no other reason that you cannot fix other problems
3:does not solve the real problem
26 Jul, 2011, kiasyn wrote in the 7th comment:
Votes: 0
Rarva.Riendf said:
Quote
He said he could get the immortals to fix it if he knew how it was done. All he has to do is point the immortals at this thread.

And suddenly they will be able to code your proposition while they cannot even use gdb to find the bug in the first place. Yeah right :p

obj_to_char and obj_from_char should be where the save method is implemented. But I think this is as a poor solution as it makes a lot of disk access. Same for implementing a unique id for items. Make so it does not crash is way more efficient. Not like it is impossible to achieve with a mud. All the rest is band aid on a wood leg because
1:it adds code, thus add possibilities for bugs
2:use diskIO for no other reason that you cannot fix other problems
3:does not solve the real problem


there are 2 problems here, the duping and the crashing.

the duping is more important because OTHER bugs can also cause the duping, as well as other problems that may not be picked up on.
the crashing should also be fixed though, of course.
26 Jul, 2011, KaVir wrote in the 8th comment:
Votes: 0
Gdb can be very helpful for tracking down crash bugs, but it won't help resolve the item duplication - and that is by far the more serious bug. Crashes are annoying, but they're only disruptive until they've been fixed. A duplication bug can have a much longer-lasting impact however, and in extreme cases can even destroy the in-game economy by flooding the market with untraceable ubergear.

If all you fix is the crash bug, it'll only be a temporary reprieve. The next time the player finds a way to crash the mud, he'll immediately start duplicating equipment again. What are you going to do about all that ubergear flooding the market? Without unique IDs you can't even tell for sure which items are duplicates, and you're going to be facing this same problem every time another crash bug appears.

obj_to_char() and obj_from_char() are not the appropriate places to do the saving, although you might choose to set a dirty flag in those functions and then have some sort of SaveUpdate() that saves everyone who has a dirty flag. Or if you want something really quick and easy, just do a save whenever you get, drop, give, etc - this approach isn't so nice though, as you'd need to make sure you caught every possible case, including disarms and such.
26 Jul, 2011, Rarva.Riendf wrote in the 9th comment:
Votes: 0
Quote
the duping is more important because OTHER bugs can also cause the duping, as well as other problems that may not be picked up on.

A matter of opinion, I do not see how you can dupe item without a crash in ROM code, (though I am willling to hear it) and I prefer to solve real problems than the consequences (and deal with people that exploit those bugs, as gdb will show who crashed the mud).

Quote
If all you fix is the crash bug, it'll only be a temporary reprieve. The next time the player finds a way to crash the mud, he'll immediately start duplicating equipment again. What are you going to do about all that ubergear flooding the market?

Deal with the player…

Quote
Without unique IDs you can't even tell for sure which items are duplicates, and you're going to be facing this same problem every time another crash bug appears.

Fix the REAL bug, deal with players exploiting it. Eventually your mud is bug free, without having a code cluttered by band aid. (and dont tell me a mud cannot be bug free….)

Quote
obj_to_char() and obj_from_char() are not the appropriate places to do the saving

Tell me why, as you should always go through those function anytime an object leave or goto player
26 Jul, 2011, Runter wrote in the 10th comment:
Votes: 0
Quote
A matter of opinion, I do not see how you can dupe item without a crash in ROM code, (though I am willling to hear it) and I prefer to solve real problems than the consequences (and deal with people that exploit those bugs, as gdb will show who crashed the mud).


This is nonsense. If you want to deal with real problems then solve the fact that any time your game crashes (or the server gets rebooted, or goes down unexpected, or the process is terminated) that players could have duplicated equipment. Even worse, it could have happened unknowingly. The "consequences" of not solving this real problem is having to do what you're proposing. And if you think it's easy to undo duplication once it happens you are wrong. The gear usually gets spread throughout the playerbase, your image as an admin looks terrible (and keystone copish) in the way you are going to have to administrate it, and no players (honest or otherwise) will have much faith in your ability to keep the game legit. After the first time it happens there will be tales and allegations of cheating against every honestly successful player on your game. If you want a surefire way to screw your game up then let something as glaring as an item duplication exploit stay possible and keep hand-waving it away.
26 Jul, 2011, Rarva.Riendf wrote in the 11th comment:
Votes: 0
Quote
This is nonsense. If you want to deal with real problems then solve the fact that any time your game crashes (or the server gets rebooted, or goes down unexpected, or the process is terminated)

crashes: Sorry but my game does not crash so frequently and so easily that duping items can even become a problem. Maybe because I actually fix bugs instead of putting band aid…
Reboot:all players are made stand still and saved…(if it goes down unexpected->ie a crash, either of a game or the whole server…and if it is the whole server…player cannot really exploit it since it is well….unexpected by everyone)

Quote
Even worse, it could have happened unknowingly.

Err nope…at all, a ROM mud is a simple enough program to handle the whole logic of it, (not multithreaded)

Quote
If you want a surefire way to screw your game up then let something as glaring as an item duplication exploit stay possible and keep hand-waving it away.

A surest way is to have a game that you can exploit/crash so easily/frequently that you have to put code against equipment duplication….

And all this actually only matters if your mud if your mud fun rely on eq grinding.
26 Jul, 2011, KaVir wrote in the 12th comment:
Votes: 0
Rarva.Riendf said:
Quote
If all you fix is the crash bug, it'll only be a temporary reprieve. The next time the player finds a way to crash the mud, he'll immediately start duplicating equipment again. What are you going to do about all that ubergear flooding the market?

Deal with the player…

I'd rather fix bugs than waste my time punishing people for exploiting them.

Furthermore, in this case you might not be able to discover who was responsible. You might not even know the bug is being exploited at all.

I've also duplicated items by accident in the past, and I've had it work the other way as well - I give an item to someone, save, the mud crashes before they save, and the item is lost. Are you going to reimburse players for equipment lost in crashes? How will you know if they're telling the truth about what they lost?

Rarva.Riendf said:
Quote
Without unique IDs you can't even tell for sure which items are duplicates, and you're going to be facing this same problem every time another crash bug appears.

Fix the REAL bug, deal with players exploiting it. Eventually your mud is bug free, without having a code cluttered by band aid. (and dont tell me a mud cannot be bug free….)

A mud cannot be bug free. Particularly one that's still undergoing active development. There are two "real bugs" in this thread, one is a crash, the other is duplication. Both need to be addressed, but that doesn't mean you won't have more bugs in the future.

Rarva.Riendf said:
Quote
obj_to_char() and obj_from_char() are not the appropriate places to do the saving

Tell me why, as you should always go through those function anytime an object leave or goto player

Do you really want to save the pfile 100 times in a row just because you dropped 100 potions on the floor?
26 Jul, 2011, Runter wrote in the 13th comment:
Votes: 0
I hate to break it to you, but item duplication is a bug. And you're suggesting not fixing it, and instead telling people to just not exploit it who play your game. That, sir, is worse than a bandaid. Yes, if only we could all be like you and write a game that never crashes, on a server that never reboots, with admins that never accidentally kill processes. Then we wouldn't have to take time to design our games properly, either. /sarcasm

And since we're on the topic, it's very possible to exploit item dup bugs without crashing the game. It all depends on what and where the "bandaids" are to keep players from doing it. I've been on many a diku where you could dup items by sitting at login prompt and finishing logging in to disconnect a previous socket. It would have the player file in the state it was when you first hit the login prompt. Not the same thing, you say? Well, yes it is. It all has to do with when files were saved vs when the state on the login has them. If you have no bulletproof way of knowing items cannot be duped the bug is going to keep reappearing in places, perhaps in places you never considered putting an actual bandaid on.
26 Jul, 2011, Rarva.Riendf wrote in the 14th comment:
Votes: 0
Quote
I hate to break it to you, but item duplication is a bug.

I hate to break it to you but it is the result of exploiting another bug. So no the item duplication is not a bug at all in itself unless it actually happens without any other bug. (and then it would not be a 'bug' but more of a logic problem)

Quote
I've been on many a diku where you could dup items by sitting at login prompt and finishing logging in to disconnect a previous socket.

Yep a common logic problem of many Diku….hint, fix it….A char should be unique, sockets is only a variable.

Quote
If you have no bulletproof way of knowing items cannot be duped the bug is going to keep reappearing in places, perhaps in places you never considered putting an actual bandaid on.

Again it is not a bug, the real bug is the one that permits duplication. And it is not about putting bandaid everywhere to prevent it, but simply to fix the actual bugs.

Quote
A mud cannot be bug free.

A ROM one can pretty much be. Not complex enough to be.

Quote
Particularly one that's still undergoing active development.

If it is active development, ok, but is item duplication by players a problem when you are in a development stage ?…


Quote
I've also duplicated items by accident in the past, and I've had it work the other way as well - I give an item to someone, save, the mud crashes before they save, and the item is lost. Are you going to reimburse players for equipment lost in crashes? How will you know if they're telling the truth about what they lost?

In this case, that has nothing to do with any bugs but about when you automatically make the player save.
It is a policy:you can make it everytime there is an inventory change, or every xxx seconds etc. That has nothing to do with item duplication.

By hearing you I can only shudder at the fact you have so many crashes that players can actually shedule items duplication. Or get away with it….Or so much complexity about dealing with inventory you cannot even check all cases…


Quote
Do you really want to save the pfile 100 times in a row just because you dropped 100 potions on the floor?

Then you make a tradeof, it could crash at the 50s potion…(that is why I said it was too diskIO intensive, but that if you really wanted to be perfect about it, it should be there)
26 Jul, 2011, Runter wrote in the 15th comment:
Votes: 0
Rarva said:
Blah blah … bug isn't really a bug … [handwave]… blah blah…I'm a fail coder … Blah blah blah
26 Jul, 2011, Vigud wrote in the 16th comment:
Votes: 0
Kellendros said:
Okay, this isn't something I'm trying to do myself, I'm just wondering .. I play a mud where when the mud crashes it loads player files from a backup.. and there's a certain player, that if I could tell the Immortals how he's doing it, keeps crashing the mud and duplicating items, quest points, gold, everything. The mud also has a crafting system that has random output variables for things like hitroll, average damage, and damroll on weapons and armor, it's sort of obvious that he's duplicating them because at one point he had 13 weapons with the exact same stats. If I knew how, or even could figure it out myself, we could get the Immortals to fix it.. wherever it is. Does anyone here have any ideas on how it could be done?


First and foremost, those people with access to program sources should learn how to debug it, preferably with a debugger. This will enable them to find and fix every new crash once for all. Of course, most MUDs will always have bugs (as in programming errors causing program crashes), but if you fix code that crashes the program every time a crash happens, malicious users will have to search for new ways of crashing the MUD. The program will get more stable over the time, possibly to the point when it's safe to call it a stable program.

Duplicated items are a real problem, but at the same time it's just a consequence of the program's instability. While the MUD is unstable, it's not insane to try to prevent item duplication by designing something like unique ID system, although fighting the causes of crashes alone should reduce the amount of duplicated items. It's a matter of considering pros and cons of building such system (it can help, it can't harm, but it requires time that could otherwise be spent on making the MUD more stable).

Malicious players should always be punished. Stripping all their characters from all goods, legitimate or not, should be a convenient way of reducing duplicated items, noticeable penalty (who knows, maybe they'll stop trying to find new ways of cheating just because of it?) and a clear message to legitimate players that not cheating pays off.
26 Jul, 2011, Rarva.Riendf wrote in the 17th comment:
Votes: 0
Runter said:
Rarva said:
Blah blah … bug isn't really a bug … [handwave]… blah blah…I'm a fail coder … Blah blah blah

Childish heh…at least my code is not so unstable that I have to put bandaid to cover my failures like you.
26 Jul, 2011, Vatiken wrote in the 18th comment:
Votes: 0
Rarva.Riendf said:
Quote
Do you really want to save the pfile 100 times in a row just because you dropped 100 potions on the floor?

Then you make a tradeof, it could crash at the 50s potion…(that is why I said it was too diskIO intensive, but that if you really wanted to be perfect about it, it should be there)

If I really wanted to be perfect about it, I would fix the duping bug.
26 Jul, 2011, Runter wrote in the 19th comment:
Votes: 0
Rarva.Riendf said:
Runter said:
Rarva said:
Blah blah … bug isn't really a bug … [handwave]… blah blah…I'm a fail coder … Blah blah blah

Childish heh…at least my code is not so unstable that I have to put bandaid to cover my failures like you.


For what it's worth I meant "I'm" as in "Runter's a fail coder" as in you were calling me fail. :rolleyes:
But whatever, since it's come to this I stand by my statement as written and apparently taken.
26 Jul, 2011, Rarva.Riendf wrote in the 20th comment:
Votes: 0
Vatiken said:
Rarva.Riendf said:
Quote
Do you really want to save the pfile 100 times in a row just because you dropped 100 potions on the floor?

Then you make a tradeof, it could crash at the 50s potion…(that is why I said it was too diskIO intensive, but that if you really wanted to be perfect about it, it should be there)

If I really wanted to be perfect about it, I would fix the duping bug.

Sorry but the only bug is to be able to predict when the game crash…duping is only a side effect.
0.0/72