PDA

View Full Version : A complete trimming implementation


MarkShot
09-01-2004, 09:59 PM
First, a little background ... I have been using TM controls since around 1992; before they were even programmable. I have a TM Cougar set up, but recently bought a set of CH controls. The Cougar's strong joystick tension (even reduced by changing springs) was not very friendly to my arthritis. So, I purchased CH controls, since my requirements were lots of buttons, programmability, and a light touch.

I decided to post this code here, since I was really suprised after purchasing my CH controls to find that there wasn't much user community support on the Web. So, as I show of support, I thought I might publish some useful code and insights.

Well, I embarked on my first CMS script programming exercise. It was for RBII3D. Some of those WWI planes require very significant control deflections to maintain level flight. Of course, WWI planes had no trimming functions and having to fly with extreme deflection all the time does get tedious (even if it is realistic). Although the FS does have two trim wheels, they are not very convenient to use.

The programming sample in the help file does have a trim function, but it is of very limited utility. The trim function presented does provide for defining a new logical center point for the controls. However, it does not provide the full range of axis values to the simulation being operated. Once trimmed, deflecting the stick in one direction will quickly reach the axis bound before the physical bound is reached, and deflection in the other direction will not reach the axis bound at all despite the physical bound being reached.

One can quickly see that the short comming of the example can easily be rectified by establishing a ratio between physical deflection of the stick and the logical values generated to the game after the new center points are taken into consideration. I tried for quite a while to implement that and couldn't understand why my program was failing. Then, it finally dawned on me (remember this was my very first project) that the CMS division operation only supports integral division (meaning it drops any decimals). This left me stuck as to how I could establish ratio I needed and perform the necessary scaling of physical deflection to logical deflection.

Finally, it dawned on me that if I performed all calculations scaled by a factor of ten that I could achieve reasonable accuracy despite only having integral division. Thus, physical to logical ratios could look like 1:1.3; meaning deflecting the physical stick by 1 unit would generate a logical value defection of 1.3. As can be seen, this yields calculation accurate to tenths. It was also necessary to introduce a small fudge factor into the calculations to address the truncation in the hundredths due to the simulated fractional division. This guaranteed that the full bounds of logical output will be available for control while still being scaled across the physical deflection.

The code is not very documented as I never intended to publish it and it is only my first effort.

The code supports the trimming of joystick axises and rudder.

(1) JS1.B7 is a quick trimming button. Deflect the controls and press the button. While holding it, recenter the controls and a new logical center is recorded.

(2) JS1.B5 is a quick reset button. Press it and all trimming is canceled.

(3) JS2. along with JS1.B4 {shift} are trimming adjustment buttons which allow you to slowly push the trim in either direction along the axis. Thus, you can fine tune the trim established with JS1.B7.

(4) JS2.B29 is a temporary trim cancelation when held pressed. This is useful if your plane is in a spin and you want to temporarily eliminate all trim while you deal with the spin.

(5) JS1.B3 also functions as a temporary trim cancellation, but it's implementation was specific for way RBII3D behaves. This DirectX button in RBII3D also uses the joystick to pan viewing {the only game that ever did it this way}. Thus, you need to temporarily disable trimming while panning, and your plane should have the auto-pilot mode enabled so it doesn't flip over.

ツ* IF ( NOT JS1.B7 ) THEN

ツ* ツ* IF ( [ A1 == 0 ] OR JS1.B3 OR JS2.B29 ) THEN
ツ* ツ* ツ* CMS.A1 = JS1.A1;
ツ* ツ* ELSE
ツ* ツ* ツ* IF ( [ JS1.A1 == 128 ] ) THEN
ツ* ツ* ツ* ツ* CMS.A1 = JS1.A1 + A1;
ツ* ツ* ツ* ENDIF
ツ* ツ* ツ* IF ( [ JS1.A1 < 128 ] ) THEN
ツ* ツ* ツ* ツ* A11 = A1 * 10; // scaled - offset
ツ* ツ* ツ* ツ* A21 = A11 + 1280; // scaled - left range
ツ* ツ* ツ* ツ* A31 = A21 / 128; // scaled - left ratio
ツ* ツ* ツ* ツ* A41 = JS1.A1 * A31; // scaled - left deflection
ツ* ツ* ツ* ツ* CMS.A1 = A41 / 10; // actual - deflection output
ツ* ツ* ツ* ENDIF
ツ* ツ* ツ* IF ( [ JS1.A1 > 128 ] ) THEN
ツ* ツ* ツ* ツ* A11 = A1 * 10; // scaled - offset
ツ* ツ* ツ* ツ* A21 = 2550 - A11 + 1280 - 90; // scaled - right range (rounding correction)
ツ* ツ* ツ* ツ* A31 = A21 / 128; // scaled - right ratio
ツ* ツ* ツ* ツ* A41 = 1280 + A11 + ( ( JS1.A1 - 128 ) * A31 ); // scaled - right deflection
ツ* ツ* ツ* ツ* CMS.A1 = A41 / 10; // actual - deflection output
ツ* ツ* ツ* ENDIF
ツ* ツ* ENDIF

