Using POV hat buttons with FSUIPC

[David Cox]

Hi Pete - hope you are well

I have been busy programming FSUIPC/FS2004 to work with my new Saitek Evo joystick (I am programming a lot of it manually in the INI file so I can use osme buttons forSHIFT functions - this gives me 4 times the amount of usable buttons).

To achive this I have deleted the standard FS2004 joystick POV mapping and have programmed each POV direction as above, however, two things don't function as they do if I let FS2004 handle it via the joystick mapping, namely :

1) If I move directly from left view to left forward view I always briefly see the straight ahead view first (same with other directions) and

2) In virtual cockpit, the infinite virtual scrolling effect doesn't work (it just shifts from view to view as in cockpit view).

My code so far is :

10=R0,38,K100,8

11=R0,34,K102,8

12=R0,36,K98,8

13=R0,33,K105,8

14=R0,39,K103,8

15=R0,35,K99,8

16=R0,37,K97,8

17=R0,32,K38,10

Any help you can give will be appreciated

many thanks

David

[Pete Dowson]

1) If I move directly from left view to left forward view I always briefly see the straight ahead view first (same with other directions)

Why are you assigning them as Keystrokes? Best to use the FS controls for view selection.

Why do you have them repeating? There's no point in repeating fixed view selections.

Best to program them for the controls, on "Press", with release assigned to view reset.

2) In virtual cockpit, the infinite virtual scrolling effect doesn't work (it just shifts from view to view as in cockpit view).

That's because that scrolling is "panning", not view selection. By default FS uses the Hat for panning. The only advantage of using FSUIPC is to get view selection instead, which best suits 2D cockpits. I think they will pan if you set "pan_in_cockpit-mode=1" somewhere in the FS9.CFG, but I'm not sure about that and don't really see the point. If you like panning you are best using FS's Hat system.

Regards,

Pete

[David Cox]

Pete,

Many thanks for your reply

1) I tried your suggestion and have come across a problem - when I select "View Reset" as a key release command (either through the "Buttons" interface or manually using the "U" parameter) nothing happens - I noticed this earlier when testing the commands before I started programming - the release option doesn't appear to work on my system (I have tried two different joysticks - same problem).

Any suggestions as to why it's not working ?

2) Is it possible for me to keep the FS view functions working whilst using the POV hat for other functions using my shift keys - I have tried this but the FS view functions always work at the same time as my new shifted function via FSUPIC ?

Many thanks

David

[Pete Dowson]

1) I tried your suggestion and have come across a problem - when I select "View Reset" as a key release command (either through the "Buttons" interface or manually using the "U" parameter) nothing happens - I noticed this earlier when testing the commands before I started programming - the release option doesn't appear to work on my system (I have tried two different joysticks - same problem).

Ah, yes, I think you are right. In FS2004 at least it isn't what you need -- best to assign View Forward instead. It does what I wanted view Reset to do in any case.

2) Is it possible for me to keep the FS view functions working whilst using the POV hat for other functions using my shift keys - I have tried this but the FS view functions always work at the same time as my new shifted function via FSUPIC ?

I'm afraid FS doesn't provide any conditionals for use with its assignments. Whatever clever things you do in FSUIPC won't stop FS interpreting buttons and POVs the way it has them assigned. Sorry.

Regards,

Pete

[David Cox]

Thanks Pete,

I'e tried that - the problem doen't seem to be with the View Reset/Forward command but with the "U" (key release) parameter itself - anything I program using this parameter doesn't seem to work - any idea why ?

Many thanks

David

[Pete Dowson]

I'e tried that - the problem doen't seem to be with the View Reset/Forward command but with the "U" (key release) parameter itself - anything I program using this parameter doesn't seem to work - any idea why ?

Show me the relevant INI file parameters. There's no reason for it not to work.

Pete

[David Cox]

Pete - sorry, been away for the weekend

Parameters in use are as follows :

[buttons.PMDG 737-700]

1=U0,34,C65674,0

0=P0,34,C65676,0

2=P0,0,C65676,0

3=U0,0,C65674,0

As you can see, I have tried the same thing with two different buttons but the button release parameter "u" does not appear to work on my Win 2000 Pro/FS2004 system. Right view is activated but on release it stays that way. I have also used a second very simple joystick - same result.

Many thanks for your help on this one

David

[Pete Dowson]

[buttons.PMDG 737-700]

1=U0,34,C65674,0

