AI specifying, loading and packaging/storing

[Agon]

Why not have both? Archives which gets installed and other which gets moved.
Could confuse players... but archive mover would handle it so they only need to download the archive and run the archivemover.
If the ai archives needs to be installed a archivemover for Linux would be "needed".
To unpack and move them manually is a bit unhandy.

What are the points against archives for AIs?
Only point I could find was: Can not linked at runtime. Does this mean it is impossible to use archives for AIs?

[AF]

• AIs have no write access to things inside the archives
• Makes debugging of a dll inside an archive impossible
• Linking to the library while its inside the archive is problematic, and extracting it may also be problematic as it may have extra dll dependencies too which need extracting

I think this is only useful as a means of installing AIs by extracting them to the target folder out of the archive. One could then argue that we should just pass installers around not sdz/sd7 files.

[Agon]

• AIs have no write access to things inside the archives
• Makes debugging of a dll inside an archive impossible
• Linking to the library while its inside the archive is problematic, and extracting it may also be problematic as it may have extra dll dependencies too which need extracting

Okay, I think we can forgot archives for AIs.

I think this is only useful as a means of installing AIs by extracting them to the target folder out of the archive. One could then argue that we should just pass installers around not sdz/sd7 files.

Yeah, only installing AIs could be used for archives.
But we need a cross platform installer or integrate installing into ArchiveMover?

[hoijui]

Soo.. we agree that AIs:
* may be packaged in archives, but only for download/installation.
* should export human readable name
* should export a description text (possibly using BB tags)
everyone ok with that?

but what about the other thing, my purposal of interface libs and implementation libs?
some comments please!

[AF]

bb tags and archive mover.

I would suggest using aiinfo.lua or archiveinfo.lua in order to define that its an AI and the various info.

[Agon]

Yeah, archives only for installation.
And two files. One for the "ArchiveMover" and one for the AI lobby integration (custom option for AIs).

[hoijui]

i dont get it AF, where would taht lua file be? (i guess in the archive, but where after extraction?) in there, we had info like name and description of the AI? what else would be in th earchive? the AI interface library?
or short: please explain your whole solution, and possibly give some comments on mine.

how would the info be read? from whom? through what?
(the engine, the lobbies and autohosts will need the info)

[AF]

The lua file would not be extracted. It would only make sense inside the archive. Sort of like modinfo.tdf

[hoijui]

hmm... so you mean we would keep the archive and the extracted version of an AI around? and the lobbies would read the info of the AIs from the lua file inside the archive?

[Agon]

The lua file would not be extracted. It would only make sense inside the archive. Sort of like modinfo.tdf

That would be unfriendly for advanced user who want to customize the AI. But with a documentation and some hints it should not be that much confusing.

This means this folder structure? :
./AI/
./AI/Bot-Libs/ <-Stores .dll/.jar and a archive of an AI
./AI/Interface-Libs/ <-Stores the interface for a bot lib

Example:
./AI/README.txt
./AI/Bot-Libs/AAI.dll
./AI/Bot-Libs/AAI.sd7
./AI/Bot-Libs/JavaAI.jar
./AI/Bot-Libs/JavaAI.sd7
./AI/Interface-Libs/C-Interface.dll
./AI/Interface-Libs/CPlusPlus-Interface.dll
./AI/Interface-Libs/CSharp-Interface.dll
./AI/Interface-Libs/Java-Interface.dll

Or should the archive be in another folder like :"./AI/Archives/AAI.sd7" ?
Will unitsync do the work to get informations from the archive or a lobby?

Example:
./AI/README.txt
./AI/Bot-Libs/AAI.dll
./AI/Bot-Libs/JavaAI.jar
./AI/Archives/AAI.sd7
./AI/Archives/JavaAI.sd7
./AI/Interface-Libs/C-Interface.dll
./AI/Interface-Libs/CPlusPlus-Interface.dll
./AI/Interface-Libs/CSharp-Interface.dll
./AI/Interface-Libs/Java-Interface.dll

