Spring RTS Engine

I was working on AI interface improvements for some time, and a few days ago I send my patch to the devs and it was committed. Now I finally have a time to write about them here.
This is a list of changes I made:

GlobalAI:
* added new event to IGlobalAI: EnemyDamaged (int damaged, int attacker, float damage, float3 dir)
- it is called when enemy inside LOS is damaged by one of your (ai) units

AICallback:
* added 3 new functions to CAICallback:
- int GetBuildingFacing(int unitid) (needed for rotatable buildings)
- bool IsUnitCloaked(int unitid)
- bool IsUnitParalyzed(int unitid)
* removed AIVAL_SLOPE_MAP, AIVAL_MAX_HEIGHT, AIVAL_MIN_HEIGHT variables from GetValue() function
added float GetMinHeight(), float GetMaxHeight(), const float* GetSlopeMap() functions instead, so all functions concerning map info are now together
* removed AIVAL_MAX_METAL from GetValue() as there is GetMaxMetal() function already
* changed HandleCommand(void *data) function to HandleCommand(int commandId, void *data), so it is now easier to use

AICheats:
* added GetUnitTeam, GetUnitAllyTeam, GetUnitHealth, GetUnitMaxHealth, GetUnitPower, GetUnitExperience, IsUnitActivated, UnitBeingBuilt, GetUnitResourceInfo, GetCurrentUnitCommands, GetBuildingFacing, IsUnitCloaked, IsUnitParalyzed functions to CAICheats - they are the same as in CAICallback but without LOS checks
* added GetProperty(int id, int property, void *dst), GetValue(int id, void *dst) and HandleCommand(int commandId, void *data) functions to CAICheats, so cheat interface is now extendable too
* added void EnableCheatEvents(bool enable) function. If set to true it enable AI to get events such as EnemyDamaged and EnemyDestroyed even if enemy is outside LOS and radar

And some bugfixes:
* fixed bug with CAICallback::GetMinWind() and CAICallback::GetMaxWind() functions always giving wrong values when called inside CGlobalAI::InitAi
* changed so UnitDamaged function is now called after unit gets paralyzed and after attacker gets experience, as it should be

And some smaller things I omitted, cause they don't have much importance for AI coders.
All these additions will be available in 0.73b1. Hope AI makers will find them useful.

For one I'd says AIVAL_MAXMETAL should not have been removed and IAICallback::GetMaxMetal() should have been removed instead, as that improves consistency and simplicity of the headers.

Also the small things can have a big impact so post them here.

AF wrote:For one I'd says AIVAL_MAXMETAL should not have been removed and IAICallback::GetMaxMetal() should have been removed instead, as that improves consistency and simplicity of the headers.

I don't think AIVAL_MAXMETAL is better. Yes, it will allow to remove one line from the headers, but instead it will be needed to add 3 lines everytime when using it. And btw it was your fault to add this variable when there is similar function already.

AF on mailing list wrote:Whatsmore the method you used flies int eh faceof jelmer and cains
work with handlevent(), and yes it is used for captured units events,
and soon enough weapons Fired events that i added in.

I'd prefer it if the enemydamaged event was passed through the
abstract method rather than manually added to the IGlobalAI class.

This is just adding more and more code into a disorganised pile thats
already spaghetti code.

I did an exception for EnemyDamaged because there is UnitDamaged function already which looks similar, so it could be quite confusing if they were called differently. And HandleEvent() was added to allow adding functions without breaking existing ais, which imo doesn't matter as SVN code was breaking ais already.

AF wrote:Also the small things can have a big impact so post them here.

The small things are:
* increasing AI_INTERFACE_VERSION - I think everyone here already know that ais need to be recompiled for next Spring version.
* the rest were code cleanings, all of them were mentioned in the mailing list and SVN log (revision 1963) if you are really so interested about them.

Yes, it will allow to remove one line from the headers, but instead it will be needed to add 3 lines everytime when using it.

Abstraction ftw!

Also the problem here in the way events are hardcoded into the class definition is that it has to be done twice for helper AI and skirmish AI, which means when they're added the programmer neglects to add them to the appropriate places and the underlying code remains a two tier system for handling events, when it could be a unified events system. If anything I'd have moved UnitDamaged into HandleEvent().

In future I'll be writting a patch that does all of that ordering the interface into a consistent package and then writting an SDK ontop of it generalizing common actions and organising things better along with a few other things to eradicate the small things like krogs mex class and logging classes etc...

Mostly a really nice patch! thanks a bunch, i wanted some of those functions badly!

AF, make sure to write the interface in C only and also define the calling convention you use etc., so there'll finally be an AI interface that doesn't require the AIs to be compiled with same compiler vendor & version as spring itself...

Tobi wrote:AF, make sure to write the interface in C only and also define the calling convention you use etc., so there'll finally be an AI interface that doesn't require the AIs to be compiled with same compiler vendor & version as spring itself...

Pardon my ignorance, but will this be possible? I notice that the current AI interface passes many C++ objects across the interface, and some of these are not specifically AI objects (Command, CommandDescription, UnitInfo..). Even some stuff from the creg module gets passed across. Surely any difference in the assembly-level implementation of these objects would break the interface? Or is that implementation guaranteed to be the same with all compilers?

Ahem, my interface change as suggested there is not a new itnerface at all.

Rathe rits moving the existing stuff such as UnitIdle() events and the IAICallback stuff into the HandleEvent GetValue etc functions, then writting a set of classes to simplify the process in an organised way, while providing common tools and fixes such as command caching etc.

Jack wrote:Pardon my ignorance, but will this be possible? I notice that the current AI interface passes many C++ objects across the interface, and some of these are not specifically AI objects (Command, CommandDescription, UnitInfo..). Even some stuff from the creg module gets passed across. Surely any difference in the assembly-level implementation of these objects would break the interface? Or is that implementation guaranteed to be the same with all compilers?

That's actually the reason a C only interface would be useful.

It's not that important tho. In the future scripting solutions will probably be implemented...

AI development is shifting towards stability and most importantly runtime speed.

Thus I wouldnt support a scripting solution as a replacement.

Besides this upgrade thing is forcing users to upgrade AI's the the latest versions which is a good thing.

What I would sya si that when the itnerface version doesnt match the suer should be told to delete or move the groupI r skirmish AI and be told why it doesnt work and to go update.

Simply giving a message saying interface doesnt match contact AI author isnt enough.