John Dowson
Members-
Posts
12,240 -
Joined
-
Last visited
-
Days Won
249
Content Type
Profiles
Forums
Events
Gallery
Downloads
Everything posted by John Dowson
-
This certainly shouldn't happen and haven't seen this ... but I will check this here. Can you please check with another aircraft to see if this is specific to the Fenix. I don't have this aircraft so cannot test with that here. John
-
What fix? This FAQ entry explains how auto-start is implemented. Then read this article and check your files.... To start FSUIPC7 manually, you should start the FSUIPC7.exe, not the batch file. Please read this article - it explains how auto-start works, and what files are changed and how they should look. And there are two auto-start methods - the EXE.xml and via the MSFS.bat. It is better to use the EXE.xml method (the default method), but if you cannot get that working then try the alterative method. John
-
I have checked the details in that order and they validate just fine here. I have PM'ed you a key file - please try this. Re-run the installer and see if it validates. Also, try running FSUIPC7 and see if it is licensed/registered. John
-
If you are running MSFS with admin privileges, are all your other programs also set to be ran with admin privileges? Is the log file attached from the first start, when it failed, or the second start? And how come FSUIPC didn't start the programs - did you disable this in the ini file? No, you shouldn't have to do that. And I don't see how FSUIPC can be doing anything as all it is doing is starting programs. Could it be that some of these programs are already running when you start FSUIPC7 and then two copies are running? You could change the Run commands to use RunIf, which will prevent the programs from starting if they are already running, Other than that, I cannot understand why the MCP would die. Do you still get the the com error in the ProSim log when this happens?
-
pmdg777 throttles wont goto idle FSUIPC
John Dowson replied to Saren1210's topic in FSUIPC Support Pete Dowson Modules
I don't understand why you are having difficulties. Assigning your Bravo X/Y axis with Send direct to FSUIPC Calibration and using the Throttle1/Throttle2 controls should work (and also calibrate on page 3 of the calibration tab - you probably need to reverse as well). If that doesn't work, please show me / attach your FSUIPC7.ini file. I have noticed that when the throttles are in the idle position, the engine hud shows around 23%, which I guess is idle. -
Yes, sorry - I should have spotted that!
-
Can you also please attach your UH1.ini profile file please? Are your axes calibration not profile specific (the profile-specific checkbox is not checked)? How do the in/out values move when you move the axis? Does this apply to all aircraft, just helicopters or just specific helicopters? You also have a lot of joystick/controller scans in your log file - do you know what is causing these?
-
Just assign to those presets via the UI key assignment panel. Check the Select for Preset checkbox and then the Find Preset.. button and navigate to the preset you need from the MobiFlight root. You can also search for available presets first using the MobiFlight HubHop site: https://hubhop.mobiflight.com/presets/
-
First check if the calculator code is being sent and applied in the FSUIPC WASM module (presumably you have that installed - if not, you need to install that). To do this, set Debug level logging (via the FSUIPC_WASM.ini file) and check the FSUIPC_WASM.log file to see if the command/code is logged. Probably. Hvars are only known (i,e, loaded and provided) by name if they are given in an aircraft-specific *.hvar file. However, they don't need to be known if using them via calculator code.
-
Licenses sent.
-
Are you using complex aircraft, many add-ons and/or add-on scenery? Could you also please attach your FSUIPC_WASM.log file if you get a WASM crash (preferably with Debug level logging enabled via the FSUIPC_WASM.ini file) An issue has been identified when scanning for lvars that can cause a crash, but this looks to be an issue in MSFS, not FSUIPC. There is a long discussion/investigation on this issue here: To reduce the chance of this crash, try setting the WASM ini parameter: LvarScanFrequency=0 and also maybe increase the LvarScanDelay parameter to 8 or 10 seconds: LvarScanDelay=8
-
Do you mean you updated the VC++ redistributables? Can you let me know your order number and I will check your details here. Do NOT post your key details!
-
Yes - see the ini parameter OpenOnStart:
-
Can you please explain what you mean - is your throttle recognized? Can you show me / attach your FSUIPC7.log, FSUIPC7.ini and FSUIPC7.JoyScan.csv files. John
-
👍😎
-
Also I see you are running FSUIPC with elevated privileges: Make sure you are also running MSFS and all other programs with elevated privileges, otherwise they won't connect. Always better to run with standard privileges unless you have a good reason not to. John
-
FSUIPC does not necessarily start MSFS. The desktop icon, installed by the FSUIPC installer, starts MSFS. In the default configuration, with auto-start using the EXE.xml, it is MSFS that starts FSUIPC7. As I said, for ALL issues with auto-start, please see that FAQ entry I referenced. This is located in your WASM persistence area, which is: I don't think it will show much but worth checking. Make sue toy attach it after you have shutdown MSFS. I don't understand this as FSUIPC is doing nothing with your MCP as far as I can tell. I can only think that it must be one of the programs that is started/stopped with FSUIPC: Maybe try removing them (temporarily - comment them out), and start each one manually to see if one of them is causing this issue.
-
Can you show me/attach your FSUIPC7.log file. I can take a look at that for errors, but otherwise you need MobiFlight support if the problem is with MobiFlight. Also check that you are running MobiFlight and FSUIPC at the same privilege level - they won't connect otherwise. John
-
There is no specific logging for profiles. I think the only thing that is logged is overridden buttons when a profile is loaded (when logging for buttons/keys is activated), e.g. The easiest way to see if a profile has been loaded is to open the axis assignment panel, or the button assignment panel and check the profile-specific checkbox. The profile name will be displayed in the panel title bar.
-
I so not support MobiFlight, only FSUIPC. Have you verified FSUIPC7 is actually running? Can you see it sitting in your system tray? Does the key combination Alt + F open the FSUIPC7 main window? If not, FSUIPC7 isn't running.
-
Fsuipc freeze with P3D
John Dowson replied to Edoradar's topic in FSUIPC Support Pete Dowson Modules
FYI, I have now released FSUIPC6 version 6.2.1. Please update to this version. John -
Help with Controls - testing with SET_EXTERNAL_POWER
John Dowson replied to DaveSCUSA's topic in FSUIPC7 MSFS
You can do it that way, but its generally easier to use the togglebits controls. No idea what the 'Alpha controls listing' is. For standard controls (i.e. FS controls + FSUIPC-added controls), see the documentation. All FS controls are listed in the Controls List for MSFS Build 999.txt file, and FSUIPC-added controls are documented in the Advanced User guide, starting on page 28. Yes, that would be nice, but I doubt very much that I would ever have time to implement such UI updates. I would love to completely re-write the UI to update it to a more modern toolkit, but again this isn't going to happen. I spend most of my time on support, and remaining time on keeping up with MSFS/P3D updates, adding new functionality and correcting bugs, as well as updating documentation, testing, preparing releases, etc. I have to prioritize and updates that are 'nice-to-have' but take several weeks or longer to implement are just not worth my time. Allowing for a second parameter to MSFS events is something I would like to implement, but this also is quite difficult as there is no way to know which events take two parameters and which take one. I would need to go through the documentation to discover this, and this would have to be done after each documentation update. And also note that the updated SDK allows for up to 5 parameters to event, not just 2 (although I do not know if any events that take more than 2 parameters at the moment). And as there is a workaround for this (i.e. by defining a preset), this is not currently that high on my list of things to implement. No. All offsets are initially initialized to 0 on FSUIPC start-up, but not when 'ready-to-fly'. So, once you have set a value in such an offset, it will remain there until you change it. If you want to initialze your user-defined offsets, then do this yourself. However, this is rarely needed if you are using them to hold lvar or input event values as these will be set when the lvar/input event is received. John -
Also, are you running the CPFlight MCP driver (and if not, why not?)? I believe this uses the FSUIPC WASM module. Check that this is still running (via the devmode debug console window), or show me the FSUIPC_WASM.log file, but attach only AFTER exiting MSFS. There is an issue where the WASM sometimes can crash - if this is the case, there are some config. parameters you can set that will make this crash less likely. But best to confirm if this is an issue or not first. John
-
For all auto-start issues, see The log file you attached shows no issues, but also shows that you either attached it when FSUIPC7 was still running, or FSUIPC7 had crashed. Please always exit FSUIPC7 before attaching files. Does not connect to what? If the MCP doesn't connect to Prosim, this is nothing to do with FSUIPC. There are no com ports configured in your FSUIPC7.ini file. Can you switch back to the previous version and see if it works with that please. If not, it is not an FSUIPC issue. The previous version, if you don't have it, is available here. John P.S. If access is denied on a port, then it could be a permissions issue or something else could be using / blocking the port. Make sure toy are running everything at the same privilege level, and reboot your PC.
-
Help with Controls - testing with SET_EXTERNAL_POWER
John Dowson replied to DaveSCUSA's topic in FSUIPC7 MSFS
The parameter is the bit (in the byte) to toggle. x1 is but 0 (2^0). If it was bit 1 you wanted to toggle, you would use x2 (2^1=2), bit 2 would be x4, etc. And you toggle multiple bits by summing. So x3 would toggle bits 0 and 1. Basically its the mask of bits to toggle. A byte cannot hold a decimal value - you would need 4-bytes for that (a float). FSUIPC does the conversion of the original decimal value of the Input Event using the modifier you specify in the line where you add the input event to an offset. No, you didn't try this - that was SET EXTERNAL POWER, which requires two parameters. The toggle control only needs one. You add it to an offset and toggle that offset, as Al showed in the previous post. As its a toggle control, you don't need to gave a condition on this. If you did, you would just add an offset condition as explained in the Advanced User guide. John