Notes Regarding s_curMgr Entities

[CodeBytes]

I'm not sure if this was already covered on these forums, but I wanted to share my recent findings working with s_curMgr (ObjectMgr). Until recently, I thought the entity container was at 0x130. Operating under that assumption, I ran into an interesting issue while scripting the first two dungeons (Ragefire Chasm and Deadmines). I noticed my application was ignoring some objects, and after a little bit of debugging I realized the object was not found in the container. So I started poking around the struct again when I discovered a second list at 0x120.

0x120 had a lot more objects than 0x130, so I believed--initially--that I was reading the wrong container all this time. However, the same issue occurred while reading 0x120. So, naturally, I decided to read the information at both offsets and this finally produced a complete list of entities for me to work with.

The entities found at 0x120 are a mixture of different object types (item, player, etc) while the entities at 0x130 appear to be only Unit.

It should be noted that it's not just a type deficit. 0x120 does not contain every unit, and neither does 0x130. The two lists are incomplete on their own. Combining the two; however, appears to complete the list. Now my application is able to see everything and no longer has issues targeting and killing off every hostile creature in the instance.

[counted]

I'm not sure if this was already covered on these forums, but I wanted to share my recent findings working with s_curMgr (ObjectMgr). Until recently, I thought the entity container was at 0x130. Operating under that assumption, I ran into an interesting issue while scripting the first two dungeons (Ragefire Chasm and Deadmines). I noticed my application was ignoring some objects, and after a little bit of debugging I realized the object was not found in the container. So I started poking around the struct again when I discovered a second list at 0x120.

0x120 had a lot more objects than 0x130, so I believed--initially--that I was reading the wrong container all this time. However, the same issue occurred while reading 0x120. So, naturally, I decided to read the information at both offsets and this finally produced a complete list of entities for me to work with.

The entities found at 0x120 are a mixture of different object types (item, player, etc) while the entities at 0x130 appear to be only Unit.

It should be noted that it's not just a type deficit. 0x120 does not contain every unit, and neither does 0x130. The two lists are incomplete on their own. Combining the two; however, appears to complete the list. Now my application is able to see everything and no longer has issues targeting and killing off every hostile creature in the instance.

My understanding is that the 0x120 list is all visible objects, but not in guid hash table format.

The list at 0x8 is in guid hash format so if you know the guid of the object you are interested in you do not need to traverse the entire list to find it.

Look at my post on the 0x8 list.

wor...t-manager.html

Here is my post on the 0x120 visible object list

https://www.ownedcore.com/forums/wor...ml#post4069718

[CodeBytes]

It is easy to determine the completeness of the list. Simply create a container to hold the objects after iteration throughout 0x120 and place a break point after the loop. Note the size of the container. Then iterate over the 0x130 list and note the size. Then start over again in reverse, starting with the 0x130 list. You'll notice that both lists are incomplete, and iterating over both will give a complete list of entities.

It should be noted that I'm currently only interested in Units, so I allow the loop to continue when a non-unit entity is met.

Regarding the 0x8 list, you and I spoke about it already. It's quite the interesting find.

[zakkord]

You'll notice that both lists are incomplete

0x120 contains everything including mobs at Violet Hold, your loop is probably wrong. WOW wouldn't be able to function if it was incomplete as it's used in several script callbacks.