everything compiled fine on windows with only a little poking (one fix committed, and javac wasn't on PATH). good job.

What is this?: "void* ret_sharedMemArea;"

A void pointer can be a pointer to anything, how should I handle this?
As a struct, int, char, array of xy, a function pointer or what?

thanks for both!
am kind of totally unmotivated today, but will fix what you reported.

@Agon
its deprecated, you can treat it as a null event eg.

In addition to what we currently have the following are needed:

In the engine there's an object CModInfo containing various important things such as transportability, shortname and shortgame tag values etc, its extremely important we gain read access to this data structure. Parsing modinfo.tdf no longer works as expected because the modinfo.tdf we expect may not be the modinfo.tdf we're given, nm lua versions

There's also the provision of AI data. Currently its stored on a per version basis, but if I update an AI to a new version, all the caches and statistics and tables and configuration files have to be copied or started from a blank slate manually.

will do that when i am done with the change i am on right now (if no big problems arise, it should take a day or two).
i was thinking about the problem with the versioned cache data already.
with the change i am doing right now, it will be easier to make unversioned data dirs available trhough single function calls, i will do that too.

i see two possibilities, one would look like:

the other:

i would prefer the second one, as it is cleaner somehow. the dir name common would be used by all AIs, and they would fetch the location of files in there somehow like this: getVersionIndependantFile("learning/mod.txt")

that ok?

I agree a common folder encasing them all would be best.

merged airefactor to master.

new:

• /ailist lists currently active AIs in the game
• /aireload aiTeamId acts like /aikill and /aicontrol together, loading the same AI implementation that controlled the team already
• all aicomands, like the ones described above, are now usable in multiplayer games aswell
• refactoring synced AI stuff: make Skirmish AIs treatment more human-player like (will take over EVERYTHING)
• an AAI fix
• some minor fixes

I am thinking about doing a heavfty rewrite of the C AI Interface,, consisting of these:

• replacing SAIFloat3 with float[3] (minor)
• replacing all callback functions with AICommands (heavy!!)

The High-Level interfaces that everyone is using, could stay the same. These are currently the following Wrappers: Java-OO, Legacy C++, (New) C++, though i would like to unify them in the long run, which means for the Java-OO and the C++ Wrapper:
currently:

afterwards:

so the HandleCommand function would be the only function in the low level C callback, but in the high level OO callback this function would not exist, and the functionality currently available through commands (eg. MoveUnitCommand) would be integrated into the OO callback, like this:


i dug out the Tobis concerns about using commands for eveyrthign in the first place:

The inconvienience is not really an issue, as nobody will ever use the pure C interface for an AI, and so we can wrapp away all inconvienence, and for variable return data, i use two functions per logical call already: one to fetch the data size, then allocate enough memory, then fetch the data for real. same could be done wiht events, using a single event, once just fetching the size of the data, with allocated target memory of size 0, and then clal the same event type again with the needed ammount of memory allocated.
.. short, i do not see a problem anymore, except the work required to do the refactoring of course.