ツ* ツ* IF ( [ A2 == 0 ] OR JS1.B3 OR JS2.B29 ) THEN
ツ* ツ* ツ* CMS.A2 = JS1.A2;
ツ* ツ* ELSE
ツ* ツ* ツ* IF ( [ JS1.A2 == 128 ] ) THEN
ツ* ツ* ツ* ツ* CMS.A2 = JS1.A2 + A2;
ツ* ツ* ツ* ENDIF
ツ* ツ* ツ* IF ( [ JS1.A2 < 128 ] ) THEN
ツ* ツ* ツ* ツ* A12 = A2 * 10; // scaled - offset
ツ* ツ* ツ* ツ* A22 = A12 + 1280; // scaled - left range
ツ* ツ* ツ* ツ* A32 = A22 / 128; // scaled - left ratio
ツ* ツ* ツ* ツ* A42 = JS1.A2 * A32; // scaled - left deflection
ツ* ツ* ツ* ツ* CMS.A2 = A42 / 10; // actual - deflection output
ツ* ツ* ツ* ENDIF
ツ* ツ* ツ* IF ( [ JS1.A2 > 128 ] ) THEN
ツ* ツ* ツ* ツ* A12 = A2 * 10; // scaled - offset
ツ* ツ* ツ* ツ* A22 = 2550 - A12 + 1280 - 90; // scaled - right range (rounding correction)
ツ* ツ* ツ* ツ* A32 = A22 / 128; // scaled - right ratio
ツ* ツ* ツ* ツ* A42 = 1280 + A12 + ( ( JS1.A2 - 128 ) * A32 ); // scaled - right deflection
ツ* ツ* ツ* ツ* CMS.A2 = A42 / 10; // actual - deflection output
ツ* ツ* ツ* ENDIF
ツ* ツ* ENDIF

ツ* ツ* IF ( [ A3 == 0 ] OR JS1.B3 OR JS2.B29 ) THEN
ツ* ツ* ツ* CMS.A3 = JS3.A3;
ツ* ツ* ELSE
ツ* ツ* ツ* IF ( [ JS1.A2 == 128 ] ) THEN
ツ* ツ* ツ* ツ* CMS.A3 = JS3.A3 + A3;
ツ* ツ* ツ* ENDIF
ツ* ツ* ツ* IF ( [ JS3.A3 < 128 ] ) THEN
ツ* ツ* ツ* ツ* A13 = A3 * 10; // scaled - offset
ツ* ツ* ツ* ツ* A23 = A13 + 1280; // scaled - left range
ツ* ツ* ツ* ツ* A33 = A23 / 128; // scaled - left ratio
ツ* ツ* ツ* ツ* A43 = JS3.A3 * A33; // scaled - left deflection
ツ* ツ* ツ* ツ* CMS.A3 = A43 / 10; // actual - deflection output
ツ* ツ* ツ* ENDIF
ツ* ツ* ツ* IF ( [ JS3.A3 > 128 ] ) THEN
ツ* ツ* ツ* ツ* A13 = A3 * 10; // scaled - offset
ツ* ツ* ツ* ツ* A23 = 2550 - A13 + 1280 - 90; // scaled - right range (rounding correction)
ツ* ツ* ツ* ツ* A33 = A23 / 128; // scaled - right ratio
ツ* ツ* ツ* ツ* A43 = 1280 + A13 + ( ( JS3.A3 - 128 ) * A33 ); // scaled - right deflection
ツ* ツ* ツ* ツ* CMS.A3 = A43 / 10; // actual - deflection output
ツ* ツ* ツ* ENDIF
ツ* ツ* ENDIF
ツ* ツ* ツ*
ツ* ENDIF

