John Dowson

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?

But why attach the WASM - I distribute that. i need the FSUIPC_WASM.log file, not the files that are installed by the FSUIPC7 installer. A WASM module should not crash MSFS - the WASM will just crash and MSFS will continue. Please see the Asobo forums for all MSFS CTDs. This will most probably be something specific to your new PC. I cannot help with this.

You are not doing anything wrong - just use what works. I don't know why its logging something different from the VC.

Nearly all CTDs in FSX with FSUIPC4 are due to a corrupt weather file. Please see John

Thanks for the update.

There is already a preset for the alt sync, XCub Ap Alt Push, whose preset code does some thing similar to that proposed for the heading: (A:INDICATED ALTITUDE, feet) (>K:AP_ALT_VAR_SET_ENGLISH)

Can you please activate logging for Buttons & Keys and show me / attach a FSUIPC7.log file from when the keys don't work and I will take a look. John

Sorry but I didn't have time to look into this today. I am now on holiday, back in Tuesday 6th (in 4-5 days), and will take a look then. Sorry for any inconvenience, John

Thanks @ark1320 - should have checked the MSFS documentation on this. Hopefully @Guido can try your preset using PLANE HEADING DEGREES MAGNETIC simvar. Any further issues, I will take a look next week (back on support on the 6th). John

I tried that preset in the PMDG 737 and it is working as expected here. Have you used any presets before, and if so were they working? Do you have the WASM installed and enabled? Could you please attach your FSUIPC7.log and FSUIPC7.ini files and I will take a look. Note that i am on holiday from this evening, back on support on Tuesday 6th. So unfortunately I will not be able to look into this further until later next week. Also ,ale sure that you are using the latest version of FSUIPC7, version 7.4.16. If you install that and accept the defaults, the WASM should be installed and enabled, but if not enabled you can enable from Add-ons->WASM->Enable. Try that and any issues attach those files and I will take a look next week. John

Probably a better solution rather than using the HSI BEARING simvar unless this is correct. If so, you could use the following preset: SYNC_HDG_BUG_TO_HSI_HDG#(A:HSI BEARING, degrees) (>K:HEADING_BUG_SET) Suggest @Guido tries both - add them to your myevents.txt file (create this if not present) and try them both. I will take a look later if I have time, but am rather busy and am on holiday from tomorrow until the 5th (inclusive), so it may be next week. John

Still a lot of reconnection attempts though. Looks like it takes a long time for your MSFS to start-up and get to the main menu... Try increasing the parameter, i.e. DetectToConnectDelayAuto=400 And when you get to the main menu in msfs, take a look at FSUIPC7 and wait until it connects before you do anything. This will then tune that parameter for the correct value for your system. John

Don't worry about it - its not an issue. I have checked further and it is an issue with this preset defined in MobiFlight. It will be ignored. John