Pete Dowson

Right. So it loses another digit. So maybe I should reduce the size to 5 instead of 6 rather than increase it to 7. I really don't understand what they've done, at all. Try 1.244, where I've reduced the length instead of increasing it. Regards Pete GFdisplay1244.zip

Man, you are impossible. LOOK PLEASE. The bit you just quoted was from "the first place", but you ignored it completely, as you have most of the rest. Both those quotes I just gave you were from earlier messages, one a lot earlier (immediately after you showed me the log results), and another a bit later. You simply refuse to read things and then have the damned cheek to accuse me of the same? THESE QUOTES, which I repeat for the third time, were from earlier messages, and they ARE in plain English. Open your eyes, for pity's sake! If you want to toggle a panel with a known ID (it won't necessarily be 9 -- you need to find the ID in the Panel.cfg file. It'll be given in the line "ident= ...), then assign as button or key to "Panel id toggle" and place the ident number as the parameter. [i've already suggested this] Earlier: You can do the same on a button by programming those control. Use a parameter of 1 on the Press and 2 on the Release. I am not answering any more of your damn fool questions. you are a completely unreasonable person who just won't accept the help he is given. There is absolutely no point in my trying any further, at all. holiday? What holiday? Christmas is our next one. And that's usually my busiest time. I hope not to see any of your messages then. Good night. Pete

Here's 1.243, with 7 characters being sent for those 5 digit displays, instead of 6! :roll: :shock: Pete GFdisplay1243.zip

Er, if it is subjected to *3.28084 /65536, just change that to *32.8084 / 65536. It's simple arithmetic! Something which is 10 times bigger is ten times bigger, isn't it? In fact the examples in the doc are only expressed like that as an "example". Obviously you could replace the *3.28084 / 65536 by * 0.000050061646 or by /19975.372, both of which change the original value by the same factor. If you don't understand why, just get a calculator out and do the division yourself, either way up. Ah, good job you said that. I was just about to give you an update assuming otherwise. Pete

