AoA Indexer Brightness tied to DECM switch

[sLYFa]

Apparently, the DECM rotary does not only control the ECM but also the brightness of the AoA indexer in the front pit. Setting the DECM switch to OFF will turn off the AoA indexer, while setting it to RPT will give you max brightness, see attached screenshots.

[Skysurfer]

Bruh...

[FoxTwo]

Holy. $*&%.

 

Welp. Guess we found out why sometimes I can see the indexer and sometimes I can't.

 

Holy crap, good find. Can we get a hotfix boys?

[TLTeo]

I so, so wish I could see the code that caused this to happen

[Skysurfer]

Confirmed. 

 

 

Edited January 24, 2021 by Skysurfer

[wadman]

Thank you - great find!!!!.  Hopefully, this means that there is no reason that HB should not be able to formally fix this since this workaround proves that the indexer lights can be much brighter in the F14! 

[draconus]

That makes new SOP for the approach:

...350KIAS

wings 68 deg.

hook down

Jester ECM On...

[Lt_Jaeger]

Very nice find. That should, after fixing, put an end to that Indexer discussion

 

[Northstar98]

12 hours ago, TLTeo said:

I so, so wish I could see the code that caused this to happen

 

Same.

Edited January 24, 2021 by Northstar98

[wadman]

Did some carrier landing practice today - what a pleasure to actually be able to use the indexer to confirm on-speed approach as I could actually see it clearly.  Thanks again for the workaround for this bug!

[RustBelt]

So all their hemming and hawing that it was right and how they designed it and blah blah.......The Hell?

[Slant]

Give the man a medal, that's a good find. Hard to relate these two. Well done!

[DD_Fenrir]

5 hours ago, RustBelt said:

So all their hemming and hawing that it was right and how they designed it and blah blah.......The Hell?

 

Make any modules for DCS lately?

 

A small mistake was made in the code and the brightness control inadvertently connected to an erroneous switch.

 

You have absolutely no idea how easy it is to make this kind of mistake. And how difficult sometimes it can be to ID the root cause.

 

As far as HB were concerned the AoA indexers brightness values were concurrent with those of the other systems - hence why 'they made the statement that it checks out; christ, even their SME - who's flown a damn sight more REAL Tomcats than you ever will - said 'it ain't that bad' and pointed out that in some lighting conditions, guess what, the 133,000 lux received from the sun at earth level MIGHT JUST overwhelm the pissy little 30W (or whatever it is) bulb in the cockpit of your jet.

 

The fact that this escapes you I find astonishing. The fact you choose to ignore an SME I find even more so. The fact you are so quick to berate HB and demand apologies or insinuate incompetence when literally the whole rest of the module, their work ethic and their willingness to communicate with us the community on these forums is of such a high standard many use it as a benchmark of how other developers should produce and manage theirs, well... frankly I find it and you offensive. 

 

Get some perspective and grow the hell up.

Edited January 25, 2021 by DD_Fenrir

[Skysurfer]

2 hours ago, DD_Fenrir said:

 

Make any modules for DCS lately?

 

A small mistake was made in the code and the brightness control inadvertently connected to an erroneous switch.

 

You have absolutely no idea how easy it is to make this kind of mistake. And how difficult sometimes it can be to ID the root cause.

 

As far as HB were concerned the AoA indexers brightness values were concurrent with those of the other systems - hence why 'they made the statement that it checks out; christ, even their SME - who's flown a damn sight more REAL Tomcats than you ever will - said 'it ain't that bad' and pointed out that in some lighting conditions, guess what, the 133,000 lux received from the sun at earth level MIGHT JUST overwhelm the pissy little 30W (or whatever it is) bulb in the cockpit of your jet.

 

The fact that this escapes you I find astonishing. The fact you choose to ignore an SME I find even more so. The fact you are so quick to berate HB and demand apologies or insinuate incompetence when literally the whole rest of the module, their work ethic and their willingness to communicate with us the community on these forums is of such a high standard many use it as a benchmark of how other developers should produce and manage theirs, well... frankly I find it and you offensive. 

 

Get some perspective and grow the hell up.

 

 

Chill dude. You seem way too invested in this. Point is, the indexer brightness wheel was not functioning and instead the DECM mode switch in the back controlled said brightness. It happened, someone figured it out, let's fix it asap. Simple as that. You also don't know what said SME saw on his screen. What if he had the ECM on and saw the indexer at max brightness?

[IronMike]

What we said still stands: we tweaked it to the values we found most realistic (and went a bit further than that even). And we always talked about the max brightness setting. It makes of course sense that ppl who would find it too low, have been affected by the DECM switch bug, and haven't seen max brightness yet. When we adjust such things, they dont get adjusted in game of course. So max looks really max for the developer - unaffected by other bugs. To which setting the SMEs and testers responded to, I have to ask, but likely default, so medium brightness. Which is still realistic in our SME's opinion, mind you - and shows you how much we "overdid" it on max setting from the get go, which is also something we said. Additionally - I just checked it again - the medium setting will be affected even more by lower gamma settings than default 2.2. Which is also something we said along the way. What brightness fits for whom, is preferance, and we get that. Which is why we increased it even more in the end, to give everybody more wiggle-room. We also understand when realism can be detrimental for the simming experience, again, why we gladly give in to such demands - to a certain reasonable level of course.

We're happy to apologize for any inconveniences caused by this bug. But we also stand by what we said.

Thank you all for your kind understanding. We increased the max brightness (yet again), so once the DECM switch bug is fixed, everyone will be able to adjust it to his or her preferences.

Edited January 26, 2021 by IronMike

[wadman]