The archive would store two files? :
aiinfo.lua

• Stores custom options.
• And which interface will be used.

archiveinfo.lua

• File information for the "ArchiveMover" which file will be extracted and to which location.

A lobby or unitsync needs only to look in the archive to get the information which are needed to start a game or customize an AI.

The problem is this will break compatibly to old AIs. But we want a new generation of AI possibilities, don't we?

[hoijui]

nice, thank you for that explanation!
i personally think it is not that good, to do it that way, but it would be ok for me. though, i would prefer spring.exe to do the parsing, so we can have this code in a single, central place. cause the engine will always need to know the available AIs and which interface to use, spring.exe seems apropriate for it. we could make that info available to the lobbies or other entities through a command line parameter to spring.exe eg.

i am not really clear still:
i downlaod an archive, eg AAI_installer.sd7. i double click on it, and ArchiveMover extracts it to the spring/AI/ folder (into which subfolder exatly does not matter here). then i will have an AAI.dll plus an AAI.sd7 which contains only lua files.
like this?

[AF]

I do not think it would be wise to have archives after installation. Archives are for installing, and I think we should keep it like that.

I would also see this as an opportunity to rid ourselves of Bot terminology and rename bot-libs to skirmish AI

I think we should write the lua such that we have a basic lua class/table with a predefined API:

loadAI()
getName()
getDescription()

And then a spring side API. This way loadAI would know which interface to load and use spring in order to do so, whereas spring would provide a generic API to allow it to do so.

This way we could have extra logic, such as allowing the interface used to be dependant on the version of spring or loading 64bit versus 32bit or experimental versions etc.

I also think that the only code that should handle this lua file is spring or unitsync and that this should be properly encapsulated. The lobby and other external apps should not need to know about this, they should just get what's expected.

I also think that the lua file should have no or as little impact on the AIs too, and only as far as possibly defining values for the interface libs.


I should also point out that the C++ interface will be an SDK wrapper around the C interface compiled within the AI project itself. Putting ti in a dll will only mean duplication fo the C interface, as well as requiring all AIs to use the same compiler, thus defeating the whole point of a lot of interface changes.

[hoijui]

I do not think it would be wise to have archives after installation. Archives are for installing, and I think we should keep it like that.

to get more concrete: where would the lua fiel be, or how would it be named?

Code: Select all

AI/skirmish-libs/AAI.dll
AI/skirmish-def/AAI.dll.lua

?

I think we should write the lua such that we have a basic lua class/table with a predefined API:

loadAI()
getName()
getDescription()

And then a spring side API. This way loadAI would know which interface to load and use spring in order to do so, whereas spring would provide a generic API to allow it to do so.

This way we could have extra logic, such as allowing the interface used to be dependant on the version of spring or loading 64bit versus 32bit or experimental versions etc.

Sorry.. i don't understand how you mean it. What would loadAI() do? Does this mean that all AI devs will have to code loadAI() in LUA? Please give an example for a C++ AI and a Java AI, if possible.
like: springs gathers all AI-def.lua files and calls loadAI() on them -> loadAI() for hoijui.jar does ...?

I should also point out that the C++ interface will be an SDK wrapper around the C interface compiled within the AI project itself. Putting ti in a dll will only mean duplication fo the C interface, as well as requiring all AIs to use the same compiler, thus defeating the whole point of a lot of interface changes.

right! :D thanks

[AF]

aai.dll.lua would make no sense in a linux environment, nor would be replication of aai.so.lua aai.dylib.lua aai.dll.lua. Its not like the engine is looking for those so/dll/dylib files anyway. It will only look at what the lua file tells it to.

/AI/SkirmishAI/lua/ntai.lua
/AI/SkirmishAI/bin/ntai.dll

Here is some pseudocode:

Code: Select all

function LoadAI(){
    ainame = 'ntai'
    spring.pushValue("AI","NTai")
    spring.loadInterface("cplusplus")
}

