Spring RTS Engine

Where can I get the SVN builds and will you be releasing a new stable version in the foreseeable future?

It wasn't my original intention, but I've uploaded a
new build of the SVN code for 76b1. Opening post
has the link.

Will that file work with Windows installs? .tar.gz files are, in my experience, associated with linux.

It's an archive, binaries for both platforms are inside it.

Kloot, I tested with the new bot version too (edit: same result as before).

start.txt
http://pastebin.ca/981253

If you need more info (or demo) let me know.

Cheers, but running your script (even several times in succession,
since your report implied it wasn't deterministic) unfortunately did
not recreate the issue for me. Did you perhaps have an SVN build
installed at any point between the release of 0.76b1 and the one I
just posted a few days ago? If so, try deleting any KAI*/ directories
under Spring/AI/, it's possible though unlikely some old mod config
data got left behind and is messing up the commander's assigned
unit category when KAI tries to read it.

Ok, removed the KAIK013 dir (the only KIA* dir there).

Started game anew with bot, same result.

Here's the demo file:
http://merijn.bofp.org/080413-Cooper_Hi ... 0.76b1.sdf

the AI/KAIK013 dir was recreated. the log of the game was empty.

Still no luck I'm afraid, this is what happens on my end
without exception (scripts are the same, just open the
.sdf in an editor):

http://www.darkstars.co.uk/downloads/vi ... erHill.sdf

I think the only way to get to the bottom of this is to put
up a debug build with logging enabled again, I'll prepare
one later this week.

hmm...ok we'll see what the debug build has to say then

I'm dreadfully curious about that myself. Here it is:

http://www.darkstars.co.uk/downloads/vi ... LOG.tar.gz

Just let it run for a minute or so, should be enough to
gather a nice paper-trail.

Well, here you go:
http://pastebin.ca/986172

I hope this is usefull to you, it doesn't enlighten me

Very, the problem is that this line:
... is not at all consistent with this one:
Basically, the AI thinks it's on side 1 (Core) after reading the
setup script, while it actually is on side 0 (Arm). That means
the function which parses the script (ReadTeamSides) is not
interpreting the [game]\\[teamX] sections properly for some
reason, what the log should say is:
... except I have no idea why yours doesn't. The responsible
piece of code is:

So the sideName values must be empty strings on your end
even for teams 0 and 1, very strange.

edit: can you try this build and see if there's any difference?

You got something there. I ran with the v2 and now it does see it is arm. And the bot is working correctly.

CUnitTable::ReadTeamSides()
parsing GameSetup script script.txt
team: 0, side: arm (index: 0)
team: 1, side: arm (index: 0)
no game\team\side value found for team 2
no game\team\side value found for team 3
no game\team\side value found for team 4
no game\team\side value found for team 5
no game\team\side value found for team 6
no game\team\side value found for team 7
no game\team\side value found for team 8
no game\team\side value found for team 9
no game\team\side value found for team 10
no game\team\side value found for team 11
no game\team\side value found for team 12
no game\team\side value found for team 13
no game\team\side value found for team 14
no game\team\side value found for team 15
no game\team\side value found for team 16
AI team: 1, AI side index: 0
CUnitTable::ReadModConfig()
parsing existing mod configuration file AI\KAIK013\CFGs\XTAPEV944.sdz.cfg

Did you change something, or just added logging?

I changed the char arrays to std::strings, but that's it. Thanks
for your help and patience, this might have gone unnoticed for a
long time if you hadn't pointed it out.

np, helping myself there too

Its a weird problem...I must admit I am not into C++ and especially not its type juggling, but i don't understand how it could result in this kind of behaviour. It seems it was working just fine for most people, but not for me. I think I had this problem in about 30% of all KIAK game set-ups.

Anyway, thanks for the fix :)

[edit]Oh, did you create a branch for the KAIK013-76b1 fixes somewhere in svn, or only on your system?[/edit]

Damn...cheered to early. I had not tested it enough :/

I just downloaded the new KAIK013-76b1-v3.dll you put up in the first page. To test it I let it run vs an AAI bot (on cooper hill). Unfortunately the problem is still there...the KAIK bot just idles.

I re ran this setup, but instead of the V3 I used the LOG-v2. This gave me the same problem:
CUnitTable::ReadTeamSides()
parsing GameSetup script script.txt
no game\team\side value found for team 0
no game\team\side value found for team 1
no game\team\side value found for team 2
no game\team\side value found for team 3
no game\team\side value found for team 4
no game\team\side value found for team 5
no game\team\side value found for team 6
no game\team\side value found for team 7
no game\team\side value found for team 8
no game\team\side value found for team 9
no game\team\side value found for team 10
no game\team\side value found for team 11
no game\team\side value found for team 12
no game\team\side value found for team 13
no game\team\side value found for team 14
no game\team\side value found for team 15
no game\team\side value found for team 16
AI team: 1, AI side index: 1

Then i tested it with: me vs LOG-v2, me vs LOG-v2 vs LOG-v2, AAI vs LOG-v2 vs LOG-v2, LOG-v2 vs AAI (note: different order than initial test, which was AAI vs LOG-v2).
In all these tests the KAIK worked normally.

So I have only one reproducable scenario, but without human players.

The v3 and LOG-v2 seem to behave the same and are interchangeable in my tests it seems. I assume the v3 is the same as v2 but without logging?

Kloot: maybe player/team number normalization may be a (the?) problem?

(IOW, nothing says the team # you are actually exists in script.txt)

Hmm... the function that reads the script does assume the
team numbers are already normalized, but that was safe at
the time since lobby clients were required to normalize them
anyway (and for the next Spring the whole thing is redundant
with the new GetTeamSide callback). But merijn's log suggsts
the TDF parser didn't find even a single [teamX] section in his
script, so I don't think lack of normalization is the problem.

merijn: yep, V3 is just V2-LOG minus the LOG part. The fixes
only live on my machine, they're temporary holdovers until the
next version of Spring comes out anyway. Why an AAI instance
would trigger the bug again is beyond me though, it shouldn't
make any difference at all as far as the script is concerned. I'll
hack up my own "parser" tomorrow, should be straightforward
enough.

Well, it could be unrelated to AAI at all. Its not unlikely i will be able to find the bug when trying other maps or bot combinations. Its pattern of occurence already was weird

I will try to find another bug configuration with a human player tomorrow. Or maybe you can include even more log statements to see what goes on.

Having a branch on the 0.76b1 tag and commit your changes against that couldn't hurt (and should be trivial?). But I don't have mingw installed anyway...so I can't compile KAIK myself right now. Sometime I want to have a go at mingw so i can mess around a bit

[edit]Oh, and I wonder if I am the only one to have this problem at all. If so, i'd be very suspicious about it....maybe I messed something up somehow?[/edit]

Ok, i found another testcase which fails.
Me, KAIK, KAIK vs KAIK vs KAIK.
So thats me and 4 bots. The first bot (allied to me) has the problem, and the other bots work just fine.

infolog/script/bot logs:
http://merijn.bofp.org/kaik_test_20080418.zip