ツ* SEQUENCE
ツ* ツ* WHILE ( JS2.B16 );
ツ* ツ* ツ* IF ( [ A2 < 127 ] ) THEN
ツ* ツ* ツ* ツ* A2 = A2 + 1;
ツ* ツ* ツ* ENDIF;
ツ* ツ* ツ* DELAY (1);
ツ* ENDSEQUENCE

ツ* SEQUENCE
ツ* ツ* WHILE ( JS2.B14 );
ツ* ツ* ツ* IF ( [ (A2 + 128) != 0 ] ) THEN
ツ* ツ* ツ* ツ* A2 = A2 - 1;
ツ* ツ* ツ* ENDIF;
ツ* ツ* ツ* DELAY (1);
ツ* ENDSEQUENCE

ツ* SEQUENCE
ツ* ツ* WHILE ( JS2.B13 AND NOT JS1.B4 );
ツ* ツ* ツ* IF ( [ A1 < 127 ] ) THEN
ツ* ツ* ツ* ツ* A1 = A1 + 1;
ツ* ツ* ツ* ENDIF;
ツ* ツ* ツ* DELAY (1);
ツ* ENDSEQUENCE

ツ* SEQUENCE
ツ* ツ* WHILE ( JS2.B13 AND JS1.B4 );
ツ* ツ* ツ* IF ( [ A3 < 127 ] ) THEN
ツ* ツ* ツ* ツ* A3 = A3 + 1;
ツ* ツ* ツ* ENDIF;
ツ* ツ* ツ* DELAY (1);
ツ* ENDSEQUENCE

ツ* SEQUENCE
ツ* ツ* WHILE ( JS2.B15 AND NOT JS1.B4 );
ツ* ツ* ツ* IF ( [ (A1 + 128) != 0 ] ) THEN
ツ* ツ* ツ* ツ* A1 = A1 - 1;
ツ* ツ* ツ* ENDIF;
ツ* ツ* ツ* DELAY (1);
ツ* ENDSEQUENCE

ツ* SEQUENCE
ツ* ツ* WHILE ( JS2.B15 AND JS1.B4 );
ツ* ツ* ツ* IF ( [ (A3 + 128) != 0 ] ) THEN
ツ* ツ* ツ* ツ* A3 = A3 - 1;
ツ* ツ* ツ* ENDIF;
ツ* ツ* ツ* DELAY (1);
ツ* ENDSEQUENCE
ツ*
ツ* SEQUENCE
ツ* ツ* WAIT( JS1.B7 );
ツ* ツ* A1 = JS1.A1 - 128;
ツ* ツ* A2 = JS1.A2 - 128;
ツ* ツ* A3 = JS3.A3 - 128;
ツ* ENDSEQUENCE

ツ* SEQUENCE
ツ* ツ* WAIT( JS1.B5 );
ツ* ツ* A1 = 0;
ツ* ツ* A2 = 0;
ツ* ツ* A3 = 0;
ツ* ENDSEQUENCE

Revvin
09-01-2004, 10:14 PM
Welcome to The CH Hangar Mark, wow what can I say! that's one hell of a script WTG! That's one hell of a 'first project' :D I'm still relatively new to this CMS scripting and taking small steps I never really got into the logical programming with the Cougar. Thanks for posting this it's good to know there's an experienced CMS user out there and if you have any other examples of code no matter how big or small post away!

MarkShot
09-01-2004, 10:30 PM
Well, my other programming was very basic. Mainly, two things:

(1) Toggles - either this character or that character depending on the last press. Simply maintaining a stateful bit variable and inverting it and each execution.

(2) A timed macro - very useful for running through checking your six like in the BOB. Go wide FOV (field of view), look up/forward and check the mirror, look over your left shoulder, look back/up over the head rest, and look over your right shoulder, return FOV to normal.

---

Here is my impression of TM versus CH.

CH's GUI basic programming is more straight forward then TM's. Thus, it's easier for the novice to get the controls programmed for very basic stuff.

TM's GUI programming uses a language specifically tailored for control programming. As such, most intermediate level functionality is much easier with the TM controls than the CH controls. CH's CMS is a general purpose programming language and as such requires much more work to implement intermediate level functionality.

