ark1320

Hi John, It seems that when the sim has focus the four stand alone arrow keys (in the 'inverted T' pattern on many keyboards) are not seen by FSUIPC7. Perhaps this is essentially caused by the same Simconnect bug that prevents FSUIPC7 from seeing the Number pad number keys when the sim has focus. If Asobo has not at least acknowledged this Simconnect problem I would suggest it would be good for you as a developer to contact them again about it. Thx, Al

Yes, a slope setting would explain it-- forgot about that. Thanks, Al

Hi Thomas, I'm having a hard time understanding how FSUIPC came up with the Out value -7912 in the above. If the old min was -16384, then -16384/-22380 = 0.732. So I would expect any 'new' In value to be reduced by a factor of about 0.732 (ignoring the -512 offset). If the input above is -16384, I would expect an output of -16384 * 0.732 = -11993, again ignoring the -512 offset. The value of -7912 is a long way from -11993. Thanks, Al

OK, that's what I thought. I will wait - hopefully Asobo will take note of your inputs. If I want to fly now, I just use P3Dv5. My interest here is to help debug FSUIPC7 if that is needed. Al

John, I agree you should not implement workarounds at this time. I'm not currently doing any 'real' flying in MSFS because it has so many problems right now. My interest is in helping to get FSUIPC7 working well in anticipation of when MSFS finally is usable in a manner similar to P3Dv5. Al

Thanks John, I will give this a try. Al

Yes, in some a/c the AP VS is set simply by capturing the aircraft's current VS (the Learjet 35A does this). In others, you dial in a target VS for the AP. My concern with the tests described above, which I conducted with the a/c sitting on the ground, is the working of Simconnect. As you can see in the picture I posted, the Baron58/G1000 in MSFS has a blue VS bug that can be set. The value of the bug is also shown at the top of the VS scale. This is the target VS for the AP, not necessarily the current VS. While the tests showed the VS bug can be set by writing to Offset 0x07F2 , the question is why does this only work if you first execute (write) the non-working AP VS SET control (66102) at least once? Does this indicate a problem with Simconnect, or with FSUIPC7, or with the sim itself somehow? Thx, Al

Hi John, Ran some more tests. Here's what I find (at least for today)! 1. Start the sim, load the Baron58 with the G1000. The sim has the focus for all the below. 2. Run a one line test script: ipc.writeSW(0x07F2, 1200) but nothing shows up on the G1000 at the top of the VS scale (even if I rerun the script a few times). 3. Run a one line script using the AP VS SET control: ipc.control(66102, 900) but what shows up on the G1000 is not 900 but the 1200 from the previous script as shown below on the top of the VS scale! 4. Thereafter, every time I run the one line ipc.writeSW(0x07F2, ....) script, but with different VS values each time, the correct values show up on the G1000 each time. 5. If I go back and run the one line AP VS SET control script, it still doesn't work. So, writing to offset 0x07F2 only works it you run the AP VS SET control first at least once even though the control itself doesn't seem to work! I have repeated the above test sequence at least five times, restarting the sim each time. I hope you have some ideas on what might be going on, because I sure don't! Al

Today I'm getting the 0x07F2 offset to work, but not the AP VS SET control - nothing seems repeatable! I will do some more testing and get back to you. The units for the AP VS SET control I used were ft/min. Note in the P3D SDK there are two K events available: KEY_AP_VS_VAR_SET_ENGLISH and KEY_AP_VS_VAR_SET_METRIC. Al

Great, glad I could help you for a change! 🙂 If that is not time consuming to do, that might be useful to allow further testing of FSUIPC7 with MSFS. I currently find MSFS almost unusable at this point due to all the bugs, but am very interested in identifying bugs that impact FSUIPC7 so FSUIPC7 works well with MSFS in the future when Asobo hopefully gets things figured out. Al

Well, one problem with this approach is MSFS has default assignments for the "Off" Num lock keys like Insert, End, Home, Left, etc. So all those assignments would have to be changed because MSFS actions those keys as soon as they are pressed. I really think Asobo needs to make Simconnect work wrt Num Lock as it does in FSX/P3D. I would expect the will be many 3rd party developers that will want to use the Numpad for entering data 'as usual'. Al

I can set the target AP vertical speed value in the G1000 with a Lua script using the above version of FSUIPC7 by writing the VS value to offset 0x07F2. EDIT: It now seems I first have to use the AP VS SET 66102 control first at least once, and then repeated writes to Offset 0x07F2 seem to work. Strange. Al

Here is a tiny app I use that puts a very small icon in the right corner of my taskbar (by the speaker icon) that indicates if Num lock, Caps lock or Scroll lock are on or off. In the pic below, the green 'LED' above the little 1 shows Num lock is on and the other locks off. https://keyboard-leds.com/ Al

John, Attached a little app the shows the keycode when a key is pushed, perhaps it might be of use to you. Al KeyCodes3.zip

Thanks -- much appreciated! Al

Thanks John, sure hope the Numpad problem can be figured out. The non-numerical 'versions' of the numpad keys already are well used in MSFS. Al

Hi John, Any response from Asobo on this -- did they at least acknowledge the problem so it can be fixed? I was surprised to see that when FSUIPC7 has the focus and the scripts are run using the Numpad to enter values, the G1000 in the sim is in fact updated wrt to Nav and Com frequencies, transponder code, altitude preselect, heading bug and course, even though the sim doesn't have the focus. As before, however, the Numpad entries are still trapped and not getting passed through Simconnect if the sim has the focus. Al

Ah, I see now. Assuming 25KHz spacing, the frequency's 2nd decimal place digit determines what the 3rd decimal place digit HAS to be -- clever! Thanks, Al

Hi John, no problem, I appreciate all the hard work on FSUIPC7! I've tried those COM1/2 Radio Set events without any luck so far. BTW, is there any difference from a Simconnect or sim point of view between using an offset for COM STBY RADIO SET like ipc.writeUD(0x05CC, 123455000), and using a control event like ipc.control( 66371, 123455000) , or are these two instructions processed identically by the 'system'? Thanks, Al

In that case I don't see how you can specify a 25 Khz spaced com freq like 123.475. For 25KHz spacing the 6th digit can either be 0 or 5 unless I'm not understanding something (00, 25, 50, or 75 for the last two digits). Seems you need to specify 6 digits total for 25Khz spacing. Al

John, I assume the COM_RADIO_SET 5 BCD digits for 25KHz spacing will not include the frequency's leading 1 digit (so the same idea as currently for the 4 BCD digit NAV frequency case) -- correct? Thx, Al

I see, thanks for letting Asobo know. Sure hope they fix this soon. Al

Hi Thomas, I'm aware that many controls are not working. I just wanted to verify the control numbers had not changed so if a control doesn't work I know it is likely a Simconnect/MSFS issue and not a control number issue. Thanks for the response, Al

Hi John, Are the FSUIPC7 control codes for use with ipc.contol() the same as listed for FSUIPC6? I do realize not all may be working in FSUIPC7. EDIT: OK, I tried a couple of the control codes and they seem to work so I'll assume the FSUIPC6 listing is the same for FSUIPC7. Thanks, Al

I temporarily modified one of my Lua scripts to avoid using the Numpad keys and also a few of the special keys directly above the Numpad, and the script works as expected by correctly calling functions based on the ipcPARAM values associated with particular keys. So I expect all my other scripts that use ipcPARAM will work once FSUIPC7 is updated. Thanks for figuring out the Numpad keys input problem, Al