John Dowson

They don't seem to be working, and neither the Moboflight events for those lvars. They are documented as being 'not tested'. Maybe ask on the FBW forums if there is a way to control the batteries. It was reported in the other post you raised that it there are some simvars that may allow you to read the battery state, although these are currently not accessible using FSUIPC7. If those simvars (or a variables) are writable, I could add them to offsets. But best to check with FBW how they should be controlled first.

Please DO NOT DO this. The resulting log file will be huge and useless. Turn all logging options off, unless I ask you to activate them. Please DO NOT post any video clips. They are useless to me. As I keep telling you, I need to see yout FSUIPC7.log and FSUIPC7.ini files at the time of the crash. Nothing else at the moment. I am just trying to determine if it is indeed FSUIPC7 that is crashing. Once I have this basic information, we can go from there. Just follow my instructions for now please.

Yes, sorry. I thought you wanted your buttons.profile section to replace your buttons. Button and key assignments are cumulative, so it takes the general section first, then augments (i.e. replaces or adds) with your profile assignments. So, the correct way would have been to add any of your button/key profile assignments to the general button and key assignments section. also changing the index numbers to make sure they are unique. And the calibration section depends on how you calibrated your axis, whether in a profile or not. Anyway, just FYI. Glad you sorted it out.

If it is FSUIPC7 that is crashing, I will look into it. However, I suspect not. If FSUPC7 is the culprit, there will be a crash event in the logs (NOT a fault event), and there shouldn't be any other events from MSFS or SLC, and the FSUIPC7.log file will show that it did not exit properly. I need to see this log file to see if it did crash and if so what it was doing at the time (may need extra logging added). Onve it is confirmed that it is FSUIPC7 that is crashing, we can proceed from there. However, it has been reported many times that FSUIPC7 is causing MSFS to CTD, and in each case I have so far investigated the problem has been else where.

If you run FSUIPC7 before you start MSFS, you can disable that option. MSFS will also try to start FSUIPC7 (if configured to do so), but that attempt will fail and you may get an error, but you can just ignore that. Let me know how it goes once you have updated/re-installed.

You are using a very old version of FSUIPC7. Please update to either the latest supported version, v7.1.0, or the current beta, 7.2.0. Also, the defaults in the [General] section of your ini are quite old and should be updated. The best way to do this is to remove everything under the [General] section of your FSUIPC7.ini and let that get rebuilt.

Ah, I forgot one thing about the 'Exit with FS' option. If/when FSUIPC7 is automatically started by MSFS, then the 'Exit with FS' option is automatically checked (and the 'Exit with FS' menu option removed). This is necessary as otherwise MSFS will not close down correctly with FSUIPC7 still running.

For your settings, I look at your FSUIPC7.ini file. The one you attached does show 'Exit with FS' is not selected, but that doesn't match with the log file you attached. Are you sure that you didn't set this option after that log file was generated? I guess there could be something wrong in the unregistered version but that would surprise me - I will check.

Sorry, but this doesn't make sense. As I have said, FSUIPC DOES NOT LAUNCH MSFS. How are you launching FSUIPC7? To start FSUIPC7, you just double-click the FSUIPC7.exe. If you are using the MSFS icon that the FSUIPC7 installer creates on your desktop, this displays a splash screen and starts MSFS. It does not start FSUIPC7. FSUIPC7 is started by MSFS, via the EXE.xml file. The log file attached shows FSUIPC7 exiting normally as MSFS was no longer available: Which also shows that you have the 'Exit with FS' option selected. If you still think this is an issue with FSUIPC7, please show me the log file from when FSUIPC7 crashes.

You could try the following lvars with parameters 0 for off and 1 for on: XMLVAR_Momentary_PUSH_OVHD_ELEC_BAT1_Pressed XMLVAR_Momentary_PUSH_OVHD_ELEC_BAT2_Pressed

But it is MSFS that launches FSUIPC7, not the other way around. Unless you are using a very old version, in which case you should update. The MSFS icon that the FSUIPC7 installer creates in your desktop just displays a splash screen while MSFS is starting. MSFS then starts FSUIP7 via the EXE.xml file.

I cannot access that link - it says 'You Need Access', with a button to request access. However, any information you have there you should be able to attach here. If its large, just zip it up. And please show me your FSUIPC7.log and FSUIPC7.ini files.

That is using a MobiFlight event. But here you are trying to write a Hvar as an lvar... Yes, you need to use ipc.activateHvar for hvars. Not that hvars to not have an associated value - you just trigger or activate them.

Sorry, but where is your name displayed exactly? It should only be visible from your registration details, i.e. in the Help -> Registration Details... window, and also logged in your FSUIPC log file when your registration details are verified.

Can you please show me your FSUIPC7.log file. I suspect that it is MSFS that is crashing. which causes a 'fault' in FSUIPC (not a crash). However, FSUIPC7 will exit when MSFS crashes as you have the option 'Exit with FS' set. Your log file will probably show FSUIPC7 closing normally.

Please show me your FSUIPC7.log and FSUIPC7.ini files.

