Cba settings nametags

[commy2]

When merged this pull request will:

• change Nametags to use the CBA Settings framework
• requires: CBA Settings frame work CBATeam/CBA_A3#317

[thojkooi]

Moved this up to the 3.7.0 milestone.

CBATeam/CBA_A3#317 is not part of the current CBA RC. This will most likely not be included with 3.6.0. I suspect ACE 3.6.0 will be released before CBA releases the new CBA settings framework.

If things change, we can retag this for 3.6.0.

[jonpas]

Is the mod name needed here? Isn't it in separate categories anyways?

[commy2]

It's the same as keybinds. The idea is that every mod has a category. ACE is so big that components should be grouped together. Nametags has enough settings to get one tab itself.
I suggest you check it out ingame.
To view the missions tab (which has 3 additional options formly tagged with clientSettable = 0) just enter 3den. The menu can be found under "Settings".

[jonpas]

I see. I'll check it out in-game!

[commy2]

Oops. That was just muscle memory.

[nicolasbadano]

Mybe we should not change the file name, which would make the PR much easier to review

[nicolasbadano]

I strongly dislike the "settings in sqf" approach.

• Default settings can no longer be changed, forced, etc, via compat or community specific pbos
• Settings can no longer be copy/pasted into the mission description.ext
• Looks more unreadable IMO
• They get mixed with non-setting code. Less data-driven.
• I'm not sure, but the way localize is used probably messes up when you change language mid-game.

What exactly do we get in return?

[commy2]

Default settings can no longer be changed, forced, etc, via compat or community specific pbos

Is that a thing? Never heard anyone do that. Seems not very practical compared to how it could be done with a settings.sqf file in the userconfig of the server or by just changing the values as admin ingame.

Settings can no longer be copy/pasted into the mission description.ext

yes, but that is not how mission settings are done with the CBA system. You enter them ingame in 3den. If you want to edit text files, then you can also "import" those ingame.

I'm not sure, but the way localize is used probably messes up when you change language mid-game.

It doesn't. The settings are localized on the local machine.

What exactly do we get in return?

I might be able to drop the whole config reading function and simplify the CBA branch.

[nicolasbadano]

So you admit it's more restrictive but consider the additional restricition's not to be important. I can agree with that.

But I still can't see enough benefits. Are there any?

From a broader perspective, I always admired the way Arma organized content into easily acesible and patchable data using the config database. Makes for a great data-driven approach, which is partly responsible for making the game as mod friendly as it is. Putting data stuff there plays to those strengths.

[PabstMirror]

I like the config way that we currently have in ace.
As part of our modset we have a ace_settings.pbo that sets and forces a few different settings.

This is critical because it ensures that settings will be the same both on the dedicated server and when mission makers test locally.

[commy2]

I'm not sure, but the way localize is used probably messes up when you change language mid-game.

I just re-read this and it's totally right. I never even thought of that. That can be changed though.

But I still can't see enough benefits. Are there any?

It's 75 lines of config that can are reduced to 18 lines of SQF. You can add those functions you want to call whenever a setting changed directly to the setting without having to compile. You can edit these settings while debuging which isn't possible with configs on stable branch.

[nicolasbadano]

The ability of adding settings on the fly is def. an advantage. The LOC argument does not hold though

class GVAR(defaultNametagColor) {value[] = {0.77, 0.51, 0.08, 1}; typeName = "COLOR"; isClientSettable = 1;  displayName = CSTRING(DefaultNametagColor); category = CSTRING(Module_DisplayName);};

😄

[nicolasbadano]

I just re-read this and it's totally right. I never even thought of that. That can be changed though.

BTW, looking at this, apparently it doesn't work properly on the current version either. The setting name should not be localized ever, expect when actually displaying it (for example in ace_optionsmenu_fnc_settingsMenuUpdateList)

[commy2]

Yeah. While that is a extremely minor thing, this can easily be fixed on the CBA side.

[commy2]

fixed that

[nicolasbadano]

For the record, I still prefer the current approach.

[commy2]

Configs or in general?
Because CBA system can do configs too, but they don't work in description.ext and have no ACE_Server.pbo.

[nicolasbadano]

Of course ACE should migrate to CBA settings, but I'd prefer to keep settings in config for the stated advantages. If CBA can do configs, then I don't see why it shouldn't support and offer a version of ACE_Server.pbo

[commy2]

Because there is no need to. Settings are stored in the profile. And if you really want to have a file, then use the one for the userconfig.

[nicolasbadano]

How exactly does CBA settings enforce the "community wide fool-proof settings" objective that lead to the development of ACE settings?

[commy2]

Here as an example, this is what you get when you press "EXPORT" in the ingame editor:

