Problems with Aircraft Specific

[artburke]

A few months back I did some key programming in FSUIPC so my switch project would work. I had great success making "aircraft specific" assignments in the FSUIPC menu.

Now I've bought a new joystick and temporarily removed my yoke and avionics panel. In attempting to make the joystick setting aircraft specific, the rest of the panel options get greyed out when I click the "aircraft specific" checkbox.

Am I overlooking something real simple?

[Pete Dowson]

In attempting to make the joystick setting aircraft specific, the rest of the panel options get greyed out when I click the "aircraft specific" checkbox.

First, please make sure you are using the latest FSUIPC (3.30). There have been a few changes in this area in the last few months.

Second, the only reason I ever prevent access to button programming for a particular button AND context is that it is subject to something more complex -- like conditionals or multiple actions -- which can only be done by editing the INI file.

If this is the case you should see a message to that effect, I think (sorry, but it seems a long time since I did that bit).

If it is indeed the case then you will have to continue to edit the INI file for such buttons, or else delete the entries before loading FS. If you want to re-program them completely for a particular aircraft, find and delete the entire Buttons. section.

By all means paste in the Buttons section(s) of your INI file here if you are still puzzled.

Regards,

Pete

[artburke]

I wasn't originally attempting to do any conditional programming, only set "standard" FS controls for the buttons. Since then, however, I have done (successfully) some conditional programming. A very fun function you've created here - I'm already using 18 functions on a 12-button joystick!

I'll copy the .ini file out somewhere else and start with a fresh version. My [KEYS] section of my .ini file is pretty complex at the moment. I'm not running the very latest version, but what I was trying to do was working in the previous version. I'll download the newest and give it another try.

In a worst case example, i.e., if I can't figure the darned thing out within two beers!, I can always create .ini files specific to a given aircraft and load the one I need before I fly! Kind of cumbersome but a lot better than not being able to do it at all!

Great stuff here Pete, as always. I've been busy with ham radio for a few months and not done much flying. Returned here today to discover you have medical problems. Good luck and God bless. Your health is a lot more important than this! Hope your next operation(s) turns out well.

Art

[Pete Dowson]

I can always create .ini files specific to a given aircraft and load the one I need before I fly! Kind of cumbersome but a lot better than not being able to do it at all!

Well that most certainly should not be neceassary. sort of defeats the point of the aircraft specific facilities I added.

Returned here today to discover you have medical problems. Good luck and God bless. Your health is a lot more important than this! Hope your next operation(s) turns out well.

Thanks! Actually both eyes have been "done" now. I had some trouble with the first one (operated on 8 weeks ago) -- a swelling at the back prevented it focussing with any lenses at all. I've been on medication for that for nearly two weeks, with another three weeks at least to go, and at least I can focus now with both eyes at the same time, and even at the same distance, with an appropriate mixture of lenses.

I've been buying cheap pairs of reading glasses and playing around swapping lenses about and have arrived at workable solutions -- one for PC work, another for reading. It isn't worth getting proper prescription glasses yet because things will change -- hopefully for the better!

Regards,

Pete

[artburke]

Well, I'm glad you responded while I was gone. I've read and heard it's in poor taste to answer your own post(s)!! Egads!

Well, I downloaded the latest version, got it all working - properly. I suspect now, that my previous problem was cockpit error - pun fully intended!

