FSX crashes with FSUIPC4

[Pete Dowson]

I tested affinity with FSUIPC4.294:

Affinity = 1 >> OK

Affinity = 2 >> OK

Affinity = 3 >> CTD during FMS configuration of Wilco Airbus 321

I'm going to do further testing on Wednesday

Generally it seems that stability is improved

I really fail to see how allowing FSX to use multiple cores is causing CTDs unless there's a real hardware problem on your machine. I am using FSX on an 8 core system (2 x QX9775 processors) and have no such problems, and it has been running since it came out, something like two years ago (including Betas) on two Core 2 systems I have and never once has there been a CTD I could even think of ascribing to any affinity setting.

If I were you I'd be rather concerned about the stability of my motherboard.

Regards,

Pete

[dth]

Hi Pete

You are absolutely right !

I just finished my first flight with affinity = 3 :-))))))))

The problem was either the overclocking of the RAM or the DPI setting of my Razer Habu mouse, which I will try out tomorrow.

Thanks a lot indeed

kind regards

Dirk

[Muas]

After some time spent on configuring and recalibrating axes on FSUIPC4291 (and some flying in between) I got one crash, exactly like the ones before.

The ones before were preceded, in the SimConnect log, with data corruption in the Axis events being sent.

In 4.291 and after there are no Axis Events being sent for axes sent "Direct to FSUIPC calibration", and there cannot be corruption in data which doesn't exist. So to investigate further, to see if it was Simconnect related, I'd need to see the SimConnect log. It does actually sound as if your crash is not the one others have been suffering at all, and is therefore probably not related to axis assignments at all.

Also it seems that trim axes are interfering with flaps axes, sometimes I get the flaps dead, and trim axes one side full deflected, all three of them.

There's is no way in FSUIPC itself that any such cross-interference could occur. That sounds very much like FSX has picked up its own assignments (again). This can happen quite easily if you ever unplug and re-plug in any controllers. And fully-deflected axes tend to arise from a bad connections, which can look to the Windows drivers like a fully deflected lever. This used to be a common occurrence in the Game Port days.

Regards

Pete

Well, crashes seem to be gone now - only had that one on 4.291 - it didn't happen anymore.

I'm still concerned about these trim/flap axes problem, cause it's still happening.

I have flaps direct to FS, with 4 detents set at given ranges; elevator, aillerons and rudder trims go through FSUIPC for calibration. and strange thing is these usually show raw data -512 to 495 values, and after sometime they revert to -16384/+16384 range. When flight starts things seem to be alright everthing working as should, after sometime all trims fully deflect or flaps stop working. Very annoying.

If there's anything I can log to sort this out, I'd be happy to.

[Pete Dowson]

I have flaps direct to FS, with 4 detents set at given ranges; elevator, aillerons and rudder trims go through FSUIPC for calibration.

Why so mixed? Why not all the same route? And what about the actual flight controls - elevator, aileron and rudder. Where do they go?

Are the flap detente ranges using the "send control" options on the right-hand side of the Axis Assignments Tab, or are you talking about the detentes in FSUIPC's calibration facilities?

and strange thing is these usually show raw data -512 to 495 values, and after sometime they revert to -16384/+16384 range.

-16384 to +16384 is the scaled range, scaling is performed by Windows' drivers. The -512 to +495 sound like more realistic "raw" values, but for FSUIPC to see those you'd have to have the "RAW" option checked -- this sets a flag in the call to Windows to ask it to return Raw rather than Scaled values. No idea how you can get one then another without changing an option, unless it is some function of your drivers.

... after sometime all trims fully deflect or flaps stop working. Very annoying.

Very strange too. Certainly things fully deflecting are most usually associated with bad connections or faulty hardware axes. Flaps not working could be the same of course- fully deflected for that axis would be the same as flaps fuly retracted.

How are these axes connected relative to other axes? Maybe you should show me the [Axes} part of your FSUIPC4.INI file?

