OTAI Thread
Moderators: hoijui, Moderators
It's excellent, the most aggressive AI, but still there's much to do.
I've testing it on Sparewood map (8x8 + 3 mountains) in "River Dale.sd7" (shortly on others with corresponding results).
(XTA 0.66 SE, OTAI 1.10)
- In singleplayer it works very good. When AI became larger and toke about 1/3 of map, the game became laggy with "Sync request for wrong frame". My units sometimes didn't move on my command etc. This situation ended only when I eliminated AI player:

- SP Replays are very large. I don't know what kind of data is stored in replays (necessary for Spring engine), but if all of the data are transfered to all of connected human players in multiplayer, it's good reason for losing sync or lagging. Logs are the same, but it don't affect the game i think (dataflow is too low for lagging based on hardware load). During playing the game on picture above, there was generated a 800 MB replay file. It wasn't longer than 1 hour and 30 min game. That means on average -> nearly 150 KB/s. It's enough to lag on net or on Spring engine.
- Multiplayer - 2 humans (100mbit lan), 1 OTAI, losing synchronization in circa 3 minutes, client game crushes:

Similar situations on other maps (omega, islandalpha), circa 80% crushes the client player (receiving data), 20% the hosting player.
- MP Replays: The same as SP replay. During 3 minutes was generated 8 MB replay (-> average 45 KB/s). By comparsion with NTAIXE7b - 25 min game (2 humans, 1 NTAI) 750 KB replay.
I've testing it on Sparewood map (8x8 + 3 mountains) in "River Dale.sd7" (shortly on others with corresponding results).
(XTA 0.66 SE, OTAI 1.10)
- In singleplayer it works very good. When AI became larger and toke about 1/3 of map, the game became laggy with "Sync request for wrong frame". My units sometimes didn't move on my command etc. This situation ended only when I eliminated AI player:

- SP Replays are very large. I don't know what kind of data is stored in replays (necessary for Spring engine), but if all of the data are transfered to all of connected human players in multiplayer, it's good reason for losing sync or lagging. Logs are the same, but it don't affect the game i think (dataflow is too low for lagging based on hardware load). During playing the game on picture above, there was generated a 800 MB replay file. It wasn't longer than 1 hour and 30 min game. That means on average -> nearly 150 KB/s. It's enough to lag on net or on Spring engine.
- Multiplayer - 2 humans (100mbit lan), 1 OTAI, losing synchronization in circa 3 minutes, client game crushes:

