John Dowson

FSUIPC will do nothing with such sections (i.e. they will be ignored). FSUIPC only uses certain section names - others will be ignored. However, there position in the ini file may change when other sections are re-written, but I am not sure about this - just try it. John

Isn't this the same behavior you see when you push the button in the VC?

This is because you are using offset 0x2FA8, which is HSI BEARING, which, as pointed out earlier, holds: You should try with offset 0x0580 (PLANE HEADING DEGREES TRUE) or 0x2B00 (PLANE HEADING DEGREES GYRO). If you want to use PLANE HEADING DEGREES MAGNETIC, you would need to add this to an offset. Note also that for some offsets, you will need to convert the offset value to degrees before applying (e.g. for 0x0580 you have to *360/(65536*65536) to convert to degrees). Or just use a preset or calc code - easier!

Before I check this (and I am pretty sure that the details are correct - EVERY key I have checked so far has been correct), PLEASE make sure you have read the Invalid Key Section of the README.txt and/or in the installation and registration manual. All support requests on invalid keys are always due to one of three issues: - not entering the details correctly - not updating your VC++ redistributables - interference from anti-virus software

First, you are using 7.4.15 - please update to the latest and only supported version, 7.4.16. Your ini file is also a bit of a mess as it looks like the GUIDs of some of your devices have changed, and rather than correcting this you have re-assigned to the new joyletter. I have tried to correct for this in the attached ini file, so can you please try this. But as I said, isn't it 1 to activate and 0 to release? Anyway, your assignments were confused as you had assignments to PARKING_BRAKES with a parameter, and this is a toggle control that doesn't take a parameter, and also assignments to PARKING_BRAKE_SET, which does take a parameter. Anyway, try the attached ini and if you have issues with this, please activate logging for Buttons & Switches as well as Events, and show me/attach your FSUIPC7.log and FSUIPC7.ini files. Normally you would use TOGGLE_FUEL_VALVE_ENG1/2, which you have assigned to buttons 17 & 16 of your JoyWarrior A8-16 controller. Do these not work? As I don't have the ProSim 737, I cannot advise on what to use. Try using FSUIPC's logging facilities and see what control is logged when you cut-off in the VC, and then try assigning to that. Any issues with this updated ini, please re-attach it together with your FSUIPC7.log and FSUIPC7.JoyScan.csv files and explain the issue. FSUIPC7.ini John P.S. I thought with the latest versions of the ProSim 737, it is recommended to use ProSim itself for (most, if not all) assignments ...is this not the case?

You cannot add 'comment sections', and I am not sure about comments outside sections - check the documentation (via google) for comments in windows ini files. Trailing comments are allowed in most FSUIPC7 ini file sections but not all, and not on the section label itself. For example, this is from the Advanced User guide on comments in the [Buttons] and [Buttons.xxx] sections: Also, as I said, the FSUIPC7.ini file is a standard windows ini file and the standard rules on comments apply except where documented (e.g. we allow trailing comments on most but not all entries). John

Pete retired many years ago now... What do you mean by 'but using it reverses the settings.'. Normally you would activate with a parameter of 1, and release with a parameter of 0. Have you tried that? What are you using/assigning to for this? Please attach your FSUIPC7.ini and FSUIPC7.log files. I don't have the ProSim 737, but I can take a look to see if I can see anything. What do you mean by this? If MSFS is not installed on the 2nd PC, then you cannot install FSUIPC7 via the installer. If using FSUIPC7 on a client PC (i.e. without MSFS installed), please see Appendix 4 of the Advanced User guide - this gives instructions on how to install and configure FSUIPC7 on a client PC.

