Haldir

OMG I am such a moron. The helo trim does work Pete, my *sincerest* apologies for wasting your time on that. When I removed my fsuipc.ini file with the release of 4.1 I guess it was, when I was trying to figure out what was causing the multiplayer stutter, I completely forgot to remap my elevator and aileron axes through fsuipc again. It was using the FSX defaults, so the trim wasn't sticking. It works fine now. Hangs head in shame. :( Thank you once again for your patience and help Pete. Mike

Hi Pete. I logged the two offsets you requested with 4.104, just sent them to your email. No change in helo trim behaviour. I'll try some different methods of mapping my joystick through FSUIPC and see if anything changes. Cheers. Mike

Hey Pete, sorry my mistake, I didn't word my email properly, the perils of being up too late haha. Trafficlook does show my aircraft in slot 00, whether hosting or flying in someone else's session. It shows my aircraft tail # as my user ID and all the data next to that looks correct. It was the FSX SDK's tool, traffic toolbox>map that showed my helo as a "non-aircraft", not trafficlook, sorry about that. Thanks for looking into the helo pitch trim as well, its such a wonderful feature of FSUIPC. I was the one who asked you about a way to do that about a year ago, and you implemented it about two days later haha. Cheers for that. :) Mike PS: Enjoy your vacation!

Hi Pete. I checked out trafficlook, everything seems to look fine. Planes seem to show up in the correct order in the sdk traffic map tool as well, but helicopters don't show, just says "non-aircraft" for my helo, and no players who join the session with helos show up. Still everything seems to work fine there regardless. No worries on 3wire, I erroneously assumed it would start working in multiplayer after the simconnect fix in the patch, there's probably more to it. Can you tell I never fly singleplayer yet? haha. 3wire doesn't use FSUIPC at all to my knowledge so I'll ask the author about it, see if he's had the same experience, I know it's still very much a work in progress. I do have one other observation though. I can't seem to get Helo trim to work properly in fsuipc anymore. It definitely worked in your pre-patch versions of fsuipc. It 'sort' of works at the moment which I'll briefly explain. I can apply pitch trim commands either through the normal fs assignments or through fsuipc, and the helo will trim out, but the second I move the stick the pitch trim is neutralized again. However, if I then center the stick and hit the trim just once again it picks up where it left off, resulting in a big trim change at once. Seems it's remembering the amount of trim I had dialed in, but it's not applying it to the main controls if the joystick is in use. This is both single and multiplayer. Hope that description makes sense. :) Cheers Pete. Mike

I've put 4.103 through its paces with about 8 hours of multiplayer flight and no errors at all so far. Tried every aircraft I have, hosting as well as flying in others' sessions and no big stutters at all. Looks like you fixed it! I have a hunch simconnect is still going to sleep in multiplayer though despite ACES' claim to have fixed that problem. I re-enabled 3wire again just to mess with some carrier traps. It uses simconnect also and works like a charm in singleplayer, but it isn't reading aircraft position data in multi at all. I installed the latest sdk update but it didn't help. Strange. Cheers Pete. Mike

Hi Pete. Version 4.103 looks good so far! Logs are in your email. No errors in the fsuipc log, AC specific joystick settings are working again. Stutter is gone. I'll keep testing tonight in real multiplayer sessions and report back tomorrow. Cheers! Mike

Ok Pete, tried the new version. Logs are in your email. No big recurring stutter, but lots of small stutters and accompanying errors in the logs. Track-ir is disabled, I'll leave it off for testing from now on so you're not spammed with data. Cheers. Mike

Ok, sounds good Pete. Thank you again for looking into this. Your actions define a standard of customer service that few can match. I'm *always* impressed. I'll keep mucking about on my end. I don't really understand simconnect very well, but maybe I'll run across something that can help. Cheers. Mike

Hi Pete. Sorry I forgot to mention previously that I tried your timeout value suggestions, but I can't see any change in the behavior. Logs look the same. It seems that the stutters may have been spaced out a bit by setting the timeout to 9, but it was so far past my bedtime I'd have to say that was subjective at best haha. I just tried disabling the track-ir, no change at all, same regular stutter. No change in the fsuipc log. The strange thing is that my fsuipc joystick assignments, like my throttle reverse and assigned buttons all work just fine, so simconnect and fsuipc must be talking no? Mike

