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 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")
I am thinking about doing a heavfty rewrite of the C AI Interface,, consisting of these:
replacing SAIFloat3 with float (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:
C-Interface Wrapper command -> command function -> function
C-Interface Wrapper command -> function
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:
A generic callback function seems like a useless complication to me for the callback interface, not in the least because of the trouble of returning a pointer to an object:
it can't just be created on the stack in the engine because then pointer would be dangling on return of the callback function.
It can't be allocated on the heap without a bunch of code to automatically garbage collect it a later frame.
It can't be allocated on the heap and freed in the AI because they may use a different C runtime (ie. different heaps).
It can only be made a global variable engine side (or member of the object representing the AI, but that's still pretty much global), with accompanying issues of people still trying to free the pointer, callbacks being non-reentrant, etc.
Of course one could make it like this:
void callback(int id, void* data);
Where the AI allocates space for the data and the engine actually fills it, but:
I do not think this is very intuitive (because of the "out" parameter).
It wouldn't have as good compatibility because the callback data structure couldn't be made bigger in the engine: it would write out of bounds of the area allocated by older AIs.
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.
Users browsing this forum: No registered users and 1 guest
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot post attachments in this forum