Jump to content
The simFlight Network Forums

Using AdvDisplay.DLL to display jotstick shift key messages


Recommended Posts

Hi Pete,

Another question for you if I may.

I use two keys on my joystick that perform shift function (Left & Right). I have programmed them to toggle (Set & Clear) in my FSUIPC.INI, example as follows :

68=CP(F-0,10)(F+0,11)0,1,C2024,0

69=CP(F+0,10)(F+0,11)0,1,C2031,0

Buttons 10 and 11 on Joystick 0 are obviously the ones I'm using.

I would like AdvDisplay to show the words LEFT when 0,10 is set, RIGHT when 0,11 is set and LEFT/RIGHT when both are set but having looked in your SDK I have to admit I don't know where to begin.

Can you give me some pointers please ???

Many thanks

David

Link to comment
Share on other sites

I would like AdvDisplay to show the words LEFT when 0,10 is set, RIGHT when 0,11 is set and LEFT/RIGHT when both are set but having looked in your SDK I have to admit I don't know where to begin.

You are not actually writing a program for this, I assume? The SDK is really for programmers. There's no easy way to send strings to the display locations.

The FSUIPC button and key INI file facilities do allow values as large as 32-bit (4 byte) numbers to be written to specific offsets, but strings require one byte for each character plus a zero byte at the end, and the control value of 16-bits too.

This would mean, on your case, and taking "RIGHT" as an example, writing "RIGH" to 3380 as a DWORD, then "T" and a zero to 3384 as a WORD, then the control value as a WORD to 32FA.

So, three defined actions for the same button.

FSUIPC's parameters don't take strings as such, so you will have to convert the characters to hexadecimal (use an ASCII look up table), not forgetting to reverse the oder (Intel processors use Lo-Hi ordering, so the highest byte value in a 4-byte DWORD comes first).

To take an easier example, the hex for "ABCD" would be x44434241. 44 is D, 43 is C, 42 is B, 41 is A.

Regards,

Pete

Link to comment
Share on other sites

Hi Pete - thanks for your prompt response.

No, I am not writing a program, I just want a way of getting the status of my joystick shift keys displayed so I know which ones are set.

I'm afraid this stuff is all new to me so please bear with me with what may appear to be stupid questions - here goes :

1) I assume then, that this is achieved by adding instuctions to the [buttons] section for the relevant joystick button

2) If this is so then I also assume that there is a way to tell FSUIPC to update AdvDisplay when the relevant button is pressed.

3) Can I ask you to give me a sample line for a button with an explanation of what each parameter means, please (I can't find anything in your docs that explains this - unless I've missed it !).

Many thanks in advance for your guidance

David

Link to comment
Share on other sites

1) I assume then, that this is achieved by adding instuctions to the [buttons] section for the relevant joystick button

You would certainly have to edit the INI file. Multiple actions on a single button are not possible via the options window.

As I said, the system is not designed for passing strings at all, only 8, 16 or 32 bit numbers. That's why you have to convert your strings to look like numbers.

2) If this is so then I also assume that there is a way to tell FSUIPC to update AdvDisplay when the relevant button is pressed.

After writing the string to 3380 you have to send the command to 32FA, as described in the Programmers Guide. That's another 16-bit value on the same button, but it must be last (higher numbered line).

FSUIPC doesn't "update AdvDisplay". Messages are sent to Flight Sim. If AdvDisplay is running it intercepts them. If it isn't they display on the screen in the translucent green window over the top.

3) Can I ask you to give me a sample line for a button with an explanation of what each parameter means, please (I can't find anything in your docs that explains this - unless I've missed it !).

All that is in the Advanced User's manual, the definitions of all of the FSUIPC-added controls are listed there.

Regards,

Pete

Link to comment
Share on other sites

  • 2 weeks later...

Hi Pete,

Sorry to bother you with this one again - I have been trying to work out how to do this (see earlier postings) over the last few evenings using the Advanced FSUIPC User Guide (section on adding offset conditions) and the offset list in the Programmers guide but I am getting nowhere - maybe I'm missing a trick or just not undersanding hexdecimal or something but I can't make head nor tail of how the examples in the Advanced user guide are constructed e.g.

31=P174,10,Cx510066C0,x00030001 - the value in the Byte at offset 66C0 is cycled from 0–3, and back to 0, by button 174,10 - trouble is I don't understand how to translate Cx510066C0,x00030001 into your explanation and I'm still trying to get to a point where I can display the status of my joystick shift buttons in FS2004 (via 32FA).

Any chance you can show me a simple example to display the character L when the button is pressed

Many thanks

Link to comment
Share on other sites

I can't make head nor tail of how the examples in the Advanced user guide are constructed e.g.

31=P174,10,Cx510066C0,x00030001 - the value in the Byte at offset 66C0 is cycled from 0–3, and back to 0, by button 174,10 - trouble is I don't understand how to translate Cx510066C0,x00030001 into your explanation

Take it apart:

