I'm trying to use the FS's wheel for to trim 3 axis

[Acesmaker]

Hello to all:

I'm a new and very happy owner of a CH set (FS+PT+PP) since two weeks ago. Along this time I was learning how to use the CMS editor reading carefully the help manual and this forum, in order to make a script by myself. But, being the CMS editor a powerfull tool, thanks to it I found my own skills limits as "programer".:D

My idea is to use the the FS's wheel (JS1.A3) for to trim the 3 axis in "IL2-1946": Pitch (elevator) in Mode 1, Yaw (rudder) in Mode 2, and Roll (ailerons) in Mode 3.


My first steps were:

1) To asign the JS1.B3 button for to switch the Modes.
2) To set up the CMS.A1 axis (Up/Down control type, steps=80, Inc and Dec keys as they're asigned in the game's control panel), related with JS1.A3 through the script for the 3 Modes.
3) To asign the JS1.B4 button for release purposes.

My intention is to profit the whole range of the trim in each axis up to the limits hardcoded in the sim's engine.
I.e.: If I want to trim the elevator for to get a steady and positive rate of climb (ROC), I could start from the lowest position of JS1.A3 and moving it forward up to obtain the desired ROC. When the aircraft reaches the desired altitude, possibly I wold reset the trim moving the wheel backward up to get a neutral ROC, or directly using the Neutral Trim assigned button (JS1.B9 in this case) and retriming from the last wheel's position as if it were the actual (neutral) starting point.

Flying in full realistic mode, certain planes (as the He-111) require to trim the 3 axis in diferent degrees for each instance of the flight: take off, climb, cruising flight, bomb run and aiming, return to base without payload, glide to the last waypoint, and landing.

The problem is that I have one only device to perform the trim of the 3 axis and, switching from one Mode to other, my script will read the last value of the wheel and will change the actual setting of the actual axis.
Atempting to avoid that, I'm using de JS1.B4 button in order avoid unwanted tracks and to permit them after the Mode is changed, through this script:


script

IF (JS1.B4)
THEN
IF ([CURRENTMODE==MODE1] AND [A1!=JS1.A3])
THEN
A1=JS1.A3;
CMS.A1=A1;
ENDIF
IF ([CURRENTMODE==MODE2] AND [A2!=JS1.A3])
THEN
A2=JS1.A3;
CMS.A1=A2;
ENDIF
IF ([CURRENTMODE==MODE3] AND [A3!=JS1.A3])
THEN
A3=JS1.A3;
CMS.A1=A3;
ENDIF
ENDIF

endScript

Till now, with this script I solved the problem of the "unwanted automatic retriming" each time I switch the mode.
Also I can get a new neutral starting point for the actual axis, regardless of the wheel's position, each time I push the JS1.B9 button (Neutral Trim) in the actual chosen Mode.
But... when I push JS1.B4, inmediately after a Mode switching, other "unwanted retriming" is achieved before I start to move the wheel: first the trim makes the previous value, and after it tracks my desired seting... what results in an impredictable flying.:wacko:

I was trying to use diferent logical devices to solve the issue within more complex scripts, but without a satisfactory result (probably by my very low
skills managing that devices, as I tell you before).

The goal what I'm looking for would be:

a) The starting point for to trim in each mode should be any between the stop points of JS1.A3 (both included), regardless if JS1.A3 matches exactly the CMS.A1 previous value after a Mode switching, or not.
b) Any new trim value, within each Mode, should change only when JS1.B4 is pressed and JS1.A3 is moved in any direction.

Any sugestion to get it will be well apreciated.:)

Thanks in advance, and kind regards.:salute:

[Bob Church]

Hi Acesmaker,

It's really not possible to avoid the jump that way. You're telling it, for example, if A1 != js1.a3 then set a1 = js1.a3, there's a change in a1, that's transferred to cms.a1, and since the values are different the CM is going to see the axis as having moved and will generate the pulses that the movement calls for.