CH's CMS is possibly more versatile than the TM programming language, but for the most part it is too low level.

From a marketting stand point, I would say that CMS is more of a weakness than a strength for CH. I would imagine that most customers are not professional or hobbyist programmers. Thus, where as TM's tailored language is approachable by your hardcore flight simmer, I think CH's CMS requires some form of programming background by the user.

---

If you are the same guy, I knew from the SIMHQ forums, then you are engineer if I recall correctly, yes?

MarkShot
09-01-2004, 10:34 PM
Yes, there is one other thing I forgot to mention.

The TM programming language due to its lack of generality and specifity to control programming can be considered to be largely self-documenting. However, I would defy anyone to look at any non-trivial CMS code that wasn't documented and easily see what it is doing.

Revvin
09-01-2004, 11:06 PM
It's funny you have that perspective as mine is almost the complete opposite. I will admit to only scratching the surface so my opinion may change but so far I've found the CMS easier to pick up than the TM logical programming which always seemed a little more clunky. I think perhaps what makes it a little easier is the way part of it is done through a GUI (setting the CMC buttons etc) and the rest is separate from the profile all done in another screen rather than lump everythig nin together as was done for the Cougar. I think CH's CMS may be able to wield more power than TM's as you pointed out it seems a lot more 'general purpose'. Certainly CH's GUI mapping software will be easier than TM's to pick up, I was an exprienced TM user so Foxy was a joy to use for me but I know a lot of fellow sim pilots in the various online sims I played waited for me to post up a profile then modify it themselves as the Foxy frontend was a little overwhelming for them. A lot can be done with the CH controllers with the point and click GUI so many users will never really want or indeed need to go into the CMS but for those who like tweaking things 'under the hood' I think they will find the CMS easy enough as these kinds of users will often have gone into their sims in a serious manner and played around with things like the EPIC controllers and all manner of exotic control devices.

'Revvin' is my nickname at SimHQ and on most forums and games, I've used it for years. As for being an 'engineer' I guess that would be my official title but these days I feel more like a dogsbody. I test and commision electrical systems and installations for a national electrical & mechanical contractor.

BTW post up any scripting ideas you have, mine were about as basic as they come but for the new user it's a starting point and an example of what they can do to acomplish something they want their controllers to do. Often it's just as much about the idea behind the implementation of the code as it is about the code itself.

JNOV
09-01-2004, 11:46 PM
I've owned two Cougars and have the complete line-up of CH USB (and gameport) gear. I find CMS vastly superior to TM's programming "language" for the simple reason that there are lots of things that you can do in CMS that you cannot accomplish on the Cougar. For instance, in CMS, it is a simple matter to create a state machine and define keys or combinations of keys (or sequences of keys) to transition from state to state. I have found this sort of thing useful in countless situations, and, as far as I can tell, it cannot be accomplished on a Cougar.

As much as I like it, however, I will admit that CMS is a bit of a cludge. CMS and the GUI don't work together very well, in my opinion, and I'd like an option to bypass the GUI altogether. The key definitions could be handled in a text file, similarly to the way in which Foxy works.

Just my $0.02,

JNOV

hooktin
10-01-2004, 02:40 AM
Hi, Markshot. great stuff you have done...more like mind-boggling. can you send me templates for the toggle and the timed macro? thanks in advance.

mark davis

MarkShot
10-01-2004, 02:44 AM
A "state machine" ... no doubt you are a programmer!

Okay, so when is CH going to come out with Object CMS? Maybe it should be called CMS++! :)

MarkShot
10-01-2004, 02:46 AM
Oh, yes, one nice GUI feature CH has that I like very much is that MODE1 is the default behavior for MODE2 and MODE3. That saves a lot of replicating code.

MarkShot
10-01-2004, 02:50 AM
Here is the toggle. It flips a bit variable each press of JS2.B9. CMS.B1 is mapped to one character and CMS.B2 is mapped to another.


