Labels - I can only get 'FULL' or 'OFF'

[Lixma 06]

Doesn't matter what I choose in the gameplay options or in the mission editor I only get full labels or none. No abbreviated, symbol, etc.

What am I doing wrong?

 

 

[silverdevil]

@Lixma 06 - i had a heck of a time getting mine to show just dots. there are many many many posts about it. also YT vids etc. the labels.lua is fully customizable but you have to know what to change. my file is in %USERPROFILE%\Saved Games\DCS.openbeta\Config\View. take a look at mine attached and see what it does for you.

 

Labels.lua

[Lixma 06]

Nice one I'll have a play with the .lua, thanks SD.

So I take it the actual menu option is broken?

[silverdevil]

honestly i have not even used anything in the menu system. i will have to look. i think the labels being just dots is fair playing SP which is all i do. the AI surely are not having problems seeing me from 50 KM lol.

[Tippis]

24 minutes ago, Lixma 06 said:

Nice one I'll have a play with the .lua, thanks SD.

So I take it the actual menu option is broken?

Sort of, but in a very backwards and unintuitive way. The most likely culprit is actually elsewhere, but it could also be a hidden override that makes your setting meaningless.

There are three separate means and ultimately three-and-a-half layers of overriding what you say in the gameplay menu, in rough order of precedence:

1. A user-defined custom labels.lua…
   a. …placed in your %USERPROFILE%\Saved Games\DCS\Config\Views directory.
   b. …placed in an included Config\Views directory in the .miz file you're running — this overrides option 1a.
2. The gameplay preference setting (which picks the label style as defined in the default or custom labels.lua file) in…
   a. …the mission-creator's local settings.
   b. …your local settings — this is the default if nothing else happens.
3. The mission editor setting, which can be…
   a. …set to not enforce anything in SP — this reverts back to option 2b
   b. …set to enforce a specific setting in SP and MP
   c. …the surprise option: set “not to enforce” anything in MP, which actually enforces 2a(!)

Starting with the labels.lua file, you can come across roughly three different variants of the file: version 1a — the really old-school variant using a set of Lua arrays to define how each label style should be drawn; version 1b — an updated version that also supports dot labels and abbreviated labels; version 2 — the one we have now, which uses entire Lua functions to define each label style and supports two levels of dot labels (normal and ”neutral”).

So the first thing that can happen is that your labels.lua is simply outdated: you're picking a label style that doesn't exist or just isn't defined in the lua file so it reverts to… something. The fallback mechanism here is largely unexplored and unknown.

The second thing that can happen is that your labels.lua defines the labels differently from what you'd expect. For instance, the mission maker might have wanted to cover all cases and work-arounds and just defined everything to look like dot labels, no matter what option is picked in the ME or in the settings. Or, like we do in our group, we have a standardised labels file that go into all our missions where everything is redefined so the mission maker can pick between (effectively) two styles of abbreviated and two styles of dot labels (both of which show something else than simple dots) — none of them show “full” labels and none of them show nothing.