force ace_nametags_showNames = 1;
ace_nametags_defaultNametagColor = [0.77,0.51,0.08,1];
ace_nametags_showRanks = true;
ace_nametags_showSoundWaves = 1;
ace_nametags_showVehicleCrewInfo = true;
ace_nametags_showNamesForAI = false;
force ace_nametags_tagSize = 2;
ace_nametags_showCursorTagForVehicles = false;
ace_nametags_playerNamesViewDistance = 5;
ace_nametags_playerNamesMaxAlpha = 0.8;

(random settings are forced)

With this you can:

• create a mission and "IMPORT" the settings into the mission via 3den (same interface, but missions tab)
• start the server with a random mission, log in as admin and "IMPORT" them into the server profile (again same interface, but server tab - the servers profilenamespace is as persistent as the one of normal clients now)
• put that into a file called /userconfig/cba/settings.sqf on the server machine and enable filePatching (that doesn't mean clients with file patching are allowed, it's a seperate setting)

[commy2]

One could argue that it is absolutely fool proof, even more so than the ACE settings system, because there is an ingame editor with tooltips explaining every button you could press.

[nicolasbadano]

Regarding @PabstMirror 's use case, the CBA system lacks a simple way to keep the forced settings in sync between server and the clients of mission maker and community members.

I wonder if it's really confortable to use.

Example story 1:

1- Community manager A sets his default settings for the community
2- Community manager A transfers them to the headless server
3- Community manager A edits some fancy non standard mission for armaholic, changes settings in the process
4- Community manager A wants to tweak some of the server settings again.
5- Community manager A can't download the original settings from the server profile
6- Community manager A has to redo settings
7- Fail?

Example story 2:

1- Community manager A sets his default settings for the community
2- Community manager A transfers them to the headless server
3- Mission maker B wants to download the forced settings from the server to develope in correct conditions
4- Fail?

Example story 3:

1- Community manager A sets his default settings for the community
2- Community manager A transfers them to the headless server
3- Community member wants to train offline with the community profile
4- Fail?

[nicolasbadano]

One could argue that it is absolutely fool proof, even more so than the ACE settings system, because there is an ingame editor with tooltips explaining every button you could press.

The point is that settings are seldomly changed. In my opinion being fool proof means that you can set them once and forget forever, and get them as you want them on all clients and server on all missions at all times.

[nicolasbadano]

This is exactly how the vanilla settings (including keybinding) and CBA kebinding works.

Vanilla settings and CBA keybinds are never required to be shared, and they are never required to be exactly the same between different people either. Community settings are by definition.

[commy2]

So just we are on the same boat:
Community boss A sets settings for whole community on server
Community members B, C and D want to play offline - B is the host.
B starts a mission as local host, copies the communties settings.sqf file, opens the editor under the server tab (he is the server in local hosted MP) and presses "IMPORT"
C and D connect and play with the same settings forced as they are used too.

You can transfer settings with the CBA system too. It's even easier to do since you don't have to edit any (mission)pbo files.

[commy2]

For missions, if you really want to edit / copy files you can do that with the mission.sqm too. (That's where 3den stores it's settings instead of description.ext)

