Closed TheRedDaemon closed 10 months ago
Can you share a reproducible setup so I can fix this one? I am probably the culprit because I changed slightly how user configurations are handled (they got a dedicated atom now).
// The full representation of the config, becomes 'config-full' in the final config file.
FULL_CONFIGURATION = { ...uiDefaults, ...extensionConfigs, ...userCustomisations };
// If an option is reset by the user, i.e. trash customisations, then this is the value that it reverts to.
// "Defaults" is a confusing word I admit.
DEFAULTS_CONFIGURATION = { ...uiDefaults, ...extensionConfigs };
// 'config-sparse' in the final config file.
USER_CONFIGURATION = userCustomisations;
Uff, missed the notification for this one. It happens if you have a plugin that set AIs, which currently will always be handled as required. To simplify things, the AI gets locked, and while you can still click the portrait, it will just show the configuration of the AI. The button to add another one in the upper right will be disabled and should contain the name of the plugin and since most stuff fails silently, it is empty. So an active plugin with an AI config (not only an AI) should be enough to reproduce it.
config-sparse:
modules:
aiSwapper:
config:
ai:
rat:
contents:
suggested-value:
- name: Azula
language: en
root: ucp/plugins/azula-ai-0.0.1/resources/ai/Azula/
control:
aic: true
aiv: true
lord: true
startTroops: true
portrait: true
graphicsApiReplacer:
config: {}
plugins:
azula-ai:
config: {}
specification-version: 1.0.0
Found and fixed
Normally, the ai config window should disable the button to add an AI configuration and display the name of the plugin that causes this. This fails at the moment. No idea when it broke, but it should be fixed.