Interface Redesign

[BrainDamage]

no worry brain damage, lobbies will not load AIs.
i do not know what ylobby defs prefer, possible scenarios are:
* lobby reads info directly from LUA info files
* lobby asks unitsync, which gets the info from the LUA info files
* lobby asks unitsync, which executes spring.exe with --list-ais, and parses the output

I think pretty much every lobby developer would pick the second choice, it's the most portable and doesn't requires for the lobby to assume any hardcoded location (either absolute or relative). Whilst a lua parses is included in unitsync 0.77 the lobby would still need to harcode the path where those files should be, while they should be no interest but spring itself for it's internal workings. It's also consistent with the API that lobbies uses.
The third option is not really a choice, imho it's really stupid and unneded along with some problems due to OS differences (for example win version & linux version of spring gives different output & accepts different flags ), not to mention that unitsync was specifically created for lobbies to share code with spring without having to source it directly (in this case the AI lister)

btw.. why is it called unitsync? was it initially only used to let lobbies acess unit info? is it ok if i think of unitsync as a common interface for lobbies (an possibly other programms) to access game data/content?

yes & yes

[hoijui]

as said already, we would have shortName = "CSharp", and name = "C#", for example. it can never be bad to have a clean name for something anyway. though for C# we would not really need a name, as the user should not be confronted to anything about language interfaces anyway (-> shortName would be enough). but then again, maybe once in the future it will be usefull.

why is this:

Code: Select all

char** keys, char** values, int keycount

better then this:

Code: Select all

char*** properties, int keycount

which is the same as

Code: Select all

char* properties[][2], int keycount

or isn't it?
we could argue about one beeing easier to read/understand, but if that is all there is, then it would not be worth a discussion in my eyes (as there is much more other stuff to do before talking about such details).

ok BrainDamage, so the second option (if no objections).
unitsync: are there plans to rename it?

[AF]

• Multidimensional arrays are bad practice in the first place
• They would require you to calculate the position within the array of the needed key and value, math which shouldnt be required
• Its more fiddly and you have to mess around more with pointers
• Seeing *** anywhere in code is a sign that things are about to go downhill

[hoijui]

• Multidimensional arrays are bad practice in the first place
• They would require you to calculate the position within the array of the needed key and value, math which shouldnt be required
• Its more fiddly and you have to mess around more with pointers
• Seeing *** anywhere in code is a sign that things are about to go downhill

i dont have *** anywhere in my code. i do not fiddle around wiht pointers any more then it would be with your sugestion. this code is not at all performance relevant.
the first point, that it is bad practise... ok, i dont realy know about C practises. in most other languages it is a bad practise to use arrays at all (if they work like in C).
i will consider changing it to two single dimension arrays, but its not a priority. if it will not be done until then, you could also do it yourself after i comitted.

[Tobi]

btw.. why is it called unitsync? was it initially only used to let lobbies acess unit info? is it ok if i think of unitsync as a common interface for lobbies (an possibly other programms) to access game data/content?

It was ment as interface for lobbies to get access to unit data and also to allow lobbies to synchronize the available add on units, I think.

