mtjoeng Posted November 19, 2009 Report Share Posted November 19, 2009 hi i'm stuck here in my FSX [Keys.PMDG747-400] 16=72,25,M9:8,0 17=221,25,L2:R,0 '25' is registered for Shift+Tab (221 = ']') in pmdg Keyboard my - test - cargo door is Cargo Fwd SHIFT+TAB+4 and works I want more doors to open with 1 button, so I put this in a Lua, and test a Lua with 1 door first starts the problem how comes that Shift+Tab = '25'? Advanced FSUIPC doc: '1 Shift 4 Tab 8 Normal (add this in anyway)' Shift+Tab adds up to '13' ? [LuaFiles] 1=log lvars 2=pmdg747cargodoor my lua (L2) file pmdg747cargodoor.lua contains 1line: ipc.keypressplus(52,25) -- Cargo Fwd SHIFT+TAB (25/13?) +4 (52) neither value 25 or 13 does anything is assigned to Key 17=90,25,L2:R,0 90 = shft+tab+Z, and 'lua pmdg747cargodoor' selected from the dropdown what am I missing? thx mt FSUIPC 4549 FSX pmdg747x windows 7 x64 Link to comment Share on other sites More sharing options...
Pete Dowson Posted November 19, 2009 Report Share Posted November 19, 2009 how comes that Shift+Tab = '25'? As per Advanced User's document: shifts 8 normal +1 shift +2 control +4 alt (not really very useful) +16 tab (an added "shift" to give more combinations) +32 Windows key (left or right) +64 Menu key (the application key, to the right of the right Windows key) 8 + 1 +16 = 25. Advanced FSUIPC doc:'1 Shift 4 Tab 8 Normal (add this in anyway)' Shift+Tab adds up to '13' ? You aren't reading the correct chapter. you are looking at the Keypress-to-control encoding, where FSUIPC has to trap a key from the keyboard. That's windows encoding. The code for keys being pressed from buttons is documented in the Button section, which you are not reading! I would have preferred both systems were the same, but there's a long history as to why they are not, and the difference is pointed out in the docs. what am I missing? No idea. I find your dissertation rather confusing. Could you show me the relevant files or at least whole sections of them, please -- Luafiles, buttons and the Macro file. Asd some explanation of exactly what you are trying to achieve and why it has to be so complex. Surely you don't need to use Lua just to press some keys? What's that about? And why "KeyPressPlus"? Are you trying to change focus? Regards Pete Link to comment Share on other sites More sharing options...
mtjoeng Posted November 19, 2009 Author Report Share Posted November 19, 2009 [LuaFiles] 2=pmdg747cargodoor pmdg747cargodoors.LUA : ipc.keypress(52,25) sorry about the "KeyPressPlus", now changed to "KeyPress" [Keys.PMDG747-400] 18=90,25,L2:R,0 PMDG_747-400_Kbd.ini : Cargo Fwd SHIFT+TAB+4 thus SHIFT+TAB+Z should run pmdg747cargodoors.LUA pmdg747cargodoors.LUA presses SHIFT+TAB+4 SHIFT+TAB+4 opens the CargoFwdDoor (that is does on its own) doesnt ? the purpose of this exercise is to fill the Lua with ipc.keypress(52,25) ipc.keypress(xx,25) ipc.keypress(xx,25) that opens 3 or any amount of doors (the pmdg has a lot of them) mt Link to comment Share on other sites More sharing options...
Pete Dowson Posted November 20, 2009 Report Share Posted November 20, 2009 SHIFT+TAB+Z should run pmdg747cargodoors.LUA pmdg747cargodoors.LUA presses SHIFT+TAB+4 SHIFT+TAB+4 opens the CargoFwdDoor (that is does on its own) doesnt Ouch. I think the problem here is that it will be trying to do the Shift+Tab+4 before you've released the Shift+Tab+Z. So the KeyUps from the latter get entangled with the KeyDowns and Ups of the former, leading to a right old mess. Just enable Keys and Buttons logging and you'll probably see what I mean! Just to prove it, try putting an ipc.sleep(1000) in the Lua file before the KeyPress, and make sure you don't keep your fingers down on those keys too long. the purpose of this exercise is to fill the Lua withipc.keypress(52,25) ipc.keypress(xx,25) ipc.keypress(xx,25) that opens 3 or any amount of doors (the pmdg has a lot of them) It would be far easier to do with a button. And no need for a Lua program either -- just program the button to send all three (or more) keypresses. Do you really want to control this aircraft with keyboard? If so, and if it needs all those keystrokes, then you'll need to have some way of being sure not to press real keys whilst the Lua program is doing its stuff. Regards Pete Link to comment Share on other sites More sharing options...
mtjoeng Posted November 20, 2009 Author Report Share Posted November 20, 2009 It would be far easier to do with a button. .. Do you really want to control this aircraft with keyboard? .. you'll need to have some way of being sure not to press real keys whilst the Lua program is doing its stuff. it's my VRInsight MCP Combo, all its buttons can only be programmed by keystrokes, so that makes it 'a keyboard' there's no HID interface for the VRInsight MCP Combo, with its 50+ buttons and some dials, the manufacturer says with so many buttons and dials, it ran off the specs of windows Joysticks definition then on top, the PMDG Doors etc. also can only be interacted with by keystrokes, hence the issue didnt know there's a whole electonic pulses issue behind this, figures after you hear of this perhaps I'm overlooking something or else I guess I am sort of stuck, and use 1 door > 1 button when you can think of some way to try, of course I like to hear thx, mt [later] hum, found key 'V' isnt used for anything in FSX, I'll try with shorter keystrokes Link to comment Share on other sites More sharing options...
Pete Dowson Posted November 20, 2009 Report Share Posted November 20, 2009 it's my VRInsight MCP Combo, all its buttons can only be programmed by keystrokes, so that makes it 'a keyboard' Ugh. there's no HID interface for the VRInsight MCP Combo, with its 50+ buttons and some dials, the manufacturer says with so many buttons and dials, it ran off the specs of windows Joysticks definition That's not right. A keyboard is a HID, as is a mouse. Anything using the HID protocol is a HID. It is only the joystick type which has some limitations. PFC's latest devices are USB HID devices (I know because I wrote the FS driver for them). You get up to 32 buttons (64 with DX9), 4 POVs, and 8 axes on each HID joystick type device, but a single USB connection can register itself with any number of devices. Additionally, if you do your own driver, you can have any protocol you like on a HID -- PFC dfevices do both. It sounds like, to keep the cost down, they incorporated a cheap keyboard interface circuit. Which is okay, provided you don't use the keyboard too as they would interfere. perhaps I'm overlooking something or elseI guess I am sort of stuck, and use 1 door > 1 button The solution should be that their driver should allow you do produce more than one keysdtroke with any one button. That would solve it. If you are trying to make keystrokes from keystrokes you'll probably have to put delays in, as I said, and avoid doing something else afterwards too quickly. Experimentation is the key. hum, found key 'V' isnt used for anything in FSX, I'll try with shorter keystrokes Why worry about things used in FS? If you program a key in FSUIPC it won't reach FS. If the keypresses are being produced by pressing the buttons, or by a driver in the PC, it may be that you don't need much of a "Sleep" delay in the Lua program. I'd be interested in seeing the log with Button and Key logging enabled to see why you aren't getting the results you expect. One possibility which worries me is that the VRInsight driver may not be sending the KeyUp messages fpr a;; parts of its keyboard combinations. Regards Pete Link to comment Share on other sites More sharing options...
Andydigital Posted November 20, 2009 Report Share Posted November 20, 2009 Its not a keyboard emulator. Link to comment Share on other sites More sharing options...
Pete Dowson Posted November 20, 2009 Report Share Posted November 20, 2009 Its not a keyboard emulator. So, can it be programmed to send anything other than keystrokes, or, if not, can it be programmed to send more than one keystroke per button push? That might solve MT's problem? Seems VRInsight will be sending me a unit soon, so I can try things myself. I would be better placed to help then, as I do with PFC and GoFlight stuff. Maybe the keystrokes are generated not in the unit but in a driver in the PC? If that's the case and there's an SDK or other implementation information, and it isn't too much work, I could add support into FSUIPC as I do for Goflight, EPIC and PFC. Regards Pete Link to comment Share on other sites More sharing options...
Andydigital Posted November 20, 2009 Report Share Posted November 20, 2009 That's excellent news Pete I thought they would send you some hardware now that you have finally managed to make contact with them. The way it currently works you can turn button presses on the panels hardware to keystrokes if you wish, but the software also allows you to emulate mouse interactions with 2D panels too, the biggest downside with this method though is the panel has to be in view for the commands to function, its not like your mouse macros at all. Some of the functions on the panels can send two different commands on the one button, for example the push function on some of the dials can have two different commands assigned to them, but they will always cycle from one to the other function, they appear as push 1 and push 2 in the assigning software. The link below will download the latest software package, if you take a look at the MCP combo key mapper program you will get a better idea what I mean. http://vrinsight.com/download/setup_no_doc.exe EDIT: yes I think the keytrokes are made in the driver/software, there is an SDK but it is beyond my undesrtanding I'm afraid, I think there are some examples included in one of the versions of the software even if its not included in this latest download shown above. Link to comment Share on other sites More sharing options...
Pete Dowson Posted November 20, 2009 Report Share Posted November 20, 2009 Hi mt, I must apologise. It was I who was confused about those damn shift codes. The 25 is correct for Shift+Tab KeyPress encoding, for RECEIVING keypresses (as listed in the Keys programming part of the Advanced Users guide). But that means Shift+Alt for SENDING keys to FS or other programs. This mix up is dreadful, and a silly result of historical developments, some based on Windows shift codes and others based on older FS encodings. For SENDING keystrokes the shift codes are those listed in the Buttons programming part of the Advanced User's guide. i.e. The value is a combination (add them) of the following values, as needed: 1 Shift 2 Control 4 Tab 8 Normal (add this in anyway) 16 Alt (take care with this one—it invokes the Menu) 32 Windows key (left or right) 64 Menu key (the application key, to the right of the right Windows key) So your Shift+Tab would be 13. The end result is that whilst your FSUIPC INI entries would be correct with 25, these are wrong in the Lua: ipc.keypress(52,25)ipc.keypress(xx,25) ipc.keypress(xx,25) Those should be 13. I still think there might be a problem with overlapping, but that might not be too great a problem if the VRInsight driver sends the KeyUps quickly after the KeyDowns. You may still need a "sleep" in the Lua, but possibly a small one. The log will show. I'll do some log examples and post them so you can see what to look for. Regards Pete Link to comment Share on other sites More sharing options...
Pete Dowson Posted November 20, 2009 Report Share Posted November 20, 2009 I'd be interested in seeing the log with Button and Key logging enabled to see why you aren't getting the results you expect. I tried some experiments here, just with the keyboard and a Lua program. Here's a Log Extract showing what happens without that delay (comments added after ****). Note that the important lines are those starting "KEYDOWN:" and "KEYUP:" (after the time in milliseconds). Those record when Windows actually processed the keyboard messages. 2782765 KEYDOWN: VK=16, Waiting=0, Repeat=N, Shifts=1 2782765 .. Key not programmed -- passed on to FS 2783093 KEYDOWN: VK=9, Waiting=0, Repeat=N, Shifts=17 2783093 .. Key not programmed -- passed on to FS 2783593 KEYDOWN: VK=9, Waiting=0, Repeat=Y, Shifts=17 2783593 .. Key not programmed -- passed on to FS 2783625 KEYDOWN: VK=9, Waiting=0, Repeat=Y, Shifts=17 2783625 .. Key not programmed -- passed on to FS 2783656 KEYDOWN: VK=9, Waiting=0, Repeat=Y, Shifts=17 2783656 .. Key not programmed -- passed on to FS 2783687 KEYDOWN: VK=9, Waiting=0, Repeat=Y, Shifts=17 2783687 .. Key not programmed -- passed on to FS 2783703 KEYDOWN: VK=90, Waiting=0, Repeat=N, Shifts=17 2783703 .. This key is programmed in FSUIPC 'Keys' options **** Shift+TAB+Z recognised 2783703 LUA: beginning "E:\FS9\MODULES\SendSomeKeys.lua" **** Lua started 2783703 FSUIPC Control Action: Ctrl=1070, Param=3380 **** Lua "keypress" translates into FSUIPC control 1070 2783703 SendKeyToFS(000C0034=[shft+tab+4], KEYDOWN) ctr=0 2783703 Sending WM_KEYDOWN, Key=16 (Shift) (Scan code 42), Ctr=3 2783703 Sending WM_KEYDOWN, Key=9 (Tab) (Scan code 15), Ctr=3 2783703 FSUIPC Control Action: Ctrl=1070, Param=3381 2783703 SendKeyToFS(000C0034=[shft+tab+4], KEYUP) ctr=1 2783703 SendKeyToFS(000C0035=[shft+tab+5], KEYDOWN) ctr=4 2783703 FSUIPC Control Action: Ctrl=1070, Param=3382 2783703 SendKeyToFS(000C0035=[shft+tab+5], KEYUP) ctr=7 2783703 SendKeyToFS(000C0036=[shft+tab+6], KEYDOWN) ctr=10 2783703 LUA: ended "E:\FS9\MODULES\SendSomeKeys.lua" 2783703 KEYDOWN: VK=16, Waiting=0, Repeat=Y, Shifts=17 2783703 .. Key not programmed -- passed on to FS 2783703 KEYDOWN: VK=9, Waiting=0, Repeat=Y, Shifts=17 2783703 .. Key not programmed -- passed on to FS 2783734 Sending WM_KEYDOWN, Key=52 (Scan code 5), Ctr=13 2783734 KEYDOWN: VK=52, Waiting=0, Repeat=N, Shifts=17 2783734 .. Key not programmed -- passed on to FS ***** Shift+TAB+4 pressed and seen (invoked a panel in FS via Shift+4, as I hadn't programmed it otherwise) 2783781 Sending WM_KEYUP, Key=52 (Scan code 5), Ctr=12 2783781 KEYUP: VK=52, Waiting=0 ***** One of the keys just send by Lua gets its KEYUP already 2783812 Sending WM_KEYUP, Key=9 (Tab) (Scan code 15), Ctr=11 2783812 Sending WM_KEYUP, Key=16 (Shift) (Scan code 42), Ctr=11 2783812 Sending WM_KEYDOWN, Key=16 (Shift) (Scan code 42), Ctr=11 2783812 Sending WM_KEYDOWN, Key=9 (Tab) (Scan code 15), Ctr=11 2783812 KEYUP: VK=90, Waiting=0 ***** Only now does the release of the original "Z" come through. 2783812 KEYUP: VK=9, Waiting=0 ***** But whose TAB is that releasing? 2783812 KEYUP: VK=16, Waiting=0 ***** And whose SHIFT? 2783812 KEYDOWN: VK=16, Waiting=0, Repeat=N, Shifts=1 2783812 .. Key not programmed -- passed on to FS 2783812 KEYDOWN: VK=9, Waiting=0, Repeat=N, Shifts=17 2783812 .. Key not programmed -- passed on to FS 2783843 Sending WM_KEYDOWN, Key=53 (Scan code 6), Ctr=7 2783843 KEYDOWN: VK=53, Waiting=0, Repeat=N, Shifts=17 ***** The second Lua keypress combo arrives 2783843 .. Key not programmed -- passed on to FS 2783875 Sending WM_KEYUP, Key=53 (Scan code 6), Ctr=6 2783875 KEYUP: VK=53, Waiting=0 ***** The '5' is released 2783906 Sending WM_KEYUP, Key=9 (Tab) (Scan code 15), Ctr=5 2783906 Sending WM_KEYUP, Key=16 (Shift) (Scan code 42), Ctr=5 2783906 Sending WM_KEYDOWN, Key=16 (Shift) (Scan code 42), Ctr=5 2783906 Sending WM_KEYDOWN, Key=9 (Tab) (Scan code 15), Ctr=5 2783906 KEYUP: VK=9, Waiting=0 ***** Another TAB and Shift KEYUP pair 2783906 KEYUP: VK=16, Waiting=0 2783906 KEYDOWN: VK=16, Waiting=0, Repeat=N, Shifts=1 2783906 .. Key not programmed -- passed on to FS 2783906 KEYDOWN: VK=9, Waiting=0, Repeat=N, Shifts=17 2783906 .. Key not programmed -- passed on to FS 2783921 SendKeyToFS(000C0036=[shft+tab+6], KEYUP) ctr=1 2783937 Sending WM_KEYDOWN, Key=54 (Scan code 7), Ctr=4 2783937 KEYDOWN: VK=54, Waiting=0, Repeat=N, Shifts=17 2783937 .. Key not programmed -- passed on to FS 2783968 Sending WM_KEYUP, Key=54 (Scan code 7), Ctr=3 2783968 KEYUP: VK=54, Waiting=0 2784000 Sending WM_KEYUP, Key=9 (Tab) (Scan code 15), Ctr=2 2784000 Sending WM_KEYUP, Key=16 (Shift) (Scan code 42), Ctr=2 2784000 KEYUP: VK=9, Waiting=0 2784000 KEYUP: VK=16, Waiting=0 2784687 KEYUP: VK=9, Waiting=0 2784718 KEYUP: VK=16, Waiting=0 Now, whether by luck or design, the original keypresses and the Lua generated ones both use Shift+TAB. So maybe the timing of those going up doesn't matter. The only key we don't want to overlap is that 'Z'. Its release was at time 2783812. Subtract from this the time the Lua started (2783703), and you see that we need a delay of only a bit more than 109 msecs. That's with me releasing the keys pretty quickly. So, I'll try 300. Compare this now with the same example with a 300 mSec delay in the Lua, before the first keypress: (I've removed the stuff before the Lua and after the 'Z' release: 3694312 LUA: beginning "E:\FS9\MODULES\SendSomeKeys.lua" 3694406 KEYUP: VK=90, Waiting=0 See? The whole of the Lua action is now okay. If you used different Shifts in the Lua to that in the instigating keypresses, you'd need to allow the time for those too. I'm guessing that, with the VRInsight driver, the whole set of KEYUPs will arrive together and in pretty quick time, so you may get away with no sleep or a very short one. You wouldn't really notice a 300 mSec delay in any case. Hope this helps, and sorry about my confusion earlier! Regards Pete Link to comment Share on other sites More sharing options...
Pete Dowson Posted November 20, 2009 Report Share Posted November 20, 2009 EDIT: yes I think the keytrokes are made in the driver/software, there is an SDK but it is beyond my undesrtanding I'm afraid, I think there are some examples included in one of the versions of the software even if its not included in this latest download shown above. I'll install the software when the unit arrives. I've got the manual and the interface document, but see no sign of any SDK. In fact they imply that they USE the SDK's (e.g. from FSUIPC and Level D) but they write the interface. If they have a DLL which can be accessed like Goflight's one, for reading their switches, then that would be interesting. If there is an SDK, can you give me the link, please? Regards Pete Link to comment Share on other sites More sharing options...
Andydigital Posted November 20, 2009 Report Share Posted November 20, 2009 It's inside the installer Pete, there is no other way to get it as far as I know sorry. Let me send you a link to zip version of the installed folder to give you an idea so you dont have to install. I'll email you a link to it when I'm done. Link to comment Share on other sites More sharing options...
Andydigital Posted November 20, 2009 Report Share Posted November 20, 2009 Email sent Pete. Link to comment Share on other sites More sharing options...
Pete Dowson Posted November 20, 2009 Report Share Posted November 20, 2009 Email sent Pete. Thanks. Downloaded now. I'll take a look a little later. Bit busy right now. Best Regards Pete Link to comment Share on other sites More sharing options...
mtjoeng Posted November 20, 2009 Author Report Share Posted November 20, 2009 emulate mouse interactions .. not like your mouse macros at all .. the panel has to be in view - unfortunately - lots of times, this defeats the purpose Some of the functions on the panels can send two different commands on the one button .. some of the dials can have two different commands assigned to them, but they will always cycle .. they appear as push 1 and push 2 in the assigning software. 'they appear as push 1 and push 2 in the assigning software' is for ALT SPD and HDG and a Hardware 'state 2' of the dial (shows an *-asterix on the LED in this state - and this seems not documented), and is not what is meant in 'FSUIPC-speak' with 'can the button send multiple commands'. They can Not (in the present interface, called 'serialFP2'). pleasantly surprised, Pete, you can have a look at the SDK present SDK seems to invite manufacturers to assign specific commands to Buttons and Dials. That's not good. We (tout le monde, of course ;) ) want Any command (and fsuipc mouse macros) be asignable to Any dial or button (and more! Pigs Can Fly) cheerio mt Link to comment Share on other sites More sharing options...
Pete Dowson Posted November 20, 2009 Report Share Posted November 20, 2009 pleasantly surprised, Pete, you can have a look at the SDK That's not going to give you an immediate solution, even if I decide it looks like a worthwhile avenue to go down. present SDK seems to invite manufacturers to assign specific commands to Buttons and Dials.That's not good. Sorry, I don't understand that part. Maybe i will whenm I've looked into it? Have you tried my suggestions, like with a small delay? Have you tried even with the shift codes corrected? I'm reasonably sure you should achieve success. Regards Pete Link to comment Share on other sites More sharing options...
mtjoeng Posted November 20, 2009 Author Report Share Posted November 20, 2009 me very embarrassed :oops: :oops: :oops: good news, good news & embarrassing news Shift-Tab needs to be 25 in fsuipc.ini, checked and correct Shift-Tab needs to be 13 in LUA, checked and correct first time I ever started a Button Log and said: "675172 LUA: "pmdg747cargodoor.lua": not found" that was a surprise because my LUA was named "pmdg747cargodoors.lua" then I put my glasses on and saw it was 1 character too long for fsuipc (same in the dropdown, 'door'), changed it to "pmdg747cargodoor.lua", et voila, 3 cargo doors open much obliged, mt Link to comment Share on other sites More sharing options...
Pete Dowson Posted November 21, 2009 Report Share Posted November 21, 2009 ... et voila, 3 cargo doors open Good. All's well that ends well! ;-) Pete Link to comment Share on other sites More sharing options...
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