Could you please attach files rather than pasting their contents. Also, please make sure that you exit FSUIPC7 before doing this. Also please provide an explanation to accompany the files. Were the presets not working at all? The log shows that your 777-800 profile was loaded and the preset calc code was sent to the WASM. If they were not working, I also need to see your FSUIPC_WASM.log file, with Debug level logging activated in the WAPI. Please see the WASM section in the Advanced User guide on where this file is located and how to set the log level in the WASM. Please also activate Debug level logging in the WAPI (Log->WAPI->Debug). Your files do show some issues: 1. There are some reconnection attempts at start-up as your DetectToConnectDelayAuto ini parameter is set too low. This would correct itself automatically if you went back to the main menu before exiting, as these would be detected and then the auto-tuning would kick-in on the next restart. However, you can do this manually by setting DetectToConnectDelayAuto=110 in the [General] section of your FSUIPC7.ini. 2. You have many full aircraft titles in your [Profile.xxx] sections. You should switch to using substrings so that the substring matches all liveries. So for example, for the [Profile.B737] section, just use: [Profile.B737] 1=PMDG 737 and for the [Profile.A320 Fenix] section: [Profile.A320 Fenix] 1=FenixA320 2=Fenix A320 3=Vueling 4=Fenix Airbus A320 5=Airbus A320neo v2 6=fnx-aircraft 7=Air Canada CFM [Not sure about entries 3 and 7...] Do this for all your profile aircraft., i.e. use substrings that catch the aircraft you want to use with the profile rather than the full aircraft name. You should get into the habit of editing the aircraft name to be a substring whenever you add one to a profile.

There has been no change in 7.4.16 that could effect preset operation. You can start FSUIPC7 manually or have it auto-started with MSFS, which is the recommended way. FSUIPC7 should function the same regardless of how or when it is started. This warning can be safely ignored. There are a couple of things that could cause this behavior. Please show me / attach your FSUIPC7.log and FSUIPC7.ini files, generated when you experience this issue. i.e. when you get this issue, exit FSUIPC7 and attach those files (from your FSUIPC7 installation folder) here. John

Why not use the included preset XCub Ap Alt Push which uses INDICATED ALTITUDE instead of PLANE ALTITUDE?

