
John Dowson
Members-
Posts
13,486 -
Joined
-
Last visited
-
Days Won
280
Content Type
Profiles
Forums
Events
Gallery
Downloads
Everything posted by John Dowson
-
Sorry, but what does this mean? I am not saying or implying that you have changed a preset (although you can do this if you so wish - but not recommended as it will get overwritten on the next release). I include the latest preset list (events.txt file) from MobiFlight in every release. You can download and update this yourself in-between releases if you so wish. As that preset was updated on 21st March, maybe the preset was renamed? If that is the case, you will need to re-assign to the new name - you should get an error in the FSUIPC7.log file if the preset name cannot be found.
-
-
Presume you mean the presets A32NX_Autopilot_AP_1_Push and A32NX_Autopilot_AP_2_Push. I will switch to the dev version and try this later. However, if the preset mechanism is working for you (i.e. you do have a working preset), but some presets are not working, then you should report / ask about this on the MobiFlight Discord channel - preferably by tagging the author of the preset (if posible). I just provide the mechanism to implement the presets, and provide the preset file from MobiFlight (https://hubhop.mobiflight.com/presets/). John
-
No. However there is a trial license available if you would like to try it: John
-
HW: FSUIPC events for Working Title GNS 530 / GNS 430
John Dowson replied to Guido's topic in FSUIPC7 MSFS
👍 -
HW: FSUIPC events for Working Title GNS 530 / GNS 430
John Dowson replied to Guido's topic in FSUIPC7 MSFS
Did a quick check and the WT GNS 430/530 uses hvars, the same ones as the stock GNS. And these are what the MF presets use, so they should work. Your preset log file is showing that you are NOT using presets, but standard controls. For example, the preset for the clear button is called AS430_CLR_Push, and your log file is showing the standard control GPS_CLEAR_BUTTON. And always post full log files to support, i.e. do not use the New Log function. I cannot tell what version of FSUIPC7 you are using - make sure it is the latest, which is 7.3.19. Any further issues with this, please attach your FSUIPC7.ini and a full FSUIPC7.log file with logging for Events and Buttons & Keys activated. John -
HW: FSUIPC events for Working Title GNS 530 / GNS 430
John Dowson replied to Guido's topic in FSUIPC7 MSFS
Yes - you can use the DontLogThese ini parameter - see the Advanced User guide. I will take a look in the C172 and let you know - however this will most likely be tomorrow now (I have to get started on lunch...!). John -
HW: FSUIPC events for Working Title GNS 530 / GNS 430
John Dowson replied to Guido's topic in FSUIPC7 MSFS
Ok - and let me know which aircraft (Asobo) you are using, as well as a GPS control, if you you still can't find anything that works and I will take a look. John -
Ah, ok. I was just looking at your log file but it didn't help much...it looks like it was something to do with an offset/simvar not having the correct value to enable some threads to be started. I was going to add some additional logging to narrow this down - I will still add this for the next version of FSUIPC6 anyway, so that I have more info to track this issue down if it happens again. Anyway, I'm happy this is now solved (saved me some time!) but it would be nice to know the root cause of this issue. No problem. Quite nice here today - sun and clouds, but a little cold (14C). Off into the garden to prepare my outside vegetable beds to start planting later this week... Cheers - enjoy the rest of your weekend, John
-
HW: FSUIPC events for Working Title GNS 530 / GNS 430
John Dowson replied to Guido's topic in FSUIPC7 MSFS
Try the following to determine what controls to use for any button/switch and in the following order (ease of use): 1. Activate FSUIPC logging for Events (Log->Events) and open the logging console window (Log->Open Console). Then press the button/switch in the virtual cockpit and see if anything is logged, and if so you can use that. Note that you may see other events logged, some continually - this varies by aircraft. You can ignore those. 2. Search the MobiFlight hubhop site (https://hubhop.mobiflight.com/presets/) for available presets - enter 430 or 530 in the search box and you will see many generic presets for both the 430 and the 530. Try assigning to these by checking the Select for preset checkbox in the assignment panels. 3. List the available lvars using the Add-ons->WASM->List Lvars menu item and see if any look relevant to the function you are trying to assign. Once you have identified an lvar, press the button/switch in the virtual cockpit, and then list the lvar values again to see if the lvar has changed. If it has, you can then check to see if the lvar is settable by using the Add-ons->WASM->Set Lvar menu option. If that works, you can assign to the lvar in various ways: using macros, defining your own preset, or adding the lvat to an FSUIPC offset and using the offset controls. I can help you further with this if needed. I suspect it will be the AS430_* and AS530_* presets that you need to assign to, but if you have issues I can take a further look next week. John -
Where does one download that version? It doesn't appear to be available on prepar3d.com. Ok, sorry - think the difference maybe between the Academic and Professional plus versions, although I thought this was only the license and not related to the versions. I don't think this matters. The issue seems to be related to the simconnect events FSUIPC6 is not receiving, and so not switchung to the correct state to start wideserver and other related threads. I will know more once I have examined your latest log file. That is strange, but the build number seems to be correct. I am also on Windows 11 and this is what my log file reports: This information is just taken from the registry and is for informational purposes only. Its a known issue that windows 11 reports the incorrect version, but not sure why yours is reporting windows 8 though, but it will be from your registry. I will take a look at your issue and the new log over the weekend, when time permits. For now continue with the workaround you have found, i.e. disable WideServer and then re-enable. Confusing as your system was working and nothing seems to have changed. These issues are very frustrating and take a long time to investigate... John
-
Definitely something strange in the sim events being received (or, those not being received). Can you also add the following log directive (keep the others!): LogExtras=x400 This will log all simconnect data received and the log file will be large and will probably need compressing/zipping before attaching. BTW, did you re-install the P3D client? Your P3D version is also out-of-date: Prepar3D.exe version = 5.3.17.28160 Can you update to the latest version: Prepar3D.exe version = 5.3.18.28350 ? John
-
What version of the FBW A320 are you using? Those preset are listed for the dev version only. And is your FBW up-to-date? The date of that preset is 21/03/2023 so I suspect it may only work on the latest dev release. Your question also doesn't relate to the title of this topic - which is itself not a helpful title. If you cannot find a relevant topic to post your question please create a new topic. This helps others find it if they have the same issue. I am closing/locking this topic now. John
-
FSUIPC P3Dv5 Key_Event firing a mouse macro
John Dowson replied to FAR's topic in FSUIPC Support Pete Dowson Modules
👍 -
Are those the files from when you go through the procedure? I want to see them when wideserver is already enabled and you start P3D and load an aircraft and be ready-to-fly. After that, wait a minute or so and then exit. Your log file is quite strange as it shows no devices: and there is no log line indicating that everything has been started, such as the following: Nothing will connect until that is logged. Maybe also try re-installing the P3D client - this has been known to get corrupted on occasion and can give strange issues when this occurs. John
-
Ok - then please show me the WideServer.log file when you get the issue and WideServer is enabled at start-up. Especially now that OneDrive is installed and difficult to remove, even if not used. Ok - put your first WideClient.log has this: which implies that the protocol was not set. It is difficult to tell your actual set-up for each test - always better to include all 5 files (FSUIPC6.log, WideServer.log, FSUIPC6.ini, WideClient.ini, WideClient.log) from each run, generated at the same time and after everything has been stopped (i.e. at the end of the test run). Ok... I get such issues with WideServer/WideClient connections every other week, and these seem to appear and then go away at random. There has been no change in the WideClient/WideServer code for many years, and such issues are extremely difficult to diagnose,,, and usually go away for no reason that I can find, as they appear,,, John
-
What has changed in this timeframe (or just before), if anything? As you are using UDP on the server, you could try specifying this in the clients by adding Protocol=UDP to the [Config] section of your WideClient.ini files. This is strange...I may look into this but we will see.... Ok, so it works when disabled and you enable. What happens on the next run - does it come back to the initial issue (WideClients not connecting, no 'Waiting for...' message in the FS window)? Not finding a WideServer.log file is very strange...and it is difficult to diagnose issues without this file. The FSUIPC.log file does show that WideServer is started, but it is not clear from which test scenario this is from - and it is also not complete, i.e. FSUIPC seemed to be running when this was attached (no close). One thing that does strike me as slightly dodgy is your FSUIPC6 installation location - you have installed under the windows Documents folder. It is always better to choose a non-windows protected folder (e.g. C:\FSUIPC6 or C:\Prepar3D Add-ons\FSUIPC6) as windows seems to be changing access rights on windows-defined folders. So I suggest you first re-install FSUIPC6 into a different non-windows protected folder - you can skip registration and copy across your FSUIPC6.key and FSUIPC6.ini files, together with any other files you may use (e.g. *.lua, *.mcro, *.dll) from your old installation location to the new one. The Documents\Prepar3D v5 Add-ons\FSUIPC6\ folder should just be used for your add-on.xml file that allows the FSUIPC6.dll to be loaded when P3D is started. John
-
Can you try the attached version please. In this, I have allowed passthrough of key presses sent to MSFS and then received back. This should solve your issue, but I am not 100% convinced that this will be the final solution. I need to do some more testing on this, but would confirm the issue if you could test and report back. To use, re-install the 7.3.19 version, and then use the attached exe (7.3.20a) to replace the one installed. Thanks. FSUIPC7.exe
-
Ok, now this makes more sense. The older version is setting the HotKey when the keypress sent on the button press is received back: In a later version, I ignore key presses sent as this can cause issues in certain situations with keys being sent and received in an eternal loop. I must admit, I forgot about HotKeys in this situation - and am surprised that this hasn't been reported before. I will look into this and post an updated version for you to test in the next few days (hopefully!). Using the appropriate controls assigned on button press and button release. This should be straightforward if you look at the UI - and read the User guide if its not obvious... But no point in doing this anyway, as the issue is that the HotKey that is registered is not being set. As I said, I will look into this and post an update for you to test, John