0=P0,34,C65676,0

2=P0,0,C65676,0

3=U0,0,C65674,0

I see you have these buttons only enabled for the aircraft "PMDG 737-700". Can you please re-check with a default aircraft instead?

You are using FSUIPC 3.45, yes? If not please install that.

Then go to the FSUIPC Logging options page. Switch on the Event logging. Test the button again. Switch off the event logging. Look in the log, see if there's a "View Forward" control listed. If the log is short enough, show a bit here (if you are using PMDG it will NOT be short!!).

I have also used a second very simple joystick - same result.

That is also Joystick 0? Or did you pull the first one out?

There's nothing really to go wrong with the programming of button release, so I suspect something is interfering with the control instead.

Regards,

Pete

[David Cox]

Pete - OK, I've done some fiddling so here is the latest position.

1) I am using FSUIPC 3.45 - I deleted the FSUIPC.INI file as I had been makes lots of tweaks especially in the Technical page. I let it create the file from scratch and started again - the only changes I am now making are to the [buttons] section, otherwise I have a virgin file.

I have now got the U command working after carrying out the above - I got rid of a specific section for my PMDG 737, all entries are now under a [buttons] heading only. I think using a heading for the PMDG 737 may have something to do with it as I have noticed something else - if I use the following code under my [buttons] heading everything works fine :

24=CR(F-0,10)(F-0,11)0,0,K190,8

25=CP(F+0,10)(F-0,11)0,0,C65752,0

26=CP(F+0,10)(F+0,11)0,0,K52,9

27=CP(F-0,10)(F+0,11)0,0,K51,9

28=CP(F-0,10)(F+0,11)0,0,K50,9

However, if I do this :

[buttons]

24=CR(F-0,10)(F-0,11)0,0,K190,8

25=CP(F+0,10)(F-0,11)0,0,C65752,0

26=CP(F+0,10)(F+0,11)0,0,K52,9

27=CP(F-0,10)(F+0,11)0,0,K51,9

28=CP(F-0,10)(F+0,11)0,0,K50,9

[buttons.PMDG 737-700]

0=CP(F+0,10)(F+0,11)0,0,K52,9

1=CP(F-0,10)(F+0,11)0,0,K51,9

2=CP(F-0,10)(F+0,11)0,0,K50,9

In this case, all entries work EXCEPT line 28 ! (and the U parameter didn't work under the [buttons.PMDG 737-700] section either. Is it not possible to have conditional arguments for the same buttons in two different sections ?

2) Can I bother you with another couple of questions as I am new to this stuff :

I am short on normal single push buttons on my Saitek Evo joystick and would really like to use some of them to increase and decrease the speed in the PM MCP speed window. You provide four controls to do this, one set increases/decreases by 1, the other set increases by 10. I thought the best way to do this would be to use the set that increases by 1 (otherwise I would need both to set precise speeds) but when I use the control with the R parameter for single increments/decrements it takes too long (probably only 3 second). Is there a wy to increase this or can think of another solution that involves one button to increase and another to decrease (I was wondering if some form of timer can be used to start using the single control and after so many seconds switch to the x10 control until the key is released ?)

3) I am thinking of buying some cockpit gear (EFIS panel, MCP etc) but am not sure which ones to get. I see Go-Flight, Aerosoft and CPFlight/Engravity. Have you any views on which set-up is best for FS2004/PM/FSUIPC from a compatibility ease of installation/programming point of view.

Your input is much appreciated

David

[Pete Dowson]

if I use the following code under my [buttons] heading everything works fine :

24=CR(F-0,10)(F-0,11)0,0,K190,8

25=CP(F+0,10)(F-0,11)0,0,C65752,0

26=CP(F+0,10)(F+0,11)0,0,K52,9

27=CP(F-0,10)(F+0,11)0,0,K51,9

28=CP(F-0,10)(F+0,11)0,0,K50,9

However, if I do this :

[buttons]

24=CR(F-0,10)(F-0,11)0,0,K190,8

25=CP(F+0,10)(F-0,11)0,0,C65752,0

26=CP(F+0,10)(F+0,11)0,0,K52,9

27=CP(F-0,10)(F+0,11)0,0,K51,9

28=CP(F-0,10)(F+0,11)0,0,K50,9

[buttons.PMDG 737-700]

0=CP(F+0,10)(F+0,11)0,0,K52,9

1=CP(F-0,10)(F+0,11)0,0,K51,9