I've had some luck doing it a couple of different ways, you might want to give them a try. Probably the one most likely to work is this. When you set the js1.a3 value into the a1 axis (or whichever you happen to be trimming at the time), cms.a1 and a1 have the same value. If you switch modes, trim another axis, then come back to the a1 mode again, a1 and js1.a3 don't match. The way you've got it set up, a1, and thus cms.a1 will jump to the new value and the CM will generate the characters necessary to get it to the new setting, you get that "jump".

A better way is to check and see if js1.a3 is greater than or less than a1 at the time. If it's greater than a1, then don't start moving the a1 value until js1.a3 is less than or equal to a1. Likewise, if js1.a3 is less than a1, don't start tracking js1.a3 until it's greater than or equal to a1. That way, there is no jump. You have to roll js1.a3 until it crosses a1, at which point a1 will lock to js1.a3 and the trim change will start from where you left it rather than immediately jumping to the current value and going from there.

The main problem with that is that you don't know whether js1.a3 is greater than or less than a1 to begin with, so if you wanted to trim nose down for example, but js1.a3 was already on the nose down side of the a1 value you would need to first move the wheel in the direction that would trim nose up until js1.a3 crossed the current a1 value, then it would lock and you could push the js1.a3 in the nose down direction. It's a bit confusing, you try to immediately trim nose down and since it doesn't cross the current a1 value nothing ever happens, the values never cross and so js1.a3 never "syncs" with a1.

One way I found that improved the situation was to slowly, perhaps on the CLOCKTICK or using an INTERVAL timer, started moving a1 a count at a time toward the js1.a3 value. That way, if you're on the nose down side already, you'll know it since it will start trimming nose down immediately, though slowly, and you have an indication that you need to roll the wheel the wrong way at first, or the slow trim may be fast enough in which case you can just let it work it's way down and you can bring js1.a3 back up to stop it.

Either way, it's not the greatest way to handle it, but it does avoid that sudden large jump in trim when you first switch modes or push the button.

What about just using buttons rather than js1.a3? One could generate "up" character, a second could generate "down" characters, the characters used would depend on the mode. Then when you switch modes nothing at all would happen until you pressed one of the trim buttons, you could hold it down or click and release it until you had the trim you wanted and you wouldn't need to worry about hitting max or min on js1.a3, jumps, or anything. You're already sending characters so it's not analog trim anyway. You might even put it on a hat switch for up/down elevator and left/right yaw, maybe use a shift button on left/right to get the roll axis.

There's also an autotrim example in the Users Guide. You use the stick and rudder to get you where you want to be, then hold down a button, that holds the controls in that position, and you recenter the axes. Once the axes are centered, you release the button and the trimmed position is held. To "untrim" everything, you just need to center all the axes and click that same button. The sample only covers X and Y, but it's easy enough to extend it to include yaw.

So, some other ideas. It's a problem I've played with several times but trying to change multiple trims (or multiple anything, really) based on modes and a single axis has never worked very well. There's always that jump when the value changes that's just about impossible to get around entirely.

Best regards,

- Bob

The StickWorks
http://www.stickworks.com

[Acesmaker]

Hello Bob:

First of all, I thank you very much your gentle, extense and enlighten answer: being a summer's Sunday, it's many more dedication than reasonably I could expect.

Well...

About the "Autotrim" example of the Guide Manual, it's very interesting really. But it has the incovenient of to apply the trim to all the models into the sim IL2: since they're historically modeled (well... as historically as possible), some of them are fully trimable, others can be trimmed on 1 or 2 axis, and others are not trimabble at all.
So, I should do a map for each set of planes regarding with their trim availability, if I want to play "historically".

The use of buttons for to trim, using the same set in diferent modes for each axis, was my first map: I've been using it while I was attempting to perform a script for the JS1.A3 wheel.
But buttons, employed for trim purposses, have some problems (as far as I could check, for IL2 at least):

1) In IL2 each step of trim is internally delayed. That delay is unknown; but, apparently, it works like an ON DELAY TIMER. But this timer starts only if the input (regardless if such input comes from the keyboard or an external device) is as long as certain unknown time. It means: if you hit fastly and repeatedly the key set or button for to trim, you could have not trim effects after all.
And, on the contrary, whith an only but longer hit, you could have a full trim.
So, regarding of how long is your input, you could have 1, 2, 3 , 5 or more steps, up to the hardcoded trim limits.

