Pete Dowson

Sorry, I know nothing at all about WidevieW, and it does not use FSUIPC so I cannot help. I suggest you try WidevieW support. Pete

Well FSUIPC really cannot do anything unless you ask it to. Try using FSUIPC's logging to see what is happening. You can log key presses and "events". The event generated, by, default, with the G key is Gear Toggle. You could even actually assign it if you wished. But honestly, there is no way FSUIPC will "steal" the G key without assignment and without another program requesting it. Pete

Just installing FSUIPC does nothing to anything in FS, excepting if you have some application using it to access FS internals. If by "declared" you mean you've purchased FSUIPC and registered it, then any assignments you've made which are recorded in the FSUIPC4.INI file will of course be applied. You've probably made some assignment to the "G" keypress. visit the FSUIPC options and check. The FSUIPC User Guide explains how to use FSUIPC, and especially a lot about assignments. If you aren't sure, and haven't made a lot of selections or assignments yet, just delete the INI file before loading FSX and a default one will be generated which will do nothing at all. BTW 4.927 is not supported. Use 4.936. Pete

Yes, they added additional controls to the normal FS list, numbering them beyond those pre-assigned in FS. So they are "non-FS" controls in the sense that FS doesn't know those numbers, but they use the same mechanism, posting via message queues using Windows WM_COMMAND messages. Pete

Actually most of the sub-systems in the NGX are dealt with by additional FS controls which PMDG added. I don't think you need to use the L:Vars for anything, though many were discovered before PMDG released their update with the SDK. The SDK lists all the extra (non-FS) controls added to the normal FS range -- and accessed in FSUIPC by the <custom control> assignment and the control number -- as well as mapping all the read-outs so cockpit builders can show them on their hardware displays. iFly went a different way and provided the values and controls by a different interface. iFly2FSUIPC maps all those inputs and outputs to some FSUIPC offsets allocated for that purpose. I don't really know much about iFly, so I couldn't say whether they used L:Vars too or not. Pete

Please update. 4.936 is the currently supported version. So, enlighten me please. What's a "Beta range". What is it supposed to do. Feather the props or something, to aid in slowing down? What happens to the engine power / RPM in that range? I assume that it's the zero (normal idle) on the throttle which is being treated in this way. The problem is you need it to be zero, or minimum, so that the "throttle decr" control with take you into reverse. Otherwise you could prevent the throttle axis value getting that low by editing the calibration number, in the INI file, for the minimum (the first number in the parameter line) to a value below the lowest the axis can achieve - eg -16400 if the value there is -16384 or similar. It might be worth trying. If that doesn't work, or prevents the reverse from engaging, I'm afraid I have no answer -- it's really a question for Flight1 or the aircraft's author. I'm sure you can't be their only user. How do others do it? Pete

Ooops! Good spot! It was originally included in the ZIPs, next to FSUIPC or its Installer, and then it was to be Installed automatically by the Installer -- but it seems it somehow got overlooked! Apologies. I'll add it to the ZIPS for now and make a firm note to update the Installer on the next major update. Download FSUIPC4936a and you'll find it inside. Regards Pete

In the Axis assignments tab you can assign to FSUIPC's "direct to FSUIPC calibration" brakes, or you can choose to assign to FS controls "Axis left brake set" and "Axis Right brake set" controls, or, (I think these are still there, but I'm not sure), in the same drop down, the older FS98 controls "Brakes left" and "Brakes right". Yes, that's actually the most efficient way. I always use that method. Pete Pete

Mmm. New to me. Though this comment: "the joystick button is best used to apply the brakes on landing because both left and right brakes are applied equally and in that case the plane stays on a direct line without swerving left or right. On the other hand the toe brakes are best used to steer the aircraft left or right by applying more force on one toe brake or the other" should have been answered. Real pilots don't have such a "cheat". Toe brakes AND rudder need to be applied sensible to keep a straight line. Best to practice that rather than cheat. And toe brakes should not often be used for steering. The nose wheel is sensitive enough where it is controlled, and the rudder is very effective in light aircraft. There are several ways of assigning toe brakes in FSUIPC. Have you tried them all? Pete

You are either making a mistake -- not only the key must be exact, but also your name and email address, EXACTLY as first registered -- or the date set in your computer is wrong, earlier than your registration date. Maybe you've not set the date yet? Pete