However, culture changed and unit synchronization was never finished. (don't ask which was the cause )

[hoijui]

ok, i won't ask. dont have mood to end up doing it. you know.. i am looking forward to the day when i am finished with the C++ stuff

hey tobi, say something about the char*[][2] stuff. its something quite low level.. so far you mostly had the best arguments there.

was thinking about AI naming and versions:
what if we had a standard naming scheme for Interface and AI libraries, for example 'toLowerCase(<shortName>)-<version>'
so it would be:

Code: Select all

Interface/impls/c-0.1.dll
Interface/impls/csharp-0.1.dll
Interface/impls/libjava-0.1.so
Skirmish/impls/rai-0.600.dll
Skirmish/impls/libkaik-0.13.so

the user will not see the name of the library anyway, except when installing it.

i was also thinking about if it makes sense to have the AI folders in the source like this:

Code: Select all

AI/Skirmish/RAI-0.600
AI/Skirmish/KAIK-0.13

or if this would be better this way:

Code: Select all

AI/Skirmish/RAI
AI/Skirmish/KAIK

i would prefer the later one, but the buildsystems would have problems getting the version (which i would like to see in the shared library name somehow). would it be an option to have a VERSION file in each AI source folder, with eg 0.600 in the first line, and let the buildsystem read those files?
these are just some ideas, i will not do these changes (except everyone would like it, which i can't imagine ).

an other thing:
lets asume, we have the Java interface working, and i would have my java ai in the same source folder as all the other AIs. the build system would have to exclude all dirs in AI/Skirmish/* which do not contain any .h, .hpp, .c or .cpp files. is it possible to check that with the build systems?
currently, each Interface and AI is set up by hand in CMake though. but at least in scons i would end up with hoijui.dll, even doh i do not have a single C or C++ file in AI/Skirmish/hoijui.

more build system:
an AI dev keeps a file aiinfo.lua file in the source folder (eg. AI/Skirmish/AAI/aiinfo.lua), and the build system copies that file to game/AI/Skirmish/data/AAI-<version>/aiinfo.lua.
did you imagine it like this?

[hoijui]

forgot to ask this:
would we have aioptions.lua (comparable to modoptions) and aiinfo.lua (where we have the static properties like shortName, version, name, description, url, ...)?

[AF]

I would much prefer a single rai.lua ntai.lua etc

be wary of introducing unnecessary complexity

[Tobi]

hey tobi, say something about the char*[][2] stuff. its something quite low level.. so far you mostly had the best arguments there.

I wouldn't use it.

I can never remember how all pointers are laid out in memory with such definition, and I also don't know whether each compiler is guaranteed to do it exactly the same way.

Besides that, to return a char*[][2] you either need to put the data in a global variable and return a pointer to that (like unitsync does for minimap images) or you need to allocate the data and supply a FreeAIOptions() API entry too, because memory must always be freed in the DLL it was allocated in.

Personally I'd rather see a similar pattern as used for map/mod options. Heck, you can directly integrate it with those by only proviving a single extra method:

Code: Select all

DLL_EXPORT int          __stdcall GetMapOptionCount(const char* name);
DLL_EXPORT int          __stdcall GetModOptionCount();
DLL_EXPORT const char*  __stdcall GetOptionKey(int optIndex);
DLL_EXPORT const char*  __stdcall GetOptionName(int optIndex);
DLL_EXPORT const char* __stdcall GetOptionSection(int optIndex);
DLL_EXPORT const char*  __stdcall GetOptionDesc(int optIndex);
DLL_EXPORT int          __stdcall GetOptionType(int optIndex);
DLL_EXPORT int          __stdcall GetOptionBoolDef(int optIndex);
DLL_EXPORT float        __stdcall GetOptionNumberDef(int optIndex);
// etc.

Then just add one method, and reuse all the GetOption* ones. This would also allow all lobbies to easily reuse the dynamic options screen code from their map/mod options implementation.

Code: Select all

DLL_EXPORT int          __stdcall GetAIOptionCount(const char* ainame);

[Sheekel]

So without going into too much detail, what does this mean for AI developers? Can we expect to have better playing AIs?

[Tobi]

They'd be able to use any compiler to build their AIs with instead of having to use MinGW (+ the right version) and hopefully backwards compatibility would be broken less often with a good interface design.

[AF]

This should mean:

• Greater flexibility.
• Faster AI execution speed via superior optimizing compilers.
• A motivational boost for those AI devs using Visual Studio hit by the switch to mingw32 such as myself submarine and pretty much every other AI developer out there whose released an AI for spring.
• The bar of entry to new AI developers will be dropped drastically thanks to the more consistent API and the lower development cost.
• Its easier to implement support for new languages now such as java and C#

[hoijui]

AIs themselfs will not play any better just because of the Interface change.

[AF]

The interface change would bring about a better AI ecosystem with which to improve AIs though. Its more a case of wait and see.

[hoijui]

btw.. nice lineup AF, thanks.
i oftne felt like i do it all for nothing, but with this list, it already looks much better.

[AF]

Oh dotn feel like that, AI development here is somewhat stagnant, nothing much new is done except maybe by kloot, the odd refactor I do to help academics, bugfixes from reth, and the occasional bi-annual patch from submarine to AAI.

Compiling and developing new features and releasing is too great a headache and the bar for new developers is way too high, it was barely adequate when we began, mingw32 compiler enforcement simply raised it beyond the grasp of the vast majority of potential AI devs.

A C API, if only the ability to use Visual studio again, will greatly simplify things for new people.

[casperjeff]

Myself and a few buddies have recently stumbled across the Spring project and have been immersed for a few weeks in the gameplay. OUTSTANDING. We are professional developers by trade (C/C++ and Java) and are looking into coding some global AI's to compete against each other (for ultimate bragging rights).

We are struggling where to jump in.....

Lots of threads here to catch up on, but I guess I am looking for a synopsis on the global AI status...

Has there been any actual development on the new interface redesign?
Is the JAI interface fully functional in terms of exposed features/callbacks and stability?
Can we assist in any way with the new interface or coding up test AIs?
Is there a comprehensive list of current global AI functions and descriptions therein as to their functionality and use?
I'm still a bit confused about the existing AI's out there (RAI, AAI, KAIK, etc)....do they use exposed cheat mechanisms?

We are anxious to jump in ...any advice would be appreciated.

[Kloot]

Can we assist in any way with the new interface or coding up test AIs?

Well, you can always write a new AI against the current interface,
and port it over to the new one when it becomes available.

Is there a comprehensive list of current global AI functions and descriptions therein as to their functionality and use?

The most comprehensive list is the latest engine <--> AI interface
source (sparsely commented, but most of it is self-explanatory):

https://spring.clan-sy.com/svn/spring/t ... GlobalAI.h
https://spring.clan-sy.com/svn/spring/t ... Callback.h

I'm still a bit confused about the existing AI's out there (RAI, AAI, KAIK, etc)....do they use exposed cheat mechanisms?

KAIK does (it basically ignores LOS restraints), the others do not.

[hoijui]

about JAI:
i would not recommend using it. currently, there is no AI based on it (except my test AI one). JAI is built uppon the current C++ interface, and will most likely look totally different when adapted to the new C interface.

if you do not wiat for the C interface to come, you may want to use this link in addition to the source, as explained by kloot:
http://spring.clan-sy.com/wiki/AI

[hoijui]

ok.. again about the options and the static properties:
i wanted to have it in one file, AF though it should be one. but i would like some more feedback. first, i don't know anything about LUA. why i wanted it to be 2 files, is becuase in hte mods, it are two files as well: ModOptions.lua and modinfo.tdf.
i though we could have AIOptions.lua and AIInfo.lua. cause then we could surely use th eexisting parsers for LUA options, and possibly had to write one for the info, as the mods use tdf, and not lua for that (or did that change already?). Though, if it is possible to put thos htings in one file, and you think we should do that, we could do it.
soo.. feedback pls! as many as possible.