OTAI Thread

[Veylon]

Actually, several containers sort on their own, whenever something is added to them (set, mostly). All you need is to define a less-than operator to deal with them.

Code: Select all

// Header
class UnitInfo
{
  UnitInfo();
  ~UnitInfo();
  int priority;

  friend operator<(UnitInfo &A, UnitInfo &B);
};

operator<(UnitInfo &A, UnitInfo &B);

// CPP File
operator<(UnitInfo &A, UnitInfo &B)
{
  return A.priority < B.priority;
}
[code]

And then you can have a set of this class. If you don't care how they are sorted, just have the operator function return false.

BTW, forget about the priority_queue I was talking about. It was removed in the 2003 Microsoft STL. I've been using the above method, but with the set container instead, and pulling off the front with begin().

I have decided to use your command limiting idea, and it has been working quite well at reducing lag, even when a unit is stuck in a factory and can't get out. However, spring has been crashing really bad every now and then, so I'm going to have to figure out why before I can release a new version.

[AF]

I'd also advise some way of sorting priorities better.

For example if NTAI is issuing 5 scout commands per frame, 10 construction commands, and 10 atatck commands, and they're prioritised in that order, with a max par frame of 6, then all scouting works, construction is terrible and units stall everywhere, and attacking is nonexistant.

This may never happen in an ordinary game but in some mods this is a big problem (nanoblobz and lilguys joo own for example, or any really large game).

For that I think either we need some really freaky prioritisation code to change priorities based on whats been executed and whats happening without incurring more cpu wastage which would kill NTAI or OTAI on big games or mods like nanoblobz

[Veylon]

I've been sorting by the command type. Attacks and builds and self-destructs get high priority, move gets medium, and reclamation and resurrection get low priority.

What I would like is a way of randomly choosing a pending command, but weighted for priority, so that sometimes a low-priority command gets executed first, but ususally a high-priority one does.

Another possibility is to find someway to alter the priority by time, so that older commands move up in priority, so that all commands eventually get executed, even extremely low-priority ones.

[AF]

Not quite, I think time plays a big factor, afterall a command has a sense of urgency, however I also believe that all commands should have a timeout to prevent stall or waiting. So that means there should be a rise in urgency followed by a fall in urgency of that command beign issued.

I also think scouting should take a higher priority than building, sicne otherwise you could be left with idle units on the battlefield.

Also a grouping mechanism to find untis with the same commands and group them together.

I'd also imagine changing the int unit; in my TCommand structure to a set<int> so that a group can be formed then givegrouporder() be issued instead so that perhaps some engine side benefits can be entailed if they exist nwo ro in the future..

That and perhaps a random increase on the total priority value generated with a maximum increase/decrease being 40%

[Veylon]

All right! New Version: OTAI 1.11

- Command Buffering has replaced most calls to the callback, limit of eight commands per frame.
- Finally got around to using Krogothe's new metal class (with minor changes).
- Adjusted when/how to put up defenses so that a field of LLTs aren't used to cover one mex.

@AF:

I would argue that not all that many buildings are going to be put up a second, so they might as well be put at max priority to get going, instead of having to wait for a lot of attackers to get their marching orders first. The attack won't be set back more than a fraction of a frame or so (I'm using eight commands/frame). I've actually decided to skip buffering for build commands, since they come so rarely, relatively speaking, and there is no real need. Anyway, you can take a look at my new code and see what you think. At least this is a new topic for debate!

[nfekti0n]

About 10 minutes into a game on desertforts_v2 resulted in a very familiar yet much more potent desync problem, where my entire computer became unresponsive. A hard restart brought things back to normal, at which point I decided to try again, this time with OTAI_LL. Needless to say at around the same point in time the exact thing happened, and again my machine froze.

The log was not saved.

Going to give it a try on various other maps (my normal map for "testing" AIs is river dale, which seems to be very AI-friendly.) and I'll post my results with those.

[jolt8me]

dysynch error about 20 minutes into the game. Up untill that point it played really well. started getting a dysynch error and then my computer all of a sudden crawled. i hate to shut down spring. Heres what the last portion of the log file said.

CGlobalAI::UnitBuild(4807)Building Factory...
ARMALAB BT=290 MI=12 EI=60 Advanced Kbot Lab: 896
ARMVP BT=103 MI=8 EI=18 Vehicle Plant: 768
Unit chosen: Advanced Kbot Lab
Putting on Idle List
BOWa....pBOSleep00:52:05[02]BO_ThreadSearch(0F0F6460)
BOSleepBOSleepBOWakeBOWakeBOSleepBOW....

that went on and on....then it said.

