move mod-related CBA settings back to missions

[freghar]

With the introduction of the CBA settings framework, many mods (ACRE2, ACE3, Achilles, etc.) made use of it or plan to make use of it soon-ish, moving bits of functionality from editor modules to the CBA settings framework.

The CBA settings framework is fairly flexible and differentiates between client, mission and server settings, with priority logic (mission can overwrite client, server can overwrite mission), which unfortunately also creates inconsistencies across clients, missions or servers.

Currently, we have some ACRE2 settings forced by server (which I set back when ACRE2 removed the module settings) and IIRC nothing else.

The idea behind this ticket/issue is to move these settings (and extend them with ACE3 settings removed from modules) back into the mission, so that the mission behaviour is consistent regardless of the server used (incl. local SP/MP preview) and also so that we don't have the settings fragmented across our infrastructure.

This would utilize logic which we already have in our default modules for setting vanilla mission defaults (mission type, respawn settings, etc.), so the settings would be set in the mission upon placing the modules composition. This would also reduce the important persistent server state to the .Arma3Profile file only, making backups or disaster recovery easier (in case the binary .vars file causes server crashes).

The specific implementation is mentioned in #15 .

[freghar]

This is overall a bigger "problem" than I thought - it seems ACE3 is pushing mission makers to completely abandon editor modules altogether in favor of CBA settings, from https://github.com/acemod/ACE3/pull/5934/files?short_path=a2f62e5#diff-a2f62e5b12e36c4007cc1c6ffd45e2c1:

All settings are also subject to backwards incompatible changes with future ACE3 versions. We recommend switching to changing settings via the CBA Eden Editor interface and deleting any old ACE Setting modules. From Eden Editor click on the SETTINGS -> ADDON OPTIONS.

This might actually be a good thing if we manage to make it easy to set the settings in the UI and then somehow export them to a format usable in the (existing) Execute Code (Eden) module.

[CNTODachi]

This is not good in my eyes having actual modules with clear headings and settings is much easier for anybody to change and check when needed rather than a block of code with all settings in.

I have not seen CBA Eden Editor settings so do not know if it is user friendly or not I really need to look into these changes ASAP.

[freghar]

I'm afraid we won't have a choice in the future. Even now, there are settings not available via the modules as even the (old) ACE Settings framework is completely separate from the CfgVehicles-based modules.

Fortunately, the Editor-based CBA settings UI is well usable and has some "export" functionality (haven't tested), which has the option of exporting only changed settings. This exported string could then be copy/pasted to Execute Code (Eden), to be restored on composition placement, making it easy to maintain the settings persistently.

More investigation needed.

[milivojm]

Doesn’t that simply mean that ACE settings can simply be server enforced via CBA settings on the server?

[freghar]

https://github.com/acemod/ACE3/issues/5945#issuecomment-353480280 (also see the whole issue)

To add - ACE 3.12 doesn't drop the modules. I don't expect them to do so in nearby future, but we'll see how the Arma community reacts and from the discussions I've read, the trend is towards CBA settings only - this makes perfect sense for ACE, where the modules were really just setting holders, not functionality enablers (in contrast to vanilla or our A3EE stuff).

[freghar]

https://github.com/acemod/ACE3/commit/cd30b09b4f8517ab3f075def26ee0cd4c37e366c should be enough of a "proof" - notice all the scope changes from 2 to 1, making the modules placeable via script or from an old composition, but not visible in the editor units menu.

The way I see it for CNTO is that

1. we do a "hotfix" for the weather changes so weather.pbo is disabled again (like before), along with other possible module updates (#17)
2. some time later (when new CBA releases and we find a good solution for CBA settings management), we switch from using the modules to CBA settings and resolve #12 , #13 , #15 , #16 while doing it

[Abuk007]

If we will be forced to move, I'm interested in what @milivojm said.

If we can enforce setting server-side, then it would be good for us to maintain everything from a central place.

However it also means that the only viable place for testing missions would be our servers. Otherwise we would be in a split-brain situation.

As for weather.pbo - why can't we just remove it?

[milivojm]

I suggest we patch the development server with latest version of ace, cba and duck for cover. I will fix what needs fixing. Let's delay this for late January because of campaign. Is that OK with you guys?

[freghar]

If we will be forced to move, I'm interested in what @milivojm said.

There are a few ways, described on https://github.com/CBATeam/CBA_A3/wiki/CBA-Settings-System .

It is technically possible to have the settings on the server, with options to choose which settings should override clients (ie. acre settings) and which should override even the mission. However this doesn't "force" the mission to use the setting as the MM can just re-set the settings variable using an init field or something (just like they can completely wipe the server settings), it's not a "security" measure.

As mentioned before, keeping the settings on the server has some issues, most imporantly that no other server has them - editor preview, MP preview, all will use ACE defaults. This could be solved by using userconfig (and file patching) or a mod version of userconfig that doesn't require file patching, .. however in both cases, the in-game settings UI doesn't work, so a MM cannot ie. disable BFT for a guerrilla op.

Note that settings defined in the userconfig cannot be changed in the ingame settings menu.

Also, you might want different settings per mission type (Coop / PvP).

So, at this point, the most likely solution I'm considering is what we use for mission defaults (mission type, respawn settings, etc.), so that placing a composition would set the CBA settings to some CNTO defaults (Coop/PvP) that the MM could then edit (BFT, etc.) like before, to allow for trainings with settings changed, etc.

[freghar]

Also, this might be an issue with everything ACE3 in CBA settings: https://feedback.bistudio.com/T120767

[milivojm]

@freghar there was no security measure either so far. Any MM could change any module setting. But yes, I agree, we need few mission placed modules for PvP / coop distinction. Everything else might as well be on the server.

[freghar]

@milivojm I don't quite understand why, though. Imagine that you can either

1. set the settings up in a GUI, click "export", copy-paste the result into an Execute Code (Eden) module, save a new composition
2. do everything like (1), but further decide which settings should be in the mission and which should be on the server (subjective), then log on and manually set via GUI (or selectively cut-paste from the plaintext export) the server-only settings

This will be necessary not only for the initial import, but also for any new or changed options in new mod releases. Given that, I don't really see why we should pick (2) considering it has the same end result, but more work. Or do you gain something I don't see by having the settings server-side?

[Abuk007]

We only have a handful of settings which we enforce serverside and want to keep consistent independent of mission. Those areas are difficulty settings, ACRE parameters, and maybe few other smaller things, as we curate them and don't want to be modified between missions.

There's no argument they can be worked around by using init or script execution - they can of course, however if you give people an easy option they are more prone to use it because they assume its allowed (which happened in the past multiple times). As those settings are critical for how people perceive the mission, its better to lock them, than to expect from mission reviewers to check them manually each and every time.

Otherwise it's more a matter of having defaults in place so there's less work on missionmaker.

[milivojm]

I suggest keeping things simple.

Here is an important quote from https://github.com/CBATeam/CBA_A3/wiki/CBA-Settings-System#presets-system

The ingame settings menu can save whole presets of settings. These presets can be used to quickly transfer settings from the client to the server or the mission and vice versa. The presets of the last three missions you played and of the last three servers you played on will be "autosaved". Presets can be selected during the briefing. The admin can also change the servers preset (or change any individual setting).

I've double checked with guys from ACE about settings priority. Server CAN override every setting mission maker changes. See https://ace3public.slack.com/archives/C095FUDR8/p1515076285000426.

Now, if server is point of authority and since it's obvious setting presets can be transferred easily between server and client, I don't see a reason for complicating matters and simply embrace the new CBA settings as is.

I will try to copy old settings into new preset and we can employ it on development server.