Labels gone wrong

I enjoy tweaking different label mods to make spotting easier. Since the last couple of updates these label.lua fils got messed up. The game ignores the opacity setting, and it's always 100% now, apparenty.

Labels.lua

+1 Bump. Please can this be looked into.

+1

+1

+1 fix please

+1

I have some 1 pixel dot labels for use in VR and recently it seems that the transparency of the label is really high - the dot is almost invisible, and no notice being taken of the actual transparency figure you enter into the lua, as usual.

A fix for this, and some clear instruction on how to make a simple centred dot (currently use CentreCentre...which isn't centered on object) that fades with distance would be very useful.

I'm not entirely sure this is an actual issue, but that could be because I started experimenting with labels after it became a thing, and just assumed it was normal.

From what I can tell, opacity only affects existing RGBA values — specifically, they mix with the alpha component — and there's some vague reference in the labels.lua comments that suggests that this is the expected behaviour. But only shadow and blur colours are expressed as RGBA. The base text colour of the label is simply RGB, so it remains at 100% opacity at all times.

Now, the question here is whether or not this is indeed the intended behaviour. If it is, then the image below shows that opacity is working as it should. If it isn't the intended behaviour, then the image shows that opacity is not applied properly.

Yeah I did notice that line -

-- Text shadow color in {red, green, blue, alpha} format, volume from 0 up to 255

-- alpha will by multiplied by opacity value for corresponding distance

But I have tried both blur and shading and they are terrible in VR, and really you want the label itself to be transparent, not some drop shadow effect...that is pretty much useless for anything?

But as I mentioned, I have noticed lately my labels have been really transparent to the point of being nearly invisible, regardless what value I put in the second number. The colour blend is working fine, but due to the fact the labels are so transparent, I have changed label colour to 0,0,0 RGB to try and darken them up and removed any colour blend which i used to use at close range to augment VID.

[10000] = {aircraft_symbol_near , "CenterCenter",0.0, 0.0, -0.75, 0.75},

etc.

Hmm… I'd have to see the whole file to confirm, but it sounds like you might (at least in part) be experiencing the “unknown blend” that happens automatically at range. I have no idea what the exact parameters are of when and how it happens, but DCS is supposed to fade from one colour to the next as distance increases.

You have your triplet of vales: ColorAlliesSide (red), ColorEnemiesSide (blue), and ColorUnknown (grey), along with ShadowColor and BlurColor for the same cases. Maybe what you're seeing is the ColorUnknown being very neutral and easy to lose against the sky, and it has its own blue and shadow RGBA that is affected by the opacity parameter.

Just for testing purposes, set all base colors to 255,0,0 and all the shadow and blur colors to 255,0,0,255, and then make sure blending and opacity are both 1 at all ranges. From there, you'll have an easier time adjusting one parameter at a time to see what's making it all happen (or see if it's still transparent though everything should be bright red at all times with that kind of setup).

Coincidentally, that fade to ColorUnknown can actually be used to some interesting effect by pretty much reversing how you'd normally set up blends and alphas over range. Rather than making the base colours very different, set them all to the same value and make that a pale blue/gray that matches the sky. Set it to have a 5x5 blur, and set it up so that the RGBA for allied and enemy blur has an alpha of 0, whereas the unknown blur has a a pretty alpha — 128 and up. This makes it so that, at long ranges, you'll have a tiny sky-coloured dot surrounded by a sky-coloured blur such that, even if the exact “sky colour” doesn't match the sky, it will be blurred out and be difficult to see anyway. You can then set up your range bands such that opacity and blend is high at long ranges — preserving that sky colour and blur — but decreases the closer a target gets, making the blur fade away and the dot become increasingly black and distinct. And that's before you use different symbol definitions to make it stand out more at clearly at closer ranges.

Thanks for the help, but I am well aware of how to blend colours at range etc, and have been using it for a while (to simulate being able to VID targets as they get closer...but in VR).

Also you mention "make sure blending and opacity are both 1 at all ranges"...but that is the whole point of this post, Opacity value does nothing at the moment!

Along with your suggestion in the last paragraph - while interesting, your whole "pale blue/grey that matches the sky" would only work in super-isolated instances where that exact colour matched the particular background perfectly - so not that useful. Also there is no option in VR to use different symbol definitions, as even with just a full stop at 1 pixel size, the label is still huge in VR.

I probably should have mentioned I am referring to VR - in the normal 2D client the labels are not transparent at all, and are solid bright colours, whereas in VR at the moment they are barely visible - all with the same settings.

Cheers thou.

I probably should have mentioned I am referring to VR - in the normal 2D client the labels are not transparent at all, and are solid bright colours, whereas in VR at the moment they are barely visible - all with the same settings.

 

Cheers thou.

Oh, sorry, yes, I missed that completely. That's… odd. If it's for dot labels, my immediate guess would be that it's due to some flaw in the super sampling logic — that one-pixel dot is still one pixel that gets downsampled and becomes half-transparent as a result, or some such?

Oh, sorry, yes, I missed that completely. That's… odd. If it's for dot labels, my immediate guess would be that it's due to some flaw in the super sampling logic — that one-pixel dot is still one pixel that gets downsampled and becomes half-transparent as a result, or some such?

Yeah that's a good point - I might try upping the size to 2 pixels and see what happens to the transparency.