{ ED INVESTIGATING } MFD Text and symbology messy with latest update

[Dunx]

The font stokes overlap - which cause prominent bubbles due to the opacity of the stroke.

 

Is it possible to increase the intensity of the font strokes to reduce the bubbling effect?

[wowbagger]

Even on a normal 2d screen this looks a major step backwards in terms of legibility to me. I'm not talking about exports - simply playing the game on a single, 2D, flat, pancake screen (in this case 2560x1440 if that matters).

 

I eagerly look forwards to a more comprehensive and inclusive reply on this problem from the dev.

[netizensmith]

The gain down 50 clicks, contrast down 10 clicks is the simplest workaround at the moment IMO.

Alternatively a Mods\Aircraft\AV8BNA\Cockpit\Displays\Display_StrokesDef.lua that looks like this if you can't be arsed doing the clicking each time:

 

stroke_thickness  = 0.5
stroke_fuzziness  = 0.4

-- Currently is used for DMC generated fonts black outline
DMC_outline_thickness = 0.2 --stroke_thickness * 3
DMC_outline_fuzziness = 0.2 --stroke_fuzziness * 1.1
DMC_stroke_thickness  = 0.65
DMC_stroke_fuzziness  = 0.42
 

[imacken]

You've confused me, those are the default values.  What are you suggesting?

[netizensmith]

Look again. The default values are commented out (with --) and replaced with 0.2 for the outline values. Change these values per your preference. 0.2 works well for me with an HP Reverb and at 1440p 2D screen.

[imacken]

Sorry, must be going mad! Thanks!

[netizensmith]

At first glance it does look like I've done nothing! I wanted to keep the default values readable so people could judge the settings they might want to use.

[raptor909]

 

On 2/4/2021 at 4:26 PM, RAZBAM_ELMO said:

From our lead dev on the matter:

 

"YEs it is a known issue. it is a problem with the stroke (SVG) system. Fortunately it can be fixed in code, but it is a case by case basis. What is happening is that we are using a fixed thickness and fuzziness value when the display is exported.

 

static const double thickness_fix = 1 / 0.8;
static const double fuzziness_fix = 1 / 0.5;

if (purpose == CURR_PURPOSE_GENERAL)
{
//Normal stroke processing for inscreen display
}
else
{
//Exported displays values
shaderLineVariableParams.thickness = 8.0 * thickness_fix;
shaderLineVariableParams.fuzziness = 3.0 * fuzziness_fix;
}

 

So, in the future, we can implement a Special Options that can modify hte fixed value. Unfortunately this cannot be solved for everyone with a single fix as it is a case by case basis.

 

 

 

I am leaving this up here for everyone to share and see so individuals experiencing this issue can adjust as needed for themselves.

 

Ok but which is the file to put the code in ???

Edited February 5, 2021 by raptor909

[RAZBAM_ELMO]

Fix has been posted in the link above. This is a case by case issue, and due to such we are looking at implementing these features into a special tabs option. Marking as FIX AVAILABLE and moving to RESOLVED.

[RAZBAM_ELMO]

 

Fix made available as this is not something that can be solved for everyone and is a case by case basis. Team is working on a special TAB to allow adjustment in the future. Marking as FIX AVAILABLE and moving to RESOLVED.

[imacken]

7 hours ago, RAZBAM_ELMO said:

Fix has been posted in the link above. This is a case by case issue, and due to such we are looking at implementing these features into a special tabs option. Marking as FIX AVAILABLE and moving to RESOLVED.

Are you talking about the ‘fix’ you posted? The one that people keep asking what file to put the code into? The one that is about exported displays, despite people saying it’s not just about exported displays? That one?

[wowbagger]

I can't understand A) how this is a fix {what file is being referred to?}, and B) how this is a case by case basis. Isn't everyone seeing the same change in the MFDs' text ... on their normal main displays and in VR? Is it resolution dependent?

 

Again, this isn't only about exporting the MFDs. It feels like this fact is being willfully ignored in an attempt to just make the problem go away.

 

 

[Aarnoman]