Cheers Pete. I did the same test flight and have emailed you the simconnect and fsuipc logs. I wish you luck, thanks again. :) Mike

Hi Pete. Ok I did some testing and saved the logs. The problem only seems to appear consistently in multiplayer, when I'm hosting a session. It was a locked session, myself in it only. In singleplayer this is the log I get for a bell 206 jetranger flight at geneva. I've used fsuipc's aircraft specific joystick settings to reverse the throttle, no other changes...... ********* FSUIPC4, Version 4.10 by Pete Dowson ********* User Name="Michael Johnson" User Addr="ramasurinen@gmail.com" FSUIPC4 Key is provided WIDEFS7 not user registered, or expired Running inside FSX (SimConnect SP1 May07) Module base=61000000 DebugStatus=15 31 System time = 05:55:41 31 FLT UNC path = "C:\Documents and Settings\Lotus\My Documents\Flight Simulator X Files\" 31 FS UNC path = "I:\00FSX\" 1031 LogOptions=00000001 1031 SimConnect_Open succeeded: waiting to check version okay 2562 Running in "Microsoft Flight Simulator X", Version: 10.0.61355.0 (SimConnect: 10.0.61242.0) 25422 SimStart Event: Initialising SimConnect data requests 25422 FSUIPC Menu entry added 25453 C:\Documents and Settings\Lotus\Application Data\Microsoft\FSX\Previous flight.FLT 25453 I:\00FSX\SimObjects\Rotorcraft\Bell206B\Bell_206B_JetRanger.AIR 57234 System time = 05:56:38, FSX time = 14:55:45 (12:55Z) 57344 Aircraft="Bell 206B JetRanger Paint1" 62875 Advanced Weather Interface Enabled 115640 Weather Mode now = Theme No problems there. This is what I get when hosting a multiplayer session, flying the exact same aircraft at the same location, same time of day, weather etc.... ********* FSUIPC4, Version 4.10 by Pete Dowson ********* User Name="Michael Johnson" User Addr="ramasurinen@gmail.com" FSUIPC4 Key is provided WIDEFS7 not user registered, or expired Running inside FSX (SimConnect SP1 May07) Module base=61000000 DebugStatus=15 31 System time = 05:55:41 31 FLT UNC path = "C:\Documents and Settings\Lotus\My Documents\Flight Simulator X Files\" 31 FS UNC path = "I:\00FSX\" 1031 LogOptions=00000001 1031 SimConnect_Open succeeded: waiting to check version okay 2562 Running in "Microsoft Flight Simulator X", Version: 10.0.61355.0 (SimConnect: 10.0.61242.0) 25422 SimStart Event: Initialising SimConnect data requests 25422 FSUIPC Menu entry added 25453 C:\Documents and Settings\Lotus\Application Data\Microsoft\FSX\Previous flight.FLT 25453 I:\00FSX\SimObjects\Rotorcraft\Bell206B\Bell_206B_JetRanger.AIR 57234 System time = 05:56:38, FSX time = 14:55:45 (12:55Z) 57344 Aircraft="Bell 206B JetRanger Paint1" 62875 Advanced Weather Interface Enabled 115640 Weather Mode now = Theme 150109 I:\00FSX\SimObjects\Airplanes\Aircreation_582SL\Aircreation_582SL.AIR 150109 I:\00FSX\FLIGHTS\OTHER\FLTSIM.FLT 175890 I:\00FSX\SimObjects\Rotorcraft\Bell206B\Bell_206B_JetRanger.AIR 216312 **** Simconnect Data Stalled! Re-connecting now**** 216312 SimConnect_Open succeeded: waiting to check version okay 216312 Failed on SimConnect_CallDispatch for Message, return = 0xC0000120 216312 Running in "Microsoft Flight Simulator X", Version: 10.0.61355.0 (SimConnect: 10.0.61242.0) 216312 Initialising SimConnect data requests now 216312 FSUIPC Menu entry added 222203 User Aircraft ID not supplied -- trying default 225312 **** Simconnect Data Stalled! Re-connecting now**** 225312 SimConnect_Open succeeded: waiting to check version okay 225312 Running in "Microsoft Flight Simulator X", Version: 10.0.61355.0 (SimConnect: 10.0.61242.0) 225312 Initialising SimConnect data requests now 225312 FSUIPC Menu entry added 231203 User Aircraft ID not supplied -- trying default 234312 **** Simconnect Data Stalled! Re-connecting now**** 234312 SimConnect_Open succeeded: waiting to check version okay 234312 Running in "Microsoft Flight Simulator X", Version: 10.0.61355.0 (SimConnect: 10.0.61242.0) 234312 Initialising SimConnect data requests now 234312 FSUIPC Menu entry added 240187 User Aircraft ID not supplied -- trying default That repeating section just goes on and on as long as the session runs, each time giving about a 0.5 second stutter. I hope this helps? Thanks Pete! Mike