I cannot access that link. Please describe your issue. But please, if this is the same issue you thought you had before (i.e. FSUIPC crashing MSFS), then please check your FSUIPC7.log and make sue that it is not MSFS crashing and FSUIPC7 exiting normally. When MSFS crashes, this will generate faults in FSUIPC7 reported in the event viewer, but this is due to MSFS crashing, not FSUIPC7. and to verify this, turn of the option 'Exit with FS'. With that turned iff, FSUIPC7 will keep running when MSFS crashes.

I never understood the original problem, and it seems it was not related to using FSUIPC. You can zip log files before attaching - they are text files and so zip up pretty small. Anyway, the log file doesn't tell me anything. How are you trying to start your aircraft? Of using FSUIPC, then I need to see your assignments, i.e. your FSUIPC7.ini file. And what happens if FUIPC7 isn't running? Can you start your aircraft then? As with the OP's problem, I don't think this is related to FSUIPC7.

Sure. Open your FSUIPC ini file in an editor and completely remove the following sections: [JoystickCalibration] [Axes] [Buttons] [Keys] [Auto] Then, take the profile name out of the specific profile that you want to make global for those sections, e,g, change [Axes.<yourProfileName>] --> [Axes] etc. You can then remove the [Profile.<profileName>] sections, and any other profiles you don't need. Probably a good idea to make a back-up first, just in case,

You can do this as you would for any multiple assignment to a button. First assign your button for the first control and click 'Ok' to save this assignment. Then open your FSUIPC7.ini file in an editor and located the line for that assignment just added - it will be the last entry in either your [Buttons] section or [Buttons.<profileName>] section, depending upon whether or not you are using profiles. Now comment that line out by inserting a semi-colon ';' character after the index number of the entry and save that change. You can then open the Button & Switches assignment panel again and click 'Reload all buttons'. You can then assign your second action to that button. Repeat if you want to add further actions. Once all have been added, you can remove the semi-colons previously added to uncomment those entries, save the file and agaiin 'Reload all buttons'. You will then have multiple actions assigned to that button - the Button assignment panel will only show one entry and it will be grayed-out, indicating it cannot be changed via the UI (you have to edit the ini to adjust/remove when you have multiple assignments to a single button or key.

I'm sorry, but as Pete indicates, we can't support software that is using FSUIPC - you need to contact the software developer. If the developer of the package you are using is no longer supporting the software, then maybe you should switch to something else. The most advanced and often used API is the c# one provide by Paul Henty, but there are many others - check out the available SDKs that are provided, which will be under the SDK folder in your FSUIPC installation folder (if you opted to install). However, please note that we only support the interfaces that WE provide, we cannot support 3rd party add-ons or APIs, but we can point you in the right direction if using those... Many of the interfaces provided are still supported by the developers of those interfaces. John

Please realize that this is invalid. The first number is the index number, which must be unique. And why are you adding the same lvar to different offsets. I think you are misunderstanding how lvars to offsets work.... Try with this: i.e. each lvar in its own offset. Then assign your buttons to those offsets as previously described.

you could try that attached in where I've done those updates for you: FSUIPC6.ini

Hi Jim, before anything else, could you please update to the latest version, v6.1.1. Only the latest version is supported. Not sure why you have started again - you have lost so much of your assignments, If I were you, I would go back to your initial profile and we can sort out the problems there. Copy all the [Profile.PMDG 777 United] sections from your new ini to your old ini. Also, delete all parameters from under the [General] section. This will be rebuilt when you next run FSUIPC. Note also, that you should use the substring function for your profiles to catch all variants, so this, for example: Can be changed to this: The profile would then be used for all aircraft which contained the substring "PMDG 737", and so catch all variants. You can do something similar with all your Profile sections that link the profile to the aircraft. Once all that is done, test again, and report back if you still have issues.

There are 3 ways to do this: 1. create a macro file to to either set or toggle the lvar, and assign a button or switch to this lvar macro. Ecactly how you do this depends on how your buttin/switch works. 2. write a short lua script to activate the lvar, and assign your button to the lua script. Or you could use event.button in your lua script, and skip the assignment completely. 3. Add the lvar ro an offset, and then assign your button/switch to toggle or set the lvar via the offset 3 may be the easiest. However, adding lvars to offsets is only available in the latest 7.2.0 beta, so please download and install this, from Then, you need to create add an [LvarOffsets] section, or an [LvarOffsets.<profileName>] section, specifying the lvar you want to use, together with the offset to hold the value together with the size of the offset, e.g as the following (although better to use a profile]: [LvarOffsets] 1=L:ASCRJ_OVHD_LDG_NOSE=UB0xA000 This will add the lvar ASCRJ_OVHD_LDG_NOSE to offset A000 as an unsigned byte, for both reading and writing, i.e. you can read that offset to read the lvar value, and setting that offset will update the lvar value. Then, to assign to a button or switch, go into the FSUIPC7 Buttons & Switched assignments panel, press/switch your button, and then assign to the control Offset Byte Togglebits, giving A000 as the offset, and x1. as the parameter. That button will then toggle the lvar value. Depending on if using a button or switch, you could assign to Offset Byte Set with a parameter of 1 for press and 0 for release (for example, if using a switch, maybe also with an offset condition to keep the switch in-sync.). The actual way you assign depends on what you are assigning to and how the button/switch works.