26 Jul, 2011, KaVir wrote in the 41st comment:
Votes: 0
Rarva.Riendf said:
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.

I just logged onto your mud, Rarva. Twice:

<20hp 20m 100mv 100xp>
Marrik winks suggestively.

<20hp 20m 100mv 100xp> emote has a twin!
Marrik has a twin!

<20hp 20m 100mv 100xp> who
[ Human IMP N] [AFK] Mulet the NEWBIE.
[ Human War M] Marrik the NEWBIE.
[ Human War M] Marrik the NEWBIE.
[ 2] Mortals [ 0] Heroes [ 0] Legends [ 1] Immortal
[ 3] Total visible players
The point is that there will always be bugs, and you can only fix them after you find out about them. But that doesn't mean you can't put effort into making your mud more robust.

Rarva.Riendf said:
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 ?…

Yes. Because a mud that isn't being actively developed will stagnate, and its playerbase will drift away.

Rarva.Riendf said:
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.

It has everything to do with item duplication - it prevents it from occurring. And it's not a policy, it's a coded solution to a recognised problem.

Rarva.Riendf said:
By hearing you I can only shudder at the fact you have so many crashes that players can actually shedule items duplication.

I don't have any item duplication, because my mud prevents it. As far as crashes are concerned, at the time of writing this post my mud has been up 768 hours, 27 minutes and 16 seconds (with an average of 18.39 users online).

Do you know why my mud "crashed" 32 days ago? Because the server was switched off to add more RAM. I was supposed to be notified in advance so that I could shut the mud down cleanly, but apparently they forgot to tell me, and just switched it off. Is that a "bug"?

Fortunately I can be confident that there was no item duplication. Can you say the same about your mud?

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)

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.

There is no point doing 100 saves in a row, but that's what your proposal of saving inside obj_to_char() and obj_from_char() would do. And if the player was using 'give' instead of 'drop, it would save 200 times in a row.
26 Jul, 2011, Vatiken wrote in the 42nd comment:
Votes: 0
Okay, I think I get it now.
Dont use databases when you can use bash and grep.
Dont fix bugs when you can use bash and grep.

Correct?
26 Jul, 2011, Kayle wrote in the 43rd comment:
Votes: 0
This thread, in particular the posts made by Rarva.Riendf, have been infinitely worth the time it took me to read them, simply for the humor value. This thread is full of lulz.
26 Jul, 2011, Rarva.Riendf wrote in the 44th comment:
Votes: 0
KaVir said:
Rarva.Riendf said:
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.

I just logged onto your mud, Rarva. Twice: Nd it

And it has been noticed. Actually the kind of problem I expected since the day I scrapped the whole ROM char memory management and implemented a delayed extraction to get rid of the char looping problem. Funny still :) (will be fixed next reboot thx) Botch chars were saving in the same file. The first to disconnect would be the one screwed ;p

Quote
Yes. Because a mud that isn't being actively developed will stagnate, and its playerbase will drift away.

Sure that also why you should have a code port where you can sandbox most of the problems. And really, adding content should not imply adding code endlessly. adding a skill/spell should not make the mud crash as it should use a stable engine as well

Quote
The point is that there will always be bugs, and you can only fix them after you find out about them. But that doesn't mean you can't put effort into making your mud more robust.

I try to put more effort in fixing the most important bug first (and the mud I took over was ridden with them, not even counting the basic ROM problems), if your players think they can exploit your bugs and get away with them unnoticed I think it is a worst bug than eq duping.
Because eq duping is a minor problem to me than to be able to crash the mud at will.
Crashing the mud at will is:
-avoid a death (per pk or anything else) to itself or a friend (while in a clan war)
-annoy other people by controlling who can play or not
-make some stuff repop (if you have stuff that only pop once per instance, I do not but that is an example)
-a whole lot of other thing