Hi Pete. First off thank you for getting a working version of fsuipc up so quickly after the patch! However I have a small problem. With the latest fsuipc installed on sp1 I get a regular decent sized stutter every 5 seconds. I tried removing fsupic.ini and letting it build a new one but it does it just the same. If I disable fsuipic in dll.xml the stutter is gone. I've included a picture of my performance graph, you can see the stutter clearly on core 0. Usage drops about 15% during each stutter. FSX sp1 clean install, no addons except the realair sf260 and fsuipc. Happens with all aircraft, however the stutter is more severe in multiplayer, even with no one else in the session, than in singleplayer, not sure why that is. I have the registered version of fsuipc. Core 2 Duo 6600 2 Gigs 667mhz Nvidia 7900 GTO All drivers up to date. Any ideas? Sorry to be a pain. If I can send you any more information to help please let me know. Cheers Pete! Mike [/img]http://forums.simflight.com/files/fsuipcbugsmall_260.jpg

Fixed it. :) Not FSUIPC's fault at all. As a last resort I ripped out all the aircraft I had added to FSX thinking that something in one of them was causing the problem, and sure enough it started working. Turned out to be a duplicate aircraft name of all silly things. Activeky works now too....boggles! Then I went to avsim and found out someone had discovered and solved the very same problem not two hours beforehand, hahaha. (bangs head on table) Unreal. Thanks Pete!

Hey Pete, thanks for the quick reply, and sorry for my slow one. I'm glad to hear that it should be working as advertised, that's the answer I was looking for, hehe. It's been awhile since I reinstalled my OS, and it's probably all garbaged up at this point, though I can't find any spyware issues or viruses to blame this issue or my simconnect problems on. I don't want to waste any of your time chasing ghosts down for me, I think you must have your hands plenty full with bigger issues at the moment. Thank you for your wonderful and timely support as always though! I'll reformat, reinstall everything from scratch, and if I still have the issue after that (which I doubt), I'll let you know. Fingers crossed, hehe. Take care!

Hi Pete! I have a question about aircraft specific joystick calibration settings in FSUIPC4. Are they working? I read through that section of your manual but didn't see any mention of it being unfinished. If I missed something, my apologies. I'm using version 4.02 registered. The checkbox for them is greyed out to me and the aircraft specific checkbox for axis assignments won't allow me check it, even though it appears to be available. It brings up two setting confirmation dialogs, but won't check it no matter what combination of answers I give. Global axis assignment settings work when I set them, but then oddly FSX immediately crashes on the next session start and won't get past the spash screen. I end up having to delete fsuipc.ini to get it running again. Boggles. :) I'm also having the same Activesky/simconnect issues as several other people, surprise surprise, so I'm guessing my TCP protocol is trashed in some way despite having no anti-spyware software or 3rd party firewalls installed. Whatever is screwing up that connection is probably causing this issue as well I guess. Maybe this is also affecting other parts of fsuipc and I haven't noticed yet. Is the aircraft specific calibration working for you or anyone else? Haven't tried copying over my ac specific settings from FS9, but that's next. My finger is hovering over the format C: command anyway with all these issues, and a fresh install might be my only solution unless ACES gets their act together on simconnect in a big hurry, haha. Cheers Pete, and thanks!

Hey JSkorna. Thanks for the suggestions. I tried them all but to no avail sadly. Installed the latest via chipset drivers, cleaned out the ati drivers and reinstalled the latest. Dxdiag shows all tests work perfectly, cube spins smoothly. Agp is at 8x. I leave fastwrites off normally. FS never complains about FW being on, but other games do on occasion. Turned fastwrites on to test, and no change there either. Thanks for all your time though. I've put up with this bug for years, just recently decided to have another go at cracking it and thought I'd see if anyone else had run into it. Its probably moot in the end since FSX is just around the corner, hehe. I'll be first in line at EB the day it arrives, cloud stutters or not. :) Cheers! Mike

