David Cox Posted February 22, 2005 Report Posted February 22, 2005 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
Pete Dowson Posted February 22, 2005 Report Posted February 22, 2005 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
David Cox Posted February 23, 2005 Author Report Posted February 23, 2005 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
Pete Dowson Posted February 23, 2005 Report Posted February 23, 2005 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
David Cox Posted March 3, 2005 Author Report Posted March 3, 2005 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
Pete Dowson Posted March 3, 2005 Report Posted March 3, 2005 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
David Cox Posted March 4, 2005 Author Report Posted March 4, 2005 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
David Cox Posted March 4, 2005 Author Report Posted March 4, 2005 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
Pete Dowson Posted March 4, 2005 Report Posted March 4, 2005 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,x5448474929=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
hm Posted March 4, 2005 Report Posted March 4, 2005 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
Pete Dowson Posted March 4, 2005 Report Posted March 4, 2005 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
David Cox Posted March 5, 2005 Author Report Posted March 5, 2005 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
David Cox Posted March 5, 2005 Author Report Posted March 5, 2005 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
Pete Dowson Posted March 5, 2005 Report Posted March 5, 2005 "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
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now