Prepar3D Forums

I don't have P3D v4.2 installed because of the bug it has with the numbers sticking in memory causing the SimConnect window to not work properly. I know there are workarounds but I make extensive use of numbers and I don't want to change my entire 'workflow' because of this bug. I don't even have P3D installed right now: I decided to wait for the fix. But the wait is getting long... I am seriously amazed (to put it gently) that LM hasn't fixed this with a hotfix by now. Really terrible and disappointing and bad support.

1. What numbers?
2. What SimConnect window? SimConnect doesn't have a window.

If you're talking about an issue where you can select a numeric value that isn't displayed in a window like the ATC window and third party software acts on it when it shouldn't... I'd say that's part their fault as well as an issue in the core code. Their software should know exactly what values are valid as choices and ignore the rest.

WarpD wrote: ↑Sat Mar 17, 2018 1:12 pm 1. What numbers?
2. What SimConnect window? SimConnect doesn't have a window.

If you're talking about an issue where you can select a numeric value that isn't displayed in a window like the ATC window and third party software acts on it when it shouldn't... I'd say that's part their fault as well as an issue in the core code. Their software should know exactly what values are valid as choices and ignore the rest.

1. 1 to 0. ;)

2. It sure does. Open missionpanels.cfg which is in the gauges folder and look for [Window 12]. See that ident? Yep, it's called SIMCONNECT_WINDOW. ;) It's being used by addons that use SimConnect like Active Sky, GSX, ProATC, etc.

That SimConnect window works with numbers: that IS the core code. LM simply needs to fix this so things work as they should again.

As I've already stated, software should never, ever respond to input it doesn't want. The addon developers should not be paying attention to values that are not valid at the time of input.

I realize that this is something that has changed with v4.2... but that doesn't take away that the developers (not L-M) should be coding smarter. If your code isn't wanting a 4 (as example) then you shouldn't respond to a 4. You should act as if no input was provided at all.

WarpD wrote: ↑Sat Mar 17, 2018 7:18 pm I realize that this is something that has changed with v4.2... but that doesn't take away that the developers (not L-M) should be coding smarter. If your code isn't wanting a 4 (as example) then you shouldn't respond to a 4. You should act as if no input was provided at all.

BUT the problem is worse than that. There are two problems resulting from the bug in 4.2:

1. Whether or not the key (in the buffer?) is a valid menu item or not, it is treated as if an item has been selected, so the menu is promptly closed, without the user having made a choice.

2. If the key does match a valid menu entry then that menu item is chosen, even though it wasn't necessarily the one wanted by the user.

The seond problem is arising because programs like ProATC/X have the 0, 1, 2, 3 ... keys as their default-assigned action shortcuts. The work-around in that case, and in any proram which allows such shortcuts to be changed, is to reassign to something ineffectual. But it still doesn't stop the menu disappearing with no choice made.

This bug is bad enough to make many users go back to 4.1 and await a hotfix from L-M, which does seem rather slow in coming considering the seriousness (in terms of user friendlness) of the symptoms.

Pete

WarpD wrote: ↑Sat Mar 17, 2018 7:18 pm As I've already stated, software should never, ever respond to input it doesn't want. The addon developers should not be paying attention to values that are not valid at the time of input.

I realize that this is something that has changed with v4.2... but that doesn't take away that the developers (not L-M) should be coding smarter. If your code isn't wanting a 4 (as example) then you shouldn't respond to a 4. You should act as if no input was provided at all.

You don't seem to understand the problem. The fact is that the numbers actually ARE valid values. You can't code this smarter. It's not the code that isn't wanting a 4, it is the user that isn't wanting a 4! The 4 itself may be a perfectly valid number. Due to the bug the software reacts to valid values but they aren't the values a user wants at that moment but simply the latest value that has been touched on the keyboard. But well, Pete explained it perfectly. ;)

Pete Dowson wrote: ↑Sun Mar 18, 2018 9:51 am This bug is bad enough to make many users go back to 4.1 and await a hotfix from L-M, which does seem rather slow in coming considering the seriousness (in terms of user friendlness) of the symptoms.

Thanks for confirming the bug and how serious it is.

I'd also like to install 4.1 but unfortunately I deleted the installers so all I have now is 4.2 which means I am stuck.

Anyway, I didn't start this topic to discuss the bug: I simply would like to see a reply from LM with an expected release date of the fix for it... ;)

"I'd also like to install 4.1 but unfortunately I deleted the installers so all I have now is 4.2 which means I am stuck."

The Legacy 4.1 installer should still in your account ready for download.

Pete

Understood.

J van E

L-M will only state when something is to be released once they have it fixed and then they won't provide a date... rather simply stating it will be in the next released update. Discussing the bug is important... the more information, the better. I can state that they're aware of the issues and are looking into them.

Has anyone heard if this is to be fixed in v4.3? I haven't seen any more from L-M on this, and it's been a real problem since 4.2 hit the streets.

Regards

Bob Scott

Hi Bob,

This will be fixed in 4.3.

Regards,
Rob McCarthy