C = "Control". this distinguishes it from a Key Press which would be 'K'.

x = "heXadecimal, saying what follows in to base 16, not 10 like decimal.

5100 is the high 16 bits of the Control number. This identifies the command as the Offset Byte Cyclic Increment, as in the list:

x5100zzzz Offset Byte Cyclic Increment (offset = zzzz), hexadecimal

Hence "66C0" is the offset.

The "x00030001" part is the parameter. the explanantion of this is just below the list quoted above:

The increment/decrement values operate on Unsigned (U) or Signed (S) values, and have a parameter with the unsigned or signed limit in the upper 16 bits and the increment/decrement amount (always unsigned) in the lower 16 bits.

So, the upper 16 bits (0003) give the limit of 3, and the lower 16 bits (0001) gives the increment.

Any chance you can show me a simple example to display the character L when the button is pressed

As I said when you first asked this, these facilities are simply not designed to do what you apparently want to do. I've no idea why you should want to do such things in any case. But all you do is:

Write the ASCII for 'L' (0x4C, or decimal 76), followed by zero (0x00) to 3380:

... Cx02003380,x004c

The x0200zzzz control writes a WORD (16 bits) to an offset. 3380 is the offset. The value x004c is the letter L (x4c) followed by 0x00 (remember bytes are Lo->Hi in all Intel processors. This would be different in an Apple!)

Then, to make that display, write the control word to 32FA. Write zero here for it to stay displayed until changed. write a number here for a number of seconds. e.g. for a 5 second display:

... Cx020032FA,5

Pete

Link to comment
Share on other sites

Pete,

Many, many thanks for your invaluable help - I understand it now (the bit I was missing was the control number). Now that it all makes sense I have programmed the two joytsick buttons to display what I need.

For your information, my joystick has two shift buttons which gives me in excess of 60 possible buttons to play with in 4 tiers (Shift off, Left shift on, Right shift on, Left & Right shifts on). So I now display the status of the shift keys in the PM EICAS page via AdvDisplay - this eliminates the confusion of which "page" of joystick commands I'm using.

Once again, thanks for all your help on this.

David

Link to comment
Share on other sites

Pete,

A quick update for you - I've been flying with this new set-up and all is not a it should be yet - I have noticed two strange things :

1) Sometimes (usually after re-starting FS2004), the message LEFT + RIGHT gets corrupted with additional text (e.g. LEFT + RIGHT nwa MC). Yet on restart everything goes back to normal

2) Whilst AdvDisplay itself updates quickly the display (via AdvDisplay) in the PM EICAS page updates very slowly when displaying LEFT + RIGHT (approx. 7 seconds) but only when generated by button 0,10. When button 0,11 generates the same message it happens very quickly. I have also seen occasional truncation of the display in the PM EICAS (LEFT + R) but this is only very occasional.

My code is :

20=CP(F+14,2)(F-14,3)0,10,Cx03003380,x5446454C

21=CP(F+14,2)(F-14,3)0,10,Cx01003384,x00

22=CP(F+14,2)(F-14,3)0,10,Cx020032FA,0

23=CP(F-14,2)(F-14,3)0,10,Cx03003380,x454E4F4E

24=CP(F-14,2)(F-14,3)0,10,Cx01003384,x00

25=CP(F-14,2)(F-14,3)0,10,Cx020032FA,0

26=CP(F+14,2)(F+14,3)0,10,Cx03003380,x5446454C

27=CP(F+14,2)(F+14,3)0,10,Cx03003384,x52202B20

28=CP(F+14,2)(F+14,3)0,10,Cx03003388,x54484749

29=CP(F+14,2)(F+14,3)0,10,Cx01003392,x00

30=CP(F+14,2)(F+14,3)0,10,Cx020032FA,0

31=CP(F-14,2)(F+14,3)0,10,Cx03003380,x48474952

32=CP(F-14,2)(F+14,3)0,10,Cx02003384,x0054

33=CP(F-14,2)(F+14,3)0,10,Cx020032FA,0

34=CP(F+14,3)(F-14,2)0,11,Cx03003380,x48474952

35=CP(F+14,3)(F-14,2)0,11,Cx02003384,x0054

36=CP(F+14,3)(F-14,2)0,11,Cx020032FA,0

37=CP(F-14,3)(F-14,2)0,11,Cx03003380,x454E4F4E

38=CP(F-14,3)(F-14,2)0,11,Cx01003384,x00

39=CP(F-14,3)(F-14,2)0,11,Cx020032FA,0

40=CP(F+14,3)(F+14,2)0,11,Cx03003380,x5446454C

41=CP(F+14,3)(F+14,2)0,11,Cx03003384,x52202B20

42=CP(F+14,3)(F+14,2)0,11,Cx03003388,x54484749

43=CP(F+14,3)(F+14,2)0,11,Cx01003392,x00

44=CP(F+14,3)(F+14,2)0,11,Cx020032FA,0

45=CP(F-14,3)(F+14,2)0,11,Cx03003380,x5446454C