For all that it is way better to put logs that can detect who and how it is done than to actually prevent every single potential exploit that could happen. If your players know that whatever they do they WILL get caught they tend to report the bugs (and you can even give them nice stuff as an incentive). It is time better spent.

Quote
Fortunately I can be confident that there was no item duplication. Can you say the same about your mud?

Dunno, there is some save mechanism in place but there were there because the mud was crashing like crazy before I took over in the first place :) And because there was also no mechanism to help a player recover its corpse alone either. And actually it is the least of my concern as if some eq is hard to get, it does not give anyone an edge you cannote overcome (I dont like eq grinding game personnaly so my game reflects it). but again it is not why I neglect item duplication. I neglect it cause I prefer to put my effort in making so any exploit is spotted instead of putting it in coding for every kind of them.

Quote
There is no point doing 100 saves in a row, but that's what your proposal of saving inside obj_to_char() and obj_from_char() would do. And if the player was using 'give' instead of 'drop, it would save 200 times in a row.

My proposal is way easier implemented though, and considering who the target is (people who cannot use gdb), has a lot more chance to work as a quick and dirty temporary fix than your better solution. but only better if the people can implement it.

Quote
Okay, I think I get it now.
Dont use databases when you can use bash and grep.
Dont fix bugs when you can use bash and grep.

Yeah, more, bash and grep are very powerful tools for many situations. especially with dealing with logs…..logs, the thing you need when debugging. But right, better code code code code code…more code mean more bugs. I prefer the KISS way, when I can do it.
26 Jul, 2011, Rarva.Riendf wrote in the 45th comment:
Votes: 0
Kayle said:
This thread, in particular the posts made by Rarva.Riendf, have been infinitely worth the time it took me to read them, simply for the humor value. This thread is full of lulz.

You are welcome :)
26 Jul, 2011, KaVir wrote in the 46th comment:
Votes: 0
Rarva.Riendf said:
Quote
Yes. Because a mud that isn't being actively developed will stagnate, and its playerbase will drift away.

Sure that also why you should have a code port where you can sandbox most of the problems.

The point I'm making is that all muds have bugs, and players will find them. You can test in a sandbox all you want, but it'll never fully prepare you for all the things the players will try.

Rarva.Riendf said:
And really, adding content should not imply adding code endlessly. adding a skill/spell should not make the mud crash as it should use a stable engine as well

New features require new code. You're not going to retain the players interest for long if all you ever add are generic skills and spells.

Rarva.Riendf said:
Because eq duping is a minor problem to me than to be able to crash the mud at will.
Crashing the mud at will is:
-avoid a death (per pk or anything else) to itself or a friend (while in a clan war)
-annoy other people by controlling who can play or not
-make some stuff repop (if you have stuff that only pop once per instance, I do not but that is an example)
-a whole lot of other thing

I strongly disagree with duplication bugs being a lesser problem. Of course crashes are a serious problem and need to be addressed, but they can usually be pinpointed very quickly with gdb, and once they're fixed you can move on.

A duplication bug (in muds with no protection against it) can be very difficult to spot, even more difficult to prove, and can have major repercussions on the gameplay long after the bug itself has been fixed.

Rarva.Riendf said:
Quote
There is no point doing 100 saves in a row, but that's what your proposal of saving inside obj_to_char() and obj_from_char() would do. And if the player was using 'give' instead of 'drop, it would save 200 times in a row.
My proposal is way easier implemented though, and considering who the target is (people who cannot use gdb), has a lot more chance to work as a quick and dirty temporary fix than your better solution. but only better if the people can implement it.

Your proposal is not a good one, sorry. Players saving hundreds of times when they drop their gear could even cause noticable lag.

Also, as I mentioned before, gdb will not help you fix a duplication bug.
26 Jul, 2011, Vatiken wrote in the 47th comment:
Votes: 0
KISS=keep it simple stupid

Agree to disagree, but I think that eliminating the problem at the source is simpler then constantly tracking logs and then tracking down the objects and the corresponding players, despite the super powers of grep.