2=CP(F-0,10)(F+0,11)0,0,K50,9

In this case, all entries work EXCEPT line 28 ! (and the U parameter didn't work under the [buttons.PMDG 737-700] section either.

Hmmm. that's strange. Is this when the PMDG aircraft in question is loaded, or another? I think, logically, if the current aircraft is the PMDG 737-700 then, since all of the above actions are for button 0,0, then none of the entries 24-28 should work. They should be completely ignored in favour of that button's programming for the active aircraft.

On the other hand, if the current aircraft is not PMDG 737-700, none of the section so headed is even loaded by FSUIPC, so that should have no effect on the general part at all.

Can you clarify please? Also the U stuff.

Is it not possible to have conditional arguments for the same buttons in two different sections ?

It certainly should be. If there's a problem there, it's a bug, and I'll need to fix it. But first I need that clarification. Then I need to boil it down to the simplest reproducible case.

I am short on normal single push buttons on my Saitek Evo joystick and would really like to use some of them to increase and decrease the speed in the PM MCP speed window. You provide four controls to do this, one set increases/decreases by 1, the other set increases by 10.

I don't provide those, PM does. All FSUIPC does it toggle the bits PM tells me about.

when I use the control with the R parameter for single increments/decrements it takes too long (probably only 3 second)

What exactly takes 3 seconds? Just incrementing/decrementing by 1?

There's a problem there somewhere if so. It's really a question for the PM team I suspect. I must admit I am rather disappointed at the speed of reaction of the PM MCP to most of the offset controls it supports. It seems to have got slower and slower as more things have been added. I think the main concentration these days is supporting hardware MCPs directly connected, like the Aerosoft, CPFlight and PFC MCPs (all connecting by COM port). It's fine then. Maybe you can change its cycle time to make it look more often (see the MCP.INI file).

Are you running the PM MCP on the same PC as FS? I've always found that's best. The MCP is the hub.

As I say, all FSUIPC does it toggle or set a bit (it varies form control to control) in an offset. the rest is up to PM.

I am thinking of buying some cockpit gear (EFIS panel, MCP etc) but am not sure which ones to get. I see Go-Flight, Aerosoft and CPFlight/Engravity. Have you any views on which set-up is best for FS2004/PM/FSUIPC from a compatibility ease of installation/programming point of view.

For PM use, of those, your best bet is CPflight I think, but ask on the PM forum. Go-Flight at present don't support PM directly (it can be done via FSUIPC and a new program I'm working on now). Aerosoft don't make their MCP any more. The PFC one is really super but probably over the top (too expensive) unless you are very serious or very rich. Many PM users seems to be using the CPflight stuff.

Regards,

Pete

[David Cox]

Pete - thanks for your prompt response and feedback on the MCP hardware.

To answer your questions, all of the examples I gave were when the PMDG aircraft was loaded - I have not yet tried it with one of FS2004s default planes.

By using this :

[buttons]

24=CR(F-0,10)(F-0,11)0,0,K190,8

25=CP(F+0,10)(F-0,11)0,0,C65752,0

26=CP(F+0,10)(F+0,11)0,0,K52,9

27=CP(F-0,10)(F+0,11)0,0,K51,9

28=CP(F-0,10)(F+0,11)0,0,K50,9

[buttons.PMDG 737-700]

0=CP(F+0,10)(F+0,11)0,0,K52,9

1=CP(F-0,10)(F+0,11)0,0,K51,9

2=CP(F-0,10)(F+0,11)0,0,K50,9

I was trying to acheive a situation where 24 to 28 would be used by all aircraft in FS2004 including PMDG 737 if it was loaded. Entries 0 to 2 are designed to only work with PMDG 737 and this is how it works except that line 28 doesn't function (the idea was to use button 0,0 for 4 different tasks depending on the position of two shift buttons). Is this how it should work the way I have programmed it ?

I will do some more tests on this and the U parameter and get back to you.

Thanks for your input on the speed scroll issue - I presume there is no way to have FSUPIC start using one control on a button and after say 5 seconds switch to another one ?

David

[Pete Dowson]

To answer your questions, all of the examples I gave were when the PMDG aircraft was loaded - I have not yet tried it with one of FS2004s default planes.

In that case any button programmed for the PMDG will operate according to that section, not the general section. At least that's how it is designed to work. The general section provides the default action when there's nothing for that button in the aircraft specific section.