There are various options, both free and payware. There is SpaceDesk, which allows you to move pop-out instruments to virtual screens, including tablets (I believe - haven't used it). I think the most popular payware solution is Air Manager, but there are various other programs available. This allows you to design your own panels for a tablet (iPad or Android), and both free and payware panels are available so you don't have to build your own. Probably worth googling for a comparison of different products. I don't think so but am not sure - I will take a look later. This is standard MSFS functionality and not restricted to the Fenix.

I have just checked and also have the DA62X mod installed, although I haven't used it for a while.

That would be a stupid assumption to make... I expect my customers to AT LEAST consult the documentation before posting. And for the majority of issues, there are only two documents you need to be familiar with - the User guide and the Advanced User guide. I am spending hours repeating things endlessly that are already documented, not only in the documents but in many support requests. As an example, if I ask for the FSUIPC_WASM.log, id you open the Advanced User guide, search doe FSYUPC_WASM.log, you will see the documentation oin where this is located. Quick and easy. It took several message exchanges and many hours for you to find this. And please can you refrain from such message and this ongoing criticism of my support (or perceived tone). The more you continue to do this, the less inclined I am to help you.

And this not being an FSUIPC issue, I have given you all the help I can. I can guarantee you that this is not the case, MSFS is crashing BEFORE FSUIPC7 is even connected. The WASM may have started or not, but if it has it isn't doing much yet as MSFS is crashing on start-up. Well, none I hope, There are FAR more who don't know or use the documentation... Not sure why that would be...have you tried the support of the DA62 Mod? I no longer remember this item. Wasn't that long ago - this one: Ok, but why was that so difficult? You complain about the documentation but never seem to consult it. I posted the relevant section and you still couldn't find it... Of the 3 logs you posted, both of the _prev logs show that the WASM ran as expected and was closed/stopped cleanly by MSFS, i.e. no crash. For the FSUIPC_WASM.log, that shows the WASM was initialised and is waiting for an aircraft to be loaded, and MSFS was still running or MSFS has crashed. I am sorry but I have no idea what is causing your crash, but it is not FSUIPC. I don't know what could be causing this CTD. I can try that mod here but I doubt very much I will get a CTD - there are several people using this mod with FSUIPC that I have already helped. See https://forums.flightsimulator.com/t/da62x-improvement-mod-v1-0-oct-4/294584/2650 Make sure that you are using the latest version of the mod - maybe download it again and re-install it (and make sure you delete the current mod from your Community folder first).

And is it 0 when off? If so, I would expect thar the lvar range is 0 - 100. First assign your axis to an offset by checking the Send to FSUIPC Offset in the axis assignment panel. As this will be holding an axis range (-16384 to +16383), you can assign to Offset Word Set and you can use offset 6420 (first offset of PMDG data area). Then create a lua script, lets call it Milviz-UH1-grip.lua, and add the following: local offset=0x6420 function GripAxis(offset, value) -- ipc.log("Offset value: " .. value) -- value will be in range -16384 to +16383 - convert this to range 0-100 valueCalibrated = (value + 16384) / 327.67 -- set lvar ipc.writeLvar("L:collective_grip", valueCalibrated) end event.offset(offset, "SW","GripAxis") ipc.log("MILVIZ UH1 Collective Grip Lua started!") You then need to have this lua script auto-started, so add the following to your MILVIZ UH1.ini file: [Auto] 1=Lua Milviz-UH1-grip Try that. If you have issues, try uncommenting that initial ipc.log statement, and set logging for Lua Plugins to see what the issue is. You can also post your log file here and I can take a look.

The images you attach show the LocalCache folder. Try the LocalState folder. If there is no fsuipc-lvar-module folder under your Packages folder, then it is either because the WASM module is never started (or never ran long enough to generate/create a log file). Alternatively, there is something seriously wrong with your MSFS installation. If FSUIPC7 or the FSUIPC WASM was causing MSFS to crash on start-up, don't you think I would have noticed that here? I would also expect thousands of complaints, yet it is only you... Does it crash if the FSUIPC WASM is the ONLY item in your Community folder, and not without it installed? Try downloading and installing again. You recently reported a similar strange issue with FSUIPC7 crashing on start-up - you said you resolved that issue but you never said what the issue was. Maybe whatever this issue was is causing this? But I repeat, for the last time, this is not an issue in FSUIPC7 or with the FSUIPC7 WASM. The issue lies somewhere else, and I cannot help you any further with this. I really don't understand why you are always having so many issues...

Yes, looks ok to me. Yes. Its a substring match, so the aircraft Title must contain that string to match. If there is a livery that doesn't contain this., it will not match and therefore the profile will not load. Uoi would have to add any such aircraft to the profile. Alternatively, you can switch to using the folder name to match profiles, by setting the UseAirLocForProfiles ini parameter - see the Advanced User guide for details. Note however that if you change to this method you wil have to redo all your current profile sections (i.e. remove the current aircraft names from the profile sections and re-attach each aircraft to its profile. Ok. As it seems like a timing issue, you could try increasing the DetectToConnectDelayAuto ini parameter. Try increasing by 5 (seconds) or so, and keep increasing to see if this stops happening. Other than that, I don't know why this seems to affects some people and not others. I could possibly look to see if I can test for this (e.g. send a test key combination to MSFS and see if it is returned) and reconnect (or re-request) id this fails, but I would rather determine the root cause.

Please see the WASM section in the Advanced User manual: There is, if you look in the correct location... If you look at the log file you attached, you will see that FSUIPC7 had noy yet even tried to connect to MSFS before it had crashed: So FSUIPC7 has nothing to do with this crash. MSFS crashed soon (8 seconds or so) after it started FSUIPC7. You can attach the FSUIPC_WASM.log when you find it, but it will not show anything as your crash has nothing to do with FSUIPC7 or the FSUIPC WASM module. The WASM module doesn't do much at all (except initialise itself) until an aircraft is loaded and ready-to-fly, and your crash is (mostly) happening before then. If using DX12, try disabling that - this is known to cause CTDs for a lot of people. Also try disabling some on-line functionality, such as live-traffic and live weather to see if that helps. If you remove everything from your Community folder, does MSFS still crash (on occasion) or not? If you install just FSUIPC7 (and nothing else), does it then crash? I, as well as most other MSFS users I guess, also sometimes experience CTDs or, more usually, MSFS hanging on start-up. Usually these issues just go away on their own accord without me doing anything, although I have had to re-install on occasion. Other than that, I cannot help with MSFS CTDs. You can check the windows Event viewer for a crash report - this should give further information on where/why MSFS crashed, and you can include this information if you want to report to Asobo.

That's interesting - I wonder how toy do this in the virtual cockpit with the mouse...

There is an FSUIPC-added control you can use: List Local Panel Vars. Assign a spare button or key press to that. Alternatively, there is a lua plugin provided - log lvars.lua, in the Example LUA plugins package in your FSUIPC6 documents folder.

There is nothing preventing the use in the of FSUIPC as you say you cannot even assign this in P3D. If there is no P3D axis that controls this, then you cannot assign to this. You should ask the helicopter developers how to control this twist operation. You could maybe try listing the lvars to see if any of them look applicable. If there is an lvar for this, you would need to assign your axis to write its value to a free/spare FSUIPC offset, then have a lua script that monitors the offset, calibrates the axis value and then use this to set the lvar. Yes, - let me know if you get a response. John

So, the throttle axis works to control the collective. So why can't you assign the slider to the throttle axis? So, assigning your slider to the throttle axis results in PROP_PITCH_SET controls being logged with a parameter of 0? When you say 'mapping the joystick axis to throttle worked', did this result in PROP_PITCH_SET being logged with a parameter? Can you please show me your MILVIZ UH-1.ini file, both with assignments when the collective assignment is mapped to a joystick axis and it works, and another when it is mapped to the slider and it doesn't work. If an assignment to a control works on one axis, it should work on another. Do you see the in/out values change in the assignment panel when mapped to the slider? Do you mean the twist axis in the VC? An axis is just an axis, it shouldn't matter if this is a twist axis, a slider or a joystick/yoke. You do have controllers set to ON in P3D: So please check that your axes are not also assigned in P3D. Bet to disable controllers in P3D if assigning in FSUIPC. I see there are also a lot of aileron, elevator and rudder controls logged, all with a 0 parameter. What is generating these?

And when you restart MSFS, is FSUIPC7 again auto-started? And when this happens, if you restart FSUIPC7 the keys then work? The log shows no key presses were received by FSUIPC7. The next time this happens, can you try disconnecting FSUIPC7 from MSFS and reconnecting, via FSUIPC's MSFS menu. This seems to be an issue that occurs occasionally - FSUIPC7 requests all key presses when it connects, but sometimes no keys are sent, and no error is received. I am not sure why this is, or what I can do about it. And I cannot reproduce this behavior here. In your log, I see you are auto-running lua script PMCO_FNX32X.lua which is exiting if the Fenix A320 isn't loaded. Rather than doing this, you should only start the script in an auto profile section for the Fenix A320.

I have moved your post to the FSUIPC7 sub-forum. No - you can mix and match assignments between FSUIPC and MSFS. Just make sure that if assigned in MSFS, then it is not assigned in FSUIPC7. To do this, best to create a profile with both an empty axis section and an empty calibration section, although you can calibrate some axes in FSUIPC7 when assigned in MSFS if you so wish, but you should always first try without calibration. The API provided by MSFS (and FSX, P3D) only allows / provides controls for up to 4 separate throttles, and a generic throttle control that should apply to all engines. So you can try assigning to the generic throttle control. The aircraft itself may provided additional throttle controls for each engine, either via Input Events or lvars. If so, you can use those of you want to assign to 6 levers, using 2 throttles per lever. Can you control all 12 engines separately in the VC? If so, try using FSUIPC's logging facilities to see what is being used when you move each separate throttle in the VC. Try logging for Axis Controls first, then Input Events. If nothing is logged with either of those, try checking for lvars. I guess it may also/instead map the 12 engines to the 4 existing throttle controls. If so, you can map 4 of the levers to the 4 separate engine controls.

I have taken a look at this and it works just fine here. However, please note that when the lvar value changes, PMDG offset 0x64FB is also updated and vica-versa. So you don't need an event on both the offset and the lvar - an event on the offset should be sufficient. I do not know why it has stopped working for you, or why FSUIPC hangs when you restart the script - I can restart just fine here. So something else must be going on. Can you please show me your FSUIPC7.log file from when you have to kill FSUIPC7. If/when you restart FSUIPC7 after killing it, does it run ok and are all lvars loaded?