class CustomAttributes
{
    class Category0
    {
        name="Scenario";
        class Attribute0
        {
            property="cba_settings_missionSettings";
            expression="missionNamespace setVariable [""cba_settings_3denSettings"", _value, true]";
            class Value
            {
                class data

It's a bit verbose - because 3den - but it is possible.

[nicolasbadano]

B starts a mission as local host, copies the communties settings.sqf file, opens the editor under the server tab (he is the server in local hosted MP) and presses "IMPORT"

B has to has access to that settings.sqf. It implies the community manager emailing the file every time he tweaks the server settings. It's also error prone. And cumbersome if you want to play with different communities.

To me it seems a lot better to keep that data in the modpack, which people already keep in sync constantly.

[commy2]

Actually this is possible too. All you need to do is pack an addon that has this file:
/userconfig/cba/settings.sqf
As long as filePatching is disabled, this file will take precedence over the actual userconfigs file.
The PBO has to have "cba_settings_helper" in requiredAddons

[nicolasbadano]

Can you put files on userconfig inside a pbo?

[commy2]

Yes. "userconfig" is just a path. same as "addons".
The settings_helper.pbo is not very clear with that, but that is because I haven't adjusted the build/make files for that.
Checkout this: https://github.com/CBATeam/CBA_A3/pull/317/files#diff-d504d105fb41328f6722f4e5c8432a96R73

[nicolasbadano]

Well @commy2, I give up. I clearly don't know enough about the CBA setting framework to understand all the possibilities it offers. In my mind it still feels kinda convoluted though.

Maybe some documentation on how to set it up for most common use cases could help.

[commy2]

I'm still trying to figure out the use-cases as you can see.
How is it convoluted thoug? I mean if you take away all the ui stuff, it really is simple. It does always check if settings are valid etc. but I think that's a plus.

[nicolasbadano]

How is it convoluted thoug?

I said it feels convoluted to me; I'm a bit too confused to explain why. The idea is slowly growing on me though.

[commy2]

Thanks for explaining your concern though. I didn't know how the ACE settings system is used by some communities. I'll try to figure out good ways to have something similar with this. My goal still is to make nothing worse than it is now.
One huge difference of the idea behind this system is, that it is designed to be similar to how editing vanilla settings or 3den "attributes" works, while the ACE system is build around the config/description.ext.
They are very different, but in the end I think editing these settings ingame is superior. You immediately see all (or at least more) of the possibilites you have. And you instantly see what changes. Just think about the size-of-nametag setting for example.

[nicolasbadano]

Thanks for explaining your concern though.

@commy2, there's nothing to thank; I always enjoy discussing with you my friend ❤️ 😄

One huge difference of the idea behind this system is, that it is designed to be similar to how editing vanilla settings or 3den "attributes" works, while the ACE system is build around the config/description.ext.

Yes, this is exactly true.

---

Maybe when you connect to a server there should be a way to "save" the server settings to use later in the editor, both for developing missions or training with those settings. I know "export" wouldn't work on those conditions due to copyToClipboard not working in MP (super dumb restriction), but maybe a "archive server settings / review server settings" button

[commy2]

<3

I know "export" wouldn't work on those conditions due to copyToClipboard not working in MP

Wow, I didn't know about that. That sucks...
RPT printing is the only way then... To bad that has time stamps everywhere now.

Well unless I make a editbox control where you can copy paste it from manually ...

[nicolasbadano]

RPT printing is the only way then.

I was thinking something like this:

1- Connect to the server
2- Hit a "Archive server settings" button
3- Server Settings are stored somewhere in your profile
4- Disconnet and go to the editor
5- Hit "Review Server Settings" button, that would show the stored settings.
6- Export them or apply them from there

[commy2]

Sounds interesting. Basically different presets one can choose.

One guy even had the idea to have different "server presets" you can select as admin before starting a mission. I just don't know how editable those displays are.

[nicolasbadano]

"Presets" sounds like a nice definition

[commy2]

So basically 3 addional buttons for the settings menu:

Save Preset -> opens editbox to insert name, use already existing name to overwrite
Load Preset -> A listbox you can open to "import" an already existing preset

Both Preset lists have a "Delete Preset" button.

"Current Client Settings" and "Current/Last Server Settings" (as well as "Current/Last Mission Settings"?) will be automatically added as presets.

[nicolasbadano]

Sounds good I think

[commy2]

@esteldunedain
Presets done. You can save and load all settings and name them. It will "autosave" the settings of the last three server you visited (updated every time you start a mission on the server) as well as the mission settings of the last three 3den missions (If they had anything set).

Additionally you can edit these settings during briefing. This includes the server settings as admin or as local host.
You can simply load the "autosaved" settings of your communities server, so you won't have to contact the admin in case you want to play a quick round locally hosted. This should be more flexible than the current system with a PBO that includes all community specific settings, while still being easy to manage for end users.

[commy2]

Latest look of the menu:

It can now be accessed:

• in main menu
• in 3den (only place where you can set "mission" settings)
• ingame (can access server settings as local host or as logged in admin)
• during briefing (same as above)

Do you still have / have more concerns about the system? I must say that I'm quite happy with how it works now.

[nicolasbadano]

@commy2, you are a genius. Congratulations.

Quick question; how resilient is this system to new settings being created or old ones being deleted?

[commy2]

Deleted settings remain forever in profile or the mission. There is no quick way to tell whether a setting is removed from a mod or if the mod is just disabled. And I obviously don't want to reset all ACE setting just because you played vanilla once.
I thought about a deprecation system, but it's not worth the effort. It's not like we are constantly making and removing settings. The space they take up is miniscule (it only saves the settings "name" and the current value it is set to. No meta info like in CBA keybinding ...)

If a setting was changed in a way where the old value is no longer considered valid (e.g. an item was removed from a list, or a sliders max value was reduced), it will be reset to the default value (profile will be updated).

If a preset does not contain any information about a new setting, loading the preset will just keep the settings value to whatever it was set to already.

[nicolasbadano]

I thought about a deprecation system, but it's not worth the effort. It's not like we are constantly making and removing settings. The space they take up is miniscule.

But, do old (deprecated or removed) settings still show up on the settings menu?

[commy2]

No, they won't.

[nicolasbadano]

No, they won't.

Perfect, that was my concern. 👍