Pete Dowson

The files FSUIPC knows about should not be accumulating more than the number of iterations you've allowed in the settings. For files it doesn't know about you need to tell it via parameters in the INI file. This is described in the FSUIPC Advanced Users guide. The ones it knows about are FLT, FXML, FSSAVE, WX, PSS, FMC, ABL, RCD, SPB and IPCBIN. Pete

If the five positions are all seen by FSUIPC, or at least 4 "on" button states as well as an "off" state, then all you would need to do is assign them to the FSUIPC control "Autobrake set" with the parameter set to 0 for RTO, 1 for off, and 2-5 for 1,2,3,MAX. You'd need to forgo one of those of course. Pete

If the mode switch is visible to FSUIPC then you can do it by using conditional assignments, one where the action programmed depends on the state of another switch. There are general examples in the Advanced Users guide for FSUIPC, and I'm sure there must be other examples around as this sort of thing has been done by a lot of folks before. It does mean editing the INI file, you can't do it in the FSUIPC options tab. Have a look through the User Contributions subforum. Regards Pete

SLI is linking two or more video cards together for more video power. See http://en.wikipedia.org/wiki/Scalable_Link_Interface FS has never supported it, but there is an experimental version of P3Dv2 which may be able to take advantage of it. Pete

I don't really understand the problem since I've no idea what an IRIS or Tacpack is, nor why key combinations are involved. Is there a specific aircraft in there somewhere? Most add-on aircraft use controls or local variables, not key combinations directly, though they can sometimes be assigned. With FSUIPC, registered or not, you can use the Logging facilities to log key presses and controls being sent into FS's simulation engine. Maybe those will help? Pete

I'm not really understanding what you are saying. It seems that the MJC Q400 is using standard FS controls internally, from its gauges, but then ignoring them? Is that what you mean? It might help if you showed relevant parts of the Log, with Events and Buttons/Key logging enabled. You can paste such test here, just use the <> button above the edit area to envelop it. We'd need to compare the same events when you click with a mouse and press a button. Pete

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