テつ* SEQUENCE
テつ* テつ* WAIT ( JS2.B9 );
テつ* テつ* IF ( B1 ) THEN
テつ* テつ* テつ* CMS.B1 = TRUE;
テつ* テつ* テつ* B1 = FALSE;
テつ* テつ* ELSE
テつ* テつ* テつ* CMS.B2 = TRUE;
テつ* テつ* テつ* B1 = TRUE;
テつ* テつ* ENDIF
ツ* ツ* DELAY(1);
テつ* テつ* CMS.B1 = FALSE;
テつ* テつ* CMS.B2 = FALSE;
テつ* ENDSEQUENCE
[/b]

MarkShot
10-01-2004, 02:52 AM
Here is the timed sequence for checking six.


テつ* SEQUENCE
テつ* テつ* WAIT ( JS2.B4 AND NOT JS1.B4 );
テつ* テつ* CMS.B2 = TRUE; // wide FOV
テつ* テつ* DELAY(1);
テつ* テつ* CMS.B2 = FALSE;
テつ* テつ* CMS.B4 = TRUE; // left shoulder
テつ* テつ* DELAY(18);
テつ* テつ* CMS.B4 = FALSE;
テつ* テつ* CMS.B5 = TRUE; // back
テつ* テつ* DELAY(18);
テつ* テつ* CMS.B5 = FALSE;
テつ* テつ* CMS.B6 = TRUE; // right shoulder
テつ* テつ* DELAY(18);
テつ* テつ* CMS.B6 = FALSE;
テつ* テつ* CMS.B1 = TRUE; // normal FOV
テつ* テつ* DELAY(1);
テつ* テつ* CMS.B1 = FALSE;
テつ* ENDSEQUENCE
[/b]

Bob Church
10-01-2004, 05:32 AM
Hi Mark,

>> First, a little background ... I have been using TM controls since around 1992; before they were even programmable... <<

Yup. I'm glad to see you're still around, Mark!

>> Although the FS does have two trim wheels, they are not very convenient to use. <<

They have much the same effect as the sample trim program, too, as a result of the 50 degree pots. If you trim off-enter, you'll be off the resistive area before you run out of throw. They should be set near 128 in the Raw Data display when you calibrate and just left there for the most part. If you move them, they go out of calibration unless you can get them back into the same physical position.

>> The programming sample in the help file does have a trim function, but it is of very limited utility. The trim function presented does provide for defining a new logical center point for the controls. However, it does not provide the full range of axis values to the simulation being operated. Once trimmed, deflecting the stick in one direction will quickly reach the axis bound before the physical bound is reached, and deflection in the other direction will not reach the axis bound at all despite the physical bound being reached. <<

True enough. OTOH if you had a real aircraft trimmed that far to one side, would you still have full deflection on the other side? I wondered at the time, in the end I just went for the simpler example.

>> Finally, it dawned on me that if I performed all calculations scaled by a factor of ten that I could achieve reasonable accuracy despite only having integral division. <<

Yes, that's one way. It's usually enough to just make it bigger before you make it smaller. Ultimately, you have to multiply it by a fraction (k1/k2 in this example). Multiply by the numerator first, then divide by the denominator. You'll come up within one count of true value:

a1 = (k1 * js1.a1) / k2;

The multiplication will take place first because of the parentheses, so you won't lose resolution there. The divide brings you back down, but it won't truncate more than 1 count. You can always add (k2/2) should end up giving you enough resolution, it's still going to truncate to a degree. You could round it by adding half the denominator and get a little more accuracy:

a1 = ((k1 * js1.a1) + (k2/2)) / k2;

A couple of other notes. The arithmetic is done with 32-bit integers so you've got a lot of range during the calculation. Also, the CMS check for zerodivide is pretty simplistic. If the divisor is 0 it gets set to 1 and the division performed, so the divide is effectively just ignored. It's probably not the most sensible answer, I suppose 0x7fffffff would be what it should use for infinity, but it's fast, easy, and you weren't going to get anything useful with the zerodivide anyway.

>> Thus, physical to logical ratios could look like 1:1.3; meaning deflecting the physical stick by 1 unit would generate a logical value defection of 1.3. <<

It can be done a bit more simply, I think. What you really want is just to pick a new center such that the stick at physical center is just far enough from the new logical center to compensate for the drift. It's just a problem in assymetrical scaling.

