Dual Controls

[BAW019]

Pete,

Can you clarify something for me. I've set up dual controls and they seem to work fine. Having read the stuff in the Advanced User guide I decided to assign Axis Prop 3 and 4 to my second yoke but I'm bothered by the fact that if I want to fly a 4 engine prop plane the second yoke will play havoc with it's props. My second set of rudder pedals are on their way so 'll need to borrow even more axiis when they arrive but there really aren't that many axiis to steal !! When the guide says to assign an unused control that FSUIPC later "pinches" I'm assuming you mean an axis control, is that correct (as opposed to any of the other control types)? The guide says to assigin them in FSX is that correct? Even without doing so FSUPIC display the axis inputs in the Joystick calibration tab, even if it doesn't do the "max value wins"thing.

I tested this earlier on today with brake axiis -assigning them in FSX then adding the axis control codes to the Joystick Calibraion sections in the FSUIPC ini (I have several for different planes). But in a taxiing test moving the second yoke caused the brakes to be applied. It's always possible that I goofed somewhere (as usual!). When you say FSUIPC "pinches" the axis, is it supposed to prevent the original assingment being sent to FSX or would you expect both the original and the FSUIPC dual control axiis to be sent simultaneously?

Like I said it's working now but only because I'm using prop 3 and 4. I used the King Air 350 quite a bit so I can't afford to use props 1 or 2 when my pedals arrive and I haven't started to think yet about how to implement the toe brakes on the CH Pro Pedals - is it simlpy another axis to be pinched?

Thanks for anything you can add to clarify how it all works,

Ian

[Pete Dowson]

Can you clarify something for me. I've set up dual controls and they seem to work fine. Having read the stuff in the Advanced User guide I decided to assign Axis Prop 3 and 4 to my second yoke but I'm bothered by the fact that if I want to fly a 4 engine prop plane the second yoke will play havoc with it's props.

Not if those FS axes are diverted to other uses. You can either use them for Props or for other things, not both.

My second set of rudder pedals are on their way so 'll need to borrow even more axiis when they arrive but there really aren't that many axiis to steal !! When the guide says to assign an unused control that FSUIPC later "pinches" I'm assuming you mean an axis control, is that correct (as opposed to any of the other control types)?

Yes. Because they have to have a parameter (the axis value). non-axis controls are simple push-button types. No values associated with them. Axis controls have a value associated. That's the point.

There are many many axis controls. How are you possibly running out of them? Both FSX and FS9 list 26 in their assignment capabilities -- if you assign to FS controls via FSUIPC there are lots more (all the others FS doesn't bother to list for you). Surely you cannot possibly be "running out"?

The guide says to assigin them in FSX is that correct?

If you want FSUIPC to "arbitrate" for the maximum deflection/value, yes, either in FS itself, or at least to FS controls in FSUIPC.

Of course using FSUIPC axis assignments you can assign any axis to any control, as many times as you like, in any case. But then you don't get arbitration -- you need to be very sure any currently unused axis is "quiet" -- i.e. either parked in a dead zone or not liable to any jitter at all, as the last change is the one which is used.

Even without doing so FSUPIC display the axis inputs in the Joystick calibration tab, even if it doesn't do the "max value wins"thing.

Sorry, this part makes no sense to me. Can you re-phrase?

When you say FSUIPC "pinches" the axis, is it supposed to prevent the original assingment being sent to FSX

Of course -- it simply intercepts the original control and uses it for something else. This is done all the time anyway, as for instance if you "map" the one generic throttle to 4 others, or other such combinations.

... or would you expect both the original and the FSUIPC dual control axiis to be sent simultaneously?

No, of course not. What on Earth would be the point of that?

It is all very simple. FSUIPc has to intercept the controls in any case if you are calibrating in FSUIPc -- how else do you think it can do that, change the values used? It is therefore just as easy for it to forward them on as something else entirely. It is doing it all the time. Think it through. it is all quite simple and logical. The only base stipulation is that FSUIPC is calibrating, so processing, the axes.

Don't forget that with FSUIPC assignments you can have the same axes used for different things according to the aircraft being used. I hardly think any one is going to have enough real "axes" to ever run out of the FS possibilities.

Regards

Pete

[BAW019]

It is all very simple

Maybe so but if it was clear I wouldn't need to ask!

No, of course not. What on Earth would be the point of that?

I'm asking the question from experience. Having re-checked it seems to be doing just that - sending the joystick signal to both axis. To clarify: In FSX's controls dialog I've assigned joystick #2 axiis to Throttle 3 and Throttle 4. In the FSUIPC.INI file I've added the lines AileronB=66426 and ElevatorB=66429 to the [JoystickCalibration] section(s). Having restarted FSX I find that joystick #1 works just as before (ailerons and elevators) but if I watch the throttle quadrant joystick #2 clearly opens the two throttles as well as operating the ailerons and elevators. Which is why I asked for help. I don't think I missed a step from the instructions - where did I go wrong?

Cheers

Ian

[BAW019]

Aha! Just spotted something. If you have a second take a look at http://www.ianniblo.pwp.blueyonder.co.uk/homepage/fsuipc.wmv, it's a 10 sec vid of me using FSUIPC in FSX. I'm exclusivley using joystick #2 and you can see that having gone into the FSUIPC dialog the first time each stick axis is used it invokes the originally assigned control (throttles in this case) as well as the intended dual control assignment. I then reset the throttle and you can see that the stick appears to operate fine after that - no throttle action.

It seems to be repeatable and you don't even need to go to the Joystick Calibration tab or indeed click OK. Even just opening FSUIPCs form and clicking Cancel will reproduce the behaviour.

Ok well that's a solution I think - I just need to remember to 'prime' each axis of the dual controls if I visit the FSUIPC dialog (using one axis doesn't 'clear the board' for the other axiis. You need to do one at a time to clear the behaviour for each)

