Unable to *not* force label setting in multiplayer

[Tippis]

After a lot of complaining and teeth gnashing and dragging of feet, a fancy new Labels.lua file was finally put together for use on our servers and in the missions we create for it. It contains finely honed (ehrm… yes, or some such) and selected setting for dot, abbreviated, and full labels to cover all wishes and still have a consistent look.

 

The general idea is that either the multiplayer missions will all contain the same Labels.lua file, or if not, all clients will be able to download it and use it locally. They should then be able to pick their favourite label style and the mission will accommodate them all.

 

The problem

It turns out that it is not possible to not force a specific label style from the server, which means the clients' settings and the fancy style definitions in the labels file are all rendered pointless. The player simply cannot choose what type of label they want to see in MP — the mission overrides all such desires.

 

The main problem is that the mission setting where you can force a specific label option does not properly handle the case when it is unchecked and no label option is explicitly forced. Even in that case, one of the four label styles — none, dot, abbreviated, or full – will still be forced on the player and their local setting will be ignored.

 

What it is not

This is not a matter of setting the force label option wrong. Indeed, the issue arises when that option is not set at all.

 

It is also not a matter of the server's local label options. It does not matter what is set in the server's own Options > Gameplay > Label selection — this is also overridden by the mission.

 

It is not a single-player issue — in SP, the player's label selection is respected, whereas in MP it is not.

 

It is not a matter of whether or not the mission contains a Labels.lua file. The same behaviour is seen even without a file included. Rather, if the mission contains custom labels, then it will force one of those definitions (so it half-works — the included file is applied as it should); if not, it will force the style, and the client's local definitions of that style.

 

What seems to be happening

Based on experimentation, the cause seems to be this:

 

If the mission has the force label option set, then it obviously forces that label option — so far so good. If it does not have that option set, however, it starts to look in other places. One of those places is the options file the mission editor includes in every mission (and without which the mission will not work properly) that stores the mission editor's local settings. The option file includes the “difficulty” section, which, among other things, lists the label setting that the mission-editor had at the time the file was saved. The mission then forces this implicit setting on all clients in multiplayer.

 

So, either a label setting is explicitly enforced through the “force option” setup in the ME, or a label setting is implicitly enforced through the difficulty option sneakily stored in the mission file without any connection to the ME at all.

 

Setting aside the questionable sanity in storing the mission-editor's local hardware, difficulty, and module settings in the mission file to begin with, these settings really shouldn't in any way affect how a (possibly wholly unrelated) server then chooses to run the mission or what settings (definitely unrelated) clients are forced to play with.

 

 

Replication #1

Go into Options > Gameplay > Labels and pick no labels.

 

Go into the mission editor and create a new mission. Simply place down an AI aircraft, save and quit the editor. No settings should exist at this point — all “force option” checkboxes are unchecked by default, so nothing should be forced.

 

Go back into Options > Gameplay > Labels and pick something noticeably different — anything will do but full labels shows the issue most clearly.

 

Go into multiplayer and start a new server containing the newly created mission.

Note that the behaviour does not occur if the mission is loaded in SP through the missions menu.

Also note that the same behaviour will occur if joining the server as a second, unrelated client.

 

