Aegis AI errors on Skirmish maps

[michael]

Skirmish maps now work as advertised, but the AegisBot AI now gives continuous errors.

WARNING: JavaScript warning: simulation/ai/common-api-v3/shared.js line 344 reference to undefined property this._entities[id]
ERROR: JavaScript error: simulation/ai/common-api-v3/shared.js line 344 TypeError: this._entities[id] is undefined ([object Object])@simulation/ai/common-api-v3/shared.js:344 ([object Object])@simulation/ai/common-api-v3/shared.js:218
ERROR: JavaScript error: simulation/ai/common-api-v3/gamestate.js line 584 TypeError: template is null ([object Array])@simulation/ai/common-api-v3/gamestate.js:584 ([object Object],[object Array],[object Array])@simulation/ai/aegis/headquarters.js:296 ([object Object],[object Object])@simulation/ai/aegis/headquarters.js:270 ([object Object],[object Object],[object Array])@simulation/ai/aegis/headquarters.js:1036 ([object Object])@simulation/ai/aegis/aegis.js:160 ([object Object],[object Object])@simulation/ai/common-api-v3/base.js:68 @:0

[historic_bruno]

I noticed this while testing, also qBot seems to work fine. It looks like a problem in API v3 rather than Aegis, maybe it's not picking up changes during turn 1.

[historic_bruno]

There is some logic to skip turn 0 in both Aegis and the shared component, I don't know why. That keeps it from constructing the new entities created by SkirmishReplacer, when it later receives events for them, that's when the errors occur. But removing those checks only led to other errors in Aegis (e.g. undefined references in its dropsite logic).

[sanderd17]

These errors were not present in my original testing, but I know some things have changed since.

Now aegis binds his workers and buildings to a certain base (read CC). And the base only works with its own workers. In older versions of the AI, the workers were just queried every time, and if they were idle, or gathering an unneeded resource, they were re-assigned.

[wraitii]

Skipping turn 0 is done because this led to Aegis dealing with entities twice in some cases. I'll have to change the logic to read entities from the events only, which ought to be simple enough (though since I expect it to bug oddly, it'll probably take a few days).

[sanderd17]

I think the problem is bigger than just skipping turn 0. Even if you transform the objects only on turn 1, it doesn't work. I've also tried sending the MT_EntityRenamed message, which also happens on unit promotion, but this also doesn't help.

As other side effect, I've seen that the AI loses all promoted units from his army. When a unit is promoted, it becomes a different entity, the AI fails to convert it, so it doesn't belong to a base anymore and is uncontrolled. This isn't very noticable though, as the AI doesn't have a "retreat" tactics. So the units are in hostile environment and keep fighting until they die anyway.

[wraitii]

Haven't yet managed to give a look at this. You might be right, though... I'll need to make the common API stronger against entity renaming. Might fix the issue altogether, actually.

Thanks for the report.

[wraitii]

Attached is a blind patch for support of entity renaming. I'm not sure this works or fixes the issue, for that matter, but I'd like it if somebody could test it.

[sanderd17]

When I disable the ResourceDropsite component of the skirmish entities (they're not needed, they're just inherited by default), it stops the error messages, but the workers and CC aren't found. So the AI places some foundations but nobody builds it, as it can't find nor create workers.

[wraitii]

Managed to get my compilation working. You mentioned removal of the "entityrenamed" message? I don't get the same errors as you did right now when starting a game.

[sanderd17]

With the second patch, I also don't get any errors, but the AI simply doesn't react. With only the first patch applied, I still get the same errors (note that the second patch is still a WIP, with debug output and such).

[wraitii]

Ok, so we're most likely going down the right path here. I'll try to test some more things later this afternoon, but this looks promising.

[wraitii]

New version (requires recompilation). SO I changed how initializatio is handled, so there is now a call to ApplyEntitesDelta on turn 0 and it works properly. However AI still errors out as there is some issue with the handling of the renaming in the base managers themselves (as they're initialized before the change itself). This will need some more work.

In the meantime, we could also move the entity swap in skirmish maps to before the AI pre-initialization, which would probably fix those issues.

[sanderd17]

We can move the skirmish entities replacement as early as you like. But it shouldn't be run in Atlas, unless the simulation run in Atlas is started.

Currently, it switches quite simply the first time the OnUpdate message is send. Which means this is at turn 0. But you can just use the same code to switch at any other point.

[Dileepa]

Hi wraitii and sanderd17,

I applied the 3 patches, compiled and played the game and can confirm the Javascript error messages are no longer appearing. However the AI player is still idle.

[wraitii]

This is a proper fix for the issue. I'm not experiencing any error and the AI runs normally.

It's done by having the AI handle entity renaming, and by moving the point at which entities are replaced to before the "InitGame" function (in InitGame.js) is called.

However, if I don't call the component's manager "flushdestroyedcomponents" function after that, the "destroy" message appear on the first turn, which means that replaced entities still "shadow exist" at turn 0, which resulted in the same bug as above.

I'm not sure there is a nice way to force a destroy message to be sent at once.

This is slightly ugly, but imo is what makes the most sense (the entities are replaced before the game is even properly started).

[sanderd17]

The current message is sent too early. When you open a map in Atlas, the skirm entities are already replaced by civ-specific entities, so you can't save the map anymore without losing those entities.

[sanderd17]

Unless we have a way to differentiate between an Atlas simulation run and a genuine game run on the JS side. Then we could just not replace them when in Atlas, until the first turn, but replace them immediately in other games using the latest patch.

AIs won't work in Atlas, but they're never used anyway.

[wraitii]

There's one if we allow ourselves to use g_AtlasLoop (that's not the right name, but it's something along those lines).

BTW, I feel like the way we handle how games start is really, really messy.

[sanderd17]

Yeah, it's strange that the ReallyStartGame function is executed when you launch Atlas (and not really start a game).

[wraitii]

Does this fix the issue?

[sanderd17]

Your last patch didn't replace the entities when a simulation game was started in Atlas. I just added a second replacement point. For Atlas, the entities aren't replaced before game start, so then they're replaced on the first turn.

This will work fine as long as AI players don't play in Atlas simulation games (which isn't the case now).

I'm quite sure the code works, so if the style is ok (I'd never call the style of the start-game code "good"), then it can be committed IMO.

Thanks for working on this, wraitii, I couldn't have done it myself.

[leper]

Some comments would be nice (at least for the flushing).

[wraitii]

OK, then I'll add some comments and commit it tomorrow. For A16 I might just want to rework the early game, since it's fairly ugly now, so I'll stress that this should be temporary code.

[wraitii]

I of course forgot to link my commit ([14285]) to this ticket (been a while…)

I've committed basically your patch with a few comments here and there. It's good enough for me.