Follower items on floor turn into jewelry boxes in DB internalname

[GilesSmith]

Get some follower items (I just went onto AH, set filters to all follower items, rare, level 59 - max buyout 2,000) - log in, open DB, and go to town. Make DB output the "Internalnames" for them.

All fine.

Now drop all the follower items. Pick them all up again. Make DB output the "Internalnames" again.

Every single follower item is now listed as "Jewelbox_Flippy-xxx" (xxx = number) - the internalname I believe for those small jewelry boxes that can drop the story-giving scrolls and little bits of gold.

Also happens if a monster drops a follower-item - it's immediately considered to be a JewelBox with internalname.

Only happens to follower items (as far as I can see). Happens to all follower items. Happens every time I've tried it, with every follower item.

 

[Apoc]

And this is relevant how?

Use the ItemType. If that doesn't match up, then I'll look into it. (Names shouldn't be used for categorizing anything. Period.)

 

[GilesSmith]

And this is relevant how?
Use the ItemType. If that doesn't match up, then I'll look into it. (Names shouldn't be used for categorizing anything. Period.)

Because I am a developer that uses itemname for a plugin I created with many users, and this is the developers forum for making requests, asking for support, or reporting bugs, and this is a bug that has been introduced with new versions of DB and wasn't present before.

Are you refusing to fix this or look into this because you don't use itemname, or don't like my plugins, or don't like how I do my plugins?

I'm very, very confused with this reply.

This feels like a direct slap in my face, and a slap in the face to a community dev from a DemonBuddy dev. Have I done something horrible to offend you?

 

[darkfriend77]

Apoc ... from openbot and bgbot isxwow ^^ ??? still the same unfriendly selfish developper ^^?? hehehhe gz darkfriend from earlier days ^^

 

[Kane49_2]

I'm very, very confused with this reply.

Hes telling you that you should not differentiate items using internal item names.
Maybe the itemtype is not, not read correctly but wrong in the game as well.
Remember that i told you that using the internal name is more of a workaround than a solution in irc,
because if you think about it your only "guessing" the itemtype etc from the internalname instead of simply reading it.

There is however the big but that this only applies as long as the itemtype is now read correctly most of the time unlike previous Demonbuddy versions where it worked on like 2% of items , if it is not he was incredibly rude

 

[Apoc]

I didn't mean for my post to be rude. However, using the internal name as a categorization technique is the wrong way to do things. I realize you used it to work around our lack of item detection in previous versions, however that support has since been fixed fully. (At least as far as I'm aware)

The internal name is really nothing anybody should be using as a way to determine what something is, as its mostly a "useless" field other than for MPQ file lookups, etc. We have not changed anything in regards to reading item names, or more or less anything item related (as far as the memory wrappers are concerned), so this is likely something introduced in the client (or server) recently. You should be using ItemType regardless, as it's not only cached, but provides a faster (and easier) way to tell what an item type is.

I'm not going to try and convince you to change your plugin, however, if the ItemType matches correctly, it's not something I'll be putting high on my priority list of things to fix. If it doesn't match, then I'll definitely look into it, as something may have changed. However, the internal name changing, isn't something we can "fix" as we don't even use any special handling to retrieve that value. We read it directly out of the item's structure in memory.

 

[GilesSmith]

Apoc, I tried going back to using the DemonBuddy API - but new versions of DB do exactly the same as old versions. At random, they just give in and start reporting completely invalid data for loads of items - seems to happen after many runs/after a period of time, and at random. When it happens, the internalname value remains valid (correct) on all items, but the DemonBuddy values (itemtype, istwoslot, name, etc. - all the "commondata" stuff other than internalname) goes all to hell and causes infinite stash loops. Here's a log output from Latest stash replacer which was trying to use DB API to recognize item types;

[05:57:58.672 D] [GilesStashReplacer 1.9.1] GSError: DemonBuddy thinks this item is 2 slot even though it's at bottom row of a stash page: Mythic Health Potion [healthPotion_Mythic-78] type=Bracers @ slot 30/5
[05:57:58.678 D] [GilesStashReplacer 1.9.1] GSError: DemonBuddy thinks this item is 2 slot even though it's at bottom row of a stash page: Mythic Health Potion [healthPotion_Mythic-101] type=Mace @ slot 20/7
[05:57:58.680 D] [GilesStashReplacer 1.9.1] GSError: DemonBuddy thinks this item is 2 slot even though it's at bottom row of a stash page: Exquisite Essence [Crafting_Tier_04B-110] type=Sword @ slot 30/2
[05:57:58.682 D] [GilesStashReplacer 1.9.1] GSError: DemonBuddy thinks this item is 2 slot even though it's at bottom row of a stash page: {c:ffffff00}Plan: Exalted Sovereign Mail (5){/c} [CraftingPlan_Smith_Drop-114] type=Pants @ slot 30/4
[05:57:58.684 D] [GilesStashReplacer 1.9.1] GSError: DemonBuddy thinks this item is 2 slot even though it's at bottom row of a stash page: {c:ffffff00}Plan: Exalted Sovereign Helm (5){/c} [CraftingPlan_Smith_Drop-119] type=Shoulders @ slot 10/6
[05:57:58.685 D] [GilesStashReplacer 1.9.1] GSError: DemonBuddy thinks this item is 2 slot even though it's at bottom row of a stash page: Hideous Meridian [Ring_23-122] type=Gloves @ slot 10/2
[05:57:58.685 D] [GilesStashReplacer 1.9.1] GSError: DemonBuddy thinks this item is 2 slot even though it's at bottom row of a stash page: Exquisite Essence [Crafting_Tier_04B-123] type=Boots @ slot 30/1
[05:57:58.695 D] [GilesStashReplacer 1.9.1] GSError: DemonBuddy thinks this item is 2 slot even though it's at bottom row of a stash page: {c:ffffff00}Plan: Exalted Dread Shield (6){/c} [CraftingPlan_Smith_Drop-163] type=Shield @ slot 30/7
[05:57:58.699 D] [GilesStashReplacer 1.9.1] GSError: DemonBuddy thinks this item is 2 slot even though it's at bottom row of a stash page: Glory Hold [Ring_21-177] type=Boots @ slot 10/3

Note: These items were all at the bottom of a stash page, so couldn't be 2-slot items. The internalnames were correct for them all. The "itemtype" was not (which is output above).

This was one of the original reasons I abandoned the DB API initially, because it would just randomly stop working altogether - the bug still seems to exist.

So far I don't have a cause for you if you are unable to track this down. For whatever reasons, the above bug never affected the "internalname" - any idea why? Is that data for internalname read separately/first/last? Stored somewhere else? Some code that edits those other stats and is bugging them out isn't trying to edit internalname? Some function updates all item stats but doesn't update internalname which was only read once and remained valid? Do you need me to write a really really simple plugin that monitors your stash and backpack and whenever it finds a conflict (ie whenever DB seems to be getting the itemtypes wrong), posts a load of messages for you?

This was why I'd originally made the plugin and used my own item recognition code - and to date, other than the oddness with the follower items being seen as "jewelboxes" after being dropped to the ground above, had always remained stable/static and so at least a helm was always seen as a helm etc.

I'd be happy to use the DB API but right now, the DB item API still has some serious root issues with it.

Help?