I think it's time to just have one OTAI thread instead of a new one for every version. Here it is.
Links to files:
DLL: http://www.fileuniverse.com/?p=showitem&ID=2779
Source: http://www.fileuniverse.com/?p=showitem&ID=2780
http://www.geocities.com/veylon_ii/TASpring
Current Version: 1.11
Post comments, opinions, stories, etc. Below
OTAI Thread
Moderators: hoijui, Moderators
OTAI Thread
Last edited by Veylon on 28 Mar 2006, 23:13, edited 7 times in total.
The *d version crashes on startup, on ANY map.
And the otai.dll is better than the last, but unplayable, because the cpu hog problem got even worse. After at most 3 or 4 minutes the ai starts using 3-4 seconds of cpu time during its turn every minute or so, completely freezing the game for that time (with increasing frequence, after 10 minutes on wideopencombat it was stop motion).
Freezes seem to coincide with finishing of structures, so maybe the algorithm who searches for new building spots runs into a loop or something?
Check you code for something that fucks up, or abort the ai call if it stalls the game engine long enough for the game to desync...
Edit:
Absolutly unplayable. After about 10 minutes gametime, it just freezes 95% of the time, runs for 10 or 15 gameticks and freezes for 20 seconds again. Its definitively NOT the logging, as the debug screen shows that time spend is only about 30% in globalai.
_Please_ take a look at it. Its the only ai that doesnt crash on just about everything, so it really sucks that its crippled like that.
Edit2:
I just noticed that the problem is MUCH less pronounced when running only 1 ai (it will happen, but much later and not as consistently). Running 3 ais with high ressources will cause it in the first 5 minutes.
And the otai.dll is better than the last, but unplayable, because the cpu hog problem got even worse. After at most 3 or 4 minutes the ai starts using 3-4 seconds of cpu time during its turn every minute or so, completely freezing the game for that time (with increasing frequence, after 10 minutes on wideopencombat it was stop motion).
Freezes seem to coincide with finishing of structures, so maybe the algorithm who searches for new building spots runs into a loop or something?
Check you code for something that fucks up, or abort the ai call if it stalls the game engine long enough for the game to desync...
Edit:
Absolutly unplayable. After about 10 minutes gametime, it just freezes 95% of the time, runs for 10 or 15 gameticks and freezes for 20 seconds again. Its definitively NOT the logging, as the debug screen shows that time spend is only about 30% in globalai.
_Please_ take a look at it. Its the only ai that doesnt crash on just about everything, so it really sucks that its crippled like that.
Edit2:
I just noticed that the problem is MUCH less pronounced when running only 1 ai (it will happen, but much later and not as consistently). Running 3 ais with high ressources will cause it in the first 5 minutes.
1.06 has several problems:
1. Even with a edited set of cfgs, it cannot handle Spring game designs that do not include mexxes, windmills, geos, or fusions. It crashes, sooner or later. Basically, it appears to be stable... with XTA, or something that's basically the same game design.
I think when I get done with my current project... my first mini-project for the Spring community will be to release a series of very basic mini-mods that show everybody some of possible game variants, so that AI designers can test their software against more than XTA and the other large, polished (and uber-complex) mods.
2. I, too, have seen massive CPU usage over and over again, especially with multiple AIs. Methinks it's when the AI is trying to determine where/how to attack a player. This may be the cause of the crashes, too- the logs don't really tell me anything useful.
3. This thing is creating logs that are GIGUNDOUS. GINORMOUS. HUGE. This cooresponds to the huge lags. But it doesn't necessarily coorespond to the crashes. The crashes happen whether or not I see a lot of lag.
Other than these problems... it seems to be a quantum leap forwards. I've seen it build defenses that aren't completely worthless (like, for example, clusters of RTs for air defense), and it attacks swiftly and viciously, and is using Air (badly, but still- OTA's AI never used it well either, so you're already on-par). Haven't seen it use Water yet, but I haven't tested it on a water map yet (and I'll probably have to hand-tweak the cfg).
So... overall... this is a major improvement, and it certainly feels a lot "smarter" than previous AIs I've looked at. But the crashing kind've dampens my overall enthusiasm
[/code]
1. Even with a edited set of cfgs, it cannot handle Spring game designs that do not include mexxes, windmills, geos, or fusions. It crashes, sooner or later. Basically, it appears to be stable... with XTA, or something that's basically the same game design.
I think when I get done with my current project... my first mini-project for the Spring community will be to release a series of very basic mini-mods that show everybody some of possible game variants, so that AI designers can test their software against more than XTA and the other large, polished (and uber-complex) mods.
2. I, too, have seen massive CPU usage over and over again, especially with multiple AIs. Methinks it's when the AI is trying to determine where/how to attack a player. This may be the cause of the crashes, too- the logs don't really tell me anything useful.
3. This thing is creating logs that are GIGUNDOUS. GINORMOUS. HUGE. This cooresponds to the huge lags. But it doesn't necessarily coorespond to the crashes. The crashes happen whether or not I see a lot of lag.
Other than these problems... it seems to be a quantum leap forwards. I've seen it build defenses that aren't completely worthless (like, for example, clusters of RTs for air defense), and it attacks swiftly and viciously, and is using Air (badly, but still- OTA's AI never used it well either, so you're already on-par). Haven't seen it use Water yet, but I haven't tested it on a water map yet (and I'll probably have to hand-tweak the cfg).
So... overall... this is a major improvement, and it certainly feels a lot "smarter" than previous AIs I've looked at. But the crashing kind've dampens my overall enthusiasm
[/code]yay! I've been telling people I'm sick of seeing the same OTA conventional stuff, maybe this'll kick them into gear.I think when I get done with my current project... my first mini-project for the Spring community will be to release a series of very basic mini-mods that show everybody some of possible game variants, so that AI designers can test their software against more than XTA and the other large, polished (and uber-complex) mods.
@Veylon: As for logging, I was thinking that I'd end up turning the logging into some basic byte code things, afterall the majority fo the log code is repeated strings over and voer again with different parameters, and the times and such could easily eb replaced by a nubmer and a converter generating the end result file in human readable format rather than having it all in one big mass, running into huge amounts of space. When I get round to doing anythign like that I'll contact you about it and I might re-engineer it somewhat so we can both use it.
Good Input!
I haven't tried it with more than 2 OTAI's recently, so I haven't seen the CPU problems as much. I'll try having it keep track of how much time it takes to do different things and seeing what I can streamline.
I also haven't tried much for mods beyond XTA/AA (1.07, not yet out, handles AA)
As for the logs, I rarely see one more than 5 MB, but that's still pretty big. Good advice from AI, on that.
I, too, would like to have some non-OTA minimods to practice with.
Oh, and I do keep a changelog in the readmes, but haven't here. Yet.
I haven't tried it with more than 2 OTAI's recently, so I haven't seen the CPU problems as much. I'll try having it keep track of how much time it takes to do different things and seeing what I can streamline.
I also haven't tried much for mods beyond XTA/AA (1.07, not yet out, handles AA)
As for the logs, I rarely see one more than 5 MB, but that's still pretty big. Good advice from AI, on that.
I, too, would like to have some non-OTA minimods to practice with.
Oh, and I do keep a changelog in the readmes, but haven't here. Yet.
Rarely bigger than 5MB?
I would suggest you create a new spring install and use the tauniverse version of your ai then, as surely something on your system is configured differently.
If your ai doesnt crash, the logs are about 500MByte per hour of gameplay. So after a game with several AIs its often 1GB or more (as those games are abborted when it gets too bad).
I opened the logs and it seems that it outputs for EVERY construction units, for _every_ gametick, a rather long list of number - unit/name/something (when trying to decide what to do with the unit).
Changing the settings in the log.cfg (or how it is named) doesnt change anything, it seems, either. I set everything to "0" (as in no logging) and still got a 900Mbyte logfile...
And it seems that _MOST_ cases of slowdown are really logging-related, as they dont show in the "b" system load. it 30% or something and still running at only 2fps..
I would suggest you create a new spring install and use the tauniverse version of your ai then, as surely something on your system is configured differently.
If your ai doesnt crash, the logs are about 500MByte per hour of gameplay. So after a game with several AIs its often 1GB or more (as those games are abborted when it gets too bad).
I opened the logs and it seems that it outputs for EVERY construction units, for _every_ gametick, a rather long list of number - unit/name/something (when trying to decide what to do with the unit).
Changing the settings in the log.cfg (or how it is named) doesnt change anything, it seems, either. I set everything to "0" (as in no logging) and still got a 900Mbyte logfile...
And it seems that _MOST_ cases of slowdown are really logging-related, as they dont show in the "b" system load. it 30% or something and still running at only 2fps..
OK, now I see what you mean about the big logfiles. They've finally been showing up for me over the last week. I've been cutting away at the log entries for 1.07, so hopefully they'll be solved then.
I'm going to try to find a debugger for CodeBlocks, or else go back to developing in Visual Studio, because the log files haven't been cutting it lately for finding out what's wrong.
The log.cfg isn't used yet, and I won't include that file anymove until it is used. Sorry about the confusion. I'll have to fix it.
I'm going to try to find a debugger for CodeBlocks, or else go back to developing in Visual Studio, because the log files haven't been cutting it lately for finding out what's wrong.
The log.cfg isn't used yet, and I won't include that file anymove until it is used. Sorry about the confusion. I'll have to fix it.
Through the much-maligned process of logging I have located some CPU-hogging bugs and fixed them:
- Building. Many values have been precalculated, either at init or in the beginning of the function.
- Stuck Units. I've changed this a few times and now have units given an order to randomly move and then get put on the stuck list to chill out for a few seconds.
- Resurrectors: Tried to resurrect DT other non-resurrectable features. Then they looped endlessly.
- Stuck Scouts: Kept trying. Another long loop.
- Cut down on logging for things that already work fine.
I'll also release a non-logging version of the AI DLL for those who don't like such things.
- Building. Many values have been precalculated, either at init or in the beginning of the function.
- Stuck Units. I've changed this a few times and now have units given an order to randomly move and then get put on the stuck list to chill out for a few seconds.
- Resurrectors: Tried to resurrect DT other non-resurrectable features. Then they looped endlessly.
- Stuck Scouts: Kept trying. Another long loop.
- Cut down on logging for things that already work fine.
I'll also release a non-logging version of the AI DLL for those who don't like such things.
New version of OTAI! 1.07!
Get it from the link in the first post. Get the MSI to make installing a little simpler. Get the demos and see it in action.
Change log from 1.06 (see readme):
Get it from the link in the first post. Get the MSI to make installing a little simpler. Get the demos and see it in action.
Change log from 1.06 (see readme):
Code: Select all
/------------------\
| Changes from 1.06 >---------------------------------------------------------
\------------------/
- Now comes with non-logging DLL.
- Major reordering of Build code, many values now precalculated to save CPU time.
- Commander usually doesn't D-Gun other commanders. Runs away instead.
- Construction units run away when attacked.
- Adjusted lower threshold for the High Energy devices, so that the energy doesn't
get stuck in situation where all the metal makers are on, but the level is at
25-50% where they aren't turned off, but factories won't build. Adjusted to 51%.
- Added Dragon's Teeth Rings. Not that great, but it's a start.
- Bugfix: Attack teams once again allow multiple types of units, but reasonably.
(e.g. Vehicles in Kbot Group, Hovers in any Group, No Kbots in Ship Group)
- No longer saves unit info to a file. This (apparently) caused problems with the
AA mod. I'll put it back in when I figure out what the heck's going on.
- Bugfix: Scouts no longer try to move many, many times in one frame. Now, if they
fail, they get put in the StuckQueue where they belong.
- Changed some timings to reflect acceptance of knowledge that the game simulation
(and AI) run at precisely 30 FPS.
- Minor Bugfix: Resurrectors no longer try to resurrect DT. This resulted in a very
long and CPU-consuming loop.
- Dull axe taken to Logging output. Result: Smaller and hopefully clearer logfiles.
cool, i'll try it out ...
edit:
ok i had some very nice aai vs otai matches on comet catcher - the philosophy of our aais is completely different.
i noticed some severe performance problems when otai began dgunning a lot of aai units. i dont know if this a problem of your dgunning algorithm or if its aai or the engine...
btw: it's pretty funny to watch otai's nano-towers repairing aai's combat units :)
anyway, good job
greetings alex
edit:
ok i had some very nice aai vs otai matches on comet catcher - the philosophy of our aais is completely different.
i noticed some severe performance problems when otai began dgunning a lot of aai units. i dont know if this a problem of your dgunning algorithm or if its aai or the engine...
btw: it's pretty funny to watch otai's nano-towers repairing aai's combat units :)
anyway, good job
greetings alex
It STILL has the studder bug (freezing the game for a second or two when deciding for something to build or target) when using two or more ais.
And its MUCH stronger than before, but i have to say that the new AAI version is only a bit weaker. on some maps it kills otai reproducably, on others its killed _by_ otai mercilessly.
Good work on both submarines and your sides.
And its MUCH stronger than before, but i have to say that the new AAI version is only a bit weaker. on some maps it kills otai reproducably, on others its killed _by_ otai mercilessly.
Good work on both submarines and your sides.