Expected behaviour: since we have set our labels to be full, and since the mission is not set to force anything, we should see full labels when we look at the AI aircraft flying around on the server, and these labels should appear as defined in the local Saved Games\DCS\Config\Views\Labels.lua file (or as DCS' default appearance if nothing is set up in the user file structure). Likewise, if joining as a third party, we should see whatever type of label is selected locally on that client.

 

Actual behaviour: since the mission is not set to force anything, it reads the included options file and shows no labels (since that's the setting the game had when the mission was saved) — a different, hidden option is thus forced even when the mission is set not to force any option.

 

Replication #2

Go into Options > Gameplay > Labels and pick full labels.

 

Go into the mission editor and create a new mission. Simply place down an AI aircraft, save and quit the editor. Again, no settings should exist at this point — all “force option” checkboxes are unchecked by default, so nothing should be forced.

 

Add a custom labels file to the mission — preferably one with massively obvious and hideously gaudy labels defined for all three types: dots, abbreviated, and full labels.

 

Start a new server running the newly created mission.

 

On a second client go into Options > Gameplay > Labels and pick abbreviated labels. Then join the server and observe the AI aircraft from the spectator view.

 

Leave the server, go back into options and pick dot labels. Then join the server again and observe the AI aircraft from the spectator view.

 

Leave the server, go back into options and pick no labels. Then join the server again and observe the AI aircraft from the spectator view.

 

Expected behaviour: since the mission is not set to force anything, the client should see the type of label they have selected locally when they log in — abbreviated, dot, and no labels — with the appearance defined in the Labels.lua file that is included in the mission. Whatever appearance may be defined locally on the client should be overridden.

 

Actual behaviour: since the mission is not set to force anything, it reads the included options file and shows full labels for the client, irrespective of their local settings (since that's the setting the mission-maker's game had when the mission was saved). A different, hidden option overrides the explicit setting not to force any labels and the clients selection of no/dot/abbreviated labels. The appearance of those full labels will adhere to the definition in the Labels.lua file included in the mission, per expectations, so that part is working — it's just that what appears is full labels, when the client was instead supposed to see any other style.

 

 

The strangeness of the options file

An immediate idea might be to manually go into the options file included in the mission and simply cut out the “Label” difficulty setting stored in it — if no label type is set, then surely none can be forced, right? Unfortunately, what happens instead is that since no label type is set in the file, it is read as being null or zero, which the labelling system interprets as labels being set to “no labels”, so even removing the implicitly forced option still forces an option and the client still has no say in the matter.

 

The reason the behaviour does not occur if the exact same mission is run in SP seems to be that in SP, the option file is (correctly) presumed to be completely secondary — possibly entirely inapplicable — to the actual local settings. After all, just because the mission maker had set their resolution to 1280x720 for some silly reason does not mean that the player must be forced to run that resolution as well.

 

It is entirely possible that other stored options in that file might be implicitly forced by the server (things like birds, traffic, game flight mode etc — some of which have been known to have strange server behaviours before), but this brief testing only showed that the label settings are definitely affected.

 

Preferred outcome

Nothing in the options file included in the mission should in any way, shape or form affect the server the mission is run on, or the clients connected to that server. Indeed, the options file shouldn't even be included in the mission to begin with since it is simply a copy of the mission maker's local setup, which is of zero relevance to anyone else.

 

Thus, if a mission includes a label file that offers support for all different types of labels, but does not explicitly force on of those types, the client's local label setting should determine what kind of labels they see when connecting to the server.

Edited July 31, 2019 by Tippis

[TWC_Alamo]

Tippis,

 

 

 

This explains a lot. I have been chasing problems with disappearing and changing labels on missions running on our dedicated servers. I had set the the option "NOT" ENFORCE labels, assuming it would allow player to select whatever style they want. However, some times when a mission was edited, the labels would disappear. Turns out the clients I used to edit the missions have different default settings: one had NO LABELS and another FULL LABELS.

 

 

 

One thing I noticed is: if I uncheck the ENFORCED check box for LABELS on the mission's customization screen, the label style will revert to the label style of the client machine I'm using to edit the mission. I wrongly assumed when it reverted to NONE it was saying it wasn't enforcing any style. However, when I set the style to FULL, it reverts to that when unchecked.

 

 

 

Thanks for your analysis. I hope ED will address the issue.

[Tippis]

Bumping this after yet another discussion on DCS' view system and how labels are meant to compensate for the lack of proper simulation – that would be a fair stance to take if labels were working properly, but alas…

[SMH]

Yep, been this way for years. Tooltips too.

[Tippis]

That's pretty sad, but you'd think that would at least warrant a response of “we know about this already”.

 

Or maybe we should set up a betting pool about the devs asking for a track to show a bug that happens in the mission editor and settings screen. :P

[Bunny Clark]

I've been trying to figure this one out for a while now too. Good job Tippis on the detailed write-up, you've found far more information on the issue than I did.

 

It's really annoying whenever I want to run one of the stock ED missions on a multiplayer sever with a few buddies, I need to open it in the editor and change the label setting on every mission. :cry:

[Tippis]

Semi-bumping this because it's been ages and it's still a very silly problem.

It also affects all kinds of mission settings that it really shouldn't affect.

 

 

You'd think that putting a mission as “non-enforced” would not enforce that setting, but for all intents and purposes, the first column in the mission setting list is wholly redundant: all settings are always enforced in MP, no matter the state of that checkbox. This bug applies not just to labels, but also to things like game modes, invulnerability and infinite stores, GPS restrictions, blackouts — anything where you might want to give the client the option to choose, you can't because there is no way to turn off server enforcement of mission settings. It's just that those settings aren't always set by the mission, but by the wholly unrelated and irrelevant mission-maker's local computer settings.

[Gracey]

So we did some testing regarding this label issue.

 

The server always forces what is set by the mission creator. Even if ENFORCE is not selected.

 

For some people do not like full labels for example, and if the setting is local then I am not sure why it will not take the local(client) setting in account.

 

Maybe we will get the update for this soon, as they have been doing some work towards the multiplayer side of things, like for example the new dynamic campaign stuff.

[Foogle]

Has this been fixed? Or even looked at? 

[Tippis]

9 hours ago, Foogle said:

Has this been fixed? Or even looked at? 

Not as far as anyone can tell.

[draconus]

Is this reported @BIGNEWY ?

[Sandman1330]

Ahhhh, so this explains it.

 

I play with easy comms off, and I intentionally set my server missions to not enforce easy comms so other players can use it if they want. However, easy comms never work for other players on my server. This explains why!

 

I concur this would be great to have fixed. I allow a wide range of skill levels on my servers and would like players to have the choice whether to use easy comms or not (or wake turbulence, etc.)

[Tippis]

Yearly bump.

[Tippis]

Year-and-a-half:ly bump…