Hey, sorry for the late reply, didn't have any time to FS this weekend. Anyway, I set the cloud draw distance down to 30nm. Same behaviour exactly. I can watch them fade in and the fps drops from 30 solid to around 12 for 15 seconds. When the fade in is complete, jumps back up to 30. Haha. What a silly problem eh. Thanks for the help though! Mike

Hey, thanks for the quick replies Pete and JSkorna! You're fast. :) Here's a bit of info on my setup etc. Didn't want to post it in the last message as I felt it was turning into something of a book hehe. AMD 64 3400+ 2.2ghz, ATI 850XT 256mb, 7200 rpm sata drives, 1 gig of ram, and all the usual bells and whistles, track-ir, controllers etc. I fly at 1600x1200 with AA and AF completely off. At that resolution they add nothing and simply knock down my average fps, and in my opinion they degrade image quality in FS anyway. A little bit of shimmering in the extended texture ring doesn't bother me in the slightest. Last bit about me, is that I've worked in the games biz as a 3d artist for 10 years, with EA, Namco, and a couple other small developers, so I'm no stranger to messing about under the hood with textures and rendering engines hehe, but this one really has me stumped. Normally this machine just smokes FS completely. I run with max settings on everything, clouds, scenery, you name it. I have the fps locked at 30 normally. If I toss it up to unlimited I'll see fps jumping over 80 but of course that will introduce microsutters with heavy sceneries, and I prefer a little smoother ride. Even flying over seattle, with UT, 3 layers of overcast, some cirrus and maxed out traffic, the fps counter never drops below 29.5. Its rock solid in all cases, except, yup, when new clouds are fading in on the horizon. When AS is running I've tried putting in all manner of suppression ranges, from 100-500nm, and it makes no difference in this cloud fade in stutter. Doesn't matter if I shut down AS after it loads in weather either. Its definitely not AS that's causing this. I get this effect using FS's own weather as well. I've done some tests with it, basically cranking view distance to max, turning off all view distance reductions in fsuipc and AS, flying up to 35000 feet over an overcast layer, and then saving the flight. Removed fsuipc, shut down AS, restart FS, load flight, and then watching new clouds start to fade in at 80nm distance, the FS max. As soon as new clouds begin to fade in, as they cross the magical 80nm vis barrier, poof, frame rate drops to single digits for roughly 10-15 seconds. So both of your wonderful products are in no way responsible for this. :) The heavier the section of clouds fading in, the lower the fps goes, but it is for a fixed period of time. It's always 15 seconds, which seems to be how long FS thinks new clouds should take to come into view. However this only occurs if those clouds are on screen as they go through this process. If I glance away from them, framerate shoots back up to normal. If I am watching them as they do this, the second they're finished fading in, framerate jumps back up to 29.9 solid. I've tried using reduced cloud texture sizes, down to 64x64, tried both dxt3 and 32 bit, no difference. I've tried it with render to texture on and off. Leaving render to texture "Off" of course will cause the game to crash if using dxt3 clouds (its an ATI thing). Again, no difference. I've tried dropping the max vis to 60nm and setting the cloud vis out to 80, so that they might come into existence without being rendered at first, since they're beyond the clipping plane. Again, no effect. I normally use 100% 3d clouds. I've tried dropping them to 50%, with the rest 2d impostors, but they still fade in at a certain distance, making that transition from 2d to 3d, and the fps drops. I'd love to try this problem on an nvidia card, as I have a hunch this might be some sort of bug in ATI's catalyst drivers, but alas I don't have one available. I've been using and tweaking FS2004 since the day it came out, but have never managed to beat this problem, always just sort of put up with it. It exhibited the same behaviour on my old radeon 9800 as well. Could be some VIA drivers issue as well, haha who knows. Maybe it only affects my system and the system of the poster I linked in the previous message. *boggles!* Thanks guys! Mike

