Support multiple .json files in an AI directory structure

[Teiresias]

Scenario:

In an AI directory (e.g. the petra directory), place two additional json files, e. g. "data1.json", "data2.json". Content of these files is not important, a single pair of curly brackets was found sufficient.

Start 0AD in autoplay mode, e.g. as suggested in the readme.txt:

3) Observe the PetraBot on a triggerscript map:
 -autostart="random/jebel_barkal" -autostart-seed=-1 -autostart-players=2 -autostart-civ=1:athen -autostart-civ=2:brit -autostart-ai=1:petra -autostart-ai=2:petra -autostart-player=-1

What happens:

A "technicolor crash" occurs as the game is loading, starting with the error

ERROR: JavaScript error: gui/common/settings.js line 102 a.data.name is undefined loadAIDescriptions/<@gui/common/settings.js:102:28 loadAIDescriptions@gui/common/settings.js:102:13 loadSettingsValues@gui/common/settings.js:38:21 @gui/common/settings.js:27:20

at the loading screen.

This followed up by more errors after game starts:

ERROR: JavaScript error: gui/common/settings.js line 102 a.data.name is undefined loadAIDescriptions/<@gui/common/settings.js:102:28 loadAIDescriptions@gui/common/settings.js:102:13 loadSettingsValues@gui/common/settings.js:38:21 @gui/common/settings.js:27:20 reallyStartGame@gui/loading/loading.js:22:9 ERROR: JavaScript error: gui/session/session.js line 5 can't access lexical declaration 'g_Settings' before initialization @gui/session/session.js:5:20 reallyStartGame@gui/loading/loading.js:22:9 ERROR: JavaScript error: gui/session/session.js line 245 can't access lexical declaration 'g_Settings' before initialization init@gui/session/session.js:245:6 reallyStartGame@gui/loading/loading.js:22:9 ERROR: GUI page 'page_session.xml': Failed to call init() function ERROR: Errors executing script event "Tick" ERROR: JavaScript error: gui/session/session.js line 579 can't access lexical declaration 'g_Settings' before initialization onTick@gui/session/session.js:579:6 __eventhandler2 (Tick)@session Tick:1:1

The AI(s) do not operate.

Behavior reproduced with rev. 24432.

Background information:

Existance of additional JSON files in an AI directory (structure) apparently never came up till now. The C++ AI loader at ​https://svn.wildfiregames.com/public/ps/trunk/source/simulation2/components/ICmpAIManager.cpp just loads each JSON file found below the simulation/ai directory as a separate AI specification w/o checking its content. Furthermore, the JS code in ​https://svn.wildfiregames.com/public/ps/trunk/binaries/data/mods/public/gui/common/settings.js  (function loadAIDescriptions(0)) assumes each loaded JSON structure is a valid AI with "name" and "description" entries.

This affects JSCover instrumentation, since JSCover produces a coverage.json file with coverage data, and the tool itself (?-not sure) contains a version.json file. This makes up the additional JSON files which trigger the problem.

It is unknown why a single additional JSON file does not trip the error cascade.

A most easy fix can be placed into the settings.js by filtering off AIs w/o "name" or "description" elements, but is probably not worth the effort, since this affects AI writers only. Ticket created for documentation purposes.

[Freagarach]

Sounds like ​Phab:D1545?

[Teiresias]

Thanks, indeed when creating the ticket I vaguely remembered offering a similar modification some time ago, but was unable to recover it.

What I could still remember was that "marking" the JSON files describing the AIs was not applauded due to the change effort required for a consistent implementation (see smileys comment in D1545 at 2020-09-28).

Since the original D1545 did not meet much demand and given the large number of tickets currently queued up, I indented this ticket to just describe what's happening, in case someone else meets this behavior in the future, to avoid analyzing it again. In such a situation, patching the settings.js locally may be the way to go. For an actually clean solution I would prefer to modify the C++ code to avoid the Engine.GetAIs() function returning defective data in the first place.

[Stan]

Dupe at #6267