When I checked the "aircraft specific" box, the entire dialog box does indeed grey out. However, once I click a button on the joystick, then I have the option of choosing "FS Controls" or "PM" (I think - it isn't in front of me right this moment.

I had to go back and delete my old FSUIPC.INI file - I think all I did was confuse things - I BACKED IT UP!!! I put a couple of quickie tests in the box, checked to make sure the buttons functioned as expected and then exited. Upon checking my .ini file, it is exactly as one would expect! Eureka! The "flight specific" has been "honored" and I'm off and running - err, flying! Now I can re-copy the parts I backed up and use the module the way you intended!

Thanks Pete. Get well/better soon.

Art

[Pete Dowson]

When I checked the "aircraft specific" box, the entire dialog box does indeed grey out. However, once I click a button on the joystick, then I have the option of choosing "FS Controls" or "PM"

Ahall you mean is that it clears the button selection. So what you see is simply exactly the same as you see when you first go to that page, before pressing a button. Until you press a button you cannot program it, and changing between global and aircraft specific modes effectively restarts the process. That's why it says to do that selection first in the Doc.

By the way, the options are to program FS controls (on the right) or key presses (or the left). The PM controls checkbox is just to include the PM controls in the FS controls drop-down list or not.

Regards,

Pete

[artburke]

Well, I guess I'm even dumber than I originally thought. Here's my ideas:

SlopeElevator=0

SlopeRudder=0

[buttons]

0=CP(+2,0)2,6,C66080,0

1=CP(+2,0)2,7,C66079,0

2=P2,4,C65759,0

3=P2,5,C65758,0

4=R2,2,C65607,0

5=R2,3,C65615,0

6=R2,6,C65771,0

7=R2,7,C65769,0

8=R2,8,C65777,0

9=R2,9,C65775,0

10=P2,10,C66244,0

11=P2,11,C66243,0

[Keys]

0=77,24,66241,0 //TAB + M = Toggle Master Battery

1=65,24,66293,0 //TAB + A = Toggle Avionics

2=33,8,66338,0 //PageUp = Toggle Propeller De-Ice

This is a snippet from my FSUIPC.INI file. When I first wrote you earlier today, I had statements "0" and "1" working - now, with the update version (v3.30) it won't work any more. I also had some more at the bottom that were conditional programming (button programming of course). They seem to work fine. They look like:

12=CP(+2,1)2,6,K50,9

13=CP(+2,1)2,7,K51,9

14=CP(+2,1)2,8,K52,9

15=CP(+2,1)2,9,K53,9

Statements 0 and 1 are to raise and lower the landing gear conditionally, if button 0 is depressed then buttons 6 and 7 raise and lower the landing gear. It doesn't seem to want to work any more.

The last four statements use conditional button-presses. If button 1 (actually button 2 on my joystick) is depressed and button 6 is depressed, it'll bring up the radio stack. These last four statements work.

For the life of me I can't figure out why the first two *used* to work, then stopped, yet the last four are just hunky dorey!

Art

[Pete Dowson]

Well, I guess I'm even dumber than I originally thought.

No, not at all. You have discovered an interesting side effect of some safety measures I included, to prevent run-away repetition.

I was puzzled too, at first, so I tried your settings with assorted variations. The problems arise because of these lines:

6=R2,6,C65771,0

7=R2,7,C65769,0

8=R2,8,C65777,0

9=R2,9,C65775,0

Here you are defining the very same buttons you make conditional elsewhere to also unconditionally operate prop pitch inc/dec and mixture inc/dec, repetitively.

It is a little odd, to say the least, to have your Gear up/down control also increment or decrement the prop pitch, and even more odd for radio stack or GPS viewing to do similarly. But it isn't that which is the problem.

It is the "R", the Repeat action. The anti-runaway code prevents another control from the same "R" button press being sent to FS within so many milliseconds of the previous one -- the actual timing is controlled by the repeat counter parameter, I forget its name now.

This is why is didn't affect the key press values, only the controls.

Really, the correct way to program those additional actions on those same buttons is to make them conditional on neither button 0 or 1 being also pressed. i.e

6=CR(-2,0)(-2,1)2,6,C65771,0

7=CR(-2,0)(-2,1)2,7,C65769,0

8=CR(-2,0)(-2,1)2,8,C65777,0

9=CR(-2,0)(-2,1)2,9,C65775,0

[Note correction here -- in my original posting I omitted the 'C's]

Of course, theoretically FSUIPC shouldn't stop a different control being sent even though a repetitive one is instigated. I'll have to think about that though. I don't really want to remove the safety code I inserted, but it looks like it may have to become somewhat more complex. Hmmm.

Regards,

Pete

[artburke]

Well, I certainly appreciate your observation and comments, but...

While my programming skills may be suspect (thank heavens I don't do that for a living!), it just doesn't seem logical to check for conditional situations when the "0" or "1" buttons are *not* depressed!

The conventional use of the joystick is that never more than one button at a time would be pressed. My logic (perhaps incorrect) was that if I "tested" each button condition, there could be more than one function per button, depending on that buttons' "dependency."

Therefore, if button '1' is pressed and then button 12 is pressed, we get action #1. Otherwise, if button '2' is pressed and then button 12 is pressed, we get action #2, etc. Of course I'm assuming two buttons are pressed simultaneously. Maybe I misunderstood the examples in the Advanced Users doc.

It's convenient to have the repeat function for the mixture and pitch, but it *could* be worked without using the repeat function. This was certainly the first time I was aware of any "safety" factor you had programmed in. Wise on your part I must admit. What's that old adage about knowing what goes into politics and sausage??

I'll go back and play with other alternatives. Maybe pulling out my yoke and avionics stack was a mistake! The thing was so big, it cluttered my desk. The console had a dual throttle quadrant and I'm trying to compensate for its disappearance!

Thanks again Pete.

Art

[Pete Dowson]

it just doesn't seem logical to check for conditional situations when the "0" or "1" buttons are *not* depressed!

That's okay if you want those actions to occur unconditionally. Without the condition attached, they are obviously unconditional. How do you expect FSUIPC to understand you meant it to search through all the other lines to see if there were any conditions applying first before applying what is plainly defined as an unconditional requirement?

The conventional use of the joystick is that never more than one button at a time would be pressed. My logic (perhaps incorrect) was that if I "tested" each button condition, there could be more than one function per button, depending on that buttons' "dependency."

Therefore, if button '1' is pressed and then button 12 is pressed, we get action #1. Otherwise, if button '2' is pressed and then button 12 is pressed, we get action #2, etc. Of course I'm assuming two buttons are pressed simultaneously. Maybe I misunderstood the examples in the Advanced Users doc.

You have things slightly wrong. The button being actioned in both cases in your example is #12. When #12 is seen, FSUIPC scans your list to see if there's anything it needs to do. If there is, it processes all the lines with #12 as the prime instigator, and checks the conditions, if any.

It treats each and every line the same -- independently of all the others.

As the documentation clearly says, you can have many more than one action resulting from the same single button press -- this is often the only way to do some things, and is the programming way of getting sequences -- sequences of controls or keypresses or a mixture.

If it were programmed your way, multiple actions for a keypress would not be possible without changing things completely and allowing lists of actions on the same line.

It's convenient to have the repeat function for the mixture and pitch, but it *could* be worked without using the repeat function.

You can use it with the Repeat. This is not about the repeat, though that is what showed up the weakness (bug if you like) in my recent releases. Even if it were a simple Press programming, it would still occur unconditionally UNLESS you add the conditions, as I said.

This was certainly the first time I was aware of any "safety" factor you had programmed in.

It's in this item of the release notes for 3.30 (in the History document and in the Announcements above):

5. The button repeat timing is now more properly regulated. It was sometimes far too fast in recent releases, due mainly to the increased button polling rates being used by default. The repeat rate used can be set by a "ButtonRepeat" parameter in the main [buttons] section of the INI file, with a range of 1-100, with 0 meaning no restriction. The default of 20.

Wise on your part I must admit. What's that old adage about knowing what goes into politics and sausage??

I don't know, sorry.

I'll go back and play with other alternatives.

But why reject out of hand the solution I gave you? All you had to do was cut and paste from my message into your INI file. What's so hard? I don't understand. Why don't you want to make the pitch and mixture inc/decs conditional on neither of your control buttons being pressed?

Regards,

Pete

[artburke]

Pete wrote:

But why reject out of hand the solution I gave you? All you had to do was cut and paste from my message into your INI file. What's so hard? I don't understand. Why don't you want to make the pitch and mixture inc/decs conditional on neither of your control buttons being pressed?

You're absolutely right! I need to adjust my thinking. It appears *my* logic is backwards relative to the way you wrote it. I need to get it through my thick head that your way works cuz that's the way you intended it to be!

Back to my plane! Thanks again for being so patient.

FWIW, the old adage about politics and sausage is that most people really don't want to know what's in either one!! Maybe it's too American! LOL!

Art

[Pete Dowson]

FWIW, the old adage about politics and sausage is that most people really don't want to know what's in either one!! Maybe it's too American! LOL!

Ah, yes. It probably is! :)

Actually sausages are quite a serious business here, probably more so than politics :D. Of course, we have 'proper' sausages, packed not just with meat, but all sorts of assorted other goodies, and most folks certainly do distinguish between those other things, as they provide much of the flavouring. The meat part is usually just minced pork, but also beef and even venison ones are common.

Anyway, back on the subject, I will be looking to see if I can refine the "Repeat" coding so that it doesn't prevent multiple events from the same instigating button. That's a side effect I hadn't intended, so thanks for 'finding' that bug for me.

Regards,

Pete