Uh. :-( I did list it in the list of 3 changes. Hmm. Why not just multiply the value by 10? I missed one of your replies which included this: "but only 4 digits display and its divided by 10". That implies that the digit missing is a 6th digit which I don't send. That's interesting. It implies a different interface despite the similarity to the MCP non-Pro. I'll make a version with 6 characters being sent. [LATER] Ahbefore I do that, please confirm that the Speed display is okay. That's another supposedly 5 digit display, right? So it should suffer the same digit loss? Regards Pete

So, the ident is 2. See, where it actually tells you this? Exactly as I said? Yes. You are repeating yourself. I told you how to use that information already. You chose to ignore me, again. Oh dear. I most certainly told you TWICE, and you persist in ignoring what I tell you! Please do READ WHAT I WRITE. I'm really getting fed up with your refusal to see what I write and repeat questions which I've already answered. Look, from an earlier message: If you want to toggle a panel with a known ID (it won't necessarily be 9 -- you need to find the ID in the Panel.cfg file. It'll be given in the line "ident= ...), then assign as button or key to "Panel id toggle" and place the ident number as the parameter. [i've already suggested this] and from an even earlier one: You can do the same on a button by programming those control. Use a parameter of 1 on the Press and 2 on the Release. I certainly hope so, because I'm not answering you any more. I've had enough. Sorry. Pete

Sorry, I'm not clear what you mean. Are you saying that the displays are still wrong, even using a completely different call into GFDev.dll? I'm not dealing with segments now, just sending the text to the device using text requests. Is there no difference at all? I'm amazed. Do the displays actually display text if sent, e.g. like "TEXT"? Regards Pete

Okay. Please try the attached version 1.242. I've made these changes only: 1. Allows LED23. 2. Keeps its own record of LEDs set, not trusting the read facility. 3. Uses the alternative text display mode for the displays -- on the MCPPro only. Let me know what results this gives. I've also posted some questions off to GoFlight themselves. Regards Pete GFdisplay1242.zip

So what were those controls showing toggling of panels 1 and 2? Did you try doing that? If you want to toggle a panel with a known ID (it won't necessarily be 9 -- you need to find the ID in the Panel.cfg file. It'll be given in the line "ident= ...), then assign as button or key to "Panel id toggle" and place the ident number as the parameter. [i've already suggested this] Correct. You cannot do what you want without writing a small Lua plug-in. I've been giving you huge amounts of help, to the exclusion of almost anything else these last two days. Time to ration my supplies of help to you I think. Maybe others will chime in then. Pete

Have you definitely checked that they display the 9's correctly with GF's own software? If not then it sounds like a hardware fault. Ah, wait a minute -- didn't you say that the GF software got to +/- 9900 on the V/S? If it isn't hardware I can only think there's something wrong in the interface module, GFDev.DLL. Either that or they've done something mighty strange with the code I have to send for '9's, which seems very unlikely. Could you please try the slightly older GFDev.dll from my Updates announcement just in case they've messed something up in the newer version? The setting of these LED segments is simply by bits in a byte. Examples: The digit 0 is 3F (0011 1111) The digit 8 is 7F (0111 1111) .. one extra bit for the crossbar The digit 9 is 6F (0110 1111) .. like an 8 but losing a left-hand element. To get 9's changing to 0's would mean two bits being changed. Very strange. Let me summarise the problems: 1. LED missing, probably L23 -- easy for me to fix, and I will 2. Vis goes to +8800 and -8900 (care to amend that last, since 9's don't appear?). -- I've checked. I do not impose any limits -- that would be up to your parameters. Would the changing of 9's to 0's maybe misleading you there? 9900 -> 0000? For now I'll assume this is a 9's problem. 3. V/S and ALT divided by 10. -- This is a real mystery. Both of these were 5 digits displays on the non-Pro MCP and worked fine. I do have one possible qualm, with the altitude: D3.1=C0 X4E4 S16 *100 D-50 ; PMs Alt as (-)nnnnn D3.2=!C0 X7D4 S32 *3.28084 /65536 D-50 ; FSs Alt as (-)nnnnn These both require the Altitude display to be capable of 5 digits plus a sign -- which, unusually the non-Pro one was. Could, possibly, the MCPPro one not have this capability? If so then you might be simply losing a digit for a sign. (Real MCPs do not show negative Altitudes BTW, 00000 is the minimum). So try D50 instead of D-50 here. That wouldn't explain the V/S losing a digit though. 4. LEDs not being read (so only getting 1 set at a time) -- I think this is certainly a bug in GFDev.dll. The code is definitely correct here. It seems that the facility to read the state of the LEDs is not working. I can program around this, by remembering what has been set before. But this goes against the grain a bit -- I've always made GFdisplay cooperate with other programs using the same hardware. 5. The 9's changing to 0's everywhere (!) -- That's a real b****r. I can't see an easy way around that. It must surely be a bug in GFDev.dll, but i can't imagine what sort of bug could do that. If it was my segment tables (the ones for digits 0-9, A-Z, as per the examples above) getting corrupted it would affect 9's everywhere, on every device. There is another way of writing to displays, using plain text strings instead of lighting the segments up specifically. I could try that, just as an experiment. But I've never used them before so I'm not really sure how they work. I can guess though. Regards Pete

So, for instance. you get sequences like 298, 299, 300looking like 208, 200, 300? The routines to display the numbers are the same for every display, so can you please check the 9's on the others -- the speed, altitude and V/S? Pete

Okay. Done. It is exactly as I thought, and the same as other rotaries I've met. Each click turns the "switch" on or off. If you leave it in a position where it is "on" your original code will repeat its action forever. Really, with a rotary, it is the CHANGE from on to off and off to on which should be used, not its current state which is really unpredictable and therefore unusable. To prove that this was how it worked, and that this is correctly reflected in the Lua detection too, here is a little Lua test I used: while 1 do if ipc.testbutton(174,10) then rslow = 1 else rslow = 0 end if ipc.testbutton(174,11) then rfast = 1 else rfast = 0 end if ipc.testbutton(174,9) then lslow = 1 else lslow = 0 end if ipc.testbutton(174,8) then lfast = 1 else lfast = 0 end ipc.log("Dial1 State = " .. rslow .. "," .. rfast .. "," .. lslow .. "," .. lfast ) ipc.sleep(100) end and here's an extract of the FSUIPC log which I obtained when moving the rotary a bit one way or the other (I've deleted most of the repeated lines at 100 mSec intervals). I also had Button logging enabled so you could see exactly where I turned the rotary: 3264266 LUA: Dial1 State = 1,0,0,1 3264375 LUA: Dial1 State = 1,0,0,1 3264469 LUA: Dial1 State = 1,0,0,1 3264578 LUA: Dial1 State = 1,0,0,1 3264672 LUA: Dial1 State = 1,0,0,1 3264703 JoystickValues joynum=0, dwCount=1, data[2]={000000ae 00000700} 3264781 LUA: Dial1 State = 1,0,1,1 3264875 LUA: Dial1 State = 1,0,1,1 3264984 LUA: Dial1 State = 1,0,1,1 3265078 LUA: Dial1 State = 1,0,1,1 ... 3266094 LUA: Dial1 State = 1,0,1,1 3266203 LUA: Dial1 State = 1,0,1,1 3266250 JoystickValues joynum=0, dwCount=1, data[2]={000000ae 00000300} 3266297 LUA: Dial1 State = 0,0,1,1 3266406 LUA: Dial1 State = 0,0,1,1 3266500 LUA: Dial1 State = 0,0,1,1 ... 3267312 LUA: Dial1 State = 0,0,1,1 3267375 JoystickValues joynum=0, dwCount=1, data[2]={000000ae 00000700} 3267422 LUA: Dial1 State = 1,0,1,1 3267516 LUA: Dial1 State = 1,0,1,1 3267625 LUA: Dial1 State = 1,0,1,1 ... 3268234 LUA: Dial1 State = 1,0,1,1 3268328 LUA: Dial1 State = 1,0,1,1 3268375 JoystickValues joynum=0, dwCount=1, data[2]={000000ae 00000300} 3268406 JoystickValues joynum=0, dwCount=1, data[2]={000000ae 00000b00} 3268437 LUA: Dial1 State = 0,1,1,1 3268437 JoystickValues joynum=0, dwCount=1, data[2]={000000ae 00000300} 3268469 JoystickValues joynum=0, dwCount=1, data[2]={000000ae 00000b00} 3268500 JoystickValues joynum=0, dwCount=1, data[2]={000000ae 00000300} 3268531 LUA: Dial1 State = 0,0,1,1 3268641 LUA: Dial1 State = 0,0,1,1 ... 3271078 LUA: Dial1 State = 0,0,1,1 3271109 JoystickValues joynum=0, dwCount=1, data[2]={000000ae 00000100} 3271141 JoystickValues joynum=0, dwCount=1, data[2]={000000ae 00000000} 3271172 LUA: Dial1 State = 0,0,0,0 3271187 JoystickValues joynum=0, dwCount=1, data[2]={000000ae 00000100} 3271219 JoystickValues joynum=0, dwCount=1, data[2]={000000ae 00000000} 3271250 JoystickValues joynum=0, dwCount=1, data[2]={000000ae 00000100} 3271281 LUA: Dial1 State = 0,0,0,1 3271312 JoystickValues joynum=0, dwCount=1, data[2]={000000ae 00000000} 3271375 LUA: Dial1 State = 0,0,0,0 3271484 LUA: Dial1 State = 0,0,0,0 3271578 LUA: Dial1 State = 0,0,0,0 So, my conclusion is that everything works as intended, and your results were basically arising from a misinterpretation, plus bad luck in always leaving the rotaries in an "on" position. I think you should be fine using the "event" system instead, though it may depend how fast those routines you are using are. If you continue using a loop instead you will have to make it check for off so you know when the on means something (and vice versa if you want action on every click). Oh, this also means that, for rotaries, in the event solution, you should realy use the parameter "3" instead of "1" so that you get something happening on every click, not only on the "off-to-on" clicks. Regards Pete

Okay, thanks. Useful info. Yes. I actively disable LED numbers which GF says aren't connected. They probably wouldn't do any harm, but you never know! ;-) Yes, I understood the first time. I'll re-check my code, but if that is okay I'll need to do it the less friendly way, assuming GFdisplay owns the LEDs exclusively. Regards Pete

You mean Event logging? FSUIPC can only intercept and log controls sent through FS's "clearing house", the place where it directs all the controls to their correct places. I am guessing that the GPS is relatively self-contained, that it need not send controls to FS's main routines only to be redirected back for it to action. Evidently the FS controls were added by the FS programmers merely to allow key or button assignment to them. I just wish they'd done that with all of them, and that add-on panel makers would do likewise! ;-) Regards Pete

The limits on the V/S might be correct. I'll check though. I've not even got an MCP non-Pro to test on these days. Not sure why they should be divided by 10, as I'm using the same code as for the non-Pro model. How many digits do the displays have? L130? The numbers only go up to 31 max in any case. I suspect the right FD LED is #23 -- it is marked in the GoFlight SDK doc I have as not connected, though. I'll try enabling it for you. Hmm. That implies that the facility to read the lights isn't working, which is a worry. It works okay on all the other units. If GFdisplay is the only thing using the displays then I could do it by remembering the last value written, but generally GFDisplay is designed to be able to share functions with the GoFlight software, or even with other copies of GFDisplay on other WideFS client PCs. I don't remember much of this stuff, but those lines seem to imply that the ALT display has 5 digits plus sign, and the V/S has 4 plus sign. Can you confirm exactly how many digits there are please? I might be mis-viewing the photos on their website. Regards Pete

I realise that, but you were describing the phenomena as something you thought you discovered, even though I'd told you before (and it being stated in the documentation), and you also misconstrued it as being FS somehow realising that FSUIPC was using the keystroke. No, no. You are wrong again, still, and clearly disregarding things I have told you and files I have referred you to. FSUIPC is not using any names it invents itself, it is using the names in FS. I showed that to you. Please just go look at the Keyboard assignments in your FS9.CFG file for proof. I'm sorry, but it doesn't appear it is. :-( No idea what this is about, sorry. Send a string of what to where? Are you sure there's no keystroke? All panels are normally switchable by the assortment of PANEL controls, by default assigned to Shift+0 to 9. There's also an FS command from calling up a panel by ID, using the ID as parameter. You'd need to get the ID for any non-standard panel from the PAnel.CFG file for the aircraft. Centre it where? That makes no sense. The heading bug relates to a selected heading. Perhaps you really mean to set the heading bug to match the current heading? In other words a "heading lock"? Okay. Those by default are Shift+1 (the main keyboard 1) and Shift+2. The first normally toggles the main panel and the second will toggle a different panel. You can do the same on a button by programming those control. Use a parameter of 1 on the Press and 2 on the Release. That's the same -- you are simply toggling the same views back again to where they were. Unless you've reassigned the keys, you should find exactly the same happens using keystroke Shift+1 followed by Shift+2, or vice versa. The parameter goes into the little edit box obscurely labelled "parameter". But you can't set two parameters in the same box! If you want to avoid the complication of editing the INI file to assign two actions to the button press, just do one action on the press and the other on the release. I don't teach. :shock: Sorry, I don't have the patience for that as you must surely have noticed? :? Pete

I'm glad it is being found useful! Regards Pete

There was no such bug in that area, and it worked okay here in all the tests I did. Sorry, but I am going to need specific examples again if you find different. Pete

No, that's not true -- the KEYpress you use will not be available. FSUIPC cannot stop the FS functions being available. Oh dear. Have you not even bothered to read ANY of my replies to you? I truly am wasting my time! :-( I already told you. If you assign a keypress in FSUIPC, it will be taken by FSUIPC. FS will never see it. FS does not "know" FSUIPC has it, it just doesn't see it. This is clearly documented and I've told you several times already! If I try to find the FS2004 functions listed in the FSUIPC pull down lists, they are not there, or named something else. They are not listed as FS lists them. Thus, you can see the confusion! I told you how to work that out, but you ignore me. Use logging. I explained that to you also, at length, and with references. In the menus FS uses DESCRIPTIONS not NAMES. The descriptions will be different in each version and in each language. The NAMES don't vary. It is the only way FSUIPC or anything else outside of FS's menus can operate! :roll: :roll: I hope not to hear from you again until and unless you bother to read what I've been writing. Pete

Still not tested this here -- probably this afternoon or tomorrow morning. However, I have some thoughts which I think are relevant. First, you are testing buttons in a loop. You act when they are pressed. For any given press you will be acting a variable number of times which is not regulated by the button repeat setting in FSUIPC's INI file. Since you don't check for the button being released you cannot regulate it yourself. Second, you need to understand how the rotary switches operate. Most of those I know provide pulse when turnedf - on, off, on, off. Usually one of these per 'click'. So when you stop turning, the current state may be 'on' or 'off' -- you can't tell from the switch position. So, question: are you perhaps thinking they are always 'on' in the Lua testing simply because, after turning, they are being left parked in the 'on' position? Can you try a single click turn ansd see if that turns them off? If so, then there's your answer. If not then I suspect the particular way the rotaries work (or are wired) on the GoFlight units are such that it only pulses "off" when turned, and always parks in an "on" position. If this is the case you could perhaps reverse your logic -- only act when it is off, rather than on. There wouldn't be any difference in the outcome. I wil check this myself when I get my RP48 connected. Really, the answer is to do it a different way. Use the event facilities in FSUIPC's Lua libraries so that you only act when the buttons change instead of sitting in a loop polling them. In fact it was fpr applications such as yours that the event system was devised. Here's a re-working of your code using events (untested): joynumdial = 157 joynumbutt = 158 bincaltslow = 10 bincaltfast = 11 bsynchdg = 12 function joyaltslow(joy, btn, downup) -- Increase Alt slow rotateALTKnob("R", 0) changeALT(100) end function joyaltfast(joy, btn, downup) rotateALTKnob("R", 1) changeALT(2500) end function joysynchdg(joy, btn, downup) SyncHDG() end -- Replace '1's in these lines by 3 for action on both "on" and "off": event.button(joynumdial, bincaltslow, 1, "joyaltslow") event.button(joynumdial, bincaltfast, 1, "joyaltfast") event.button(joynumbutt, bsynchdg, 1, "joysynchdg") See? No loops, just actions on button presses. If you want twice the speed, act on both presses and releases (downs and ups) -- change the "downup" parameter in the event calls. I will check the behaviour of the GF rotaries, though, to confirm my suspicions (or otherwise). :-) Regards Pete

So you were only reading 4 bytes, not 8? It does say it is an 8-byte (64-bit) value. How did you know to divide by (65536*65536) if you didn't know you had the fractional part? For example, if this: was talking about the fractional part, then you already have that: in metres the fraction is 2.92/3.28084. (Naturally the fractional part can't be as much as 1 metre). So if the integer part is, say, 53 metres, the whole answer is 53 + (2.92/3.28084) metres, or 53 * 3.28084 + 2.92 feet. This works okay provided the altitude is always zero or positive. If the integer is negative, so too will be the fraction, so you would subtract the fraction, not add it. It is actually much easier if the compiler / language you are using contains 64-bit integer facilities. Then simply read the 8 bytes into a 64-bit integer and then do the calculations as you were. In MSC/C++ a 64-bit integer is defined by __int64. I think also "long long" works in some compilers. Pete

Ah, sorry. It's late. I was thinking it was an abbreviation for an addon aircraft, perhaps the PMDG JS41? Not sure what you mean there. If you assign CTRL+S to something in FSUIPC, then it isn't going to be seen by FS as FSUIPC will get it first. If you assign it to something different in FS, it will do that different thing. Where does "duplicate entry" come into it? There are NO "equivalent FSUIPC commands", because, as I thought I explained, there's no such thing as FSUIPC commands for FS functions. Those are FS commands. All FSUIPC does is list them for you using the FS names for FS commands. "View -Switch To Top Down" is a description, it is NOT the name FS uses internally nor therefore the name FSUIPC uses. Please re-read my last reply. You seem to have only read as far as "JS"! I am wasting my time trying to help if you don't read what i write! :-( If you ever want to find the true FS name for a control, just use FSUIPC's Event logging, then use the FS control and see in the log both the name and its number. I've just done that in FS9 and this is what I get for those two you can't find: CTRL-S: 145360 *** EVENT: Cntrl= 65829 (0x00010125), Param= 0 (0x00000000) VIEW_TYPE W: 151875 *** EVENT: Cntrl= 66404 (0x00010364), Param= 0 (0x00000000) PANEL_HUD_TOGGLE Oh. "CTRL+W" does not, by default, do "panel on-off", it creates a separate chase window instead. It's log line is: 698782 *** EVENT: Cntrl= 66500 (0x000103c4), Param= 0 (0x00000000) KEY_CHASE_VIEW_NEXT There's NEVER been any change in any version which would EVER allow keypresses programmed in FSUIPC to get through to do anything in FS! Oh, and as promised, now I know which version of FS you are talking about, all of the Keyboard assignments are detailed, using the names you incorrectly refer to as "FSUIPC Commands", in the FS9.CFG file, in the section headed [KEYBOARD_MAIN]. There's also a section headed [KEYBOARD_SLEW] which details the differences in Slew mode. The lines in [KEYBOARD_MAIN] relating to your Ctrl+S and W keys are: Ctrl+S: VIEW_TYPE=83,10 W: PANEL_HUD_TOGGLE=87,8 Ctrl+W: KEY_CHASE_VIEW_NEXT=87,10 Note the keycodes, which are the same used by FSUIPC in its INI file and documented in FSUIPC's Advanced User's guide. Pete

In that case it doesn't use any. Regards Pete

What's a "JS"? Are you talking about FS2004, FSX, or one of the older FS versions? I don't know how you'd lose them in FS. Sounds like one of your FS files is corrupted. I know FSX uses an XML file to define all of its keyboard commands. FSUIPC doesn't interfere or change anything like that. But if you program FSUIPC to use keys for other functions, then they'll not get through to FS. FSUIPC will intercept them and act on them as you've programmed. Hmm. Never used that. In FSX I think the default key for that is F12, but I'm only going by what others tell me. The FS control name is probably "View down" (not really so obscure?). Not sure about that one. "Full window toggle" maybe? Or perhaps "View mode". Oddly enough the "." key for brakes uses a command simply called "Brakes". Again, not terribly obscure. Why not use the list of controls I publish and try those which seem likely? It shouldn't be that hard. If you were to actually mention the version of FS you are using I might even be able to point you to the correct file in FS where they are defined. ;-) FS doesn't have any functions for FS controls -- they are all FS's own, and the names in the FSUIPC dropdowns are those defined by FS in its CONTROLS module, and are the names used internally and in that file I mentioned. FS's menus for assigning controls don't give you the names, but a description, which is different in different languages. Regards Pete

Well, I would be too, because I do not know anything about VB. Well, I can help with C, C++ and Assembly Code even, but not Basic, C# or Delphi. Sorry. Perhaps if you posted the questions you just asked me in a new thread with something like "Help with VB please!" in the title, some kind soul will be able to advise. Regards Pete