I was trying to acheive a situation where 24 to 28 would be used by all aircraft in FS2004 including PMDG 737 if it was loaded.

But all the entries are actions for the one button, 0,0, so, unless I've made a big error someplace, none of your lines 24 to 28 in the general section should work when the PMDG aircraft is loaded.

If it is not working like that I will indeed have to look at it and fix it!

line 28 doesn't function

Well, apart from the fact that it shouldn't anyway (see above), how can you tell? It is exactly the same as line 2 for the PMDG aircraft, look:

28= CP(F-0,10)(F+0,11)0,0,K50,9

2= CP(F-0,10)(F+0,11)0,0,K50,9

I will do some more tests on this and the U parameter and get back to you.

Okay, thanks. I am deep into something else at present and must get it done. I am trying to make ready an interim release of WideFS, FSUIPC and a new package "GFdisplay" by the end of tomorrow. Then I have a couple of days of family stuff to see to, but I'll be ready to have a proper look at any problems at the weekend, or shortly thereafter.

In the interim version of FSUIPC which I'll be uploading here (check announcements) there will be extra logging for button programming. I've had to add it to help with GFdisplay programming. Maybe this will help resolve your problems too, or identify the bugs more exactly.

Thanks for your input on the speed scroll issue - I presume there is no way to have FSUPIC start using one control on a button and after say 5 seconds switch to another one ?

Well, the only thing I can think of it to have that button also programmed to Repeat with an Offset Byte Increment control, adding 1 to a free offset in FSUIPC (66C0-66FF are available for general user application). You'd have an offset test condition for the byte to get to a certain value, then do something different. if the repeat rate is reasonably predictable that should do the trick.

In other words something like:

100=B66FF&C0=0 R1,1,Cxxxx,0 ; Your main initial control repeated till 66FF >= hex 40
101=R1,1,Cx110066FF,x00400001 ;Increment 66FF on each repeat till hex 40
102=B66FF&C0 R1,1,Cyyyy,0 ; Your different control after n seconds
103=U1,1,Cx010066FF,x00000000 ; Reset count to zero on button release

You'd have to adjust this for timing. Incrementing Byte 66FF by 1 on every repeat till it gets to 64 (hex 40) will only give 5 seconds if the repeat rate is somewhere close to 12/sec.

Unfortunately this won't work with the current FSUIPC because I found a bug in the offset condition testing. Strange no one reported it. It is fixed in the version I'll release here soon.

Regards,

Pete

[David Cox]

Pete - sorry I think I gave you some bum text - I have just tested with the following entries in FSUIPC.INI

[buttons]

1=U0,34,C66147,0

0=P0,34,C65676,0

*2=CR(F-0,10)(F-0,11)0,0,K190,8

*3=CP(F+0,10)(F-0,11)0,0,C65752,0 **

[buttons.PMDG 737-700]

0=P0,38,C65680,0

1=U0,38,C66147,0

*4=CP(F+0,10)(F+0,11)0,0,K52,9

*5=CP(F-0,10)(F+0,11)0,0,K51,9

*6=CP(F-0,10)(F+0,11)0,0,K50,9

1) The U parameter now appears to be working in all scenarios both with the 737 PMDG loaded and any other FS2004 default plane - that is how I interpret the above code so please ignore this one unless I get back to you at later date. I think I must have ended up with som corruption in my previous set-up.

2) The problem relating to button 0,0 still exists - I show the correct lines from the INI file above (marked *). Basically, if I include all these five lines in one section [buttons] they all work fine. If I split them as above then all lines work EXCEPT **(I am using two joystick buttons as to act as SHIFT keys thus giving me four possible actions for each button). I have switched on Event logging and cannot find any reference to the control (65752 -parking brakes) in this case. I hope this gives you more to go on - as far as I can tell all five lines should work for button 0,0 even though they are in two separate sections.

3) Thanks for your suggestion on the speed scroll issue - I'll try it when you release the next version in a couple of days

David

[Pete Dowson]

[buttons]

1=U0,34,C66147,0

0=P0,34,C65676,0

*2=CR(F-0,10)(F-0,11)0,0,K190,8

*3=CP(F+0,10)(F-0,11)0,0,C65752,0 **

[buttons.PMDG 737-700]

0=P0,38,C65680,0

1=U0,38,C66147,0

*4=CP(F+0,10)(F+0,11)0,0,K52,9

*5=CP(F-0,10)(F+0,11)0,0,K51,9