4 hours ago, IronMike said:

 It makes of course sense that ppl who would find it too low, have been affected by the DECM switch bug, and haven't seen max brightness yet. When we adjust such things, they dont get adjusted in game of course. So max looks really max for the developer - unaffected by other bugs. 
 

 

This approach seems odd (and surprising) to me and why there has been a big disconnect on the discussion on AOA indexer brightness - if you don't validate your changes in the actual game, how can you know that you actually addressed the user's issues?  At the end of the day, how things work in the actual game we are playing are what matter?

[IronMike]

3 hours ago, wadman said:

This approach seems odd (and surprising) to me and why there has been a big disconnect on the discussion on AOA indexer brightness - if you don't validate your changes in the actual game, how can you know that you actually addressed the user's issues?  At the end of the day, how things work in the actual game we are playing are what matter?

 

That's the job of testers, SMEs, etc. not necessarily developers. And of course our developers also do check how stuff looks in game, run debuggers, have a model viewer to check quickly, etc. etc... But things may also work differently in a debugger, you can set certain things simply with menus, etc... All this is needed so the dev saves time on testing and spends more time on developing - and is a standard procedure throughout the entire industry.

Edited January 26, 2021 by IronMike

[RustBelt]

On 1/25/2021 at 9:23 AM, DD_Fenrir said:

 

Make any modules for DCS lately?

 

A small mistake was made in the code and the brightness control inadvertently connected to an erroneous switch.

 

You have absolutely no idea how easy it is to make this kind of mistake. And how difficult sometimes it can be to ID the root cause.

 

As far as HB were concerned the AoA indexers brightness values were concurrent with those of the other systems - hence why 'they made the statement that it checks out; christ, even their SME - who's flown a damn sight more REAL Tomcats than you ever will - said 'it ain't that bad' and pointed out that in some lighting conditions, guess what, the 133,000 lux received from the sun at earth level MIGHT JUST overwhelm the pissy little 30W (or whatever it is) bulb in the cockpit of your jet.

 

The fact that this escapes you I find astonishing. The fact you choose to ignore an SME I find even more so. The fact you are so quick to berate HB and demand apologies or insinuate incompetence when literally the whole rest of the module, their work ethic and their willingness to communicate with us the community on these forums is of such a high standard many use it as a benchmark of how other developers should produce and manage theirs, well... frankly I find it and you offensive. 

 

Get some perspective and grow the hell up.

 

Making the mistake is fine, Arguing for most of the year with the customers that it's not a mistake......that's another story and one Endemic to DCS. 

[RustBelt]

On 1/26/2021 at 2:20 AM, IronMike said:

 

That's the job of testers, SMEs, etc. not necessarily developers. And of course our developers also do check how stuff looks in game, run debuggers, have a model viewer to check quickly, etc. etc... But things may also work differently in a debugger, you can set certain things simply with menus, etc... All this is needed so the dev saves time on testing and spends more time on developing - and is a standard procedure throughout the entire industry.

 

 

Which is fine, right up until the point that someone using the product in game says there's an issue, then you need to verify it as noted, not in a developer environment. Knowing the limitations of a tool is the mark of a craftsman. And clearly the Developer tools have limitations that need to be accepted and understood before assuming there isn't a problem when people tell you there seems to be one. 

 

Standard Procedure isn't always right, because a lot of times Standard Procedure isn't BEST Procedure. 

[IronMike]

Ah Jayzus, Rustbelt... I mean I get it, it pisses you off, for some reason way more than it should, but ok. Let me explain it yet again: we cannot argue what you see, we can only argue what we see and what we tweak. And in that we do not argue personal preferences either, but the process, outcome, etc... At 20%, if you wanna take the value from "good points", it still appears realistic to us with our settings and on our monitors, and to our SMEs. So, no wonder Cobra wanted to smack me every time I asked him to increase it yet more... We said from the get go that the max setting was already way too bright in terms of realism. Only that we thought you all saw it so dim, because of your gamma settings, and not because of the DECM switch. Great, it got cleared up now. That changes nothing of what we said, and still stand by. I dont know, but maybe you noticed that we're not the types who argue being right, when we are not. But we can only ever argue to our best knowledge. And we did accept that you guys found it too dim, and increased it even more. What you want else? You're not getting an apology, for what still stands: at that dimmer setting it is realistic, and at max brightness it isn't. Realism has not the final say in this case though, because preferences and monitors... Nothing has changed in that. We do these things and argue these things to improve your experience, not ours. And we're more than happy to apologize for the DECM bug and any inconveniences it caused, that is self understood. Mind you, you never wanted it realistic, you wanted it brighter. And that is what you get. So, not sure what your point is here...

Edited January 28, 2021 by IronMike

[fat creason]

17 hours ago, RustBelt said:

 

Which is fine, right up until the point that someone using the product in game says there's an issue, then you need to verify it as noted, not in a developer environment. Knowing the limitations of a tool is the mark of a craftsman. And clearly the Developer tools have limitations that need to be accepted and understood before assuming there isn't a problem when people tell you there seems to be one. 

 

Standard Procedure isn't always right, because a lot of times Standard Procedure isn't BEST Procedure. 

 

Behold: https://en.wikipedia.org/wiki/Dunning–Kruger_effect in action!

Edited January 28, 2021 by fat creason

[RustBelt]

6 hours ago, IronMike said:

 I dont know, but maybe you noticed that we're not the types who argue being right, when we are not. 

 

Uhhhhhh You really said that? You especially? The most argumentative member of Heatblur? 

[IronMike]

1 hour ago, RustBelt said:

Uhhhhhh You really said that? You especially? The most argumentative member of Heatblur? 

 

Yes, especially me, the evil person who argued your personal preferences into being within the dev team... Anyway, I hope it makes you feel better, so we can close this thread now. 
 

Edited January 29, 2021 by IronMike