If there's anything I can log to sort this out, I'd be happy to.

Log axes (one of the options in the Logging tab), of course. It may show something that helps, but logging doesn't in itself sort things out.

Regards

Pete

[Muas]

Why so mixed? Why not all the same route? And what about the actual flight controls - elevator, aileron and rudder. Where do they go?

Aileron and rudder go directly to FS; elevator goes to FSUIPC calibration to get a smoother curve output.

Are the flap detente ranges using the "send control" options on the right-hand side of the Axis Assignments Tab, or are you talking about the detentes in FSUIPC's calibration facilities?

Flaps goes directly tp FS using detents set by "send control" options. It's controlled by a four position lever switch using resistors. I set data intervals for each position. This is the generic configuration. Then I have specific config for 737, where flaps detents are set through FSUIPC calibration, and is controlled by a quadrant style lever axis. The prop ac flap lever is disabled for this config.

-16384 to +16384 is the scaled range, scaling is performed by Windows' drivers. The -512 to +495 sound like more realistic "raw" values, but for FSUIPC to see those you'd have to have the "RAW" option checked -- this sets a flag in the call to Windows to ask it to return Raw rather than Scaled values. No idea how you can get one then another without changing an option, unless it is some function of your drivers.

The RAW option appears checked and greyed out for flaps (I cannot uncheck it) when using the generic config; thus initialy always displays RAW values.

Certainly things fully deflecting are most usually associated with bad connections or faulty hardware axes. Flaps not working could be the same of course- fully deflected for that axis would be the same as flaps fuly retracted.

I really don't believe this is about bad connections; I tested the other way round, the quadrant lever axis setting the detents on "send control" (directly to FS) and the trim axis interference happened that way too.

How are these axes connected relative to other axes?

Generic config - non aircraft specific, I use it for piston/turboprop ac:

Aileron directly to FS (yoke)

Rudder directly to FS (pedals)

Elevator through FSUIPC with a smooth curve output set (yoke); parking brakes on when full forward set on "send control"

Throttle through FSUIPC calibrated -16384 to +16384 linear (quadrant), if I get it directly to FS it gets output 0 to +16384, thus working mid travel only

Prop pitch through FSUIPC calibrated -16384 to +16384 linear (quadrant), just like thrust for the same reason

Mixture through FSUIPC calibrated -16384 to +16384 linear (quadrant), just like thrust for the same reason

Flaps directly to FS using "Flap detent set" and detents set on "send control" (4 pos lever switch sending raw data)

Diferential brakes directly to FS (pedals)

Aileron trim through FSUIPC with a smooth curve output set (thumb wheel)

Rudder trim through FSUIPC with a smooth curve output set (knob wheel)

Elevator trim through FSUIPC with a smooth curve output set (thumb wheel)

Specific config for stock 737 (aircraft check):

Aileron directly to FS (yoke)

Rudder directly to FS (pedals)

Elevator through FSUIPC with a smooth curve output set (yoke); parking brakes on when full forward set on "send control"

Throttle through FSUIPC calibrated -16384 to +16384 linear (quadrant), if I get it directly to FS it gets output 0 to +16384, thus working mid travel only

Spoiler directly to FS with up position "arm off" set on "send control" (quadrant)

Flaps through FSUIPC with 8 detents set on calibration facilities (quadrant)

Diferential brakes directly to FS (pedals)

Aileron trim through FSUIPC with a smooth curve output set (thumb wheel)

Rudder trim through FSUIPC with a smooth curve output set (knob wheel)

Elevator trim through FSUIPC with a smooth curve output set (thumb wheel)

All axes disabled on FSX settings interface; sensivity mode off set on fsx.cfg

As far as I remember the flaps/trims interfere only when using the generic config; but its not control related, because I tested it changing lever controls.

Maybe you should show me the [Axes] part of your FSUIPC4.INI file?

Off town tonight. I'll send it on Friday.

[Pete Dowson]