46=CP(F-14,3)(F+14,2)0,11,Cx01003384,x00

47=CP(F-14,3)(F+14,2)0,11,Cx020032FA,0

Any idea what is casuing these eratic anomalies ?

Many thanks

David

Link to comment
Share on other sites

1) Sometimes (usually after re-starting FS2004), the message LEFT + RIGHT gets corrupted with additional text (e.g. LEFT + RIGHT nwa MC). Yet on restart everything goes back to normal

You have some errors:

28=CP(F+14,2)(F+14,3)0,10,Cx03003388,x54484749

29=CP(F+14,2)(F+14,3)0,10,Cx01003392,x00

...

42=CP(F+14,3)(F+14,2)0,11,Cx03003388,x54484749

43=CP(F+14,3)(F+14,2)0,11,Cx01003392,x00

The zero terminator is being written to 3392, which is 10 bytes later than 3388, not 4. You seem to have reverted to counting in decimal, not hexadecimal. 8 + 4 in hex is C. Hex digits go 0-9 then A B C D E F.

2) Whilst AdvDisplay itself updates quickly the display (via AdvDisplay) in the PM EICAS page updates very slowly when displaying LEFT + RIGHT (approx. 7 seconds) but only when generated by button 0,10. When button 0,11 generates the same message it happens very quickly.

No idea why that should be. If the 0,10 and 0,11 programming is similar they should be the same. Are you sure the button 0,10 isn't doing something in addition or different which is responsible for the delay?

Regards,

Pete

Link to comment
Share on other sites

Wow, David, you have given me some ideas. I also looking for a method to schedule some message depending on some button or flag condition. It would be nice if Pete would provide some control to launch a message like

40=CP(F+14,3)(F+14,2)0,11,Cx????3380,"Message"

41=CP(F+14,2)(F-14,3)0,10,Cx01003384,-1

where rule 40 would store a C string in the consecutive memory cells, starting from the given address.

and rule 41 (allready provided) to launch the (scrolling) message with a control and a duration parameter (here 1 second, 0 = eternal)

Hugo

Link to comment
Share on other sites

It would be nice if Pete would provide some control to launch a message

Unfortunately it wouldn't fit in at all with the current FSUIPC control mechanism. It would have to be a complete new and separate facility.

And, I'm sorry, but it is now too late for new facilities for at least two months -- much longer if Microsoft are planning a new version of FS this year.

Regards,

Pete

Link to comment
Share on other sites

Pete,

You are saying that just two of my lines of code have errors, I think ?.

You said :

"The zero terminator is being written to 3392, which is 10 bytes later than 3388, not 4. You seem to have reverted to counting in decimal, not hexadecimal. 8 + 4 in hex is C. Hex digits go 0-9 then A B C D E F".

Sorry, this is all new to me and I'm confused (possibly thick !).

So what should the zero terminator be written to - 338C ?. Please explain. I don't think I'm fully understanding how the HEX works with offsets.

Many thanks

David

Link to comment
Share on other sites

Pete,

Ignore my last post - I see I got it right (338C) and all is now working well. Also, I have shortened LEFT + RIGHT to L+R and that has resolved the problem with the delay in the PM EICAS display. I tested without any other button programming and it did not resolve the display delay so I will let Enrico know what I found as it may be a problem with PM GC.

Once again, many thanks for your guidance on this one - I think I'm starting to get my head around hexadecimal !

David

Link to comment
Share on other sites

"The zero terminator is being written to 3392, which is 10 bytes later than 3388, not 4. You seem to have reverted to counting in decimal, not hexadecimal. 8 + 4 in hex is C. Hex digits go 0-9 then A B C D E F".

Yes, exactly.

Sorry, this is all new to me and I'm confused (possibly thick !).

So what should the zero terminator be written to - 338C ?. Please explain. I don't think I'm fully understanding how the HEX works with offsets.

Oh dear.

Hex works as hex no matter whether you are talking about offsets or not. It is a number system. It is not specific to FSUIPC or offsets or anything!!

"Hex" is short for "hexadecimal". Hexadecimal numbering is a system where each digit represents values from 0 to 15, unlike decimal numbers which run from 0 to 9. In a decimal number, each digit represents 10 times the next one, so

123 = 1 x 100 + 2 x 10 + 3 x 1

In hexadecimal, 123 means something entirely different:

x123 = 1 x 256 + 2 x 16 + 3 x 1, which in decimal is 291.

Because digits in hexadecimal need to go right up to 15, the letters A -F are used. So numbers go:

0 1 2 3 4 5 6 7 8 9 A B C D E F

with A = 10, F = 15.

When you add 4 to 3388 you therefore get 338C, not 3392. You were adding in DECIMAL, not HEXADECIMAL!

8 + 4 = C (see list above).

It's all simple arithmetic, just in a different base system.

That's as much as I can explain, really. Please refer to a guide to computers for more about binary, octal and hexadecimal number systems.

Regards,

Pete

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.