Opened 6 years ago

Closed 6 years ago

#2180 closed defect (fixed)

Aegis AI errors on Skirmish maps

Reported by: michael Owned by: wraitii
Priority: Release Blocker Milestone: Alpha 15
Component: UI & Simulation Keywords: AI skirmish maps
Cc: wraitii, dileepa.ameresekere@… Patch:

Description (last modified by historic_bruno)

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

Attachments (6)

AIFix_.patch (2.5 KB) - added by wraitii 6 years ago.
AIFix_.2.patch (4.2 KB) - added by sanderd17 6 years ago.
AIFix_.3.patch (6.0 KB) - added by wraitii 6 years ago.
AIFix_.4.patch (9.9 KB) - added by wraitii 6 years ago.
AIFix_.5.patch (10.3 KB) - added by wraitii 6 years ago.
AIFix_.6.patch (10.8 KB) - added by sanderd17 6 years ago.

Download all attachments as: .zip

Change History (31)

comment:1 Changed 6 years ago by historic_bruno

Cc: wraitii added
Description: modified (diff)

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.

comment:2 Changed 6 years ago by 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).

comment:3 Changed 6 years ago by 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.

comment:4 Changed 6 years ago by wraitii

Owner: set to 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).

comment:5 Changed 6 years ago by Dileepa

Cc: dileepa.ameresekere@… added

comment:6 Changed 6 years ago by 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.

comment:7 Changed 6 years ago by 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.

Changed 6 years ago by wraitii

Attachment: AIFix_.patch added

comment:8 Changed 6 years ago by 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.

comment:9 Changed 6 years ago by 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.

Changed 6 years ago by sanderd17

Attachment: AIFix_.2.patch added

comment:10 Changed 6 years ago by 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.

comment:11 Changed 6 years ago by 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).

comment:12 Changed 6 years ago by 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.

Changed 6 years ago by wraitii

Attachment: AIFix_.3.patch added

comment:13 Changed 6 years ago by 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.

comment:14 Changed 6 years ago by 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.

comment:15 Changed 6 years ago by 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.

Changed 6 years ago by wraitii

Attachment: AIFix_.4.patch added

comment:16 Changed 6 years ago by 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).

comment:17 Changed 6 years ago by 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.

comment:18 Changed 6 years ago by 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.

comment:19 Changed 6 years ago by 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.

comment:20 Changed 6 years ago by sanderd17

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

Changed 6 years ago by wraitii

Attachment: AIFix_.5.patch added

comment:21 Changed 6 years ago by wraitii

Does this fix the issue?

Changed 6 years ago by sanderd17

Attachment: AIFix_.6.patch added

comment:22 Changed 6 years ago by 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.

comment:23 Changed 6 years ago by leper

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

comment:24 Changed 6 years ago by 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.

comment:25 Changed 6 years ago by wraitii

Resolution: fixed
Status: newclosed

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.

Note: See TracTickets for help on using tickets.