Aileron and rudder go directly to FS; elevator goes to FSUIPC calibration to get a smoother curve output.

I'm afraid that tells me little or nothing. FSUIPC calibration can be used no matter how you route the axes. Are you saying you don't use FSUIPC at all for aileron and rudder? And is the elevator assigned in FS or in FSUIPC, and if in FSUIPC, is it using the "direct to FSUIPC calibration" or via FS?

Flaps goes directly tp FS using detents set by "send control" options. It's controlled by a four position lever switch using resistors. I set data intervals for each position.

Sorry, by "direct to FS", do you mean assigned in FS? I really am gleaning nothing from this sort of description.

There are these possibilities for each axis:

1. Assigned in FS, not calibrated in FSUIPC, FSUIPC has nothing to do with it

2. Assigned in FS, calibrated in FSUIPC

3. Assigned in FSUIPC, using the FS control option, not calibrated in FSUIPC

4. Assigned in FSUIPC, using the FS control option, calibrated in FSUIPC

5. Assigned in FSUIPC, using the direct to FSUIPC calibration option, calibrated in FSUIPC

6. Assigned in FSUIPC, no Axis control allocated, range facility used to send controls to FS

If you mean you use the last for flaps, then there are no axis controls involved. If you are using a flaps axis AND sending controls then that is probably one of the problems, they may be conflicting.

FSUIPC does provide, for flaps, a detente programming facility in the Calibration section. That works much better normally than trying to assign specific controls to specific regions.

The RAW option appears checked and greyed out for flaps (I cannot uncheck it) when using the generic config; thus initialy always displays RAW values.

There's a restriction in the DirectInput and Windows joystick APIs which makes it necessary to either read axes on a joystick in RAW mode or in calibrated scaled mode. Once you have enabled RAW mode on any axis on a joystick then it must apply to all the others on the same joystick. To clear RAW mode settings you need to clear (delete) the settings for each axis on that joystick, then re-assign them. I'm wondering now how much this mix-up is contributing to the confusion.

Generic config - non aircraft specific, I use it for piston/turboprop ac:

Aileron directly to FS (yoke)

Rudder directly to FS (pedals)

Elevator through FSUIPC with a smooth curve output set (yoke); parking brakes on when full forward set on "send control"

Throttle through FSUIPC calibrated -16384 to +16384 linear (quadrant), if I get it directly to FS it gets output 0 to +16384, thus working mid travel only

Prop pitch through FSUIPC calibrated -16384 to +16384 linear (quadrant), just like thrust for the same reason

Mixture through FSUIPC calibrated -16384 to +16384 linear (quadrant), just like thrust for the same reason

Flaps directly to FS using "Flap detent set" and detents set on "send control" (4 pos lever switch sending raw data)

Diferential brakes directly to FS (pedals)

Aileron trim through FSUIPC with a smooth curve output set (thumb wheel)

Rudder trim through FSUIPC with a smooth curve output set (knob wheel)

Elevator trim through FSUIPC with a smooth curve output set (thumb wheel)

Unfortunately these descriptions are all rather ambiguous. When you say "directly to FS" that sounds like you don't use FSUIPC at all for those. And those "through FSUIPC" could be via any of about 3 or 4 of the methods I list above.

All axes disabled on FSX settings interface

Ah, does this mean when you say "directly to FS" you really mean "assigned in FSUIPC"?

I'll send it on Friday.

Because of all the confusion above I don't think I can even think about it until I see your INI file -- not just the [Axes] sections, looks like I'll need to look at the calibration sections too. ZIP the complete INI and send it to petedowson@btconnect.com please.

Regards

Pete

[Muas]

There are these possibilities for each axis:

1. Assigned in FS, not calibrated in FSUIPC, FSUIPC has nothing to do with it

2. Assigned in FS, calibrated in FSUIPC

3. Assigned in FSUIPC, using the FS control option, not calibrated in FSUIPC

