Hi!
I let E323AI and KAIK do a match versus each other. One thing I noticed was that during the match, E323AI did not build any kind of intel gathering (radars), or jammers. It might be nice to have some sort of implementation for this, as it will allow the AI to spot incoming attacks earlier and prepare for its arrival.
Just an example from that match: E323AI built an advanced kbot lab on a hill. There came an attack from KAIK, while E323AI was for some reason sending its units the other way. The lab barely survived, mainly due to that the units were still in the area.
But E323AI won in the end =)
Great job!

Afaik E323AI uses cheats and sees the whole map, so not real need for radars?

Slogic, you are the god of code, the master of AIs, the warrior of lua and the bane of bugs.

PLOX TO RELEASE NEW VERSION FOR CURRENT SPRING KTHXBYE

Crash after start countdown, infolog attached.

1v1 DSD
BA 7.18

AI log folder wasn't generated... =(

Afaik, you'll need the 3.22.4 version if you want to play with the current Spring... or compile the latest 3.23.0 version yourself...

My bad, sorry for not reading thoroughly.

Here, have a replay. =P

Same strategies worked as for the earlier version.

I am trying E323 with water (it seems to build water units now), however, it doesnt seem to build underwater mexes. using 3.22.4.

Sometimes it manages to get a little metal by building underwater metalmakers and tidals. The underwater mex seems to be allright in the categorization file, so it is some specific problem i guess.

Merijn

I tried a pretty strange strategy (for me at least)

Instead of trying to outbuild the AI, I just microed a small force with commander support.

Which won me the game at 10 minutes. AI needs targeting priority (shoot my commander first).

Slogic, conflict terra has gone through some pretty massive changes since last time this AI worked for it. Could you show me how to write configuration files i can submit to you?

may someone is so kind to compile me a actual version of the E323AI

3.23 is way better to play against

i tried already multiple times to compile myself, but have somewhere a glitch between gcc and mingw

thx

I concur, can we get the latest version for current spring version ? Please ??

in current E323AI master, playing BA, the AI sets the commander to "cloaked" right from the start. this causes very heavy energy drain, which in turn totally cripples early game. it first builds a lab, then ~10 winds (not having a single mex yet).

After BOTA maintainers changed ALL unitdefs i understood i need to improve auto-categorizer than to update config files manually & massively. Configuration files will be left for patching improper AI guessing only. This is the future. So, I don't want to support current mode. I plan to implement new categorization files in 3.25.0.


I did not declare 3.22.4 supports naval gameplay. I'm prepared basic naval support for upcoming 3.24.0.


You fixed smth? I think Error added turning on special abilities (cloaking exactly) when task is assigned to group since early ages of project. But it hasn't been working for a long time (for me at least) :) Turned this off in my local repo.

Is there anywhere we can follow the development?
I thought this AI was dead

on github of course :D
it even supplies RSS feeds.

the only recent changes though, are adjustments to changes in spring master (to be found in the pureint branch of E323AI), so nothing that changes gameplay.

@slogic
no, i did not change/fix anything.. i tested on master with the pureint branch of the AI though, but as said, it should not contain logic changes, only adjustments to interfacing with the engine.
if you want to see for yourself, you can check with a recent master build of the engine (which contains the AI too), eg:
http://springrts.com/dl/buildbot/defaul ... 391da9.exe

Well, currently i'm changing lots of stuff and i can't upload them to "master" at github because it breaks everything. "master" branch should be always in playable state. So, before uploading i need to test AI which takes very much time. That is why versions which i provide generally stable.

Another way of working is creating a branch and uploading there every source code change. So it will be in unplayable state most of the time. Eventually i can merge a branch into master. But i still have difficulties with handling github. So, as you see i'm working alone i prefer making massive changes locally. You won't see them until i'll be happy with my tests.

nice to hear you are working on changes! i also did not know.

you can always ask me or anyone else in #sy for help with git/github. this is something that generally everyone likes to help with. it will aslo make you feel more comfortable with git over time, which will lower frustration for you.

engine devs faced a similar problem as you.. and we most likely be using the solution discussed here (or a simpler version of it):
http://nvie.com/posts/a-successful-git-branching-model/

the most important thing there, is usage of master as the stable/release branch, and develop as the default dev branch.
something like the changes you are talking about, should probably be in yet an other branch though. one they call feature branch in that model. you can do that really easily:

then you make commits as usual, and from time to time, you push them to github with either git gui, in the same way you do it when working on master, or with:


The best thing on working this way, is not that others can see the changes earlier, but that you will end up with a number of small till mid-sized commits, instead of s single big one. with the later, it is harder for others to understand what you did and harder to find bugs.

Here is new version: 3.24.0.

Changelog:

• naval units support
• updated config files for BA only

DLL is compatible with Spring 0.82.6.x. Do not use it with older versions.

Known issues:
* commander will try to build TIDAL generator on maps with some amount of water even if water is far away
* shipyards may have improper facing
* amphibious units are back on maps where they should be disabled

The first two will be fixed with introducing/refactoring terrain analyser.

Tested with NOTA 1.64 and BA 7.19

Critical:
- AI issues move orders to static commanders
- if geothermal is withing reach of commander he builds it as a first unit => instafail, making some maps unplayable with this AI
- scouts get in range of enemy mobile/immobile commander and die (it may seem unimportant but this is critical). This is a degradation, it used to be OK before (long time ago i mean).

Important:
- When does it decide to make a second lab? Currently if exceeds metal without making 2nd lab. This was never the case before (long time ago). Sometimes it does make 2nd lab though.
- Energy stall prevention and perfect economy were once one of the strong features, now its not working properly - it still can pause the lab but is not eager to start energy buildings, and does not pause other production when e-stalling.
- Commanders are very unvilling to make mexes, first mex is usually build after solar, lab, and some units. Total metal-wise losses from this behavior are huge.

Other:
- NOTA disables some units in the t1 lab menu before you have t2 com. We call them t1.5 units. This AI is still able to order them - this is minor.
- Saw commander stuck forever in weird state with unit being built at 0% completion. This does not seem common so its minor.


Sadly I don't have the time and mental power to look into the code, hope someone (slogic?) fixes the bugs before the next version.

How do I enable AI logs?

All these concerning NOTA gameplay? I did not test latest versions with NOTA and any other mod except BA due to lack of man power & time. Also config files for all mods except BA are not updated & i have no time to monitor other game changes. I'm already finished patch-categorization files support & now improving unit auto-categorization algorithm. Main categorization file won't be required to be updated manually.

AI may build energy maker before mex depending on initial factory cost. Old algo was hardcoded and was not suited for every mod & also sucked when no initial resource was supplied by mod rules. New formula is based on how much metal should left after the first factory is built. For now it is ok for me. But any help in improving this algo WITHOUT hardcoding is welcomed. Also note that commander will not run far away for metal even on metal stall when there are other builders. This is a protection mechanism of commander.

To enable logging you must tweak AI configuration via SpringLobby only when adding a bot.