It does look awesome :) So tempted to do some gui stuff, just it tends to blow up on fullscreen and XP, back when I still ran XP :) I guess with a command it's not so bad, only shows if an experienced user asks for it :)
i forked it and made two branches (engineint = Engine integration): http://github.com/hoijui/BAI/tree/engineint http://github.com/hoijui/BAI/tree/engineint_cleanup the first one consists of changes that i think you could merge into your master branch as is. the second one (cleanup) removes a lot of files that are only needed for you, while developing, and also moves some files to other dirs, where the engine expects them. i am currently using the second one as a submodule in spring master, and it compiles & runs fine i did not yet reference it as a submodule in spring master (for others to get it), because the file handling (log, cache, ...) you are using is not spring conform (will write to the wrong dirs under linux). that should not be too big of a change, i think (and hope). worst thing would be, if it conflicts with the way you want to use it (with your settings/options classes), but i think both should work together, when we just set the defaults to the spring conform dirs. i did not check how your system really works; whether it caches the defaults, but i guess it does.. have to check then.
i also tried making a branch of it compatible with spring pureint, but .. too many changes required, lost mood
did two test games, BA 7.12, Brazillian Battlefield, 1vs1: lost vs KAIK won vs RAI
cooping with the AI seems to work nicely building placement is not really its strengths, but it is enough
so.. nice! :D one more AI, and even in Java!
join other AI devs in #ai in the lobby, if you like
commands are integrated into the callback -> no more callback.getEngine().handleCommand(new UnitMoveAICommand(dest)), but instead callback.getUnits().moeTo(dest) (that is the change which seemed too much work for me in BAI, cause of your CommandUtil)
minor package changes (can be solved by about 3-5 find&replace over all source files)
all callback classes (Unit, UnitDef, Resource, ...) come in these flavors:
interface (Unit) implemented by the other 3
abstract (AbstractUnit) is used by wrapper and stub
wrapper (WrapUnit) OO wrapps the C style Java callback; so this so what you will usually get when calling the callback
stub (StubUnit) has a setter for each getter. i think this could be useful for you, as you have something like UnitDefCache, which does do about this. though... maybe you will not need this anymore, as cranphin reported the JNA -> JNI move helped performance a lot.
also.. if you are missing something in pureint still, tell me, and if it makes sense to have it, and it not utterly difficult or ugly, i will likely do it.
not pureint related: you should use Mod.getHumanName() or Mod.getShortName(), and never Mod.getFileName() (is @deprecated in master and pureint). of course it is not very important for cache files, but still better. there is a new archive format in spring, which is called rapid, and works a bit like git. archives (mainly mods) are downloaded not as one file, but each file (zipped) is downloaded separately. on mod update, only changed files get downloaded, and you can use both versions of the mod with 30MB + 100KB bandwidth + file-system usage, instead of 60MB. the file names of these archives are hashes though, while the human- and short-name stay the same.
changes needed in your AI for engine conformance: spring can have multiple data-directories, and these days, it is used on all platforms by default. only one of these directories is writable though. on windows, this is not really a problem for AIs, as all their files will be in the same data dir, which is also the writable one. under linux though, this is often/usually not the case. with the result that your SkirmishAI.jar will be here: /usr/shared/games/spring/AI/Skirmish/BAI/0.1/SkirmishAI.jar and cache & log files should be here: /home/user/.spring/AI/Skirmish/BAI/0.1/logs
The AI interface has helper methods for this. How you should create the log file path, for example:
writeable file needs to be writable; this should be false for config files eg. if you do not need to write to them create the directory should be created, if it does not yet exist. dir whether the path is to a directory (in contrast to a file) common if true, will look for BAI/common/<relPath>, instead of BAI/<version>/<relPath>; also mainly useful for config files, in case the format does not change, the user can have them in common, and does not have to copy them around when a new version of the AI comes out. i know your AI does not use config files, but well..
I think I've figured out the problem. The data\0.1 folder is empty.
The entire thing is in .java files in the other folders that I apparently have to compile first. >.> Except that what I know of java involves compling .java files into .class files. Is this right? Do I need to do that?
EDIT: furthermore, I've no idea which file goes into which folder once I've compiled it. (dling a java complier and running it is no problem)
EDIT2: comparing the null java AI and the lib folder makes me think I'm supposed to make a .jar file somewhere... Perhaps I should wait until an actual release. >.>
it is setup to be compiled together with spring as a whole (the CMakeLists.txt file is used for that). if you want to only compile the AI, then an ant build setup would be useful for that. the AI does currently not come with one (there was one, but it was system dependent). The other Java AIs shoudl have system independent Ant build files. They consist of build.xml and some *.properties files. You could copy them over from AI/Skirmish/NullOOJavaAI/bin/ eg, and if you are lucky, you will only have to change the properties file (one of them)... well.. maybe it is too complicated for you, if you are not familiar with Ant.
maybe have a look at the log file(s) under AI/Interface/Java/log/. post through pastebin.com if you can not get anything out of them. as this has not been very widely tested, i can not guarantee it has no bugs, but under windows it should work if you have a recent JRE or JDK installed. it should find it through registry. if you have it installed, but it does not find it anyway, then you might set the JAVA_HOME env var.
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