Without seeing the axis values each time I really could not say. Sorry. I'm sure you can work it out yourself using the logging facilities. Pete

and what is your aircraft altitude? Maybe you should save the flight at the point you think it is wrong, and ZIP up the FLT + WX file and send it to me, petedowson@btconnect.com. All FSUIPC does for those offsets is search through the cloud and wind layers, trying to find one in which the aircraft is flying. Then is computes the nmubers to go into those offsets. This has been working fine -- in fact something like the Lua you are using is in use by many folks with no problems. Pete

Well I still think you have unequal brake pressure applied. Try calibrating with a wider null zone -- i.e. press the pedals down before setting the minimum. No, it's the input from the two brake axes, left and right. Proper calibration will get them both equal and off when the feet are relaxed, and both equal and max when both are fully depressed. anywhere else is unlikely to be equal pressure. Pete

The offsets only change if there is turbulence reported at the altitude of your aircraft. Saying the weather looks okay doesn't help. You need to work it out. Pete

I'm off on holiday after tomorrow and up to my eyes in stuff at present. I can take a look, but it will be in a couple of weeks. Remind me on or after 9th September. Pete

Okay, so the weather values used to set those offsets don't change. Are you sure you get any turbulence? Use the weather logging to check FSUIPC is reading the weather using the standard SimConnect weather facilities. Pete

I'm pretty sure it's a line-based facility only at present. Without checking my code I'm not sure how much work it would be to make it stream based. The problem then is processing embedded controls. It gets much more complicated. Pete

Try enabling the Lua debug/trace option on the FSUIPC logging page. Since you are having the Lua started when FS starts you'll need to enable that option then restart P3D. BTW this line is wrong: sound.stop=(ref) That's going to mess things up, if it is ever executed. It should of course be sound.stop(ref) You could also using FSUIPC's monitoring facilities to see if offsets 0E88 and 0E98 ever change. If they are never set >0 then the sound will never trigger. If you want to check that the sound would play if it is triggered, just try adding this at the beginning: ref=sound.playloop("turb.wav") ipc.sleep(3000) sound.stop(ref) Pete

FSUIPC cannot be used with CFS3. Unlike CFS1 and CFS2, which were both based on FS, CFS3 was a completely different development and did not allow add-in DLLs like FSUIPC. Pete

Well, if the BRAKES control is being sent but ignored by the model, it must surely have something to do with the specific model you are using. However, you say "my problem is with a standard FSX plane", so it is indeed a puzzle. But one thing I do notice, and that is the final Left Brake axis value is 56675 *** AXIS: Cntrl= 66387 (0x00010353), Param= -16193 (0xffffc0bf) AXIS_LEFT_BRAKE_SET which is not actually "off"! Why not try proper calibration so that the differential brakes do go completely off ( i.e. -16383 or -16384, never quite sure which). Maybe the BRAKES can't operate normally when a differential brake pressure is still actively applied. That wouldn't surprise me so much, really. Certainly FSUIPC only uses the BRAKES control when both pressures are the same. Pete

There's nothing I know of which is suddenly stopping the normal "Brakes" control working -- that's the one assigned to the '.' button by default. I'd check what your other add-ons are doing if i were you. FSUIPC actually used both -- it sends the Brakes control when the pressure on both pedals (after calibration) is equal. Use FSUIPC's logging to see what is going on. Pete

All those values are available. Just check the offsets list installed in your FSUIPC documents folder, inside the FS modules folder. Regards Pete

Sounds like a corrupted length field. Try using the logging in FSUIPC to see what is going on -- though I think that error is detected in the FSUIPC_Read or Write functions built into your code, before FSUIPC sees them. Pete

Please always quote version numbers -- many folks say "latest" meanng "the latest one they noticed". The currently supported version for FSX and P3D is 4.936, for FS9 and before it is 3.999z8 or z9. Is this with FS9, FSX or P3D or some earlier FS? You need to say really. It sounds exactly like a dual assignment. You don't say where you assigned the axes nor to which actual controls. If you are assigning in FSUIPC you should disable controllers in FS to avoid conflicts. You can use FSUIPC's logging to see what is going on. Pete

Sorry. FSUIPC really only handles axes fully if they are assigned in FSUIPC. If you disable controllers in P3D they should remain dfisabled? Pete