All the best

Ian

[Pete Dowson]

In FSX's controls dialog I've assigned joystick #2 axiis to Throttle 3 and Throttle 4. In the FSUIPC.INI file I've added the lines AileronB=66426 and ElevatorB=66429 to the [JoystickCalibration] section(s). Having restarted FSX I find that joystick #1 works just as before (ailerons and elevators) but if I watch the throttle quadrant joystick #2 clearly opens the two throttles as well as operating the ailerons and elevators. Which is why I asked for help. I don't think I missed a step from the instructions - where did I go wrong?

Hmmm.. Are they calibrated in FSUIPC? There were a lot of changes to avoid intercepting and *stopping* axes unless you actually calibrate, because othjerwise it was upsetting some complex aircraft like the Level D 767.

Otherwise, maybe you've found a bug. I'd need to do some more checking to see. I doubt if many folks use these facilities, maybe you're the first with FSX.

Pete

[Pete Dowson]

It seems to be repeatable and you don't even need to go to the Joystick Calibration tab or indeed click OK. Even just opening FSUIPCs form and clicking Cancel will reproduce the behaviour.

Ok well that's a solution I think - I just need to remember to 'prime' each axis of the dual controls if I visit the FSUIPC dialog (using one axis doesn't 'clear the board' for the other axiis. You need to do one at a time to clear the behaviour for each)

Hmm. I don't understand any of that. Certainly, it is possible that the axes need MOVING so that a value i detected *before* FSUIPC starts mapping them -- so initially, the first movement of the axis, might not do as you expect. This is because FSUIPC doesn't intercept any axes unless it detects that they are used. Again, this was a safeguard added to avoid problems with complex aircraft.

But normally all that sorts itself out automatically within the first few seconds of so of being "read to fly". You shouldn't need to do anything, unless your axes are so stable they give no signals until moved.

I don't understand why opening and closing an options dialogue will do anything special. That's a puzzle. I'll have to look into that.

Regards

Pete

[Pete Dowson]

But normally all that sorts itself out automatically within the first few seconds of so of being "read to fly". You shouldn't need to do anything, unless your axes are so stable they give no signals until moved.

Okay, I've checked all this, and it all operates as I thought it did -- basically, since version 4.15 (July last year) no axes are intercepted UNTIL some action on them is detected. This was done as a precaution because problems were occurring on the more sophisticated add-on aircraft which use the controls themselves.

As I said, mostly this would go unnoticed, and the "action" is often seen during the FS start-up phase so would have no effect worth noting. However, when they are cross-assigned like this they may initially, for one or two readings only, operate directly in FS without being intercepted and so re-directed.

Testing here I can see it happening with your sort of cross-assignment, but it only occurs the once and then it is all okay. I don't have to go into FSUIPC options or do anything other than waggle the axes. I think you will find the same -- I would guess what is happening when you call up a menu is that because FSX is suspending the axis scanning whilst in menus and re-instating it on exit (which I know it does), is this which generates thje initial reading sufficient to make FSUIPC4 do the interception.

I hope this explains things for you?

Regards

Pete

[BAW019]

Yep, many thanks Pete, mystery solved!

Ian