5 - Mobs aren't always counted when looting
What steps will reproduce the problem?
1. I cannot reliably reproduce this. It seems to happen randomly, though may be at least partly caused by multiple mob loots in a small area.
What is the expected output? What do you see instead?
Each loot of a new mob should increase the loot counter as well as add the new loot items to the list. In some (relatively rare) cases, the loot counter does not increase. When this happens, about half of the time, no loot is added to the list and the other half of the time, the loot is added. When no loot is added, it's not really a big deal other than loss of stats on that looted mob. However, when loot IS added, but the counter isn't increased, it throws off the percentages. Of course, given a large enough pool of loot data, that will be minimal. But for anyone using only their own loot data, it can be noticeable.
What version of the product are you using?
MI3 v0.801 (also seen in MI2 versions)
Do you have an error log of what happened?
No actual errors, so no.
Please provide any additional information below.
As I mentioned, this may be related to multiple mob loots from a small area, if MobInfo doesn't think they are different mobs or something. However, there have been times when the mobs were well-spaced and still had that problem. An easy way to see when this happens is when you're killing mobs for a quest and have to kill a certain number and haven't killed them before, or else you need to loot a certain number of items and you haven't looted those items before. When you finish and compare the number of items you've looted or the number of mobs you've killed and MobInfo doesn't match up with the quest data, you know something wasn't counted. A good test for this would probably be the quests in Nagrand where you have to kill all of the neutral animals for the hunter guy with the name similar to Ernest Hemingway (same guy who is in Stranglethorn).
| User | When | Change |
|---|---|---|
| riamus2 | Thu, 08 Jan 2009 01:01:39 | Create |
- 3 comments
- 3 comments
- #3
Speeddymon Sun, 27 Sep 2009 00:08:52This goes hand in hand with the 0/0c value bug.
- #2
riamus2 Tue, 11 Aug 2009 14:44:21Ok, after scanning the code, I found the following functions: MI3_GetCorpseId() MI3_StoreCorpseId() MI3_CheckForCorpseReopen()
These functions prevent duplicate loot data when reopening a corpse. They also cause this error, where the same loot for the corpse as that of an earlier loot prevent counting the data. Right now, it stores the "Corpse ID" as the loot information and then compares that to see if it's the same corpse. Of course, if 2 corpses drop 1 linen cloth and nothing else, then they have the same corpse ID. I see a few ways this can be changed to improve the loot counting.
1) As a very minor (though easy) improvement, you can add the mobname or ID number *AND* mob level to this "corpse ID" value. The mobname/ID shouldn't really matter, but it might. The level should matter, though. It should make it so that if different level mobs drop the same thing, they'll still be counted. This only really makes a very small difference as it's still one count for the same data for each level of the mob, but that's better than only one count for all mob levels. It's only a minor improvement, but it's at least something and should be very easy to do.
2) Include the coordinates of the corpse in the "corpse ID". Then, when checking to see if the corpse is reopened, compare the coordinates with the player's current location and give a range of 1,1 in all directions from the original corpse location (in case the player moved and is in a different location, but can still reach the corpse). As long as the player is within 1,1 of the original loot location and the loot data is the same, consider it to be reopened. Otherwise, treat it as a new corpse as the same corpse can't be in two places at once. This can still "miss" data if the corpses are really close together, but it's at least something.
3) Implement a "clear old data" method for corpses so that it stores only the last X corpses or only stores corpses for X seconds. This will limit the problem to only corpses opened close together rather than all corpses until logging off. Not a perfect solution on its own, but still helps.
4) If it's possible to know if the corpse is completely looted (checking if the window is automatically closed or if the last item is taken by the player or something like that), then delete the corpseID from the list of opened corpses. If it's already looted completely, then any corpse opened after that with items in it is new and can be counted. The issue here is that a party member looting it will not remove the corpse ID. Still, even in a party, you tend to share loots, so eventually, you could end up removing it by taking the loot.
These are just some examples. Any of them would help and including all would probably prevent a LOT of missed loot data. Any other ideas to improve this "reopened corpse" code would also be helpful.
- #1
riamus2 Tue, 24 Mar 2009 03:26:32Ok, so after a lot of watching this bug, I believe it's caused by the part of the code that prevents getting duplicate drop info if you open the same mob multiple times. Right now, if you get exactly the same loot dropped from a mob, it will eventually stop counting those drops. It seems to count the same loot drop for a bit before stopping, but eventually it does stop counting if the loot is the exact same items (if it has money, the money also has to be the exact amount, which is why you rarely get missing counts off mobs with money). I haven't really tried, but this may start counting again if you log off or exit the game between. Either way, I'm sure that it is caused by that duplicate preventer thing. I'm not sure if something can be done with that to adjust the sensitivity a bit. Perhaps also have it check your current coords and if you're within 1,1 in any direction, don't count if it's duplicate, but anything beyond that it will count. Or something. I'm not sure, but it definitely needs fixed.