4. Assigned in FSUIPC, using the FS control option, calibrated in FSUIPC

5. Assigned in FSUIPC, using the direct to FSUIPC calibration option, calibrated in FSUIPC

6. Assigned in FSUIPC, no Axis control allocated, range facility used to send controls to FS

Option 1 and 2 are out - I'm not using them. As I said at the end of my last post, I cleared all the ingame FSX axes assignments. I'm using FSUIPC to config them all, mostly options 3 and 5, I didn't realize option 4 was possible at all?!? I really wished that was possible, but I thought it wasn't.

I'm also using option 6 for the analogue flap switch lever, but I allocated the flap axis too, together with send controls upon ranges - maybe this causes the conflict.

Sorry for all this misjudgement, maybe it isn't all so clear in the manual, or maybe it's my fault.

I know exaclty what I want, and now I think I know how to set it.

I'll clear all the axes assignments and start from scratch with a generic set up, and then I'll check for conficts.

Meanwhile I'll save the current ini and send it to you.

Regards.

[Pete Dowson]

I'm using FSUIPC to config them all, mostly options 3 and 5

So you have a mixture of some axes using SimConnect intensely and others now bypassing it?

I didn't realize option 4 was possible at all?!? I really wished that was possible, but I thought it wasn't.

4 is "Assigned in FSUIPC, using the FS control option, calibrated in FSUIPC".

Why wouldn't it be possible? That was actually the "norm" for some time -- the direct to FSUIPC calibration option was a much more efficient method I devised after I realised it was a bit stupid catching the axis in FSUIPC, converting it to the appropriate FS axis control, sending it to FS, intercepting it again then modifying its parameter for calibration and sending it on its way again. Effectively in FSX that's three SimConnect exchanges for every twitch of the axis!

Why did you ever think it wasn't possible to calibrate an FS axis when this has been the mainstay of all the joystick facilities in FSUIPC for years? And why, having read of the improvements and efficiency in the "direct to calibration" facility would you prefer to do it indirectly with three times as much simConnect traffic? Really the only reasons I can see of ever doing that are:

(a) for use with some add-ons which intercept the FS axis controls themselves for special treatment -- e.g. possibly some airbus implementations.

(b) to use one of the FS controls which aren't subject of FSUIPC calibration and which are therefore not listed in the "direct" drop-down.

I'm also using option 6 for the analogue flap switch lever, but I allocated the flap axis too, together with send controls upon ranges - maybe this causes the conflict.

Why is the flaps axis operating as well as controls sent in specific zones? I don't see any point in that whatsoever. Surely they'll fight each other? The option to send controls during parts of an axis range was to allow for things like Airbus throttle modes, or operating the Gear using an analogue lever rather than a toggle switch or button. The flaps operation is surely well provided for by the notch calibration facilities in the flaps calibration section?

Sorry for all this misjudgement, maybe it isn't all so clear in the manual, or maybe it's my fault.

Well, something must be way too clear in the manual if you've used such complex and rarely used facilities and almost got them working. I'm amazed really.

Meanwhile I'll save the current ini and send it to you.

Yes, because I still don't know how you are seeing, for example, the trims all reset to one extreme. Maybe the flaps problem is because of the conflict of the dual controls fighting, but that doesn't seem to apply to the trims which are, after all normal axes.

Regards,

Pete

[Muas]

Pete,

I sent you my old ini file, and a new one after configuring FSUIPC all over again.

Things look much stable now, there seems to be no conflict between axes, but, after an aircraft change, the aileron and rudder trims appear full deflected... after a little touch on their axes controls they wake up and return to neutral position - needless to say this is terrible in a "start on air" flight.

Maybe its because I set wide deadzones on them, they were a bit spiky... but no, when I restart on the same aircraft this doesn't occur - gotta be another reason.

[Pete Dowson]

I sent you my old ini file, and a new one after configuring FSUIPC all over again.

