Murder Count Bug [RC0]

[XxSP1DERxX]

As everyone probably knows.. there is a feature missing (or an exploit standing, depending on how you look at it). Where a player can rack up counts on another, causing the other player to go red and get guard whacked. This is a problem because on OSI, you can only give one count to a person every 5 minutes.

Two questions about this.. first off is there a fix planned to be released with the next version? And next, if I wanted to fix this now, which approach should I take.

If i use timers, then there could be a timer going for every two-person combination on the shard (theoretically). And you can see the potential problem in a CTF or shard-wide event where players are subjected to killing each other numerous times. If timers are not used, the next optionj would be a murder count pool just as the first option would have, except using a struct. The struct has the datetime of count given, and the person who gave the count. Everytime someone is killed, the countpool is checked and if the datetime is less than 5 minutes from current time, then another count cannot be given. If it is more, than a count can be given, and the datetime is updated. Which comes back to the point that the first has intensive CPU (potentially), while the second has potential memory. To alleviate the memory on the second option, upon save, all instances of the struct in each person's pool which is older than 5 minutes would be deleted.

Anybody have any ideas on this? Or a better approach to fixing this.


EDIT:

To give an idea of what I mean -
Using timers with a 150 person CTF, there could be up to 22,500 timers (realistically around 7500-10,000) all in arraylists. These would last 5 minutes each...
Using structs with a 150 person CTF, plus whatever happens after that until the next worldsave, would be over 30,000 instances of the struct (realistically around 10,000-12,500) all in arraylists. These would last until the next worldsave.

Which is worse on resources?

[mikelezz]