FYI, if I was a player on a mud, especially a new player, and I had bought/traded for an item that I didn't know was duped, and then had an admin strip it from me… I would be choked, and if I didn't quit then, I would after asking "what will be done to prevent this in the future?", and receiving "grep" as a response.

Consistantly punishing innocent players for an admin's lazy coding practice is a sure fire way to shrink your codebase… But I guess you can always get remaining players to dupe themselves.
BAAA-ZING!!!
26 Jul, 2011, David Haley wrote in the 48th comment:
Votes: 0
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.
26 Jul, 2011, Rarva.Riendf wrote in the 49th comment:
Votes: 0
Quote
Agree to disagree, but I think that eliminating the problem at the source is simpler then constantly tracking logs and then tracking down the objects and the corresponding players, despite the super powers of grep.

I am eliminating the problem at the source, in eliminating way to allow duping items in the first place….
And about constantly…really constantly ? Hell Kavir showed it:one UNEXPECTED crash in 32 daya…you call that 'constantly' ? Get real….

Quote
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.

Fixing bugs is what make your code safe….implementing smart logs helps make your code safe. Coding test unit cases makes your code safe. All that is better time spent than trying to put band aid for any kind of exploit a crash can lead to. (duplicating items is as I showed, only ONE of the possible exploit of a crash) and not the worst, depending on your game goals.

Quote
Your proposal is not a good one, sorry. Players saving hundreds of times when they drop their gear could even cause noticable lag.

And you are exagerating to make your point (and I said a long time ago it could be disk intensive anyway, so there is not even an argument as I agree)…, as players do not dump or give hundred of stuff in a general case….
26 Jul, 2011, KaVir wrote in the 50th comment:
Votes: 0
Rarva.Riendf said:
Quote
Your proposal is not a good one, sorry. Players saving hundreds of times when they drop their gear could even cause noticable lag.

And you are exagerating to make your point (and I said a long time ago it could be disk intensive anyway, so there is not even an argument as I agree)…, as players do not dump or give hundred of stuff in a general case….

It's not at all uncommon for players to type things like "drop all", "get all.bread", "give all.potions bubba", etc, in a typical mud.

Furthermore, if the excessive saving were enough to cause lag on the server, players would use it repeatedly - either as a combat tactic, or just to annoy each other.
26 Jul, 2011, Rarva.Riendf wrote in the 51st comment:
Votes: 0
Quote
It's not at all uncommon for players to type things like "drop all", "get all.bread", "give all.potions bubba", etc, in a typical mud.

With hundred of stuff at the same times…Man you can carry a shitload of stuff :P

Quote
furthermore, if the excessive saving were enough to cause lag on the server, players would use it repeatedly - either as a combat tactic, or just to annoy each other.

