Pete Dowson

There's no 'C' for Control in the Keys parameters -- it is only needed in the Buttons parameter section to distinguish Keys from Controls, but you can't program a key to send a key. (I should probably have accepted the 'C' for consistency). 117,26 is Ctrl+Tab+F6. I assume that's what you programmed the device to send? Just the 'C' I think. Yes, that should work, but without the C.. Regards Pete

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

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

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: 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

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

Ugh. 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. 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. 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

Yes, don't worry. He's evidently not read the thread in any case -- your problem is not one of installation at all. Something is obviously wrong, but it is something which I've never heard of occurring before, and so quite mystifying. After all, if there was something wrong with the joystick drivers the problem would also affect the Buttons tab too, and the Axis Assignments tab. Could you show me your FSUIPC.INI file, please, the one you'll find in the FS Modules folder? Just paste it into a message here -- if you enclose it using the "Code" button, just above where you enter messages, it will keep the message quite compact still. Hmm. If you do that, check that FSUIPC works at each stage, so we can tell at which point things go awry. You only need save the FSUIPC.KEY and FSUIPC.INI files. You can always download FSUIPC -- the latest one, in the Announcements above, will probably be different from the one you have in any case. I'd like to understand what the problem is, so do please post your INI file and I'll look into it from that end whilst I await the results of your reinstallations. Regards Pete

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. 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

Two ways, up to you. With just [buttons] entries, you can make a set of entries for each of the two effective buttons (clockwise and counterclockwise). In each of the two sets you have one unconditional entry which uses "Offset Byte Cyclic Increment" (clockwise) or "... Decrement" (counter-clockwise) to change a user-available offset (e.g x66C0 -- all of those from x66C0 to x66FF are available to users). Then you have a conditional entry, for the same button, for each of the cyclic values that offset can take, one for each of the controls you wish to send. Conditional entries based on offset values are the same as ordinary button entries but preceded by the condition, for example B66C0=1. Check the section in the Advanced User's document headed "ADDING OFFSET CONDITIONS". If you want to see a few practical examples, download the GFdisplay package. althoguh it's for Go Flight buttons, there are several cases there of using iffsets and conditions in this way. Alternatively, if you really want to use Lua, as your subject heading suggests, you'd need to trap both button press actions with an event.button(...) arrangement, using a local variable in the Lua program to keep track of what control should be sent. Then it's just a matter of a few if's and else's as you've done before. But it will only start from the same place each time you restart FS. If you want to have a memory of the position outside of FS you will have to create an INI or CFG file to remember it in. you can do that using Lua io.open() and :read() and write() calls. You'd need to refer to the Lua reference website or programming book for that. There is an example of file reading and writing I added to the end of my Lua announcement -- it's a little Lua program I wrote for scaling the FSUIPC dialogues up by automatically reading and modifying the C/C++ resource file which defines them ("ScaleRC.lua"). Regards Pete

So nothing is actually highlighted? Okay. So we need to process of elimination. Can you list all of the add-ons installed and programs running, please? Pete

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. 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. 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

Ah. sorry. I really hadn't noticed you were using FSX. I should pay more attention to the pictures. You didn't actually say which version you were using till just! ;-) Of course version 3 will not work in FSX. Mea culpa. In the Updates & Goodies announcement did you not see the latest for FSX? 4.551 is there now. Try that. Pete

Where's the picture to prove it? It really does sound as it you are still running 3.93. Please check the main About tab in the obtains -- I suspect you didn't install the update in the real Modules folder, only the Alias.. BTW, did you try 3.947, released in the Updates announcement today? Pete

By "calibrate button" do you mean the Tab labelled "Joystick Calibration"? Okay. So it is an FS hang not a system hang. Erthere's no button to be highlighted. Can you be more specific please? I cannot picture where you are when this happens. Did you check for Actigate.dll, for a non-Microsoft mouse driver? Did you try in Windowed mode? Regards Pete

Well, I don't know about not starting FS9, but for a registered/unregistered difference there are only two possibilities: EITHER your registration key is invalid, one produced by a pirate key generator, OR your PC's system date is incorrect, one before the date of purchase of the key. Regards Pete

In the end I decided to simply make the whole lot 20% larger, and wrote a small Lua plug-in, running under FSUIPC itself, to do the scaling for me. ;-) So, get FSUIPC version 3.947 or 4.551, now available from the Updates announcement. If you are interested in the Lua scaling program I've added it at the end of the Lua Plug-Ins announcement. Regards Pete

If you have to re-boot your system it really cannot be anything in FSUIPC -- that's merely a user level module and has insufficient privileges to hang the whole system. It must be something in the joystick drivers. What's actually on the screen when you get the lockup -- is it all black, or is the FSUIPC option still showing, and if so which page / tab? And are you sure you have to re-boot the whole system? There's usually very little reason ever having to do that. Have you tried simply closing the FS9 process (Ctrl-Alt-Del to get the task manager, then select FS9.EXE in the Process list and use the delete process button). Also see if it happens in Windowed mode. (Alt+Enter swaps FS between full screen and windowed mode). If not, then it's likely to be a video driver problem. Video driver bugs can certainly hang the whole system. Have you tried any of the other facilities in the FSUIPC options? Button assignments, for example, or axis assignments. You aren't supplying me with enough information about what is happening for me to help much I'm afraid. Please try every Tab in the FSUIPC options and let me know what works for you and what does not. One thing more: do you by any chance have a module called "actigate.dll" in your FS9 modules folder? If so, try taking it out. Some versions of that seem to cause problems. The other thing to watch out for is an older Kensington mouse driver -- always use the Microsoft mouse driver even for a Kensington mouse. Regards Pete

