ThomasAH

I'd recommend using VRiSim and the modules corresponding to your hardware from http://www.vrinsight.com/devel_shot/index.html

I have pressing H on my checklist, too ... together with things like which program to start first or which USB cable goes where :)

While this is mostly true, this type of icing happens more easily on fuel injected engines in FSX than other sources suggest, e.g. https://www.pprune.org/archive/index.php/t-334977.html (this mentions icing in air intakes, too, so this matches what N4GIX wrote in the linked P3D ticket) I have seen this problem (bug or not) very often in FSX, and with both engines of e.g. a Carenado 337H always losing power at exactly the same time.

It is not specific to P3D, but already present in FSX, too. Some links: https://www.avsim.com/forums/topic/375838-the-carb-heat-bug-for-fuel-injected-engine-fixed-by-payware-aircrafts/ http://www.prepar3d.com/forum/viewtopic.php?t=12379 https://www.avsim.com/forums/topic/364421-icing-or-why-engine-slow-down/#comment-2282713 https://www.avsim.com/forums/topic/408841-question-to-the-carenado-c337-owners/#comment-2676149 and various others. I must admit that it took me some years to find out about this bug, too :)

You did not find it (http://library.flight1.net/?p=3681) or it does not do what you want (I haven't verified)?

Search for "iFlyToFsuipc"

You won't see the axis because you have no trim wheel, at least your log only shows joystick and rudder. You can still use the buttons part of my script above though and ignore everything related to the trim axis. Here you have to set the joystick letter and button numbers in the script.

I adjusted Pete's script to solve all three of your issues: The script writes directly to offset 0x0BC0 For larger movements of the wheel the script makes larger changes the offset. If the wheel is near the end of its range (upper or lower 1/16th) a warning popup will appear and suggest disconnecting and reconnecting the wheel (I have connected it to the USB hub of my Saitek yoke, so this is easily reachable) Additionally I have configured the trim wheel to set AP vertical speed or pitch or attitude hold if the AP is enabled instead of acting as a trim wheel. And for the times I use only a joystick instead of the full setup, I have assigned two joystick buttons to act as trim, with increasing speed if the buttons are hold for a longer time. Maybe you can adjust it for your own needs: -- Using a trim wheel axis to operate with trim INC and DEC instead -- http://forum.simflight.com/topic/72492-using-a-trim-wheel-axis-to-operate-with-trim-inc-and-dec-instead/ -- -- [Auto] -- 1=Lua trimwheel -- assign your axis, in the normal FS controls assignment on the left, to "Luavalue trimwheel". boundary = 16384-2048 joystick = "J" -- Saitek Aviator Stick button_dn = 4 -- T1 button_up = 5 -- T2 function trimbutton(joynum, button, downup) factor = 20 direction = (button == button_up) and -1 or 1 trimwheel(factor*direction) ipc.sleep(100) while ipc.testbutton(joynum, button) do if factor < 200 then factor = factor+2 end trimwheel(factor*direction) ipc.sleep(30) end trimwheel(0) end function trimwheel_trim(change) trim = ipc.readSW(0x0BC0) - change if trim < -16384 then trim = -16384 elseif trim > 16383 then trim = 16383 end ipc.writeSW(0x0BC0, trim) end function trimwheel_ap_vs(change) if ipc.readUW(0x07BC) == 0 then -- AP disabled trimwheel_trim(change) elseif change > 0 then ipc.control(65895) -- AP_VS_VAR_DEC elseif change < 0 then ipc.control(65894) -- AP_VS_VAR_INC end end function trimwheel_ap_pitch(change) if ipc.readUW(0x07BC) == 0 then -- AP disabled trimwheel_trim(change) elseif change > 0 then ipc.control(66584) -- AP_PITCH_REF_INC_DN elseif change < 0 then ipc.control(66583) -- AP_PITCH_REF_INC_UP end end function trimwheel_ap_pitch_atthold(change) if ipc.readUW(0x07BC) == 0 then -- AP disabled trimwheel_trim(change) elseif change > 0 then if ipc.readUW(0x07D0) > 0 then -- AP alt lock ipc.control(65804, 1) -- AP_ATT_HOLD_ON end ipc.control(66584) -- AP_PITCH_REF_INC_DN elseif change < 0 then if ipc.readUW(0x07D0) > 0 then -- AP alt lock ipc.control(65804, 1) -- AP_ATT_HOLD_ON end ipc.control(66583) -- AP_PITCH_REF_INC_UP end end function trimwheel_ap_pitch_althold(change) if ipc.readUW(0x07BC) == 0 then -- AP disabled trimwheel_trim(change) elseif change > 0 then if ipc.readUW(0x07D0) > 0 then -- AP alt lock ipc.control(65816, 1) -- AP_ALT_HOLD_OFF end ipc.control(66584) -- AP_PITCH_REF_INC_DN elseif change < 0 then if ipc.readUW(0x07D0) > 0 then -- AP alt lock ipc.control(65816, 1) -- AP_ALT_HOLD_OFF end ipc.control(66583) -- AP_PITCH_REF_INC_UP end end function trimwheel_c182(change) if ipc.readUW(0x07BC) == 0 then -- AP disabled trimwheel_trim(change) elseif change > 0 then ipc.writeLvar("kap140_dn_button", 1) elseif change < 0 then ipc.writeLvar("kap140_up_button", 1) else ipc.writeLvar("kap140_dn_button", 0) ipc.writeLvar("kap140_up_button", 0) end end function aircraftchange(eventtype) if ipc.readSTR(0x3D00, 14) == "C337 Skymaster" then trimwheel = trimwheel_ap_pitch_atthold elseif ipc.readSTR(0x3D00, 5) == "C182_" then trimwheel = trimwheel_c182 elseif ipc.readSTR(0x3D00, 10) == "Cessna 441" then trimwheel = trimwheel_ap_vs elseif ipc.readSTR(0x3D00, 20) == "Boeing Stratocruiser" then trimwheel = trimwheel_ap_pitch_althold else trimwheel = trimwheel_trim end end aircraftchange(nil) -- initialize at least once function checkvalue(val) if prev ~= nil and val ~= prev then -- axis moved if math.abs(val) > boundary then ipc.display(string.format( "Warning:\n\n" .. "Trim wheel value near boundary: %d\n" .. "Reconnect to restore full range.\n", val), 10) else ipc.display("") end trimwheel(val - prev) end prev = val end event.sim(AIRCRAFTCHANGE, "aircraftchange") event.param("checkvalue") event.button(joystick, button_dn, "trimbutton") event.button(joystick, button_up, "trimbutton")

I use ext.runif() in FSX/Modules/ipcInit.lua for exactly this feature: quickstart = false ext.runif('C:\\Program Files (x86)\\EZCA2\\ezlauncher.exe') if not quickstart then ext.runif('D:\\FSX\\fsrealtime\\FSRealTime.exe', EXT_CLOSE) ext.runif('D:\\FSX\\WhereAreMyAircraft\\WhereAreMyAircraft.exe', EXT_KILL) ext.runif('D:\\FSX\\AivlaSoft-EFB\\AivlaSoft.Efb.DataProvider.exe') ext.runif('D:\\FSX\\AS16_FSX\\AS16.exe', EXT_CLOSE) if ipc.buttons("Y") >= 256 then ext.runif('D:\\FSX\\SPAD\\Spad.exe') ext.runif('D:\\FSX\\VRInsight\\bin\\VRiSim.exe') end end If I want FSX to start quicky (with most runifs disabled), I just set "quickstart = true". The ipc.buttons() check is done to see if my yoke is connected. You could invent more conditions, e.g. if a certain file exists, and write a simple batch file to create or remove this file, and then start your simulator.

L-M is Lockheed Martin, the developer/published of P3D. PeD is just a typo, Pete meant P3D.

Requiring a separate key purchase would solve it for some (maybe even for many), but people still marry, get divorced, get adopted, have a gender reassignment, are forced to drop a letter from their last name because the ex-husband decided to change the transliteration of his name many years after their marriage (yes, this happened to someone I know!), or have other reasons to get a new first and/or last name. But thank you, allowing the separate name, even if it needs to be manually entered, is a good solution! Despite all this: FSUIPC and WideFS are definitively worth more than they cost! But some people having to pay more than others just for the reason above wouldn't be good.

I feel like walking on thin ice here, but I have to say something in support of the original poster and in support of legal customers who do something that should be considered normal. As someone who changed his name (luckily before buying FSUIPC and WideFS) and got new email addresses that match this new name, I'd be interested how SimMarket reacts. I could understand if they need to see the official documents. But Pete, you might want to reconsider the statement that this is a mockery, this could easily be considered insulting. And I have seen men being mocked and bullied for taking their wife's last name! The name I had before that wasn't really usable for identification either, because there were three people with that name in the city I live in, and one day I got a call from someone with the same name, stating that he founded a club of people with this first and last name and already has over 60 people from northern Germany who joined. Since that day I hoped that when I marry, I can take my wife's last name, which luckily coincided with my wife's wish to keep her last name :-)

A2A aircraft do many things different from default aircraft. Here is a list of LVars they use in the C172: http://www.a2asimulations.com/Cockpitbuilders/A2A%20C172%20Trainer%20-%20Variable%20list.pdf If you want (or need) to assign everything in FSUIPC (either in the GUI, INI file or lua scripts), then you don't even need VSPE and VRiSim, because this coupling is only needed to pass the existing functionality of VRiSim to FSX while being able to modify only parts of the behaviour implemented by VRiSim. (e.g. I have the M-Panel and use a lua script to have the altimeter in millibar instead of inHg and to use the gear indicator leds to display AP status and parking brake, but everything else should behave as the M-Panel does by default). But I would assume it is quite a bit of work to configure all the mappings needed for A2A aircraft. If you are willing to do that, you might get some inspiration by the LINDA module: https://www.avsim.com/forums/topic/418321-new-a2a-c172-trainer-module-version-103/ (I haven't really used LINDA so far, and I think above module only covers VRInsight's MCP) So in the end the question is: How much work are you willing to put into this? I would assume that you need at least some programming, or at least FSUIPC4.ini entries that are complex enough to be at the same level of difficulty. If yes: Congratulations, you are a cockpit builder! :-) If no: You are in the same boat as I am. I avoided A2A aircraft for a long time due to this, but now I just use the mouse (or in my case: trackball) in the virtual cockpit for such things, because I have realized that I want to fly this specific aircraft and not my "desktop cockpit" where every aircraft has all the relevant knobs in the same place.

I would recommend using VRiSim and the Radio Stack module from http://vrinsight.com/devel_shot/ instead of the old SerialFP2. Next step would be to make this setup work without the virtual com ports of VSPE. Only after this works you should attempt the next steps: - know which COM port your VRI device appears as, lets assume COM3 (which it is for me) - setup a virtual serial cable between COM4 and COM5 using VSPE (or something else, I use com0com) - add this to your FSUIPC4.ini to make FSUIPC connect to the device on COM3 and talk to VRISim on COM4: [VRInsight] 1=COM3,COM4 - Start VRiSim only after you have started FSUIPC (i.e. the flight simulator), so it does not connect to COM3 (which is busy now), but to COM5 (which looks like a VRInsight device, because it is connected to COM4, which is FSUIPC passing the information to and from the real device on COM3). I start VRiSim via FSUIPC, so the order is guaranteed. Edit: And a clarification: You need FSUIPC for the VRInsight devices, but you don't need any configuration in FSUIPC and you don't need VSPE! You only need VSPE and additional FSUIPC configuration if you want to filter/adjust/extend the existing functionality provided by VRiSim (or SerialFP2).

Clarification: FS9/FSX ATC is still running internally, because you can't disable it. You may see their messages in the kneeboard when you are on a frequency that is identical to what FS ATC uses. Additionally PF3 mostly only reacts to AI actions (which kind-of listen to the internal FS ATC). Only in certain cases does PF3 control AI, e.g. by freezing AI to avoid collisions during taxi.