For example, physical center is 128, physical range is 0 to 255. Suppose we want the CM to put out a a value of 100 when the stick is centered, 0 at full left, and 255 at full right. IOW, 28 counts of left trim. Now the left range is 0 - 100 raw, the right is 100 - 255 raw. It looks like this (conveniently ignoring how the offset was determined in the first place and that we'd need to do a similar thing with the Y Axis):

script

// A1 is the trimmed center value for straight and level flight.
// I'll (conveniently<g>) omit the details of how that's obtained
// here, since it doesn't really matter.
//
a1 = 100; // The "trimmed" center value we want for straight and level flight.

// Now we determine if the stick is left or right of physical
// physical center.
//
if( [ js1.a1 < 128 ] ) then

// It's left of physical center
//
cms.a1 = a1 - ((( 128 - js1.a1 ) * a1 ) / 128);

else

// It's right of physical center
//
cms.a1 = a1 + ((( js1.a1 - 128 ) * ( 255 - a1 )) / 128);

endif
endScript

That doesn't correct for truncation errors, you'd need to add 64 to the dividend equation to do that. Testing it here shows the right side only hits 253 on the Raw Data display, it's just what would be expected since you're on the long side.

>> CH's GUI basic programming is more straight forward then TM's. Thus, it's easier for the novice to get the controls programmed for very basic stuff.

TM's GUI programming uses a language specifically tailored for control programming. As such, most intermediate level functionality is much easier with the TM controls than the CH controls. CH's CMS is a general purpose programming language and as such requires much more work to implement intermediate level functionality. <<

I agree, really. But then "simple" is only a thin wrapper on "complex", the gap can be filled. A parameter-passing procedure call mechanism, a couple of libraries, who knows..... I always go for functionality first. If it will do "complex", "simple" can be arranged. If it wont do "complex", "simple" is all you'll ever have.

>> CH's CMS is possibly more versatile than the TM programming language, but for the most part it is too low level. <<

Well, if you're talking raw programming power, I'd have to take just a little exception to the "possibly" part. I think the CM wins that battle hands down. But then then I'm biased. ;)

>> From a marketting stand point, I would say that CMS is more of a weakness than a strength for CH. I would imagine that most customers are not professional or hobbyist programmers. Thus, where as TM's tailored language is approachable by your hardcore flight simmer, I think CH's CMS requires some form of programming background by the user. <<

DEF'd flags and logical statements weren't (and aren't) understood by a large percentage of TM users, either. OTOH, they made the F22 capable of things that nobody had dreamed of earlier (just ask Ulf<g>). I wouldn't leave it out just just because not everyone isn't born with the knowledge to use it. I'd rather put it in and try to explain it than cut the capability. Just MHO.

Anyway, good to see you over here!

- Bob

P.S Just saw your last posts. CM3 has a built-in toggle function now:

script
toggle( d5 ) = js1.b1
endScript

flips D5 everytime js1.b1 changes.

- Bob

The StickWorks
http://www.stickworks.com

MarkShot
10-01-2004, 03:43 PM
Hey, Bob!

Good to see you. You and Ken "Stinger" Richardson are some my oldest memories of making stock joysticks do more and work better.

Thanks for the sample code. If this forum had been here before, I could have just posted the problem and let you crack that nut me for me. :)

The wise programmer knows how to engineer a solution. The wise designer knows how to get the best and quickest solution which in many cases is avoiding the "do it yourself" route! Next time, I guess. :)

---

Some comments. I never used TM's logicals. For the most part, most of what I wanted to do could be done with the TM button/mode/switch programming language. The language was easier to work with and more readable than CMS. It was certainly less powerful than CMS.

For me, I find that a lot of stuff I might want to do will require CMS programming. I don't think CMS should be eliminated, but I think to improve the market appeal of the power CH controls offer, more programmability should be accessible in the friendly GUI. One should be able to access the power of these sticks without being a programmer. Of course, I am getting old and don't have children. For all I know, perhaps every kid now is required to take computer programming in junior high school like I had to study geometry. So, perhaps this is just a bias of my generation.

---

To those who have jumped into this thread or reading (including CH developers). I mean no offense by any of my comments. I hate the stupidity I see that goes on on so many Internet forums. These are just my perceptions and they may not even be worth the price of one cheap joystick and I don't attach any religious significance to them. :)

hooktin
11-01-2004, 12:54 AM
Mark thanks for sending the scripts. Bob Church and I have corresponded on this a bit in the past. He knows I am CH challenged for sure...