I'm done buying Razbam products. This whole argument is completly silly at this point as Elmo/by extension Razbam as a whole is incapable of grasping the point made by many community members in multiple threads now, with screenshots repeatedly showing the decrease in clarity. Also the point that this affects regular flat screens, VR devices, and exported MFD's also seems to be impossible to grasp for some reason.
This whole endevaour is completly frustrating, it really should not require this level of pushback from the community for it to be recognised that

1) This is a genuine issue that is affecting many people.

2) This needs more than a 'specials tab' option to fix.

 

Also, watch this post be deleted by Elmo like the last one that was critical of the issue. Absolute class act Razbam, this criticism is well deserved for your behaviour.

 

[Teeps]

Perhaps the one that netizensmith mentioned a few posts above?

[Teeps]

I think what Elmo is saying is the optimum setting depends on the users configuration. It looked good on the dev's screen, but might not look good on mine. Given that the best setting is not the same for everyone, they're going to give the option of changing to taste. In the meantime netizensmith has explained the file to change it in manually for now here: 

 

I think people are being unfair to Razbam in their reactions here to be honest. I'd like to balance the negativity by saying thanks to Razbam for the harrier and it's continued development.

[netizensmith]

Whilst some of the posts do seem to be needlessly aggressive, I could not have been clearer in stating, and showing via screenshots, that this is a global issue, no matter where your mfds are being displayed and yet that was ignored in the initial response and in every response since. There are three reasons I can think of that we got to this point, a) devs/community liaison not reading what I and many others wrote (a poor show), b) not understanding what I and others wrote (English not first language is the only way you couldn’t understand it though), or c) deliberately ignoring it to make the problem go away. I can think of a way to fix a (I suspect Elmo is overworked dealing with the Harrier plus the other Razbam modules) or b but not c. Is there a fourth explanation I haven’t thought of?

 

Edit: I do not have any issue with the developers. Bugs happen. It’s a fact of

life. The pain point sits between the developers and the community I’m afraid but I do have sympathy here.

Edited February 8, 2021 by netizensmith

[wowbagger]

53 minutes ago, Teeps said:

I think what Elmo is saying is the optimum setting depends on the users configuration. It looked good on the dev's screen, but might not look good on mine. Given that the best setting is not the same for everyone, they're going to give the option of changing to taste. In the meantime netizensmith has explained the file to change it in manually for now here: ...

 

 

 

That could well be true. In which case I would have expected something like:

 

Quote

There is a problem with the the new SVG system that can cause legibility on 2D screens, in VR, and on exported displays. We plan to implement the ability to tweak these settings in the Special Options tab in an upcoming patch. In the interim, you can adjust them yourselves by editing FILE LOCATION/ FILENAME.lua and adjust the THESE VALUES in THIS WAY. 

 

I will mark this  as [FIXED INTERNALLY] and leave it in the BUGS  section for others to find until the Special Options is available.

 

As it is I still don't know if they recognize the scope of the issue, and I don't know how to apply the fix or if the fix is indeed meant to work for a normal, 2d, non-exported display.  All it would take is a few answers to questions in these threads and one clearly worded reply.

Edited February 7, 2021 by wowbagger

[derfritz]

This is not really acceptable to me, especially since the Viper and Hornet are perfectly readable in VR and flat screen. ED uses .svg so it can't really be a "case by case basis". Maybe ask ED how they did it and try to replicate that? I love the work that is done on the mfds tho, I think .svg system has a lot more future potential, and I appreciate bringing the harrier up to date in that manner.

[Harlikwin]

Um, not sure why you are trying to make it look like I made that pilot post. That was another dude. Maybe some actual editing is in order. @elmo

Edited February 7, 2021 by Harlikwin

[Fri13]

On 2/5/2021 at 3:26 PM, netizensmith said:

The gain down 50 clicks, contrast down 10 clicks is the simplest workaround at the moment IMO.

Alternatively a Mods\Aircraft\AV8BNA\Cockpit\Displays\Display_StrokesDef.lua that looks like this if you can't be arsed doing the clicking each time:

 

stroke_thickness  = 0.5
stroke_fuzziness  = 0.4

