How to determine mine and herb?

[starfish99]

I know both mine and herb are gameobjects,
and their game object subtype is chest (GOT_Chest=3)
so, my program is confused with herb,mine and real chest

below is my descriptor for gameobject(delphi code)

TWOWGameObjectData = record
WOWObjectData : TWOWObjectData;
OBJECT_FIELD_CREATED_BY : TWOWGUID;
GAMEOBJECT_DISPLAYID : DWord;
GAMEOBJECT_FLAGS : DWord;
GAMEOBJECT_PARENTROTATION : Array[1..4] of DWord;
GAMEOBJECT_DYNAMIC : DWord;
GAMEOBJECT_FACTION : DWord;
GAMEOBJECT_LEVEL : DWord;
GAMEOBJECT_BYTES_1 : DWord; //SubType := thisfield shr 8
{for trap}
GAMEOBJECT_SPELLID : DWord;
GAMEOBJECT_RADIUS : Single;
end;

but GAMEOBJECT_BYTES_1 and GAMEOBJECT_FLAGS cannot tell me whether it's a herb or mine or real chest
Should I get information from GAMEOBJECT_DISPLAYID?

Another question:
After a corpse has been looted, it may be shown as minable or herbable,
I analyzed this situation, and found that, it's UNIT_FIELD_FLAGS had this mask : UNIT_FLAG_SKINNABLE = 0x04000000,
So I am confused with mineable and herbale and really skinnable for a corpse !

Appreciate for any help!

[Cypher]

Lol, delphi.

Use the model of the object. Call the GetModelName VMT func or pull out the DisplayId of the gameobject and look up the model in the DBCs, then check using that whether it's a herb or mine. You only need to check one string because all the objects of each type start with the same thing...

It's like __MININGNODE__\\ or something. Can't remember and too lazy to open VS and check. It's easy to do on your own.

[starfish99]

yes, I did it before,
Getting a gameobject's name and parsing string may be possible to find out mine and herb with English client, but it fails when using other language clients, such as chinese,korean,etc.

Just now I found an interesting function :
0x0059BE00 : GetUnitSkinType (3.1.3 9947)
it's Unit Object's memeber function, and it returns the skin type of a unit's corpse
0 - UNIT_SKINNABLE_LEATHER
1 - UNIT_SKINNABLE_HERB
2 - UNIT_SKINNABLE_ROCK
3 - UNIT_SKINNABLE_BOLTS

but this function can't resolve my problem of determine a mine or herb for a gameobject.

[Cypher]

yes, I did it before,
Getting a gameobject's name and parsing string may be possible to find out mine and herb with English client, but it fails when using other language clients, such as chinese,korean,etc.

Just now I found an interesting function :
0x0059BE00 : GetUnitSkinType
it's Unit Object's memeber function, and it returns the skin type of a unit's corpse
0 - UNIT_SKINNABLE_LEATHER
1 - UNIT_SKINNABLE_HERB
2 - UNIT_SKINNABLE_ROCK
3 - UNIT_SKINNABLE_BOLTS

but this function can't resolve my problem of determine a mine or herb for a gameobject.

Non-english clients are for those crazy foreigners I couldn't care less about.

(i.e. I have no idea because I've always used models. Sorry.)

[starfish99]

Non-english clients are for those crazy foreigners I couldn't care less about.

(i.e. I have no idea because I've always used models. Sorry.)

why you say "those crazy foreigners"?

[Cypher]

why you say "those crazy foreigners"?

Because I'm a xenophobic Australian.

inb4wutizxenophobia

[suicidity]

Just thought I might ask, are you using Unicode (For the Korean, Chinese .. etc Clients)?

[amadmonk]

Because I'm a xenophobic Australian.

inb4wutizxenophobia

Wut iz xenophobia?

Please don't use long words. I'm scared of things that are different.

To the OP: see if the GameObject VMT has a method to determine the skill required (Mining, Herbalism, etc.). That might be what you need.

A little debugging (trace from the Interact VM -- is it still 38 for GO's?) should do the trick.

[Apoc]

Hint: Model names/paths DON'T CHANGE regardless of client locale! (Eg; _MININGNODE_ remains even in CN/KR clients.) The only thing that changes, is the use of a different string index in the DBCs. (Notice how they have LOCALIZED strings?!?!)

[Cypher]

Wut iz xenophobia?

Please don't use long words. I'm scared of things that are different.

To the OP: see if the GameObject VMT has a method to determine the skill required (Mining, Herbalism, etc.). That might be what you need.

A little debugging (trace from the Interact VM -- is it still 38 for GO's?) should do the trick.

Winnarrrrr.

Pretty sure you can do skill checks with DBCs too.

[Nesox]

Just use the entry.
Lookup the ids on wowhead /?object=id
make 2 dictionaries <string,uint> name and entry then you can do something like this in your Gameobject class:

public bool Herb { get return herbDictionary.ContainsValue(Entry);
public bool Mineral { get { return mineralDictionary.ContainsValue(Entry);
public bool Node { get { return Herb || Mineral } }

now you han easily check if its à herb or à mineral, dunno how you would do it Delphi but therw should be something similiar.

[Apoc]

Just use the entry.
Lookup the ids on wowhead /?object=id
make 2 dictionaries <string,uint> name and entry then you can do something like this in your Gameobject class:

public bool Herb { get return herbDictionary.ContainsValue(Entry);
public bool Mineral { get { return mineralDictionary.ContainsValue(Entry);
public bool Node { get { return Herb || Mineral } }

now you han easily check if its à herb or à mineral, dunno how you would do it Delphi but therw should be something similiar.

NOU! Doing .Contains on ANY collection is costly! (Unless it's a hashtable, in which case, that's pretty much what it's made for)

[Nesox]

NOU! Doing .Contains on ANY collection is costly! (Unless it's a hashtable, in which case, that's pretty much what it's made for)

stop raping my posts Q_Q

[Cypher]

NOU! Doing .Contains on ANY collection is costly! (Unless it's a hashtable, in which case, that's pretty much what it's made for)

I dunno about C# but in C++ maps/sets (unhashed associative containers) are sorted at all time stored as red-black trees. This makes searching for a specific value fairly efficient, more efficient than in say a vector (unsorted sequent container -- excluding cases where you sort the vector manually). Though putting a new element into the container is more expensive because the container needs to put it in the 'right place'.

Unless you're working with extremely large data sets (which is not happening in example) I wouldn't exactly call it 'costly'.

[Apoc]

I dunno about C# but in C++ maps/sets (unhashed associative containers) are sorted at all time stored as red-black trees. This makes searching for a specific value fairly efficient, more efficient than in say a vector (unsorted sequent container -- excluding cases where you sort the vector manually). Though putting a new element into the container is more expensive because the container needs to put it in the 'right place'.

Unless you're working with extremely large data sets (which is not happening in example) I wouldn't exactly call it 'costly'.

It's a non-ordered list of objects, usually updated each frame (or every-other frame). It's costly as hell. (Roughly 30-40 CPU cycles per .Contains)