Difference between ACDGuid and ActorSNO
- Thread starter AgentK
- Start date
ChuckyEgg
Member
- Joined
- Jun 14, 2012
- Messages
- 635
- Reaction score
- 8
I'm also trying to work this one out.
It looks like ACDGuid is dynamically generated when the object is placed in the world, whereas ActorSNO is static.
I came to this conclusion (dynamically generated), because wherever I have seen ACDGuid used, people are having to store all of them, then search through them to find the exact one they need.
It looks like to be able to interact with certain objects (e.g. portals) you have to use the ACDGuid, not the ActorSNO.... damn and fiddle sticks, lol
Examples of this can be found in GilesSmith's Trinity and a query made by XSOL for his [Plugin] MyBuddy.Local a.k.a Follow Me.
xsol's query - http://www.thebuddyforum.com/demonbuddy-forum/developers/65435-actors-actor-visible.html
I'll test this further tomorrow, and if proven to be true (dynamically generated IDs), I'll have to come up with a way to store these and locate what I want easily (minimise processing).
-------------------------------
I'm thinking out loud in typing form here......
I guess the ACDGuid is part of a list of objects in the game world, a dynamically generated list, for perhaps as an easy means to deal with the objects in the world.
When we write an instruction in the Profile to interact with an object e.g.
The actorid (ActorSNO) is then used to locate the object's ACDGuid, and as a consequence the object itself in the actual world.
*** WARNING ***
This is total conjecture on my part!
*** WARNING ***
It looks like ACDGuid is dynamically generated when the object is placed in the world, whereas ActorSNO is static.
I came to this conclusion (dynamically generated), because wherever I have seen ACDGuid used, people are having to store all of them, then search through them to find the exact one they need.
It looks like to be able to interact with certain objects (e.g. portals) you have to use the ACDGuid, not the ActorSNO.... damn and fiddle sticks, lol
Examples of this can be found in GilesSmith's Trinity and a query made by XSOL for his [Plugin] MyBuddy.Local a.k.a Follow Me.
xsol's query - http://www.thebuddyforum.com/demonbuddy-forum/developers/65435-actors-actor-visible.html
I'll test this further tomorrow, and if proven to be true (dynamically generated IDs), I'll have to come up with a way to store these and locate what I want easily (minimise processing).
-------------------------------
I'm thinking out loud in typing form here......
I guess the ACDGuid is part of a list of objects in the game world, a dynamically generated list, for perhaps as an easy means to deal with the objects in the world.
When we write an instruction in the Profile to interact with an object e.g.
PHP:
<UseObject questId="1" x="2400.494" y="2451.034" z="27.1" actorId="176003" isPortal="True" destinationWorldId="161961" />The actorid (ActorSNO) is then used to locate the object's ACDGuid, and as a consequence the object itself in the actual world.
*** WARNING ***
This is total conjecture on my part!
*** WARNING ***
Last edited:
GilesSmith
New Member
- Joined
- Jun 2, 2012
- Messages
- 1,564
- Reaction score
- 34
ActorSNO relates to the "basic type" of object. For example, *ALL* wretched mothers are actor SNO XXXX. All desecrator pools are YYY. All destroyable chairs in Act 1 are ZZZ. Etc. - It's a pointer to pull up the "basic, core data" about an item, and so is an extremely reliable way to filter "types" of things (rather than focus on one exact, specific individual instance of an object). Eg I use SNO's to detect avoidance objects, and I use them to blacklist certain types of monsters or give extra weight to other types of monsters, etc.
As far as I can work out for these three;
ACDGuid, RactorGUID, and DynamicID are all unique and specific to that exact "instance" of an object in the game world at that time.
ACDGuid is only generated for objects which have ACD data - which covers monsters, items on the ground to loot, gold piles, health globes, shrines, containers, destructibles etc. etc. - and the ACDGuid is needed to interact with items.
RactorGUID I have found is a great unique key - it seems to be the least buggy to retrieve from Diablo 3 memory - because it works for all objects (not just ACD based ones), and is a root variable within the object.
DynamicID I have fallen out of favour with. It is hidden within CommonData - and this proves to be one of the more buggy areas of Diablo 3 for DemonBuddy to interact with. The only use I can find for DynamicID's at the moment are for inventory based stuff - so used to sell an item from your backpack, or move an item from your stash to your backback or vice-versa. I don't think you need ever look at the DynamicID for anything else.
This is all based on what I've picked up from developing and experimenting Trinity - I could find no documentation on any of this anywhere.
As far as I can work out for these three;
ACDGuid, RactorGUID, and DynamicID are all unique and specific to that exact "instance" of an object in the game world at that time.
ACDGuid is only generated for objects which have ACD data - which covers monsters, items on the ground to loot, gold piles, health globes, shrines, containers, destructibles etc. etc. - and the ACDGuid is needed to interact with items.
RactorGUID I have found is a great unique key - it seems to be the least buggy to retrieve from Diablo 3 memory - because it works for all objects (not just ACD based ones), and is a root variable within the object.
DynamicID I have fallen out of favour with. It is hidden within CommonData - and this proves to be one of the more buggy areas of Diablo 3 for DemonBuddy to interact with. The only use I can find for DynamicID's at the moment are for inventory based stuff - so used to sell an item from your backpack, or move an item from your stash to your backback or vice-versa. I don't think you need ever look at the DynamicID for anything else.
This is all based on what I've picked up from developing and experimenting Trinity - I could find no documentation on any of this anywhere.
