New C++ AI Interface

[hoijui]

umm.. :/
sorry, my bad again, i did not fix everything wiht the last commit. now it should be fixed, try again, you did it right. ache clenaing should not be needed.

if you have further problems, come ot the #ai channel in the lobby, and ask me or just ask into the round, if i am not there. i am there most of hte time when i am online.

[bbe]

Thanks Hoijui - all working now. I even managed to get it to build a solar collector!

[hoijui]

ehh cool!
and now? you trying to extend the interface, or just start writing an AI?

tell me if you mis something urgent.. best is if you autojoin the #ai channel in the lobby.

[bbe]

Plan is to tinker creating my own AI in part as an interesting project to learn C++. Whether it will come to anything is another matter. I will try to remember to join the #ai channel when I get a moment to work on it!

[AF]

How would I start moving my AI over to this interface without doing a humonguous 1 step refactor?

[hoijui]

both the new and the old C++ interfaces are actually wrappers, which means they are part of the AI, and not of the engine or the C interface plugin. so it should be possible to use them both at the same time, i guess. you would do this in the AIExport source file in your AI. As you have the Legacy one in there already, you have to get the new one in there somehow.
For all of this to work, you had to use the cppintnew branch. You can see how the new one works in the sample AI/Skirmish/CppTestAI/.
This has not yet been done for a legacy AI.
best is if you do it with a script, i recommend AWK, as it is platform independent. as basically all of the work is search&replace, the script way should end up in shorter work time, plus be reusable (eg for other AIs, or for an other stage of your AI, so you can keep coding on your AI in parallel, while developping the conversion script, and every then and when run the script, test compile, and then reverse all the changes of the script (with git eg)).

[AF]

I'd think such a script would only work for NTai, and once development is complete it would be ran once and then discarded as ti would serve no use.

I also have no knowledge of awk whatsoever.

If you can show me some nice documentation that doesn't require em to pick apart rival java AIs to figure out the basic basic uber high level design which should only take a 100 word paragraph to outline, or some doxygen documentation or something of the kind..

[hoijui]

If you can show me some nice documentation that doesn't require em to pick apart rival java AIs to figure out the basic basic uber high level design which should only take a 100 word paragraph to outline, or some doxygen documentation or something of the kind..

...what? :D
best way to see how hte interface works, is to look at the mentioned test AI. why would you pick apart Java AIs?
maybe contact me in the lobby.

[AF]

Because the c++ wrapper is based off the java interface Ive seen people say on here

[hoijui]

yeah true. its not based on it, but shares the same basic OO design.
so yeah, makes sense i guess.

[hoijui]

this is now merged into spring master.
to anyone already using it, please give feedback!
i am pretty sure it still has some ugly egdes, i wont see them, as i dont use it.

[initram]

One ugly edge I see is that you can crash the engine by only calling the API functions:

example(When an enemy unit is destroyed):

Code: Select all

Unit *unit = Unit::GetInstance(destroyedUnitId)
UnitDef *def = unit->GetDef();
char *name = def->GetName();

This example has the potential to crash the client as the call to GetName might make an illegal access violation. This may happen in the case where the unit destroyed is not in LOS, in this case the UnitDefId for def is -1 and this is passed along to underlaying functions.

A better way to handle "the error", was to either return NULL when calling GetDef() on a unit that is not in LOS, or make all functions in a UnitDef check to see if the unitDefId is -1, before calling further down. This would make it a lot easier, and would make the API more robust.

Returning NULL may lead to the AI code trying to follow a NULL pointer, but at least this is a more clear error to catch than when spring crashes when calling a function on an object returned from the API.

[AF]

I agree, the engine API end should not crash if invalid data is passed t it, rather it should catch and return an error by checking the inputs validity before processing.

It is an AI developers responsibility to check for error codes, not the engines, and if the engine is fed bad stuff it shouldn't process it, and the AI should check for that scenario and adjust accordingly. Any crash should happen in AI land not interface land.

[hoijui]

thanks initram, of course this is clearly a bug.
sad thing, i already fixed the exact same thing on the Java interface, and seem to have forgotten to fix it here too.
I had no idea that there are so advanced projects using the interface already (read about brAIn in the other thread) :D
cool!
(the fix should be simple, its on my todo now)

i agree that exceptions thrown in the AI should never reach the engine. This is not even technically viable, as it would go through the C interface, and we can not count on the engine and the AI using the same exception system.
i just wrote some commits for the Java interface 2 days ago, that now ensure that no Throwable can crash the native part of it. so i hope i still remember where to put them. remind me again to do it, in case i forget

[hoijui]

Done both of these (are on main repo master now).
While the -1 -> NULL is done in the callback, the exception catching is done in the AI, so you have to merge the changes i did to AI/Skirmish/CppTestAI/src/AIExport.cpp into your AI.
relevant commit for the exceptions: 3a3aac01beca80941a49845e9b5fec0ead4f5a05

As i only have the test AI for testing, which essentially does nothing, i can only guarantee that it compiles, not that it works propperly.

[initram]

I have been looking through some of the generated source for the C++ interface, and have found that functions that return vectors, e.g. springai::AICallback::GetUnitDefs(), are a source of memory leaks and are generally not very optimized (i don't know how much the c++ optimizer changes)

The memory leaks come from the fact that the functions dynamically allocate arrays (a = new int[size]), but they never free this memory again (delete [] a).

Another change could improve performance, or maybe not change a thing. It is when you set the return vector (_ret), this will copy the vector it is set to, which is unnecessary as there is no need for two copies of this vector. Just fill the return vector right away or return the temp vector.

Hope that I understand the code and the fixes are implemented... :)
If i had a better understanding of the awk files i would have provided a patch.

[hoijui]

:D
yeah.. nobody ever even tried to do somethign wiht the AWK files yet
(as much as i know)

i am currently in a big refactor, first doing the Java AI Interface, and then have to do the C++ one too. no use in trying to change such details before that is done, as it would be reimplemented again afterwards.
if this stuff is a problem for you, and you dont want to mess with the AWK scripts, you could write your own, short AWK or other script, that post process the generated sources, and put it into the build queue (in CMake eg).

thanks for the report though, i'd be glad if we could look at such things after the refactor together.

[AF]

Okay I want to use this and Im stuck with 3 awk script files and no idea how to use them.

Im running under windows 7 using visual studio 2008, and I have XP machines at uni with VS2008 I'd have to use.

[hoijui]

can't you use the cmake genereated vs project?
if not, look at AI/Wrappers/Cpp/CMakeLists.txt maybe.

[AF]

I don't understand, there are no visual studio projects for anything related to the C++ Wrapper or the test AI that I am aware of. I am working off of the source tarball on the download page.