GlobalAI()
Closing TrigTables...
Deleting Strategic Air Command...
StrategicAirCommand::~StrategicAirCommand()~
Deleting Metal Handler...
00:52:05[02] MetalHandler::~MetalHandler() Freeing Reservations...
Deleting SiteData...
~
Deleting UnitDef Handler...
93752 UnitDefHandler::~UnitDefHandler()
Deleting UnitDefList
Deleting UnitTypeInfo
Deleting Equivalents
~
Deleting Attack Teams... 600:52:05[02] AttackTeam[6]::~AttackTeam()~
900:52:05[02] AttackTeam[9]::~AttackTeam()~
500:52:05[02] AttackTeam[5]::~AttackTeam()~

Deleting Defense Handler...
93752 DefCon::~DefCon() Deleting DefMap
~
Deleting Radar Handler...
00:52:05[02] RadarHandler::~RadarHandler() Deleting Radar Map
~
Deleting Scout Team Handler...
_ScoutTeam::~_ScoutTeam() Deleting ExtraLocX
Deleting ExtraLocY
~
Deleting Building Organizer...
00:52:05[02]BuildingOrganizer::~BuildingOrganizer()
Deleting Availability
~
Deleting High Energy Handler...
00:52:05[02]HighEnergyHandler::~HighEnergyHandler()Deleting Game Information...
Deleting Dragon's Teeth Handler...
00:52:05[02]DTHandler::~DTHandler()~Deleting Command Softener...
Closing and Deleting Logfile...

[AF]

Past experience has shown the best buffermax is 5, which can be surpassed every now and again, but 6 gives Argh overflows playing nanoblobz, and 5 is the max I can get away with.

Also building isn't just for actual buildings but remember it's all the units too which can be a heck of a lto after 40 minutes or so when you're buffering commands like that. Even more so when you have multiple AI instances.

[ignesandross]

Much improvement in some sectors, but the lag starts earlier now. Using the B command in-game after pausing at first sign of lag, I see the following:
http://s92183354.onlinehome.us/eisenfaust//lag.jpg
Clearly, the Sim Time and Unit Handler are the two biggest culprits.

[ignesandross]

In both 1.11 and 1.12 I found that if multiple units attack the enemy commander simultaneously, he just twitches and lets them kill him. I'm sure he just can't decide who to kill first. It makes for a swift kill on VallesMarineris_V4, since he charges across the canyon to build a kbot plant like 11 minutes into the game.

Edit: Killed him in just under 3min by building just a kbot plant and ordering 1 peewee with repeat toggled. It only took two peewees ariving at once to confuse him enough to lock up.

[AF]

If you have a delay system I think ti would be a good idea to stagger d-gun commands then after the first one has been made, maybe using a counter, incrementing by a second or two each time it fires, and decrementing it on every unitidle()

[krogothe]

If you have a delay system I think ti would be a good idea to stagger d-gun commands then after the first one has been made, maybe using a counter, incrementing by a second or two each time it fires, and decrementing it on every unitidle()

queue dgun commands? you gotta be crazy!

[AF]

crazy? not at all! I do it in XE8 and it rpevents the commander from switchign betwene multiple targets so fast it wont fire.....

That and dgun commands are shove at the front of the queue automatically

[bamb]

Same comment as ignes and submarine: otai is unusable in current state, it starts lagging like hell after a while. Even if I pause the game, it's painful even to scroll the screen.

I don't understand why it should be like that, humans give like 1 command per second and still manage to beat AI:s.

[AF]

not always, howabout queuing up untis in a factory with shift or ctrl held? Or dragging a row of buildings? or Selecting a group fo untis and issuign a command?

Eitherway I found that if NTai issues more than 5 commands per frame it causes overflows which is pretty wierd considering that there are 30 frames per second on average....

Otherwise tests of XE8 v OTAI show OTAI looses but I've never seen those lag problems exept for when I try to type .verbose which is an NTai command but it affected OTAI as shown when i looked at the debugger output

[ignesandross]

I haven't seen any lag since the 1.12 release. Just the comander issue. I'd be glad to beta-test fixes for this issue.

[ignesandross]

UPDATE: I found a way to make the commander fire. This time the commander was in "confusion mode" when interrupted between attacking my construction kbot (who was reclaiming him) and, I can only guess, reclaiming or building. When I took a couple screen shots in succession, he did shoot the kbot once before going back into his trance. I repeated the same steps several times with the same result before he was completely reclaimed.

[AF]

jolt8me or a moderator could you put a few new lines in that post so it isnt stretching the webpage to 20 times tis normal width.....

[Triaxx2]

Or just delete the blasted lines that are causing it.

[ignesandross]

'twas my screenie's fault I turned it into a link