Funny you implemented sheating but allow players to give stuff while fighting. Or you mean someone else using it to make a fight of a friend slower(but I do not see the point as it will lag for everyone anyway. Baffles me again.

Again I do not see why you keep arguing about it, as I already said your solution was better, that mine could be disk intensive so it is only a temporary but EASY fix.
26 Jul, 2011, Vatiken wrote in the 52nd comment:
Votes: 0
Rarva.Riendf said:
Quote
Agree to disagree, but I think that eliminating the problem at the source is simpler then constantly tracking logs and then tracking down the objects and the corresponding players, despite the super powers of grep.

I am eliminating the problem at the source, in eliminating way to allow duping items in the first place….
And about constantly…really constantly ? Hell Kavir showed it:one UNEXPECTED crash in 32 daya…you call that 'constantly' ? Get real….

But that's not cutting out the problem at its source, that is simply patching the players current access to your dupe bug until they find another. Kind of like a putting a band-aid on it.

And ONE crash in 32 days was on Kavir's mud, in which he has protection against duping.
And, I'm not an admin on kavir's mud so I don't know for certain, but he probably had to look up that information. Which may of taken a minute or a second, I don't know. You on the other hand, will need to have someone CONSTANTLY monitoring your muds status, as any crash bug left unnoticed for more then an hour could lead to some massive duping exploitation.
26 Jul, 2011, Runter wrote in the 53rd comment:
Votes: 0
How are you going to search through the pfiles when I've spread around a bunch of duped coins, quest points, or some other transferable resource without id numbers? What if I just rollback failures like missing a backstab on a tough npc until I get a good init off and get gear that your system says is legit? Do I really need to go through the gamut of things people can do that grep won't work to detect?
26 Jul, 2011, Rarva.Riendf wrote in the 54th comment:
Votes: 0
Quote
But that's not cutting out the problem at its source, that is simply patching the players current access to your dupe bug until they find another. Kind of like a putting a band-aid on it.

It is like saying that instead of concentrating on fixing the buffer overflow in the OS you should fix the application that triggered it. Ya know what…pretty much anybody with a brain agree to fix the OS first….


Quote
And ONE crash in 32 days was on Kavir's mud, in which he has protection against duping.
protection against duping does not help a single second in avoiding crash. On the contrary players dont even have an incentive to make it crash so they dont look for any bugs. You know what, that is called security by obscurity.

Quote
And, I'm not an admin on kavir's mud so I don't know for certain, but he probably had to look up that information. Which may of taken a minute or a second, I don't know.

Knowing for how long a process has been running is like 1 second: tail xxxx.log…..
xxx.log being the last one….

Quote
You on the other hand, will need to have someone CONSTANTLY monitoring your muds status, as any crash bug left unnoticed for more then an hour could lead to some massive duping exploitation.

What have you missed in the fact that
1:I know exactly when the mud crash. That is what log are for
2:I know exactly why the mud crash (unless it is a heap problem that gives no core dump, but in this case, it means there is an insidious bugs I missed with Valgrind and that is hard to replicate for a player) AND I start logging any players action (it is automatic, a crash means next boot all logs are on till I disable them)
3:massive dupe exploitation will be spotted and dealt with so no player has any incentive to do it….
4:my game does not crash so frequently that I have to look for it.

Probably every point as you keep talking about hypotetical cases to justify you pov that duping is the real problem (when it is not, because the course of action is crash->dupe, and not dupe while game is running fine)
26 Jul, 2011, Rarva.Riendf wrote in the 55th comment:
Votes: 0
Quote
How are you going to search through the pfiles when I've spread around a bunch of duped coins, quest points, or some other transferable resource without id numbers?

Because every action is logged, so what is the problem you are looking for an id in a database, I am looking for any action that can lead to a change in inventory in a char (not that many)

Quote
What if I just rollback failures like missing a backstab on a tough npc until I get a good init off and get gear that your system says i legit?

That means you are the one (or a friend) exploiting the crash instead of reporting it…ooo you naughty…..what the hell are you all missing in I LOG EVERYTHING A PLAYER DO AFTER A CRASH. (I know who is logged at any single time as well)

Quote
Do I really need to go through the gamut of things people can do that grep won't work to detect?

Yep cause you have not given anything that I could not find with very simple grep on a playername. So keep amusing me.
26 Jul, 2011, Runter wrote in the 56th comment:
Votes: 0
What are you missing about actions in the log not telling you how to determine what is legitimate and what is not? So what, you find a player who cheated. How do you determine who after that point made legitimate deals with me and who did not? Like if I (With illgotten gains) tell someone if they run me for xp for 3 hours I'll give them some absurd amount of gold. They do it. As an administrator you now have to deal with all of these legitimate trades and the consequences of these resources being spread around. And believe me, the players are *not* going to understand when you start confiscating stuff.

So what the hell are you missing, exactly? Pretty much everyone on this forum has told you the same thing. Policing this exploit after the fact is not an acceptable strategy. It Shouldn't Be Possible In The First Place. That's not a band-aide. That's a bulletproof assertion.
26 Jul, 2011, KaVir wrote in the 57th comment:
Votes: 0
Rarva.Riendf said:
Quote
It's not at all uncommon for players to type things like "drop all", "get all.bread", "give all.potions bubba", etc, in a typical mud.

With hundred of stuff at the same times…Man you can carry a shitload of stuff :P

I've played muds where people carried hundreds of potions.

Rarva.Riendf said:
Quote
furthermore, if the excessive saving were enough to cause lag on the server, players would use it repeatedly - either as a combat tactic, or just to annoy each other.

Funny you implemented sheating but allow players to give stuff while fighting. Or you mean someone else using it to make a fight of a friend slower(but I do not see the point as it will lag for everyone anyway. Baffles me again.

It would lag for everyone, effectively pausing the mud for a moment. Players could use that time to queue up some commands. If the game used the system clock for any timers (eg recovering from using specific abilities) this would allow you to speed them up relative to combat. You could also use it to drive off the competition - set up a bot to make the mud really laggy for half an hour or so, then when everyone else has quit in frustration you can have the best hunting grounds to yourself.

You could actually turn it into a little social experiment. Add a 'lag' command that freezes the entire mud for a few seconds, and give everyone anonymous access to it. See how often it gets used.

And no, on my mud you can't simply give things to other people unless they choose to accept them. But this isn't about my mud - I don't have problems with duplication bugs.

Rarva.Riendf said:
Again I do not see why you keep arguing about it, as I already said your solution was better, that mine could be disk intensive so it is only a temporary but EASY fix.

I disagree with your proposal being a viable solution, even as a temporary fix. If the mud doesn't have any staff capable of coding a dirty flag, then I would seriously question their decision to operate at all.

Vatiken said:
And ONE crash in 32 days was on Kavir's mud, in which he has protection against duping.

I put the word "crash" in quotes, because it was actually some guy switching off the physical machine so that he could plug in some extra RAM. Of course if I used the standard Diku approach to saving then it's possible some gear might have vanished or been duplicated - but I don't.

Actually I used to get players from Diku muds complaining that there was no "save" command. So I told them to type "alias add save display Ok.", and they seemed happy after that.

Rarva.Riendf said:
Probably every point as you keep talking about hypotetical cases to justify you pov that duping is the real problem (when it is not, because the course of action is crash->dupe, and not dupe while game is running fine)

Runter already gave one example of how equipment can be duplicated without crashing the mud. I've encountered at least one other.
26 Jul, 2011, Runter wrote in the 58th comment:
Votes: 0
Quote
I LOG EVERYTHING A PLAYER DO


It just occurred to me. Your mud must be called Big Brother Mud.
27 Jul, 2011, kiasyn wrote in the 59th comment:
Votes: 0
!voteban Ravra?

Seriously, this information is so misleading it borders on trolling.
27 Jul, 2011, Rarva.Riendf wrote in the 60th comment:
Votes: 0
Quote
I disagree with your proposal being a viable solution, even as a temporary fix. If the mud doesn't have any staff capable of coding a dirty flag, then I would seriously question their decision to operate at all.

A lot of muds works with people who only copy snippets or modifying variables here and there without understanding how it works. Adding one save_char in a method is ok for them. Adding a dirty_inventory flag in char_data, and understanding the code workflow well enough to use is in every method that can modify inventory would need a full 'how to' manual for them.

Quote
Actually I used to get players from Diku muds complaining that there was no "save" command. So I told them to type "alias add save display Ok.", and they seemed happy after that.

Just rofl….

Quote
It just occurred to me. Your mud must be called Big Brother Mud.

Don't be jealous you cannot do it because you coded a full relational database into a rom instead of logging tools.


And anyway it is not only duplicating items you should have to think about. Everything that is not saved when there is a change in a char is a problem. Stats, spell affect, position, charmies. You are only concentrating on this cause your muds probably rely on items economy. Items duplication is only so important in this case.
40.0/72