Thus, the third thing that can happen (or maybe the second-and-a-half:th) is that there is a custom labels file sneaking in somewhere that you're not aware of. For instance, if you use a mission template of some sort that you always build your missions from, that template might have a labels file included that screw up your expectations, and that you're not even aware of. This can be identified and remedied by opening up the .miz file (it's just a zip) and looking for a Config\Views\Labels.lua file.

The fourth thing that can happen is that your setting just doesn't stick — a file error of some sort, or that DCS has gotten confused about where to look so it watches the wrong directory for a file (or a setting) that tells it to do something else that what you think you've set it to. This is a four-letter-word to try to identify and trouble-shoot, and is luckily very rare, but it can happen…

The fifth thing is the SP vs MP thing. In SP, the mission may enforce a label setting, and if it does, this should obviously invoke whatever Labels.lua file is the most appropriate (custom in the .miz ranks higher than custom in the user directory, which ranks higher than default). In MP, however, it gets completely bugged. If you enforce labels in an MP mission, you get the usual result: the label style is picked by the setting chosen in the ME; the same sorting order for the Labels.lua files is used to pick the appearance. If you don't enforce labels in an MP mission… well, then you actually enforce labels anyway — just from the most bizarre, unintuitive, and obscure source imaginable: you get whatever label style the mission maker had set in their local settings when they saved that mission file. This mission-maker setting is included in the mission definition for some odd reason, and if you try to remove it, the mission breaks.

Thus, if you run in MP, even if it's just a local server for yourself, you can come across a situation where your local settings aren't used because the mission enforces something else, but your local settings are also not used because the mission doesn't (supposedly) enforce anything, and rather than looking at your local settings, it picks the label style from that included mission-maker info and uses that instead. In the ME, it will look like you've set the mission to not use any style at all, and in your gameplay settings, it looks like you've picked something very specific, but you'll get something completely different because that's what someone completely unrelated used at some point somewhere… The more you try not to enforce things, the more things are enforced, but outside of your control. But again, this is only in MP (and if you mess with the mission, it should then include your local settings as its fall-back data and use that anyway).

 

As for solving the whole thing, the immediate standard suggestion is that you (temporarily) move your Saved Games\DCS\Config directory somewhere safe and run a test to see if still misbehaves. This should set everything back to defaults and use the latest label.lua from the DCS install directory, at least if you create a new dummy mission from scratch so you know for sure it doesn't contain any custom definitions. If it still doesn't work, the DCS install has a broken labels file in it. If going for defaults works, you can then start adding files back in and see at what point the labels break again.

[Beirut]

I've got full text, blue dot, grey dot, and off. I use Voiceattck to control it. Works fine.

[Lixma 06]

28 minutes ago, Tippis said:

As for solving the whole thing, the immediate standard suggestion is that you (temporarily) move your Saved Games\DCS\Config directory somewhere safe and run a test to see if still misbehaves. This should set everything back to defaults and use the latest label.lua from the DCS install directory, at least if you create a new dummy mission from scratch so you know for sure it doesn't contain any custom definitions. If it still doesn't work, the DCS install has a broken labels file in it. If going for defaults works, you can then start adding files back in and see at what point the labels break again.

Thanks for the explanation, Tippis. 

So, I deleted the labels.lua from my 'saved' folder and lo and behold I have restored full label functionality. I have never messed about with labels until today and have never touched the .lua so I'm guessing my labels file has been customized via a mission I've downloaded (maybe) or a server I've been playing on (probably). I'll find out later if my theory holds.

[silverdevil]

1 hour ago, Tippis said:

So the first thing that can happen is that your labels.lua is simply outdated: you're picking a label style that doesn't exist or just isn't defined in the lua file so it reverts to… something. The fallback mechanism here is largely unexplored and unknown.

good explanation of the possible issues. i saw another method (i think) that the labels.lua file can be abbreviated that only changes what is wanted and let default labels settings stay. is that true?

[Tippis]

5 hours ago, silverdevil said:

good explanation of the possible issues. i saw another method (i think) that the labels.lua file can be abbreviated that only changes what is wanted and let default labels settings stay. is that true?

I don't know. It falls within that general area of “fallback is unexplored and unknown”.

From a basic programming perspective, it makes sense if it would: the defaults are (possibly) loaded first, and any custom files are loaded later — ones in the mission file are obviously not handled until at mission launch, but that's the one one we can know for sure. But if it works like that, then it should be a case of all definitions existing, and the custom ones simply overwrite any ones that were there before.

Something like, default defines “none”, “dot” (including neutral dot), “abbreviated” and “full”; if you only define “full” in your custom labels file, only the full one is overwritten and the others remain as they were.

But note the caveats here: “makes sense”, “if”, and “should”. If it actually works that way requires experimentation that I haven't seen anywhere. Or… well… I haven't really looked, so it's no surprise that I haven't seen any of it, and I haven't bothered to investigate it myself either.

There is one quirk to this, though. The way many things in that default label file are defined — things like colours, fading palettes, fading distances, and even the dot symbol — are used in all label types. It's just easier to do it that way: create a bunch of templates and then let each label type use (or not) whatever parts are needed so you don't have to re-define and repeat the same colour scheme four times over. This means that any custom lua that alters those template definitions directly would also spill over to affect even the label types that aren't explicitly defined in that custom file.