Question: in the text where "wide FOV" or "back" is indicated, are those words replaced by the equivalent in game commands? for example is "back" replaced by KP2 or "downarrow" or however a particular game assigns the command to the keyboard?

thanks in advance as always....its all i can do to find time to play my sims, let alone learn to really program like you guys do.

Mark Davis

MarkShot
11-01-2004, 01:09 AM
Yes, this was taken from my Battle of Britain (Rowan + BDG 0.0973) map.

So, various characters have been assigned to CMS.Bx just as you would assign them to physical button presses.

I go wide FOV to give me the best view of the sky behind and back to normal FOV, since I am probably in either in padlock chasing a 109E or in fixed forward view getting ready to shoot. The other views mentioned are snap to views and I have assigned delays sufficient to hold the view long enough to see if I am clear or being set up. In practice flying, it is somewhat like quickly checking the mirrors in your car or looking over your shoulder before changing lanes.

Yes, so the structure is:

Wait for the a button press.
Enable view1.
Delay long enough that the you can take in what you are looking at.
Enable view2.
Delay long enough that the you can take in what you are looking at.
Enable view3.
Delay long enough that the you can take in what you are looking at.
*{return to forward view}

* In BOB, the rear views were snap view. Thus, I was returned to whatever state I was before starting. In RBII3D (Red Baron), there are no snap views. So, I needed to explicitly reset to forward view. That would be fine, since as I said you are most likely to just about to fixate on a target in front of you and you want to make sure that it will be safe to do so.

Is that clear for you?

Bob Church
11-01-2004, 03:38 AM
Hi Mark,

>> Good to see you. You and Ken "Stinger" Richardson are some my oldest memories of making stock joysticks do more and work better. <<

It's been a long time, hasn't it? '93 or '94 I think. I used to hear from Kenny every now and then, but not for a couple of years now. I still hear from a few of the guys occasionally. Some of the FSForum Flight Simulator guys, Mike Greenwood, Ben Chiu, some of the later sysops, set up FlightAdventures.com and hang out over there now, but most of the rest have disappeared. Gone on to different things I guess.

>> Thanks for the sample code. If this forum had been here before, I could have just posted the problem and let you crack that nut me for me.

The wise programmer knows how to engineer a solution. The wise designer knows how to get the best and quickest solution which in many cases is avoiding the "do it yourself" route! Next time, I guess. <<

I thought it went "Young programmers know how to engineer a solution, old programmers just steal.".<g> Anyway, no thanks are necessary. It just looked like you were working hard than you need to at holding the resolution and I thought I'd post another solution for whatever interest it might have.

>> Some comments. I never used TM's logicals. For the most part, most of what I wanted to do could be done with the TM button/mode/switch programming language. The language was easier to work with and more readable than CMS. It was certainly less powerful than CMS. <<

It is a little different, but about all that's really missing are the /T codes. If you treat the "shift" button like it controls IO codes and use the Modes like they're UMD codes, you can do most everything the F22 would do from within the GUI. CMS comes into play at about the same point where you might have gone to the TM logical stuff.

>> For me, I find that a lot of stuff I might want to do will require CMS programming. I don't think CMS should be eliminated, but I think to improve the market appeal of the power CH controls offer, more programmability should be accessible in the friendly GUI. One should be able to access the power of these sticks without being a programmer. Of course, I am getting old and don't have children. For all I know, perhaps every kid now is required to take computer programming in junior high school like I had to study geometry. So, perhaps this is just a bias of my generation. <<

I'm not even sure they're required to take recess anymore<g>. I know what you mean, though. It's a tough nut to crack, trying to keep simplicity in the front end and still supply some powerful programming methods for the folks that can use it. It's an idea we're still working on.

>> To those who have jumped into this thread or reading (including CH developers). I mean no offense by any of my comments. I hate the stupidity I see that goes on on so many Internet forums. These are just my perceptions and they may not even be worth the price of one cheap joystick and I don't attach any religious significance to them. <<

Well, there was certainly no offense taken here, Mark. If it sounded that way then you have my apologies. I agree with most everything you said really. I only meant to offer another view on a point or two.

Anyway I'm glad you found the place, it's nice to see some of the old group is still at it!

- Bob

The StickWorks
http://www.stickworks.com

hooktin
11-01-2004, 05:47 AM
it is, indeed, clear, and thanks again.