2) With buttons (as well with the keyboard), one never can be sure how much the plane has been trimmed. The best way to know it, is watching the variometer and the turn & bank indicator, it's true. But many planes have other mechanical trim indicators to help the pilot: see the cockpit of the de Haviland Mosquito, i.e. On the right hand of the instruments panel, near of the gunsight, you will can see a rudder trim indicator. And it works! B)

Then, attempting to fix that issues, I decided to give a try to the FS wheel for to trim all the axis, maping the JS1.A3 with the CMC editor.
The main problem is the jump of the trim when I switch from a mode to other.
But I found the wheel is more precise and accurate than buttons and keys. and I decided to attempt to fix the jumps through de CMS.

However, that wheel by itself is not a good visual reference: it has not a mark as the calibration wheels have... and I can't undestand why, if the primary function of the JS1.A3 was as throttle... and one always need a quick visual reference of that device (adding unnecesarily one spare part more).

I will give a try to the ways which you have suggested in the first part of your post.;)

Thanks again, and best regards.

[Bob Church]

Hi Acesmaker,

Okay. I don't know all the ins and outs of the IL2 trim system so you know best there. It's just something I've tried, usually with multiple throttles, and it's always been kind of a "not-so-good" solution.

Anyway, best of luck with your efforts, and if I can be of any help, don't hesitate to ask!

Best regards,

- Bob

The StickWorks
http://www.stickworks.com

[Dace]

This is the trimming script I use for pretty much all my simming.
Its pretty complex.. but it works quite well so I havent bothered to do too much to it.

Bob might be able to spot some sillyness in my code and shorten it a whole lot, and id be greatefull :-D but ... as I said, it works.

What it does is use a 4way hat on my combatstick for all trimming.
A single click will inc the trimming axis by trim_slow_amt. Then if the button is held it will start repeating adding that amount. If the button is held longer it will switch to fast trimming, this uses a larger ammount and quicker repeat. so ... incase your one wing get blown to hell you can still trim it straight in less than half an hour :-) ... the script still uses three trimming axes so it will always be historically correct.

Oh right. I have the extra set of shifted action set to rest trim. This resets all trims... but its usually not too time consuming to set them straight again.


// Joy buttons used by script
//shift button used to switch between rudder/aileron and
//elevator and reset
%define btn_shift js1.b4

%define joy_trim_ele_up js1.b9
%define joy_trim_ele_down js1.b7
//Rudder and Aileron share the same buttons
//but it should be ok if you have an extra sets
%define joy_trim_rud_left js1.b10
%define joy_trim_rud_right js1.b8
%define joy_trim_ail_left js1.b10
%define joy_trim_ail_right js1.b8

// Internal bit registers used by the script
%define first b1
%define trimming b2

// Logical devices used by script
%define trim_slow d1
%define trim_fast d2
%define key_hold d3

// Constants used by script
%define trim_slow_delay 0
%define trim_slow_rep 1
%define trim_slow_amt 1

%define trim_fast_delay 60
%define trim_fast_rep 2
%define trim_fast_amt 4

script

if( not first ) then
first = true;
trimming = false;

ax_trim_rud = 128;
ax_trim_ail = 128;
ax_trim_ele = 128;
endif

//trimming
trimming = joy_trim_ele_up or joy_trim_ele_down or joy_trim_ail_left or joy_trim_ail_right;
timer( ONDELAY, trim_slow, trim_slow_delay ) = trimming;
timer( ONDELAY, trim_fast, trim_fast_delay ) = trimming;

if ( trim_fast ) then
sequence
while( joy_trim_ail_left and not btn_shift );
ax_trim_ail = ax_trim_ail - trim_fast_amt;
delay( trim_fast_rep );
endsequence