Oh dear. :roll: First of all, you don't get 4.53 from "my site" but from Enrico Schirrati's site. I don''t have a website and I have no direct control over any. :shock: Second, why not simply look at the Announcements in this Forum some time? They are full of useful information. In particular look at the Updates & Other Goodies announcement where you'll always find the very latest interim updates. :D Since my last message to you, 3.945 has been made obsolete and 3.946 is the latest. There's another due soon. :wink: Pete

WideFS is useful for running pretty much any external FS application on a Networked PC, providing that product interfaces to FS via FSUIPC. WideFS is really just a Networked expansion to the FSUIPC application interface. On my cockpit I use 8 PCs, with WideFS. Six of these run various components of Project Magenta -- for instrumentation and autopilot. Then I have Radar Contact for ATC, "Its Your Plane" for my copilot, FSRealTime to keep the FS time aligned to real time, AIsmooth to help get the AI traffic orderly, SA_WXR for weather radar, and a number of other little utilities for assorted purposes. I also have 7" touchscreens inside the cockpit populated by WideClient's "ButtonScreen" facility, and moving map programs also via WideFS and GPSout facilities. I used to have Active Sky for weather via WideFS, but now I use ASA which, with FSX, uses SimConnect instead. There are lots of other programs which will run networked. But really you should be thinking more about what you really need/want than "what can i use this for". ;-) Regards Pete

I've looked in detail through all of the Tabs, and the only ones I think are likely to be affected are the Axes and Joystick calibration tabs. The Axes one is relatively easy to tweak, but I'm going to have fun (NOT) with the calibrations one -- I count at least 36 separate controls to be repositioned and sized, not to mention their neighbours which will get jostled too! :-( Ah well, it's only time... Pete

No, your memory is fooling you. The modules menu has never, ever been a part of FS alone, it has always been added by add-in modules like FSUIPC. In fact FSUIPC was the first one to add it, then other add-ins added their own entries. Yes, that's FSUIPC. To do that you must have installed FSUIPC, or somethnig else you installed did it for you. You installed something which installed FSUIPC, that's for sure. Pete

There's pretty much nothing to read or do for WideFS -- you do need to read the first few paragraphs about configuring your network, where there's a RED note asking you to do so. That's important these days because different Microsoft operating systems have different default WorkGroup names, and this prevents broadcasting and thereby stopping WideFS's normally fully automatic operation. You either need to make sure the workgroup names are the same, or tell WideClient your Server name and protocol. And of course you have to stop your firewall, if any, blocking Wideclient from the client PC and FS from the FS PC. What is actually wrong, then? Can each one's Windows Explorer see the other? Does WideClient say "connected" when FS is running with WideServer enabled? Well, you've not yet mentioned any "issue" as such, so I don't know what to say. Are you writing just in case you have a problem? I can't help with your future, you have to get there first. And I can assure you that neither FSInn nor SquawkBox will work simply by running them on a WideFS client. As far as I know, on FSX neither of them use FSUIPC and therefore they don't use WideFS. Even if they did, that wouldn't be all. I'm pretty sure they both use SimConnect. You'll need help from those program's own documentation and support. That's not my area, I'm afraid. I don't (yet) use either of them -- i might do one day, but at present I've no idea what is involved. Regards Pete

Strange. i honestly don't know how that could have helped. All it did was stop the automatic FS repeat acceleration occurring when it shouldn't, as when other controls are occurring in between and the repeats were not genuine repeats. Maybe, in your aircraft, there are always other controls between every repeat of the trim? If so, why would that not also occur in Windows 7, or whatever? I've certainly not changed anything. Maybe it isn't related specifically to Win7 (I don't see how it can be), but the speed of your newer computer? Maybe the sequence of controls going to FS is not the same because of that? Maybe you should switch on the FSUIPC event logging and see what is going on? If you want to force it, you could, instead of using the FSUIPC offset method of trimming, assign two FS controls to the trim up and trim down actions -- the second one being something innocuous, that does nothing of any consequence. That should stop them accelerating. (Of course, assigning two controls will necessitate editing the INI file or providing macros, so your users are still not faced with something easy. However, for real control of the exact trim action, you won't get better than actually increasing it or decreasing the actual value, and each user can select his own optimum one too, that way. And the offset inc/dec method can be done in the FSUIPC options. If you wanted to use Macros you could of course just supply a macro file -- for either method, inc/dec offsets or double control. Regards Pete

Sorry, I cannot possibly support such an old version. Please update to at least 3.93. No, the Modules menu is added by FSUIPC. If it isn't installed it cannot run, and if it cannot run it cannot add its menu. Why be confused about something as logical as that? I cannot help you further unless you update to a supported version. Regards Pete

Hmm. don't know how it did that. `Sounds impossible to me. Please read the description in the User guide. Especially this part: It doesn't change the time itself, it only changes a flag which FS might set. For elevator trim adjustments of any user choice, just use the FSUIPC offset facilities. The setting of trim to any increment you like is actually the example used in the Buttons section of the User Guide for "Offset Increment/Decrement Controls". Look for the boxed section with that title. Regards Pete