This is sort fo aimed at engine developers and any AI developers.
I wonder if it would be wise to pass over the units UnitDef id along with its unitID in event calls across the AI interface. It would be a tiny optimization and it would help prevent issues where say a unit has been created and the calls been made and calls to getunitdef don't initially work, or some issue inside the AI.
The idea came from looking at some of trepans commits. I say the id as in UnitDef::id rather than a unitdef pointer in order to keep to standard C types and minimize potential ABI issues with passing pointers to C++ classes.
What do people think about this?
AI Interface Proposal
Moderator: Moderators
Re: AI Interface Proposal
Hmm, seems like a bug if that is really so (UnitCreated being called before the unit is fully created -- or rather, before the unit is sufficiently created to make AI callbacks work).AF wrote:I wonder if it would be wise to pass over the units UnitDef id along with its unitID in event calls across the AI interface. It would be a tiny optimization and it would help prevent issues where say a unit has been created and the calls been made and calls to getunitdef don't initially work, or some issue inside the AI.
Pointers are standard C types tooThe idea came from looking at some of trepans commits. I say the id as in UnitDef::id rather than a unitdef pointer in order to keep to standard C types and minimize potential ABI issues with passing pointers to C++ classes.
, but I get what you mean.I don't think it really helps with ABI issues since you just delay the marshalling of the pointer: it will be needed later anyway to figure out what's in the unitdef (unless someone makes a wrapper with get functions for all unitdef values, like hughperkins did in his C# thing).
I guess it would make sense in that you'll usually be interested in a unique unit identifier and the type of the unit.
Even then, it would need to be a const UnitDef*, or a GetUnitDefById function needs to be added to IAICallback (though technically AIs can use GetUnitDefList .. but I guess that's just a harder way of doing it..), because now you can't get UnitDef's by UnitDef id, as far as I can see.
Indeed a GetUnitDefByID() callback function would be good, albeit not necessary.
Sometimes in the AI interface with unitcreated you would get error values returned if you did a callback function on that unit because the respective data had not been created, usually a problem with when you first start and the frame number is small say 1 or 2 etc. You would have to make a special case for the commander as the usual unitcreated->unifinished setup did not occur and the commander would be left out of the loop unless catered for by the AI developer.
One example of such a callback that returned a null UnitDef pointer was when an enemy unit entered your Line fo sight. You would have to add it to a cache and process the event on the next frame to get meaningful data out of it.
Also, if I rely on a system inside my AI for unitdef management and that system is flawed, It makes it harder to manage without a debugger or do simple tests, whereas I can do an instant comparison check, perhaps even use the id to bypass the retrieval of a unitdef pointer entirely.
Sometimes in the AI interface with unitcreated you would get error values returned if you did a callback function on that unit because the respective data had not been created, usually a problem with when you first start and the frame number is small say 1 or 2 etc. You would have to make a special case for the commander as the usual unitcreated->unifinished setup did not occur and the commander would be left out of the loop unless catered for by the AI developer.
One example of such a callback that returned a null UnitDef pointer was when an enemy unit entered your Line fo sight. You would have to add it to a cache and process the event on the next frame to get meaningful data out of it.
Also, if I rely on a system inside my AI for unitdef management and that system is flawed, It makes it harder to manage without a debugger or do simple tests, whereas I can do an instant comparison check, perhaps even use the id to bypass the retrieval of a unitdef pointer entirely.