Spring RTS Engine

Posted: **23 Feb 2009, 18:26**

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

Posted: **23 Feb 2009, 20:02**

struct SCreateSharedMemAreaCommand {
	char* name;
	int size;
	void* ret_sharedMemArea;
}; // COMMAND_SHARED_MEM_AREA_CREATE

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?

Posted: **23 Feb 2009, 20:15**

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

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.

Posted: **03 Mar 2009, 18:47**

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.

Posted: **03 Mar 2009, 21:22**

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:

Code: Select all

AI/Skirmish/AAI/0.X/log.txt
AI/Skirmish/AAI/0.Y/log.txt
AI/Skirmish/AAI/learning/mod.txt
AI/Skirmish/AAI/learning/map.txt
AI/Skirmish/AAI/cache/map.txt

the other:

Code: Select all

AI/Skirmish/AAI/0.X/log.txt
AI/Skirmish/AAI/0.Y/log.txt
AI/Skirmish/AAI/common/learning/mod.txt
AI/Skirmish/AAI/common/learning/map.txt
AI/Skirmish/AAI/common/cache/map.txt

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?

Posted: **03 Mar 2009, 23:26**

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

Posted: **07 Sep 2009, 16:44**

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

Posted: **12 Oct 2009, 16:49**

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:

Code: Select all

C-Interface   Wrapper
command   ->  command
function   ->  function

afterwards:

Code: Select all

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:

Code: Select all

callback.getFriendlyUnits()[0].move(pos)

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

Tobi wrote: 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:
Code: Select all
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.

Spring RTS Engine

Interface Redesign

Re: Interface Redesign

Re: Interface Redesign

Re: Interface Redesign

Re: Interface Redesign

Re: Interface Redesign

Re: Interface Redesign

Re: Interface Redesign

Re: Interface Redesign