[Plugin] Giles World Object Handler

[Bazingaw]

I want to report a bug with the version 1.7, it is blacklisting loot (for example iLVL 61+ rares) because of unknown object type.

See screenshot:
View attachment 52730
snip from Dump RActors:
[00:11:24.437 N] [2EC410A0] Type: Player Name: Barbarian_Male-5 ActorSNO: 3301, Distance: 0
[00:11:24.453 N] [2EC480D8] Type: Item Name: Gloves_norm_base_flippy-7724 ActorSNO: 4264
[00:11:24.470 N] [2EC5C0E0] Type: Item Name: Bracers_norm_base_06-7728 ActorSNO: 56328
[00:11:24.486 N] [2EC48928] Type: Item Name: shoulderPads_norm_base_flippy-7737 ActorSNO: 5288
[00:11:24.503 N] [2EC47460] Type: Unit Name: Hireling_Enchantress-39 ActorSNO: 4482, Distance: 9.216996
[00:11:24.519 N] [2EC52718] Type: Unit Name: FallenGrunt_C-5073 ActorSNO: 4084, Distance: 9.958313
[00:11:24.536 N] [2EC52B40] Type: Unit Name: FallenGrunt_C-5075 ActorSNO: 4084, Distance: 10.04665

I have a question: This issue is caused by DB misreading the item right and not this plugin? Which would mean with or without this plugin it would still not loot it am I correct in saying this?

edit: call me crazy but disabling object handler running act 2 over the past hr or so it seems like more items, logs show no form of item blacklisting/ignoring (any unmatched to rules seem to be matched through name)

 

[Bazingaw]

Just wanted to post and double check a possible fix.

Say we open up GilesWorldObjectHandler.cs and look for the IsValid Item function, and say below the check for the DiaObject name matching minimap, we add the following

	    string glovename = thisobject.Name.ToLower();
	    if (thisname.StarsWith("glove"))
	    {
		return true;
	    }

This should technically force the item to match up by name and be marked as a lootable even if its turning up as an unknown type no? If that is the case then we could fix this problem semi by adding multiple item name check types.

 

[GilesSmith]

Just wanted to post and double check a possible fix.
This should technically force the item to match up by name and be marked as a lootable even if its turning up as an unknown type no? If that is the case then we could fix this problem semi by adding multiple item name check types.

No because DemonBuddy is still reading game balance data from items to give items their item type, their quality, their item level in variables - and these are the values that must be correct for an item to be picked up.

Since DB seems to corrupt these/mess these up with alarming frequency (maybe 1 in every 200 items?), then quite often items that are ACTUALLY, say, a rare ilvl 61 glove, might be being read by DB as a crafting page.

DB seems worst at legendary/set items - they seem the most likely to cause DB to mis-read, which Apoc mentioned to me once is because legendary/set items have very weird "flags" (or something).

 

[Bazingaw]

Ahh right thanks for clearing it up

 

[theatristformallyknownasG]

No because DemonBuddy is still reading game balance data from items to give items their item type, their quality, their item level in variables - and these are the values that must be correct for an item to be picked up.

Since DB seems to corrupt these/mess these up with alarming frequency (maybe 1 in every 200 items?), then quite often items that are ACTUALLY, say, a rare ilvl 61 glove, might be being read by DB as a crafting page.

DB seems worst at legendary/set items - they seem the most likely to cause DB to mis-read, which Apoc mentioned to me once is because legendary/set items have very weird "flags" (or something).

Welcome back, missed you long time

G

 

[Geckoz]

Why couldn't potions have a weird flag so I could get more legendaries?

 

[lypnn]

Since DB seems to corrupt these/mess these up with alarming frequency (maybe 1 in every 200 items?), then quite often items that are ACTUALLY, say, a rare ilvl 61 glove, might be being read by DB as a crafting page.

Actually its not a problem of demonbuddy, from my D3A time I know that the actor table is a mess, so its the D3 client. But the real problem comes from your plugin blacklisting every "unknown object" for 10 min although in the next second the object type would have been filled out correctly. You can see this in my bug report: the type in the dump is "Item" right after it got blacklisted for not being an Item.

Everyone who is looking for a quick fix: comment out line 283 and 284

 

[hetsig]

Actually its not a problem of demonbuddy, from my D3A time I know that the actor table is a mess, so its the D3 client. But the real problem comes from your plugin blacklisting every "unknown object" for 10 min although in the next second the object type would have been filled out correctly. You can see this in my bug report: the type in the dump is "Item" right after it got blacklisted for not being an Item.

Everyone who is looking for a quick fix: comment out line 283 and 284

Giles could you comment on this? Dont wanna do anything that can mess it up

 

[GilesSmith]

Giles could you comment on this? Dont wanna do anything that can mess it up

Yeah lypnn is certainly right there does seem to be issue with item data randomly screwing up one moment then not the next. The new plugin I'm bringing out this week already fixes this (with a combination of changing how it handles items, reads them, caching of a lot of data that can be cached, how it actually interacts with items on floor, dealing with avoidance, etc. etc.) - but a quick-fix in the mean time would be to do exactly as lypnn suggested. It just means it'll KEEP re-trying the same items/keep checking them each loop. That shouldn't cause any problems in theory, but I suppose if something really *DOES* screw up from DB and remains screwed up it could possibly get you stuck on an item/crash your client (should be rare if it happens at all) - without handling things better as the new plugin will be doing.

(unlike lypnn though I have no experience at other stuff that has tried to read Diablo 3 memory - so as far as I was aware it is simply DemonBuddy mis-reading things, obviously I have no way of knowing whether it's Diablo 3 memory that is wrong or Demonbuddy's reading of that memory that is wrong! )

 

[hetsig]

Actually its not a problem of demonbuddy, from my D3A time I know that the actor table is a mess, so its the D3 client. But the real problem comes from your plugin blacklisting every "unknown object" for 10 min although in the next second the object type would have been filled out correctly. You can see this in my bug report: the type in the dump is "Item" right after it got blacklisted for not being an Item.

Everyone who is looking for a quick fix: comment out line 283 and 284

Ok so just wanna make sure I did this right. It is in the worldobjecthandler you should do this?

 

[JoeC]

I believe Lypnn was referring to these lines:

{
                Logging.WriteDiagnostic("[WorldObjectHandler] Blacklisting a minimap icon [" + thisobject.CommonData.Name + "] SNO=" + iThisObjectSNO.ToString());
                Blacklist.Add(iThisObjectGUID, BlacklistFlags.Loot, TimeSpan.FromMinutes(10.0));
                return false;
            }

 

[lypnn]

GilesWorldObjectHandler.cs

            //Logging.WriteDiagnostic("[WorldObjectHandler] Blacklisting a world object [" + thisobject.CommonData.Name + "] because it was an unknown object type.");
            //Blacklist.Add(thisobject, BlacklistFlags.Loot, TimeSpan.FromMinutes(10.0));

make sure you don't comment out any more lines like the return statement, so only those two lines.

 

[hetsig]

GilesWorldObjectHandler.cs

            //Logging.WriteDiagnostic("[WorldObjectHandler] Blacklisting a world object [" + thisobject.CommonData.Name + "] because it was an unknown object type.");
            //Blacklist.Add(thisobject, BlacklistFlags.Loot, TimeSpan.FromMinutes(10.0));

make sure you don't comment out any more lines like the return statement, so only those two lines.

Thanks a lot! Been running for a couple of hours now and Ive been getting like 5-6 more rares per hour than I used to

 

[JoeC]

Giles stated he will be putting out a consolidated profile which should include most if not all of these fixes.