Here it would be quite obvious what the extension should be because the cplusplus interface knows it cant open a .jar file. If there's a C# and a c++ dll then they cant have the same name so we'd say pushValue("AI","NTaicpp")

The spring engine can only load libraries so it would load cplusplus.dll from the interfaces loader or .dylib or .so depending on the platform.

interface libs would go in /AI/Interfaces/, and the lua files would specify them by name, not file name. Thus we don't need to implement a C API dll or a C++ API dll, they can be implemented inside spring.

This method also allows us to sort out proper full lua AIs that don't need to be bundled with mods, but that would require extra work from trepan to be completed. Mods could at least bundle their own lua AI files in the same directory so that spring/unitsync sees the existing lua AIs and we can use 1 unitsync interface to see the AIs rather than one for lua as and one for normal.

[Pxtl]

I know this is pretty far off-topic, but am I the only one who thinks that BB tags, Wikicode, etc are a freaking abomination? I mean, they're no easier to learn or type than HTML, and just add another confusing mark-up syntax to learn. HTML is a perfectly good standard for human-readable markup. Why does everybody re-invent the wheel and force me to learn yet-another-syntax?

[Agon]

@Pxtl:
This code syntax is mostly for AI developer.
A normal user does not need to care about the syntax.

@AF: Sounds good for me.

What about the custom options? Are they handled by this function?:

Code: Select all

spring.pushValue("AI","NTai")

So that I can write:

Code: Select all

spring.pushValue("difficultLevel","Easy")
spring.pushValue("difficultLevel","Normal")
spring.pushValue("difficultLevel","Hard")
spring.pushValue("mapHack","true")

And this pushed values would appear in the lobby as select able options?
Wouldn't it be better to have something like this?:

Code: Select all

local items = array {"Easy","Normal","Hard")
spring.pushValueList("difficultLevel",items)
spring.pushValueBool("mapHack")

[Kloot]

Soo.. we agree that AIs:
* may be packaged in archives, but only for download/installation.
* should export human readable name
* should export a description text (possibly using BB tags)
everyone ok with that?

No.

AI libs packaged in archives _just_ for installation sounds like change
for the sake of change. 1) Map or mod archives are not meant to be
extracted, AI's should not break that paradigm. 2) Packaging them is
overkill, your average AI is a single .dll/.so plus some config files which
would have separate extraction targets. 3) The archive sd{z,7} would
be left behind unless manually deleted, a step which would then nullify
the benefit of not having to do a manual install.

Human-readable names are convenient for lobbies, and would be the
perfect filler material for an AIDetails.lua parsed by unitsync, not for a
dynamically linked lib loaded by Spring at game start.

AI descriptions are on the Wiki already, which is the first place people
should check for mod compatibility info (since those text are editable
by anyone and thus better suited to being kept up to date when new
versions of the AI / mods are released, unlike static text exported by
the AI). And as suggested a few posts up, shoving them into Lua is a
far more maintainable alternative as well.

but what about the other thing, my purposal of interface libs and implementation libs?
some comments please!

Doable, assuming the interface libs were standardized and reasonably
stable (ie. not subject to constant change like the AI's themselves) and
AI implementations specified their required interface (if any) through an
external Lua / TDF companion file to avoid memory corruption scenarios
and let unitsync do the parsing (smallest amount of work for all involved
devs).

The problem is this will break compatibly to old AIs. But we want a new generation of AI possibilities, don't we?

That can be achieved without breaking anything.

[AF]

What your suggesting agon sort of implies that these lua scripts are in contact with the lobby client which is a huge no no. Their sole purpose is to tell the engine how to load the AI.

[Agon]

This is still not discussed to the end...

Kloot thinks archives are an overkill (single dll and a config file)
and they need to be statically linked (Don't know if this is a big bad thing)

I think we can stick with the current setup but we need something for customizing AIs like a Lua file.

A Lua config file which gets read by unitsync and then unitsync post the information to the lobby there it can display it to the user.
User can select options and the lobby parses the start script.
Spring expose the customized AI options to the AI.