Hi Pete! First off let me thank you again for adding the helo trim function to fsuipc, that was simply superb! Cheers. :) Anyway, I have a question regarding a problem with cloud rendering in FS that I was hoping you might have some insight into. I doubt that FSUIPC is in any way responsible for this issue as I removed the DLL and no improvement was seen, so please feel free to ignore this post if you're busy! If anyone else can shed some light into it though, please do. :) It is related to a much older post on this forum, for which a cause or solution were never discovered. I've discoverd the cause at least. http://forums.simflight.com/viewtopic.php?t=30422&highlight=clouds The problem is an intermittent drop in framerate when clouds are present. Whether created by an addon program like activesky or coming from FS's own weather, global or locally set, it makes no difference. When flying at high speed, every minute or so, if clouds are ahead, I experience a severe drop in framerate. The cause of this, which the previous poster didn't catch I think is that FS "fades in" clouds as they come within view distance. This process of inceasing the alpha value of the polygons the clouds are textured onto takes roughly 15 seconds. It fades them in as square shaped tile sections in pretty much the same manner that scenery tiles are loaded it seems. It's during this fade in that the frames per second just plummet, but only *if* that particular section of clouds is visible on screen as they materialize. The second the clouds have finished their alpha transition from invisible to opaque, the fps jumps back up to normal. If more clouds are present over the horizon beyond those ones, the process repeats roughly a minute later, depending on velocity of course. This is easily testable if you have a track-ir. These drops in fps only occur when looking forward in the aircraft. As soon as a section of clouds starts to fade in and the fps drops, if you quickly look to the left or right, so that those particular clouds are no longer visible, the fps jumps back up to normal (regardless of how dense the clouds all around you are). Look back towards them, and if they haven't finished fading in, you're back to a slideshow until they do. I know for a fact it is this fade in process that causes the drops in framerate. It does not occur when flying from a heavy cloud area into clear air. The denser the cloud section being loaded into view (ie: heavy overcast) the lower the frames go during this time. Whether this is unique to ATI cards, or affects everyone, I have no idea, but the poster in the link above had an Nvidia I think. I'm guessing this is a basic part of the dynamic weather system that isn't defeated by setting weather change rate to 0. So my question for you, and anyone else: Is there a way to simply force cloud sections coming into view on the horizon to pop in all at once instead of gently fading into view? I'd much rather see a minor graphical anomaly on the horizon for a second than a 20 fps drop for 15 seconds every minute or so. I know the FS weather engine *can* do this, because anytime you use an external weather program, all local weather simply pops into view at once the moment the program has finished sending the data to FS. Its only when you want to go somewhere that the slideshow begins. ;) The reduction in framerate from this phenomenon is pretty nasty, from around 35 fps (my norm at 1600x1200 with maxed everything) to around 5-10 fps, unless I stare out the left window for a minute until it's finished, hehe. Seems like a small process to hog so much in the way of resources, but it brings my machine to its knees every time, and results in the famous blurries for another 30 seconds as everything tries to catch up, haha. Has anyone else run into this? Thanks again Pete! Take care. Mike

Hehe...oh there are definitely a few choppers out there that could be considered "wobbly goblins" I'm sure, but most are pretty solid. Actually I think the most amazing ones of all are the radio controlled model variety, the manoeuvres they can pull off are utterly insane. :) Take care. Mike

Hi Frank. Actually a helicopter is a surprisingly stable flying device, albeit somewhat less so in a hover than in forward flight. It does require more attention and in some cases a finer touch than a normal fixed wing aircraft, but it is by no means exponentially more stressful or difficult to fly. The centre of lift in a helicopter is a significant distance above the centre of gravity of the machine, and the helicopter body is essentially suspended below the rotor disc, much as a ball hangs from a string. Gravity takes care of the rest. As long as the helicopter body is loaded within CG limits it is very stable indeed. In forward flight the body of the helicopter, notably its tail section, provides yaw stability much as the vertical fin in a fixed wing aicraft does. If the chopper begins to yaw in one direction, a high pressure region will form on the side of the tail opposite to the turn and resist the yawing force. The tailrotor takes care of yaw control and resists the torque effect of the main rotor in a hover, but its effect is largely reduced in high speed flight. As a helicopter picks up speed in forward flight the rotor blades begin to behave as one. In effect the entire rotor disc becomes just a giant wing as far as the air is concerned, and the chopper behaves much as a conventional aircraft does. This is called translational lift, and like any normal wing, the faster you go, the more lift is generated and the more the wing/rotor disc tends to pitch up as a result. There is a limit to the forward speed of a helicopter though, because beyond a certain speed the rotor blades that have passed the front of the helicopter and are rotating back towards the tail can find themselves literally flying backwards through the incoming air, producing a partial or total stall on one side of the rotor disc. This is called retreating blade stall, and results in a helicopter going into its own version of a classic spin as experienced by fixed wing aircraft, though it is much more dangerous obviously. As well, even in a hover, when all lift is generated directly by the rotor blades themselves, with no translational lift, the gyroscopic effect of the spinning rotor mass makes it as stable as a quickly spinning top on a table. The higher the rpm of the blades (or the heavier the blades), the more stable the rotor disc is. In fact the very job of the cyclic control is to upset this balance on one or more quadrants of the rotor disc. As each blade passes through a specific region of its rotation arc, the cyclic's actuators on the rotor hub change the angle of attack of the blade as it passes that point, forcing it to momentarily generate more or less lift as needed. This is what allows a helicopter to bank in any direction. Many helicopters do have cyclic trim controls, especially those designed for long endurance times or long distance flight, ie: military applications above all. As early as the vietnam war era, helos were equipped with at least simple mechanical spring or magnetic linkages attached to the cyclic for this, and in newer aircraft the systems are mostly electronic. Many others have trim control on all three axes I've discovered: longitudinal and lateral cyclic trim, and tail rotor trim. Most systems appear to simply read and then hold the current positions of the cyclic, collective, and tailrotor controls, and then allow some movement by the pilot from these new positions. Some info here, with explanations and diagrams: http://incolor.inebraska.com/iceman/pilot36.htm Cheers. Mike