Similar situations on other maps (omega, islandalpha), circa 80% crushes the client player (receiving data), 20% the hosting player.
- MP Replays: The same as SP replay. During 3 minutes was generated 8 MB replay (-> average 45 KB/s). By comparsion with NTAIXE7b - 25 min game (2 humans, 1 NTAI) 750 KB replay.
This AI works great. It only has two major issues that I've found and they are probably related. The first is that sometimes constructions units will be building something and they just leave to go do something else and leave their unfinished building to decay. Second is that it is impossible to play OTAI in multiplayer due to OTAI issuing so many orders at once that it causes synch problems (like the ones explained above). Please fix this issue, I really want to play this AI in multiplayer!
I think to fix these two issues, I'll try some version of order caching, as AF has suggested, and see if that fixes the first problem.
The second issue is a bit more complex. There are several reasons that OTAI will have builders abandon projects:
A) A builder gets hit and runs away. It "forgets" what it was doing.
B) A building isn't getting built, so other builders are summoned from nearby, again "forgetting" what they were doing earlier.
C) Not enough resources. The projects is cancelled. (I don't remember if this was in this version or the next.
Overall, I want builders to abandon unnecessary projects during a resource crunch, but I'll have to find some way to make builders remember abandoned buildings and come back for them later.
I personally think that most of this sync stuff is caused by units getting stuck and sending the stuck message over and over again and it not getting resolved by the AI, but I don't have any definitive way to check this. It doesn't happen with human players because they don't check units 30 times per second.
The second issue is a bit more complex. There are several reasons that OTAI will have builders abandon projects:
A) A builder gets hit and runs away. It "forgets" what it was doing.
B) A building isn't getting built, so other builders are summoned from nearby, again "forgetting" what they were doing earlier.
C) Not enough resources. The projects is cancelled. (I don't remember if this was in this version or the next.
Overall, I want builders to abandon unnecessary projects during a resource crunch, but I'll have to find some way to make builders remember abandoned buildings and come back for them later.
I personally think that most of this sync stuff is caused by units getting stuck and sending the stuck message over and over again and it not getting resolved by the AI, but I don't have any definitive way to check this. It doesn't happen with human players because they don't check units 30 times per second.
I have found several unanticipated benefits of my command caching system, such as delayed commands, and filtering out of timeout commands so they arent wasting engine resources, prioritizing different commands, and possibly adding other types of commands and use it to balance how much cpu NTAI takes up.
But do look at NTAI and how it does it as I found a few problems I had to overcome to get it simply working.
Then a bit to clear up all the objects in those containers with executed == true, which comes after all the other repeat loops for the other levels of prioritization. Then all the usual stuff for eliminating commands when a unti si destroyed etc....
I usually have the a itneger as a global object so that the command cache thign works across all the NTAI's so it isnt made useless if you add more NTAI's, and I have this done in update around every 3 frames, at the start of which the first instance of NTAI resets a to zero.
But do look at NTAI and how it does it as I found a few problems I had to overcome to get it simply working.
Code: Select all
helper::Giveorder(TCommand tc){
if(tc.priority == tc_low){
lowcache.push_back(tc);
} else if( etc......
}
helper::update(){
int a = 0;
for(vector<TCommand>::iterator i = lowcache.begin(); i!= lowcache.end(); ++i){
if(a == COMMANDMAX) break;
if(i->executed == true) continue;
if(i->executed == false){
int j = cb->GiveOrder(i->command,i->unit);
i->executed = true;
a++;
if( j == -1) unitidle(i->unit);
}
}
}
I usually have the a itneger as a global object so that the command cache thign works across all the NTAI's so it isnt made useless if you add more NTAI's, and I have this done in update around every 3 frames, at the start of which the first instance of NTAI resets a to zero.
In regards to the most current version, I'd have to say this AI is rather unplayable. No matter what map, no matter what speed setting, no matter what mod I try that this AI supports, I always encounter the same problem. When playing AI I usually always play with 2.0 speed, sometimes 3.0, and a bit less frequently, I'll do 1.0 when I feel like taking my time (boredom). I always end up with a mass spam of overflow error messages in the text area of the game client. It's quite frustrating because this AI (IMO) is the most aggressive out of the available AI's. Simply put, it almost plays like a half-way decent human player. But no matter what, EVERY single game I try to play against this AI, I run into overflow error messages that lag the living end out of my box. I have a 2.5ghz CPU, with 2 gigs of dual channel 3200, which isn't really anything to boast about, but I'm sayin', this type of thing isn't being encountered because I have a crappy box or something.
Not trying to complain either; I'd love to play against this AI. It just always ends up with me exiting because I'm at 0.05fps with mass error messages spamming the game.
With previous versions of this AI, this problem was encountered, but not NEARLY as often. I'd estimate that I used to get a good 3-4 solid games out of this AI before I'd run into the overflow stuff.

Not trying to complain either; I'd love to play against this AI. It just always ends up with me exiting because I'm at 0.05fps with mass error messages spamming the game.
With previous versions of this AI, this problem was encountered, but not NEARLY as often. I'd estimate that I used to get a good 3-4 solid games out of this AI before I'd run into the overflow stuff.

- unpossible
- Posts: 871
- Joined: 10 May 2005, 19:24
Wouldn't a hack-ish fix just to self destruct the unit that's stuck? I've noticed AAI has problems with getting stuck units unstuck too. In most cases the unit is pretty cheap...and not in the base so it wouldn't be a big loss.
Some sort of record for how many time a unit is 'stuck' and can't reach destination...but not too long a list else too many units will start suiciding after they get stuck a few times at different locations
!
Oh yeah and that's not mentioning mountains/water/move orders to inaccessable locations...
in summary...perhaps a check of how many times a unit was stuck and how far it moved in the last 30 seconds or so
boom.
Some sort of record for how many time a unit is 'stuck' and can't reach destination...but not too long a list else too many units will start suiciding after they get stuck a few times at different locations

Oh yeah and that's not mentioning mountains/water/move orders to inaccessable locations...
in summary...perhaps a check of how many times a unit was stuck and how far it moved in the last 30 seconds or so

Veylon: If a con unit is going to abandon a project due to low resources, why not have it reclaim its current project? That's what most human players do when they begin stalling and have one or two items that they need resources for.
I've played this AI once or twice, and it really surprised me - I began expecting the usual AI slowness, and then got hit by raiders and hurt pretty badly. Then it took the middle on small divide and entrenched it pretty signifigantly. I won at the end, but only after bombarding the middle with artillary bots on the hills and taking out all the units on the AI's starting side.
Great work.
I've played this AI once or twice, and it really surprised me - I began expecting the usual AI slowness, and then got hit by raiders and hurt pretty badly. Then it took the middle on small divide and entrenched it pretty signifigantly. I won at the end, but only after bombarding the middle with artillary bots on the hills and taking out all the units on the AI's starting side.
Great work.
lol AF you're so wrong, and you're mad cuz ur wrong!AF wrote:hmm you advertised CAI in the metal algorithm thread, even posted a screenshot, it wont be long before we see mroe CAI shots, or OTAI blobz for 0.3 trying to pawn NTAI
ive posted one shot of it beetween all my existance in spring to show you that it wasnt krogothe's metal class's fault!!!
and one shot only!
and only after i posted something like 5 or 6 times trying to explain that , when you wouldnt believeme still! (lol..)
and just for the record lol, how many times do you saw me calling it on other threads ? lol AF wake up for like and stop advertising on other's thread like this
note: i left CAI so that argument is no longer valid.The overflow problem is a problem I had with NTAI too, and solved by caching commands, as I said further up this thread...
And if you think OTAI is agressive wait till you see NTAI XE7.5 on nanoblobz ;D
*AF, bedazzled by the shiny lights approaches the teeming halls of combobulation searching for a place to hide the sacred fondue cookies when he comes upon chocapic in the hall of the combobulator, 'here ye here ye' AF cries, to hasten to no reply he wonders, and all is alight in gargantuan cornflakes*
@ Unpossible: I had thought of suiciding stuck units, but as you said, there would be explosions all over without controls. I might add it as an option, depending, of course, on the size of the potential blast and what's around. I'd rather have them going bang in the dragon's teeth than next to my fusion generator, and I sure don't need the Commander going up in smoke!
I had been using a method of giving the unit a stop order and giving it a timeout for a bit, but switched for one that randomly sends the unit off for a 1000 units in a random directions.
Another couple of ideas I've had are to:
a) Reclaim the unit (no bang).
b) Keep a few air transports on hand to pick the unit up and carry it to the destination (if necessary). I'm working on a handler for this.
@ Nemo: I felt is was simpler to simply let the thing decay, rather than queue orders. Another thing I'm trying is for the update function to check if I'm nanostalling and then order the biggest offender to Stop, which'll lead it into going and doing something productive (I hope).
@ nfekti0n: I'm working on it. Feel free to complain.
@ AF: Have you considered using a priority queue? If you did that, you could just skim the top three or however many commands off the top and let STL handle the sorting for you. It'd free you up from having to only put the commands on the top or bottom.
I had been using a method of giving the unit a stop order and giving it a timeout for a bit, but switched for one that randomly sends the unit off for a 1000 units in a random directions.
Another couple of ideas I've had are to:
a) Reclaim the unit (no bang).
b) Keep a few air transports on hand to pick the unit up and carry it to the destination (if necessary). I'm working on a handler for this.
@ Nemo: I felt is was simpler to simply let the thing decay, rather than queue orders. Another thing I'm trying is for the update function to check if I'm nanostalling and then order the biggest offender to Stop, which'll lead it into going and doing something productive (I hope).
@ nfekti0n: I'm working on it. Feel free to complain.
@ AF: Have you considered using a priority queue? If you did that, you could just skim the top three or however many commands off the top and let STL handle the sorting for you. It'd free you up from having to only put the commands on the top or bottom.