*6=CP(F-0,10)(F+0,11)0,0,K50,9

2) The problem relating to button 0,0 still exists - I show the correct lines from the INI file above (marked *). Basically, if I include all these five lines in one section [buttons] they all work fine. If I split them as above then all lines work EXCEPT **

Okay, so the bug in FSUIPC is that I am allowing the line

2=CR(F-0,10)(F-0,11)0,0,K190,8

to work in the [buttons] section when I shouldn't? Hmm. That's odd. I'll try to reproduce it here, but it will be in a few days from now, as I explained.

as far as I can tell all five lines should work for button 0,0 even though they are in two separate sections.

No, no: that isn't how it is intended. The programming is for button 0,0. If you program button 0,0 in an aircraft-specific section then it should be ignored in the general section. That applies to all instances of it as the prime operating button.

I thought I already explained this? Why do you think it should be opposite to what I say? Do I have it documented wrongly some place?

Regards,

Pete

[Pete Dowson]

Okay, so the bug in FSUIPC is that I am allowing the line

2=CR(F-0,10)(F-0,11)0,0,K190,8

Okay, curiosity got the better of me in the wee hours last night, and I worked out what was happening here.

It's the "Repeat" action which defeats the anti-duplicated button check.

In fact the initial "Press" is still eliminated -- what you are getting is the first and subsequent repeats. These are effectively defeating my duplication checks because a repeat action is neither a press or release -- there's no change in the button state.

I'll work out a fix for this and it will be included in the interim version uploaded here later today or tomorrow.

Sorry for any confusion this has caused!

BTW on the question of repeating for so many seconds, etc, I forgot to mention that you can set the Button repeat rate using the

ButtonRepeat=20

parameter. This is covered in the Advanced User's guide.

Regards,

Pete

[David Cox]

Pete, many thanks for your input on this.

I think my confusion was not about whether an aircraft section had precedence over the general [buttons] section but more about the fact that I had four/five actions for one button but wanted to put some in the aircraft section and some in the [buttons] section - I didn't find anything in your guides that expalined that all actions for a single button have to go in one section

Thanks for the additional info on the Button repeat rate - that may fix the problem - I'll try it later - by the way, I was getting 3 presses a second when I programmed the MCP speed scroll the other day

Bye for now

David

[hm]

Hi David,

Something I found in a cockpit builders forum and which looks very promessing:

http://www.mindaugas.com/products/MJoy16-C1/

Regards,

Hm

[Pete Dowson]

I didn't find anything in your guides that expalined that all actions for a single button have to go in one section

Well, that's not really true, that's why. It's just that if a button is programmed in an aircraft-specific section, and that aircraft is currently loaded, then the specific programming for that button takes precedence over any programming for the same button in the generally applicable section.

You can have the same button programmed for completely different things in each aircraft-specific section and also in the general [buttons] section. The latter programming simply becomes the default action for when you load an aircraft with no specific programming.

What you were effectively trying to do was have a single button, with a number of different conditions attached, spread over a the section and a specific aircraft section. It's not only horrible to contemplate programming that way (well, it is to me :) ), but it would be a devil of a job to understand what was going on when it went wrong (as it, in fact, did! :wink: )

Thanks for the additional info on the Button repeat rate - that may fix the problem - I'll try it later - by the way, I was getting 3 presses a second when I programmed the MCP speed scroll the other day

Is that by measuring the sending of the commands in the Log (Event logging), or merrely by seeing the results? Other things conspire to slow things down.

I also noticed that for several functions you were using FS keypresses rather than the equivalent commands directly. That will slow things down too -- each of those keypresses get looked up by FS in its assignments list and converted to an FS control then posted back to the same window for execution. Why not simply assign the control you want in the first place?

Regards,

Pete

[David Cox]

Pete,

Thanks for the mindaugas link - looks really promising - similar to an EPIC board but a fraction of the price !!!.

Also, thanks for the explanation on the buttons/sections - I understand now !. Also, your advice on controls vs. keys - I'll change them wherever I can.

The 3 presses a second measurement was done by me watcing how fast the MCP guage in my FS panel updated over a 10 second period - I haven't looked at this in the Event log yet - I'll do that and let you know the results in a day or two

David

[Pete Dowson]

Thanks for the mindaugas link - looks really promising - similar to an EPIC board but a fraction of the price !!!.

That wasn't me but Hm. :)

Regards,

Pete