Hehe, yes by 'tick' I meant the inc/dec controls. Sorry for the daft terminology. ;) Ok, I've tried your new version here with 7 helos so far, freeware and payware, and it works perfectly with all of them. A nice side benefit of having this new trim is being able to set up a really stable hover. Generally FS helos tend to pitch up all on their own when hovering which, when you're using a track-ir and staring between your feet at the ground, can get pretty annoying. That behaviour is probably realistic, but your new trim takes care of it perfectly. I'm not sure if a real chopper has rudder trim, but I'm guessing most wouldn't, and its really no concern at all, I was just curious. The rudder force needed is absolutely nothing compared to the tricep building that maintaining level flight in helos has entailed so far. Hahaha. If I'm flying in a straight line just cruising, I'll just use a few taps of direct keyboard rudder control and then forget about it. Don't really need to touch the rudder/tailrotor again until I'm ready to slow down. Great job Pete! Thanks so much for helping me out here. I think a lot of rotorheads will love this new feature when you release it. Take care! :) Mike

Pete! You're brilliant. Its absolutely perfect. :) Just tested it on the bell, and it trims just like a normal aircraft. Whatever value you chose to add to the elevator per tick is excellent, very fine control indeed. I'll test it out this afternoon with the rest of the helos in my hangar, all of which I'm pretty sure use the bell style flight model, and report back. Can this same process be applied to the aileron and rudder axis as well? The aileron axis is great as is really, but the rudder/tailrotor axis at least always requires constant deflection to maintain a straight line in a helo at full speed (though not nearly as bad as the elevator deflection needed was). Its trim axis is always zeroed out like the elevator's as well I guess. Either way I'm stoked! Many many thanks! You've just made helo cross country flight in FS viable. :) Mike

Ok, I tried everything in the default robinson as well. I mapped my joystick's y-axis to the elevator trim axis, through normal assignments first and through fsuipc after that, and again those two trim offsets just read zero constantly. Went back to the bell, same thing. Sorry about this. I was hoping there was some easy solution that I'd been too blind to notice. Instead it looks like I gave you another headache. :( Many thanks for looking into this though. Not sure what MS was thinking here. Perhaps there's some nasty destructive property to their helo model and they thought that if they removed cyclic trim, that everyones' wrists would tire before they could notice it. Hehehe. Guess they expected everyone to just putter around cities in them and not try cross country flight, which is damned near impossible in its current state. Good luck! :) Mike

Hi Pete. Ok, I tried monitoring the two offsets you specified, using the default Bell 206 and the default cessna 172 as well. In the cessna the trim controls increment properly adding plus or minus 32 each tick I think. In the bell it just reads zero regardless of what I do with the trim keys. I'm not sure if this helps you? FS could be zeroing the trim inputs, or simply ignoring them altogether. FSUIPC is logging the key inputs, but there's no change in the value in those offsets. I've tried leaving them mapped through the regular FS key assignments, and mapping them through fsuipc as well, seems to be no difference. Also I was unaware that there are two helo models. I've just been using the default jetranger for testing.