Perhaps I'm gonna say a stupid thing.
Set a "on", "off" property for every players. Every murder count anyone give to another, his state (I'm speaking of the one who has been murdered) change from "on" to "off" so he can't give another one.
Every 5 minutes (but i think 6 fits better) there is a check to all players, if they are "on", nothing happens, if they are "off", automatically their state is changed to "on" so they can give another murder count.. and so..

[XxSP1DERxX]

The idea is that lets say there are 3 players

Player A kills Player B
Player B gives a count to Player A
Player A kills Player C
Player C gives a count to Player A
Player A kills Player B
Player B cannot give a count to player A for 5 minutes..

with your idea.. Player C cannot give a count to Player A.. which is not how OSI works :\ Although for simplicity, it would be alot less overhead/resources.

[Phantom]

Yes its planned I am sure, as its on UO Gamers now.

[XxSP1DERxX]

Which method are they using? The idea where a player cannot receive counts from ANYONE for 5 minutes... or the idea where they cannot receive counts from that other particular player?

[XxSP1DERxX]

Fuck this post... just lock it. Obviously nobody cares about accuracy to OSI, or resource count so it doesn't matter. I will just do it the way mikelezz mentioned (my first idea before the accuracy took precidence).

[DuGrand]

put a array in the palyermobile with a timer.

The reciving player should be tracking who and when the count was given,
then have the script giving the count check the playermobile.
This will not use mutch resource. just make sure you stop and or remove the timer and array when the array itself is empty.

if your a good scripter it should be easy to make, if not then check party.cs most of the code is already in there.

anyway hope this help.

[XxSP1DERxX]

The problem is....
lets say there is a CTF, and there are 150 players. Every player will have up to 149 timers, so thats 149 * 149 timers. That IS alot of resources and WILL lag a production shard with heavy volumes of players.

Its not the fact of how to do it... I know how, its the question of which method will use the least resources possible when events are taking place and massive amounts of people are killing each other at once.

[EUORoadkill]

I don't see why you need a timer at all. You are only concerned with two pieces of data per kill:
1. WHEN did the death/murder/count take place?
2. WHO gave the count

Now, when someone kills a player, you check their arraylist of kills/count times and who:
1. is the top of stack > 5 min old? If YES, allow murder report. If NO then:
2. is the murder count from YOU? If YES, disallow the murdercount, done. If NO then:
3. Next item in the arraylist, repeat.

The array list should not have to be too long, how many people can you kill in 5 minutes? On saves, just record data that is < 5 minutes old.

I would expect that for most players, most of the time (99%) the data would contain zero elements. A few folks will have a count within last 5 minutes.

During big wars, CTF maybe, you may see a few UberKillers who perhaps kill someone every 30 seconds, so you get a stack of 10items in the array, two data pieces in each. 20 properties max probably for a very few super killers.

I don't think that woud in any way lag a shard or consume memory, the total system is < the amount of data held by 4 spawned creatures. No timers, ONLY timestamps saved, which are checked.

[Tannis]

EUO, this post is 10 months old.

[EUORoadkill]

True. But after searching the entire site, every forum, for every post containing the word "murder" and reading every one of them...
... and looking for answers to a specific bug that we have found in the runUO core concerning reporting of murders, BY attackers against Defenders...
... and not knowing enough to provide an intelligent solution to it yet...
... this was the closest thread I could find to the particular areas of interest. And since no one ELSE has posted an answer to this pertinent question, and Spider is still around and very active, I decided the best thing to do was stay inside an existing thread, and talk to someone knowledgeable who appeared to be interested in the same area as me, who by now likely had some insight that would help me.

If anyone had posted anything more useful on the reporting, counting, and manipulation of Murder Counts since this post, I probably would have started there. But having read every post on the forums concerning murders, several hours later this appears to me to be the best lead. See? There WAS a method to it

[Memnoch]

Hell of a justification. I would have just taken you at your word if you would have said "i'm trying to fix a problem no one else has looked into for almost a year."

[XxSP1DERxX]

Not really it was already fixed in 1.0.0

EUO what you proposed was already talked about in the initial thread. I don't know if I mentioned but on a technical scale, you would have to write a custom IComparable to compare the struct values of the list to find a relevent one for the person you killed again. Blah blah, it doesn't matter now, it was fixed. If you want me to explain the approach used by the devs then tell me, and I will look up the code and tell you. If I remember correctly they didn't use timers.

[EUORoadkill]

Thx Xxsp1derxX. Hiyas Memnoch! Well, since you're looking, and I still couldn't figure it out yesterday, I'll post what our problem is.

There is a problem with the fact that an attacker stays grey to his attackee for 5 minutes, but the res-kill 5-minute protection has been removed, which allows anyone to ATTACK this guy AFTER he dies, and then give him a count. Before judging the fairness of that, please read the scenario below:

If Bob attacks Susan, he goes grey. Fine. Susan kills Bob, fine, no count can be given. Bob is criminal for two min, after which he can rezz, but he is STILL GREY TO SUSAN (and others) FOR 5 Minutes. Now, on OSI there is a 5 minute timer during which murder reports cannot be repeated. Let's say Bob had won and Susan reported him. Bob takes a count, but if Bob rezkills susan for the next 5 minutes, she can only give him one count.

Ok that isn't too fair, and on RunUO it doesn't work that way. Here, after the KILL and the REPORT/MURDER COUNT, it is a "New Game New Day". If you murder again you take another kill.... but the grey timer doesn't match this! Follow along.

Bob, the evil agressor, is now dead, having attacked susan and been defeated. 2 min later Bob resses and decides that is enough, he wants his stuff and he's leaving. He made his attack, he lost, he didn't kill anyone, and he paid his price--death. Bob goes to his corpse... where Susan is waiting. Bob is GREY to susan for another 3 minutes. Susan ATTACKS BOB!! Bob DEFENDS HIMSELF. He only wants to get his stuff, NOT lose more insurance, and haul booty. Susan, the Vengeful Rez-Ganking griefer, LOSES. Bob successfully defends himself against her AGGRESIVE ATTACK. BUT... Susan gets the opportunity to give him a count! Why? Because Susan was blue and Bob showed Grey to her.

The 5 minute Grey timer MUST be reset to make it a FAIR, "New Game New Day" after a resurrection, if we are not going to allow free res killing. There should be NO "free murder counts" either, when YOU are the AGGRESSOR against a newly ressed dude.

In a big battle where people are fighting, quickly rezzing by nearby healer and jumping back in the battle, this scenario plays out MANY TIMES. People were dying, healer right there, ressing, and anyone that was Grey was being attacked-- and those greys then got murder counts if they defended themselves successfully. They should never have been grey after they originally died, waited 2 min for criminal, and rezzed.

1. The problem is NOT the 2 minute criminal timer, we must be sure to maintain that.
2. The problem is the individual "grey to one person" 5 minute timer that is not being reset after Death.


Ok. THAT is what we are trying to fix. I've been looking in two areas, the playermobile.cs, and again in the reportmurderergump.cs, and it seems to me that on line 42 or so of the reportmurderergump.cs that there is some comparison going on of attacker and attackee. But my real problem is getting rid of that 5 min grey timer OnDeath somehow.

Any ideas? And thanks for reading !

[XxSP1DERxX]

Yes you are correct... to simplify it he is saying

A attacks B and A looses
A is now grey to B
A is ressed
B attacks A because A is grey and B looses
B gives count to A

B should not be able to give a count to A since an aggressor should never be able to give a count for losing a battle they started. I will look into this as a possible bug. I suggest you put this on the bug tracker if this is indeed a bug with the distro system. This would be a different bug than the murder count bug of RC0.

To fix this is not a matter of resetting timers or anything. Its a simple aggressor check.

[autumntwilight]

It's like that on OSI though... or was last time I played it... Pretty sure...