sequence
while( joy_trim_ail_right and not btn_shift );
ax_trim_ail = ax_trim_ail + trim_fast_amt;
delay( trim_fast_rep );
endsequence

sequence
while( joy_trim_ele_up and not btn_shift );
ax_trim_ele = ax_trim_ele - trim_fast_amt;
delay( trim_fast_rep );
endsequence

sequence
while( joy_trim_ele_down and not btn_shift );
ax_trim_ele = ax_trim_ele + trim_fast_amt;
delay( trim_fast_rep );
endsequence

sequence
while( joy_trim_rud_left and btn_shift );
ax_trim_rud = ax_trim_rud - trim_fast_amt;
delay( trim_fast_rep );
endsequence

sequence
while( joy_trim_ail_right and btn_shift );
ax_trim_rud = ax_trim_rud + trim_fast_amt;
delay( trim_fast_rep );
endsequence
else
if ( trim_slow ) then
sequence
while( joy_trim_ail_left and not btn_shift );
ax_trim_ail = ax_trim_ail - trim_slow_amt;
delay( trim_slow_rep );
endsequence

sequence
while( joy_trim_ail_right and not btn_shift );
ax_trim_ail = ax_trim_ail + trim_slow_amt;
delay( trim_slow_rep );
endsequence

sequence
while( joy_trim_ele_up and not btn_shift );
ax_trim_ele = ax_trim_ele - trim_slow_amt;
delay( trim_slow_rep );
endsequence

sequence
while( joy_trim_ele_down and not btn_shift );
ax_trim_ele = ax_trim_ele + trim_slow_amt;
delay( trim_slow_rep );
endsequence

sequence
while( joy_trim_rud_left and btn_shift );
ax_trim_rud = ax_trim_rud - trim_slow_amt;
delay( trim_slow_rep );
endsequence

sequence
while( joy_trim_ail_right and btn_shift );
ax_trim_rud = ax_trim_rud + trim_slow_amt;
delay( trim_slow_rep );
endsequence
endif
endif

sequence
wait( (( joy_trim_ele_up ) or ( joy_trim_ele_down )) and btn_shift );
ax_trim_rud = 128;
ax_trim_ail = 128;
ax_trim_ele = 128;
endsequence

endscript

[Bob Church]

Hi Dace,

>> Bob might be able to spot some sillyness in my code and shorten it a whole lot, and id be greatefull :-D ... <<

I looked at it, I don't see anything that's really going to save some space. I might look at the "IF/THEN" blocks around the sequences. They can be a little chancy because if the IF/THEN/ELSE fails, the sequences stall because the DELAY statements don't run until the IF/THEN/ELSE starts running again. Maybe set a flag going in that keeps it running until it's complete. OTOH....

>> ,,, but ... as I said, it works. <<

in the end, that's all that matters. If you're not having trouble with it, I'd just leave it alone. :)

Best regards,

- Bob

The StickWorks
http://www.stickworks.com

I look

[Dace]

Cool... I am not really sure about sequences yet ... so I though I might have done something glaringly wierd... but if you say its cool, then ill take your word on that :-P.

Im trying to figure what Im gonna do to get a Ka-50 in the air with only 1 mfp and a combat stick at the moment... so hehe... I have plenty of this kind of thing waiting.

[Seeker]

Working in a similar vien: trying to get one axis to do two things, would it possible to have the Pro throttle act as a throttle unshifted, and as a prop pitch control shifted?

[Dace]

Yes it should be possible...

Although you will have to be carefull when you switch between them so that the axis jump doesent mes with whatever you had set up.

I think there is actually a example in the script help file for switching between axis on two devices that should be fairly similar to what you are trying to do.

[Bob Church]

Hi Seeker,

It is possible, but as Dace points out there can be a jump when you switch values. I've had some luck by setting up the logic so the shift isn't made until the lever crosses the current value, so if it's at 100 and the other axis is at 150, when you make the switch the transition doesn't occur until you get the lever to the right position. That way, the jump doesn't occur, when you finally get control it's because the lever and the value are the same.

Best regards,

- Bob

The StickWorks
http://www.stickworks.com