Object Manager Help

[nathan2022001]

Heya,

I have managed to (I think) enumerate the objects but I have one issue, while attempting to acquire the GUID of each of the objects I noticed that after around 15 objects the GUIDs started becoming negative numbers. I was just wandering if this is normal or if anybody else has experienced a similar issue?


Thankyou.

[lanman92]

Maybe read it as unsigned...? And why is this a problem in the first place? It's still unique and long.

[nathan2022001]

I checked out the memory location of one of the objs and it was also negative. Do you think a GUID is ok to be negative then?

Thanks for the reply.

[ziinus]

Edit : My Mistake, it's an unsigned long =D.

[BoogieManTM]

guid is indeed unsigned, and is int64, not 32.

[amadmonk]

I'd wager that you've started hitting the 0xFxxxxxxxxxxxxxxx guids, which are indeed negative when represented as signed ints. The first bunch of objects you enum will be inventory items and they have a different guid mask than the unit objects that come later.

Use unsigned, as everyone else says.

[vulcanaoc]

I checked out the memory location of one of the objs and it was also negative. Do you think a GUID is ok to be negative then?

Thanks for the reply.

If a memory location is negative, you might be in trouble.

[Cypher]

Lol @ "negative memory location". Someone doesn't know the difference between signed and unsigned types imo.

[nathan2022001]

Im aware of signed and unsigned you misunderstood me, I meant that I went to the memory location in a memory editor and found the value to be negative, not the memory address itself but the GUID stored there.

I'm using a UINT64 anyways.

[vulcanaoc]

I checked out the memory location of one of the objs and it was also negative. Do you think a GUID is ok to be negative then?

Thanks for the reply.

Im aware of signed and unsigned you misunderstood me, I meant that I went to the memory location in a memory editor and found the value to be negative, not the memory address itself but the GUID stored there.

I'm using a UINT64 anyways.

There was no misunderstanding, you just misrepresented yourself.

[furang]

I faced this problem few weeks ago and solved it in some minutes. But at first i was surprised. As it was mentioned first goes guids of items (they are 0x478*). Then mobs and npcs. By the way i wrote a function for myself, that can distinguish object by guid so then you know what kind of object it is and what offsets you should use to get necessary values.

[Apoc]

I faced this problem few weeks ago and solved it in some minutes. But at first i was surprised. As it was mentioned first goes guids of items (they are 0x478*). Then mobs and npcs. By the way i wrote a function for myself, that can distinguish object by guid so then you know what kind of object it is and what offsets you should use to get necessary values.

So did I!

public WoWObjectType Type { get { return (WoWObjectType)GetStorageField<uint>(ObjectFields.OBJECT_FIELD_TYPE); } }

Then I do some awesomely complex logic...

switch(obj.Type)
{
case WoWObjectType.Item:
break;
...
}

Since y'know... everything derives from the base GameObject (Or WoWObject) class. They all have those descriptors. But I'm sure you already knew that.