
John Dowson
Members-
Posts
13,466 -
Joined
-
Last visited
-
Days Won
279
Content Type
Profiles
Forums
Events
Gallery
Downloads
Everything posted by John Dowson
-
Excessive stuttering the last few days with MSFS 2020
John Dowson replied to Jermaine's topic in FSUIPC7 MSFS
No this is not possible (FSUPC7 is a distinct application). The only thing I can advise is: 1. Check the MSFS console - if you see excessive logging there then that could be the culprit 2. Check the Asobo forums for similar issues I would suspect MSFS server issues. You can try and disable some online services (AI traffic, weather) to see if that improves things. Sorry I can't be of more assistance, John -
Presumably the mouse macro is being called? You can verify this by logging Buttons & Keys and checking the log. If the macro is being called but is not working, it could be that you need to manually modify/edit the mouse macro to either add a button release (the macro will have only recordeed the mouse press), or change the press to a press-and-drag and also add a release. This is similar to what I explained in this post: So try modifying the macro - if you can post/attach it here I can take a look and adjust it for you. John
-
Yes, that is the brute-force method, but you will have lost the auto-start of your other entries: FenixBootstrapper AFCBridge IVAO Pilot Client Couatl FSRealistic SimHaptic That is why I didn't recommend that. If you also want those auto-started, try that last EXE.xml I attached (or add the entries for them back into your current EXE.xml). John
-
Yes, sorry - there is something very strange with that EXE.xml. I have re-written it - try this one: EXE.xml You should be able to uninstall/re-install with that one. John
-
Sorry, but what issue with uninstall? It maybe the same issue - problems loading your EXE.xml. I have just tried with your EXE.xml and I can see the issue - never ending messages updating the EXE.xml. I will take a deeper look...
-
There was a problem loading your EXE.xml for both MSFS2020 and MSFS2024: I am not sure why the installer couldn't load your EXE.xml as it looks ok - this normally happens if there is an xml syntax issue in the file. You can add the FSUIPC7 entry manually: <Launch.Addon> <Disabled>False</Disabled> <ManualLoad>False</ManualLoad> <Name>FSUIPC7</Name> <Path>D:\FSUIPC7\FSUIPC7.exe</Path> <CommandLine>-auto</CommandLine> <NewConsole>False</NewConsole> </Launch.Addon> I have added it for you in the attached MSFS2024 EXE.xml. John EXE.xml
-
No problem! John
-
...but this shouldn't apply when using presets/calc code as that is executed via the Gauge API, so I don't understand this either...
-
All FSUIPC log files can be found in the FSUIPC installation folder. The location of the EXE.xml file is also logged in the InstallFSUIPC7.log file, but I see you have found and attached that. Well, FSUIPC7 will not auto-start as there is no entry for FSUIPC7 in the EXE.xml that you attached. Did you install the auto-start component, and if so which one? Re-run the installer and leave all the settings as-is, then try again, and if you still have issues please show me the InstallFSUIPC7.log file - I need to see this to diagnose any issues. John
-
You can use the ini parameter DontLogThese to ignore those, best used in your profile section. See the Advanced User guide for details on this ini parameter. Yes, strange, However there is an issue with some external controls in that they don't work in the same manner as the internal one. This has been reported to Asobo (a long time ago), but I guess it has not yet been fully addressed. Is there another lvar that holds/controls the light state? If so, you could try using that.... John
-
Also, for any/all auto-start issues. please see the following FAQ entry: John
-
You should only use the direct SteeringTiller axis if you want to blend with the rudder (and then assign to the same axis as rudder) If you are using separate axes and don't want any blending, you can try assigning using 'Send to FS as normal axis' and try either the Axis Steering Set and Steering Set axes. You can still calibrate. Axis Steering Set seems to work fine in the longitude. Also no issues if you want to bind that axis in the sim.
-
So it installed ok after the reboot, including updating the EXE.xml? If FSUIPC7 is not starting with MSFS, then its most likely an issue with your EXE.xml. Please show me/attach that file, together with your InstallFSUIPC7.log file and I will take a look. Note that you should run MSFS at least once after re-installing and before installing FSUIPC7. John
-
Ah...I think you are misunderstanding FSUIPC's rudder/tiller blending facilities. These are intended to be used when both the rudder and tiller are assigned to the same axis. It doesn't make sense blending these if separate axes are used as there are already separate values for rudder and tiller. That is strange - it should show the deflection that you apply (once calibration has been applied)....
-
Can you please set logging for Axes Controls, and also log offsets 0C08 and 0C0A, both as S16 (and log to normal log file) and show me a FSUIPC7.log file. Thats strange - I will check this. Note that you have a profile-specific calibration section for the DHC-4 - were you looking there? It is still set to Q in the ini you attached. Strange that the first image you posted shpws the general calibration section though, and not the profile-specific one. Did you make this profile-specific after attaching that image? I don't have the DHC-4, but I will check this in another aircraft. You should also consider changing your aircraft names in the profiles to use substrings, so that they catch mpre variants. e.g. change to and update the other aircraft names in your profile sections to use substring matching. John
-
Maybe the lvar is only controlling the visuals? If thats the case, then something else may be needed to control the actual functionality (and sound). I don't have this aircraft so cannot look into this. There are a few things you can do: 1. Use FSUIPC's logging facilities, and log Events and Input Events. What do you see logged when setting the autobrake with the mouse, and is this different than when using the preset? You can check this in real-time by opening the logging console (Log->Open Console). 2. Inspect the code of the autobrake switch/rotary to see how it is implemented. See https://www.badcasserole.com/uncovering-input-events-using-the-msfs2024-model-behavior-dialog/ 3. Ask about this preset on the Mobiflight HubHop support. on Discord under the MSFS2020 channel. John
-
Glad you got this working! Yes, doing that should have given you a lot if insight in how and why to use such functionality as assignment overloading, adding lvars to offsets, and using offset conditions, That should be useful for future complex assignments. The lua script is also not a bad solution, but this is probably more resource efficient and will execute faster, as it won't have the thread creation overhead (as all lua scripts are ran in separate threads). No problem - and thanks for the update. John
-
In short, no. You can only discover/find hvars either by inspecting the xml code of the aircraft, or if published in the aircraft documentation. There is no method (that I know of) to discover hvars by any other means, not even programmatically. This is why you need to provide a file to tell FSUIPC what hvars are available, if you want to use them. Also, it seems to me that hvars have fallen out of favor. Many early MSFS2020 aircraft used them, but later ones have switched to b-vars/input events. If using hvars, I think its better to use them via presets and forget about the *.hvar files. The direct access to hvars was added before the preset/calculator code interface was added. As hvars have no state/value (they can just be triggered), there is really no need for these to be known by FSUIPC, and better/easier to just trigger them via calc code or a preset. John
-
This depends on where the FD is getting the ILS data. You could try setting the follwing ini parameter in FSUIPC to see if that helps: See It may be worth asking Project Magenta support about this as that post was from Enrico, the author of PM. Is Navigraph using the output from MakeRwys? Note that I do not support MakeRwys, but the source is available if needed: John
-
I cannot see anything, and no macro button' should appear. The macros's should be available for assignment in the control drop-down menu, preceded by the file name. Are they not there? If I save your macro file to my FSUIPC7 installation folder, I see them all: Note also that presets already exist to control/set those hvars, e.g. Why don't you just use them? You also have the lua file being auto-ran: You should remove that - there is no need or reason to run that file.
-
Yes, both would work as both strings 'Cockspur PH100' and 'PH100' are contained within the aircraft names 'Cockspur PH100 Brown and Black' and 'Cockspur PH100 Factory 1', hence they are substring matches. This just means that the hvar filename string exists/matches to a string in the aircraft name. You could use the entire aircraft name if you like, but that would just match one aircraft and would not match if you changed the livery/version. Note you can (and should) also use substring matching for your aircraft profile names. Change to which would then match all variants of that aircraft. You should get into the habit of editing the aircraft names in the profile section when you create a new profile or add an aircraft to an existing profile, and reduce it to a substring of the full aircraft name so that it matches other variants.
-
PMDG 737 and myevents.txt for issuing the commands
John Dowson replied to AlMassimo's topic in FSUIPC7 MSFS
That's rather strange, as only 10 presets are sent each time - well, 10 on press and 10 on release, so maybe 20. So I am not sure why 1 "fast" inc/dec would change by 40. You can adjust this yourself - just remove some of the fast inc/dec assignment lines from your ini. Try with the release assignments removed, i.e. the ones that start with 'CU'. Note that you can edit the ini with FSUIPC7 running so you can adjust this and test without restarting. Just make sure that the button assignment panel/window is open when you edit the ini, and once you have saved your changes, click the Reload all buttons button to reload the updated ini and then test. You can repeat and add or remove more assignments until it inc/decs how you would like it to. John -
PMDG 737 and myevents.txt for issuing the commands
John Dowson replied to AlMassimo's topic in FSUIPC7 MSFS
The log file shows that the assignments are working as expected: - pressing button 16 without 18 being pressed sends one inc preset: - pressing button 17 without 18 being pressed sends one dec preset - pressing button 16 with button 18 pressed sends 10 inc presets: - pressing button 17 with button 18 pressed sends 10 dec presets: So the assignments are working as expected. What do you actually see on slow/fast clockwise/anticlockwise rotary movements? Are he slow ones now at least working. incrementing and decrementing by 1? Do you see any change when also using button G18 (i.e. the fast/larger in/dec)? -
As any lua lvar function using the lvar name is quite expensive in turns of performance (as it has to scan all lvars and do string matching to find the id), you could improve that by just reding the lvar value once:: domeLightDisplay = ipc.readLvar("L:VC_Dome_Light_Display_VAL") if domeLightDisplay == 0 then ipc.execCalcCode("39 (>L:VC_Miscellaneous_trigger_VAL,number)") elseif domeLightDisplay == 1 then ipc.execCalcCode("39 (>L:VC_Miscellaneous_trigger_VAL,number)") elseif domeLightDisplay == 2 then ipc.execCalcCode("38 (>L:VC_Miscellaneous_trigger_VAL,number)") ipc.sleep(100) ipc.execCalcCode("38 (>L:VC_Miscellaneous_trigger_VAL,number)") end I'm trying to figure out how this would work. So, if I define a preset as suggested by you, how do I then proceed? Where do I define such a preset? Can you point me to the right support document or some kind of tutorial? Sorry, I'm pretty new to this part of coding and appreciate some hints. You define presets in a file called myevents.txt (you have to create this) - see the section Using Calculator Code Presets on page 50 of the Advanced User guide. If you wanted to replicate that lua script using presets and direct assignments, you would need to: 1. define 2 presets in the myevents.txt file, e.g. //iFl/737MAX/Lights Dome_Light_Up#39 (>L:VC_Miscellaneous_trigger_VAL,number) Dome_Light_Down#38 (>L:VC_Miscellaneous_trigger_VAL,number) 2, Add the lvar VC_Dome_Light_Display_VAL to an FSUIPC offset. Best to do this in your profile, e.g. if your profile is called xxx, the following would add this lvar to offset 0xA000 as a single byte value: [LvarOffsets.xxx] 1=L:VC_Dome_Light_Display_VAL=UB0xA000 See the section Adding Lvars to Offsets on page 47 of the Advanced User guide. 3. Assign your button to one of the presets. This will result in an entry in your FSUIPC7.ini like the following (the index, joystick letter and button number will differ): 73=PS,3,CPDome_Light_Up,0 -{Preset Control}- 4. Open the button assignments panel in FSUIPC7, and also open the FSUIPC7.ini file in an editor and locate the button assignment line. You then need to duplicate that 4 times, changing the index number and the preset used: 73=PS,3,CPDome_Light_Up,0 -{Preset Control}- 74=PS,3,CPDome_Light_Up,0 -{Preset Control}- 75=PS,3,CPDome_Light_Down,0 -{Preset Control}- 76=PS,3,CPDome_Light_Down,0 -{Preset Control}- 5. You then need to add the delay between the two down presets, and add an offset condition to the offset holding the value of the lvar VC_Dome_Light_Display_VAL: 73=BA000=0 PS,3,CPDome_Light_Up,0 -{Preset Control}- 74=BA000=1 PS,3,CPDome_Light_Up,0 -{Preset Control}- 75=BA000=2 PS,3,CPDome_Light_Down,0 -{Preset Control}- 76=BA000=2 PS,3,C1152,100 -{pause (ms)}- 77=BA000=2 PS,3,CPDome_Light_Down,0 -{Preset Control}- See the section Adding offset conditions on page 24 of the Advanced User guide 6. Save the changes to the FSUIPC7.ini file, and then click the Reload all buttons button in FSUIPC7 to reload the updated ini. The one doubt I have on this is whether the last preset (with index 77 above) will be sent or not: it could be that the lvar is updated, and thus the offset value, before that assignment is considered for execution, and if that is the case it will not be executed as the offset value will no longer be 2 but 1. If this is the case, reduce the delay - 10 or 20ms should be enough really. John - :