I'm not yet sure why the old one behaved exactly as it did, but there are certainly worrying things wrong with it, here:

[Axes]

0=0R,R1,D,21,0,0,0

1=0V,R1,D,27,0,0,0

2=0S,R1,F,66732,0,0,0

3=0T,R1,F,65760,0,0,0

4=0T,B,400,512,65595,0

5=0T,B,250,350,65597,0

6=0T,B,125,225,65599,0

7=0T,B,-512,-400,65603,0

8=1R,1,F,65696,0,0,0

9=1V,1,F,66387,0,0,0

10=1T,1,F,66388,0,0,0

11=2X,1,F,65695,0,0,0

12=2Y,1,D,2,0,0,0

13=2Y,B,16224,16383,65752,0

14=2Z,1,D,4,0,0,0

15=2U,1,D,5,0,0,0

16=2V,1,D,6,0,0,0

I've emboldened all the questionable settings. First, using RAW mode for all of the Joystick 0 axes is really bad. As it says in the documentation, RAW mode is only useful for software-controlled axes (like those from an EPIC or other program-controlled USB board), and is then useful for directly setting things like radio frequencies, MCP registers and bug positions, values which have to be precise. That is also the only time where a Delta of '1' comes in, to send every minute change through.

All of your uses are for analogue values, where such precision is a nonsense and all you are doing in causing a hundred or more times more messages flying about in FS and between FSUIPC and SimConnect and FS. Terribly inefficient and really quite prone to things going wrong.

To make things worse you have an odd mixture of some axes going direct to FSUIPC (and therefore avoiding SimConnect altogether) and others routed via FS controls, so using SimConnect three times per single change (as I explained before). It would be far more sensible to be consistent, and the most efficient by far would be to route everything direct with the only exceptions being (a) when you want to use a control not covered by FSUIPC's calibrations, or (b) when you are using an Add-On which needs to see and intercept the relevant FS control.

Finally, you have in two instances, Flaps and Elevator, not only assigned an axis control to an axis but also FS controls based on Ranges. This is fine for non-conflicting uses, but having the same axis send a FLAPS_SET control to FS and, in certain ranges, also send FLAPS_UP, FLAPS_! etc controls is rather flabbergasting. Why on Earth try to make FS do two things at once with the same lever? What were you thinking? It just makes no sense and I cannot imagine your line of thought there. I'm not surprised you got conflicts.

The other use of sending a control by an axis value is on the elevator:

12=2Y,1,D,2,0,0,0

13=2Y,B,16224,16383,65752,0

The control is "PARKING BRAKE". Why would you want to operate the parking brake with an extreme twist (16224-16383) of the elevator?

Anyway, enough of that. On to your new settings:

[Axes]

1=0V,32,F,66731,0,0,0

2=0S,32,F,66732,0,0,0

3=0T,1

4=0T,B,-16384,-16384,65595,0

5=0T,B,-10648,-10613,65597,0

6=0T,B,-5976,-5942,65599,0

7=0T,B,16383,16383,65603,0

8=1R,128,F,65764,0,0,0

9=1V,128,F,66387,0,0,0

10=1T,128,F,66388,0,0,0

11=2X,128,F,65763,0,0,0

12=2Y,128,F,65762,0,0,0

13=2Y,B,16288,16383,65752,0

14=2Z,128,F,65765,0,0,0

15=2U,128,F,66291,0,0,0

16=2V,128,F,66292,0,0,0

0=0R,32,F,65766,0,0,0

First, I still don’t understand why you don’t use the FSUIPC flaps notch calibration facility for your generic flaps, instead of the controls mapped to axis values, but at least you aren’t sending the Flaps axis value at the same time, so it is better.