-- Currently is used for DMC generated fonts black outline
DMC_outline_thickness = 0.2 --stroke_thickness * 3
DMC_outline_fuzziness = 0.2 --stroke_fuzziness * 1.1
DMC_stroke_thickness  = 0.65
DMC_stroke_fuzziness  = 0.42
 

 

You are doing the commenting wrong and confusing people.

Do not move the old values to comments on new lines.

Proper commenting happens this way;

 

You use the commenting to explain the line purpose (green font):

 

stroke_thickness  = 0.5 --this value sets the font thickness on HUD and MFCD.
stroke_fuzziness  = 0.4 --this value sets the font edge blurriness.

 

That is the way to do the commenting so one reading the code knows that what each line does and is purposed.

When you need to change some value, you will copy-paste the old line, comment the old line out and then add below it a new modified line (purple font):

 

--stroke_thickness  = 0.5 --this value sets the font thickness on HUD and MFCD.

stroke_thickness  = 0.7
--stroke_fuzziness  = 0.4 --this value sets the font edge blurriness.

stroke_fuzziness  = 0.25

 

This way the original line stays as a reference for everyone that what was the change between old and new. If there is requirement to explain the modification change, it can be done with the comment line with the new line (as the comment line is not required to be copied over to modified line).

 

--stroke_fuzziness  = 0.4 --this value sets the font edge blurriness.

stroke_fuzziness  = 0.25 --changed it thinner so it is more useful in the VR, might want to use little thicker like 0.3-0.32 for normal display.

 

That way anyone can read what was changed, and why it was changed. And it stays clear for the future purposes to track changes.

 

So to do it properly:

Here is the original code from patch that is broken:

 

stroke_thickness  = 0.5
stroke_fuzziness  = 0.4

-- Currently is used for DMC generated fonts black outline
DMC_outline_thickness = stroke_thickness * 3
DMC_outline_fuzziness = stroke_fuzziness * 1.1
DMC_stroke_thickness  = 0.65
DMC_stroke_fuzziness  = 0.42

 

Modified for your changes:

 

stroke_thickness  = 0.5
stroke_fuzziness  = 0.4

-- Currently is used for DMC generated fonts black outline
--DMC_outline_thickness = stroke_thickness * 3

DMC_outline_thickness = 0.2 --removed the multiplier from base values.
--DMC_outline_fuzziness = stroke_fuzziness * 1.1

DMC_outline_fuzziness = 0.2 --removed the multiplier from base values.
DMC_stroke_thickness  = 0.65
DMC_stroke_fuzziness  = 0.42

 

 

[Fri13]

On 2/7/2021 at 12:45 PM, Teeps said:

Perhaps the one that netizensmith mentioned a few posts above?

 

The code is only for exported displays. Otherwise the normal code is used.  Totally useless for a VR users or desktop users.

Here is what the "fix" does for the VR users.

 

 

Edited February 10, 2021 by Fri13

[netizensmith]

@Fri13Yeah I know how to comment code mate. This is a dirty quick hack, not a fix and I didn't expect it to go through code review 

Edited February 10, 2021 by netizensmith

[Fri13]

10 minutes ago, netizensmith said:

@Fri13Yeah I know how to comment code mate. This is a dirty quick hack, not a fix and I didn't expect it to go through code review 

 

 

Just to make it more readable as you removed important parts that you wanted "to keep it readable". A "dirty quick hack" still is easier to make just copying the line and commenting old out without making it more difficult to see what was really changed. If knowing, then it is easier to do so in first place.

 

Just for the future readers to see.

[netizensmith]

@RAZBAM_ELMOHi!

Can you please confirm you/developers understand that the new stroke outline functionality has had an adverse effect, for everyone i.e. 2D monitor users, VR users and MFD Export users? The fix provided currently is for exported MFD users only, and incomplete as far as I understand in that no one knows while file to put the fixed LUA script into. At the moment we feel like our concerns have not been fully understood.

 

Many thanks

Edited February 10, 2021 by netizensmith

[wowbagger]

I asked a similar question last week about the TDC AXIS not working well in a three year old thread (moved to resolved), but so far have got no reply; I hope you fare better. The communication on these issues is not what I had hoped for or expected.

Edited February 11, 2021 by wowbagger