Second, why are you using such a low delta, like 32, for your aileron and rudder trims? This implies you have hardware axes capable of 1024 different positions, which would in turn imply they are extremely high precision and very very expensive. No commercial axis system I know of it capable of more than a resolution of something like 200 positions, and usually much less, less than 100 and most around 40 or 50. The default Delta of 250 allows 128 positions, but even that can be too low if there's any sign of jitter on the axes. By setting a delta too low you are simply wasting your PC's time with many spurious values which have either no effect or (because of jitter) an unwanted effect.

Third, you still have extreme elevator values toggling the parking brake. I find that fascinating. Care to explain?

Last, but probably not least, you are now using FS controls to the exclusion of any directness. Therefore every operation here involves lots of SimConnect activity (3 exchanges per axis change), so you are really gaining nothing by using FSUIPC assignments and certainly you are not benefitting at all from any of the improvements I made recently. I'm not sure why you've done this -- it is perfectly legitimate, just a bit mystifying.

Things look much stable now, there seems to be no conflict between axes, but, after an aircraft change, the aileron and rudder trims appear full deflected... after a little touch on their axes controls they wake up and return to neutral position - needless to say this is terrible in a "start on air" flight.

This is because, in order to calibrate axes coming from FS, as all yours are (because you directed them back to FS), FSUIPC has to place SimConnect intercepts on them. But it must only do this on the ones which are in use -- otherwise it risks wrecking things for add-ons like LevelD 767 and PMDG aircraft. Each time you load a new aircraft it clears down all the intercepts and waits for axes to be used again, so that it doesn't keep intercepting axes it shouldn't. How an axis behaves BEFORE the intercept is in place is in accordance with what FS makes of its value, without the benefit of any FSUIPC calibration or Reversal or Mapping, etc. FSUIPC's intercept will occur after the one reading, so it doesn't persist -- unless of course a second reading doesn't arrive (you don't move the axis and there's no jitter), in which case you might have a problem.

This can be solved in one of two ways, one better than the other.

The best way is to use Direct to FSUIPC calibration mode for every axis, all of them. This way there's no worries about interception, because they don't need intercepting, and, with the recent changes, SimConnect is not even used once, let alone three times per axis change as you have at present.

On changes of aircraft you may still need to move a lever to get a reading set though, unless you take great care to save a starting Flight for each aircraft with things set normally, and load the aircraft by loading the flight rather than by selecting an aircraft. I think this can apply no matter how you use your axes.

The other way is to tell FSUIPC to intercept axes regardless. If you are not using any add-ons which this would adversely affect, then this will work too. It doesn't make anything more efficient though. To do this use this parameter, documented in the Advanced users guide:

AxisIntercepts can be set to ‘Yes’ to force the intercepting and forwarding of axis controls by FSUIPC4, even if this action is not needed for FSUIPC4 calibration (where it will be done automatically in any case). This action will be needed for some “fly-by-wire” aircraft only.

Regards

Pete

[Muas]

Pete, sorry for all this mess, I sent you my last (I hope) ini file just to check if that is the more efficient way of setting axes through FSUIPC.

First, I still don’t understand why you don’t use the FSUIPC flaps notch calibration facility for your generic flaps, instead of the controls mapped to axis values, but at least you aren’t sending the Flaps axis value at the same time, so it is better.

Beacause its more reliable on my analogue swithch arrangment, thats all. I tested it using the detents calibration facility, but it didn't work consistenly. As I told before, its a 4 position switch, not a real axis lever (a Telecaster switch - ironicaly in the fifties electric guitar parts came from post-war spares from the aviation industry, now I'm using one of those in my pit :wink:). As for a jet liner I agree the detents calibration facility is the most efficient way to do it, and I got set that way for specific aircraft like the 737.

Second, why are you using such a low delta, like 32, for your aileron and rudder trims?

Your're right, I corrected that for 128, thats the minimum value my axes read.

Third, you still have extreme elevator values toggling the parking brake. I find that fascinating. Care to explain?

Well, I'm kinda use to it - I have no such a lever for the parking brake, an a on/off switch doesn't seem right, and it helps for that short runway take-offs, where you apply full power with parking brakes on an then release it without taking hand off yoke, just a by depressing it. No such a big deal, and it works perfectly.

Last, but probably not least, you are now using FS controls to the exclusion of any directness. Therefore every operation here involves lots of SimConnect activity (3 exchanges per axis change), so you are really gaining nothing by using FSUIPC assignments and certainly you are not benefitting at all from any of the improvements I made recently. I'm not sure why you've done this -- it is perfectly legitimate, just a bit mystifying.

That wasn't clear for me. Now I've got them all set through FSUIPC calibration.

...[the axes interception issue] can be solved in one of two ways, one better than the other.

The best way is to use Direct to FSUIPC calibration mode for every axis, all of them. This way there's no worries about interception, because they don't need intercepting, and, with the recent changes, SimConnect is not even used once, let alone three times per axis change as you have at present.

On changes of aircraft you may still need to move a lever to get a reading set though, unless you take great care to save a starting Flight for each aircraft with things set normally, and load the aircraft by loading the flight rather than by selecting an aircraft. I think this can apply no matter how you use your axes.

The other way is to tell FSUIPC to intercept axes regardless. If you are not using any add-ons which this would adversely affect, then this will work too. It doesn't make anything more efficient though. To do this use this parameter, documented in the Advanced users guide:

AxisIntercepts can be set to ‘Yes’ to force the intercepting and forwarding of axis controls by FSUIPC4, even if this action is not needed for FSUIPC4 calibration (where it will be done automatically in any case). This action will be needed for some “fly-by-wire” aircraft only.

Using all axes through FSUIPC calibration does seem to solve the problem - on flight start, trim axes are in neutral position now :D

Cheers.

[Pete Dowson]

I have no such a lever for the parking brake, an a on/off switch doesn't seem right, and it helps for that short runway take-offs, where you apply full power with parking brakes on an then release it without taking hand off yoke, just a by depressing it. No such a big deal, and it works perfectly.

Hmmm. Interesting idea! ;-)

Using all axes through FSUIPC calibration does seem to solve the problem - on flight start, trim axes are in neutral position now :D

Good. So all set for some good flying now, eh?

Regards

Pete

[snomhf]

Now that the smoke is clearing a little bit on all this, :) I've been wanting to ask why the default for assigning axes is "Send to FS as normal axis" rather than direct. I've only been using the registered FSUIPC for a few months. Anytime you begin to use an unfamiliar program, you tend to use whatever defaults are already there and then fine-tune later. Is there a reason why "direct" is not the default? Course, I would have started this thread several months earlier if that were the case. :D

No biggie. Just curious. Loving this direct mode!

Thanks again

-mark

[Pete Dowson]

've been wanting to ask why the default for assigning axes is "Send to FS as normal axis" rather than direct.

Because the axis assignments facility was designed to allow folks to assign to all sorts of FS controls which take parameters (all axis types and lots of "SET" types which also can take an analogue or other value), all of those which cannot be assigned in FS itself. This is the "axis" equivalent, if you like, of the Buttons and Keys assignments, where the range of FS controls which can be assigned to far exceeds those provided in FS's own assignments.

The options to go direct to the FSUIPC calibrations, bypassing FS altogether, was added as a more efficient alternative, but it only usable for those few axis controls for which FSUIPC calibration is provided. As an extra facility is has obviously come into much more use, of late, especially with FSX the way it is, but this was never the main purpose of the axis assignments facilities -- it was, as I say, for access to all possible axis controls, plus, of course, the possibility of different assignment for different aircraft.

As such, really, when it was designed, I only thought it would be a minority of users using it -- cockpit builders or folks with sets of, say, helicopter controls on one side and aircraft controls on another, wanting to swap easily between them. I'd assumed folks simply wanting to use FSUIPC's calibration facilities would continue to use normal FS assignments -- those facilities have been in FSUIPC for many years whereas the axis assignments facilities are quite recent, relatively speaking.

Regards,

Pete