Pete Dowson

But I tend to think that's not really relevant. The logs show the sequence is identical up to the point where it finished executing the final 1070 control. The thread running the Lua program is dead and gone by then. All of the "SendInput" actions to FS are done in the main FS thread. And the keypress encoding for the button isn't from a separate thread. I really don't understand why there's a difference, and, unfortunately it is impossible to trace it or even log it more finely without changing it (a touch of Heisenberg's Uncertainty Principle)! I did try some small timing changes, mostly to the speed at which the SendInput calls are made, and doing this I could get all three ways acting the same -- but they all simply then obeyed the ALT+A (displaying the Menu (yes, even yours)), but lost all further keys -- or possibly stored them and released them to FS after. That is actually what i expected to happen in any case, but now I know that the multiple keysends and the Lua action works so well, I put the code back so that those complete sequences still work okay. Regards Pete

Okay. When you've registered FSUIPC4, on the GPSout page of the options, in FSX itself (in the AddOns-FSUIPC menu) you will see Sentences, Interval, Port and Speed selections and you can enter them there. No file to edit, FSUIPC4 does that for you. Well, that and a sample configuration file was all it came with. Well, the separate GPSout program needed FSUIPC installed for it to work too, and that came with a User Guide which I suppose you ignored too? :-) All that has happened is that GPSout is now incorporated into FSUIPC4, and is no longer freeware. The fact that the GPSout documentation has then been improved and included in the FSUIPC4 documentation wouldn't matter to you if you never even saw any for the old GPSout! If you don't want to look at any other parts of it it won't matter. But you need to get a Key then Register (which you do at the Installation stage, so you'd need to re-run the Installer after you've obtained your key). Regards Pete

What do you mean "syncro"? Throttle, flaps and toe brakes are independent, not synchronised. And there's generally no need to edit any INI files unless you are doing fancy programming stuff on buttons, or making lots of aircraft-specific settings and need to rationalise them. Just calibrate your controls first, as in the User Guide. Pete

Okay, i've done all the testing I can here. I don't know why it isn't working from your gauge. It works, as you know, from that Lua program, and it works also with a button programmed like this: 1=P1,1,K65,24 2=P1,1,K65,8 3=P1,1,K80,8 4=P1,1,K13,8 The Lua program is doing EXACTLY the same as your gauge, except that it terminates as soon as it is done (and it runs in a different thread to FS in any case). A button programmed as above isn't using offset 3110 or control 1070, but it is merely sending keystrokes direct. The sequence from your program logs EXACTLY the same, almost to the millisecond, as the Lua program. The whole sequence is dealt with in 281 or 282 milliseconds in both cases, every time. Where they differ is in the ARRIVAL back in the FS window procedure of the sequence of WM_KEYDOWN and WM_KEYUP messages. And that is outside of my control. They've all been sent within the 300 milliseconds. They all arrive differently in the two cases. I suspect this must have something to do with what your Gauge is doing immediately after sending the sequence. Does it then exit and wait for then next normal Gauge wake up call, or whatever? (Sorry, I know next to nothing about writing gauges). I think it may need to. If you are continuing to keep control of the main FS thread after the sequence is sent, you are not allowing FS to process its messages correctly and this messes the timing of the ARRIVAL (and therefore interpretation0 of these keyboard messages. FSUIPC cannot give control back during the processing of your request, of course, as this is within a windows message already (from the SendMessage in the interface code). It has to exit, back to your code. In the case of the Lua program, it is terminating (and it uses a different thread in any case). In the case of the button programmed to send keystrokes, FSUIPC goes directly back into dormant mode waiting for new requests immediately afterwards. So, in both cases, FS's message processing proceeds normally directly after. If, looking at your gauge, you cannot solve this by rearranging things, then I suspect the only answer will be to program a virtual button to do as above, or else use a Macro or a Lua plugin like the one we've tested. However, if these are activated from your Gauge I suspect the same problem may arise if it then keeps control. Note that, if all this is merely in order to load a different aircraft, a possible alternative method which might be worth investigating is renaming aircraft files somehow and using the "Reload User Aircraft" control -- assuming the details aren't being cached by FS, of course. Regards Pete

No. The program can be installed for use as an interface for client applications, but the User Facilities are only available after Registration. There's no where which talks about any user trials. Click on the link in the documentation, or on the Web site where you downloaded FSUIPC, or in the list of supported versions in the Announcements above. It is really, really hard to miss! There's even a whole page about it in the documentation, even how to pay by post if you don't want to use credit cards! The user guide tells you exactly how to register, with pictures even, once you have purchased a key. Without a key you cannot register. And the documentation tells you how and where to purchase a key, as do virtually all other places talking about FSUIPC! No. but you said you had it working with FS9 using the free GPSout program didn't you? You said "I am able to load and use GPSOUT with the FS9 ( 2004 version), and it works fine with my GPS 396." So, it will work with the GPSout facility built into FSUIPC4, once you register. Since it is a lot easier to set up with FSUIPC4 than it was with FSUIPC + GPSout on FS9, it makes me wonder how you managed that, then? Or did someone do it for you? The documentation is more comprehensive for the GPSout facility in the FSUIPC4 user guide than the small text file provided with GPSout, and its options dialogue does have a checkbox to enable it, and a place to enter the Port. You just need to actually read the right part of the User Guide! There's even a contents list to help you find it quickly! And there isn't a file to edit with some complex text editor as you had to with GPSout! I really cannot understand how you find it all harder now when it is all made so much easier! Can you explain that? Regards Pete

Yes, certainly. You have permission. Okay. Thanks. Maybe I'll get my son, who lives in Spain, to read them for me! ;-) Thanks and Best Regards! Pete

SimConnect and WideFS are not exactly alternatives. Lets take one step back a moment: FSUIPC provides an interface for applications, an interface which has remained backward compatible now since FS98 -- i.e. through FS2000, CFS1, FS2002, CFS2, FS2004 and now FSX and ESP (though with two new independent versions in the latter two cases). With FSX and ESP, Microsoft finally "saw the light" and officially supported an application interface. This is "SimConnect." Both FSUIPC's and SimConnect's interfaces are used on FSX. In FSUIPC's case this is partly because there are still a lot of add-ons which have been carried forward to work on FSX/ESP (because the FSUIPC interface is compatible), and partly because some folks find it easier, more powerful, or just more suitable for their applications. This is all true for a single PC running FSX or ESP. Now add other PCs in a Network, and both interfaces have extensions to take advantage of this. WideFS is the extension to the FSUIPC interface for other PCs on a Network, whilst for SimConnect you install the SimConnect package on those other PCs and configure a couple of files. Neither is better or worse than the other. They are different. If you want to run FSUIPC client programs over a Network link, you need WideFS. If you want to run SimConnect clients over a network link, you use SimConnect. [bTW, FSUIPC itself uses SimConnect internally too, amongst other things]. In answer to your question "what addons cannot use SimConnect?" all I can say is "all addons which have not been programmed to use SimConnect", which of course means at least all those written before SimConnect was available, and, indeed, some written or released since. Gradually more and more SimConnect add-ons are appearing, but there are still many many more which are FSUIPC clients instead. If you have none you wish to run, and don't think you will be getting any, then you probably* don't need WideFS. Regards Pete * I say "probably" because there are a couple of uses of WideFS which don't involve FSUIPC clients: 1. Button screens, aimed at touch-sensitive screens, for an array of touch-buttons, and 2. The ability to use a GPS-sensitive moving map on another PC using the Network link rather than a "null modem" serial cable.

Sorry, but there appears to be an obvious contradiction there. You say there's "nothing" in the Add-Ons menu, but then go on to say there IS an FSUIPC entry, and that "just opens the options & Settings menu"! If there IS an Add-Ons menu, and it DOES contain FSUIPC, and when selected, FSUIPC DOES open the Options and Settings menu, then it all works. That is EXACTLY what it is supposed to do. Have you not looked at the User Guide at all? The install log, of course, confirms that it was all installed okay, but it also shows this: Did you deliberately not check your FSUIPC4 registration? I'm not sure why you provided the FSUIPC4.INI file, which appears to be the default, showing you've made no settings of your own yet. The Log file would have been much more informative, as it tells us what FSUIPC4 made of your setup. However, the INI file does show that, if the GPSout facility isn't working for you, it is simply because you have not gone to the GPSout tab and enabled it. There's not even a Port specified! Maybe you've forgotten to Register FSUIPC4? Without registration you get no user facilities. I think you should possibly take a few moments to at least browse through the User Guide, get some idea of what FSUIPC is all about? Regards Pete

Well, of course you wouldn't for an external program. You'd use FSUIPC_User.lib instead. That's if you are a C/C++ user, of course. Other languages have other methods. That's fine. That's an alternative to binding in the same code as a static library -- the lib files are simply pre-compiled versions of the same source code you are using. You'd normally use the source code instead if you needed to make any changes, or get deeper into things for any reason. The lib files are merely provided as a convenience. Right. Of course that's another excellent reason for using the source instead, or even making your own Lib from the source provided, one which matches your compiler. Regards Pete

THAT's a great Idea "Yoke"=3 "Joystick"=1 etc something like this would defeat the MS Tombola eternally ;) No, I didn't mean quite like that, though that's another idea -- rather more ambitious, though. I meant simply to list the name provided in the Registry for the device, which would presumably be something like the one FS displays. A way of having pseudo-numbers/names for the joysticks might be interesting, though. However, because of the way all the code is designed there's no real way I can have full names in each parameter line. But possibly you could, for example, nominate joystick device 0 as "A", 4 as "B", 1 as "C"or whatever, and then see those A-Z names appear in the Dialogues instead of the numbers currently shown. Then you just change the assignment of the letters to numbers to change things around. This might be clearer than re-mapping numbers, which would tend to confuse things. If I can extract the proper device names I could still add the list of which number is which device name, to make re-assignment to the letters easier. I don't think I'll have time to do any of this till after Christmas now, but I'll make notes. Regards Pete

What does "loading the 738 in cold and dark cockpit throught the default cessna" mean? Are you sure you did not simply assign the switches with "aircraft specific" selected, so they only apply to that specific model? A quick look at the FSUIPC.INI file's [buttons ...] sections would tell you. FSUIPC does not deliberately throw assignments away! Regards Pete

I think they are just the logs of the keypresses arriving -- i.e. the actual KEYDOWN and KEYUP messages. They seem to be incomplete, which may explain things, possibly. I'd like to be able to compare the Lua program results with yours, side-by-side, so I can see all the timing and order differences, to try to understand it. That's what i meant when I asked. If you can do two logs, one with Lua and one with your gauge then I could compare them line for line. There is an alternative, of course. if your Gauge is reasonably free-standing you could send it to me for testing here. i can trace through what is happening in FSUIPC then. petedowson@btconnect.com. Zip stuff, please. Regards Pete

Not JUST changing the Open call -- you link with the module users library, not the normal FSUIPC library. It does things completely differently internally. And in the Open2 call YOU provide the static memory to be used for the data transfers. Pete

I really meant "happened to a lot of people", which, apparently, it doesn't. I am amazed that you somehow manage to get all the joystick numbers changed 6 or 9 times! That would have really made a horrible mess of Flight Simulator assignments too, before they changed over to DirectInput. Even now, if two or more of the devices are actually the same type then they can get swapped even in DirectInput mode. I'll put it on my list. But it would still need the user (i.e. you) to determine which number became which other number. There's no safe way of doing it automatically without changing over to DirectInput throughout and using device names (or more likely "GUIDs", in the INI file at least -- like FS does) instead of joystick numbers. I might just be able to provide a number = name list in the INI file to make the job a bit easier though. Don't know yet. Regards Pete

I hadn't noticed before: you are sending a Return as well as Alt+A, A, P. Try adding a Return code to the Lua program too, i.e. use this: ipc.writeStruct(0x3110,"2UD", 1070, 0x1041, 0x3110,"2UD", 1070, 0x41, 0x3110,"2UD", 1070, 0x50, 0x3110,"2UD", 1070, 13) (assuming you moved on to FSUIPC version 3.852). Here this does actually work (which surprised me!). It selects a Piper Cub and returns to flight mode. Log the working sequence with the Lua program, and then log the same with your Gauge. Comparing them might show what differences there are that could cause your problem Regards Pete

Good. So that proves the sequence of 1070 controls is working, and so it should certainly also work in your program. You are connecting to FSUIPC from a Gauge? I thought you were using an external program still! Are you using the module user library for this, with FSUIPC_Open2(...) instead of FSUIPC_Open(...)? If you are still using the external interface with an internal program, like a Gauge, then, yes, it explains a lot. It is a big no-no. the normal external interface for FSUIPC is based on shared memory for inter-process communication. When you are completely in-process the shared memory is shared by every client, so gets trampled on. Also, please make sure that you only Open the FSUIPC link once when the gauge is loaded, and is Closed when it is unloaded. Do not keep opening and closing it, and do not forget to close. Regards Pete

Okay. Download this new interim update for FSUIPC3: http://fsuipc.simflight.com/beta/FSUIPC3852.zip This contains an enhanced Lua "ipc.writeStruct" facility (readStruct also, but that's not relevant here) which can write to several different (or same) offsets in one Lua instruction. This enables it to get all of the ALT+A, A, P sequence into the keyboard buffer before FS has changed focus to the dialogue. After placing that FSUIPC.DLL in your FS9 Modules folder, replace the "testmenu.lua" program I gave earlier with this one: ipc.writeStruct(0x3110,"2UD", 1070, 0x1041, 0x3110,"2UD", 1070, 0x41, 0x3110,"2UD", 1070, 0x50) Then run it as before, using the button (preferably) or keystroke you already programmed for it. This opens the Aircraft menu and selects the first "P" entry, exactly as you expect when using the keys themselves. Note that this Lua plugin, whilst obviously not subject to the focus problems inherent with running a client program on the same PC as FS, is in effect doing EXACTLY the same as your program should be doing if it were writing the correct values with one FSUIPC_Process call. This is why I am showing you, because it demonstrates that it works! You can, of course, invoke Lua programs from your own program, just by writing the Lua control name ("Lua testmenu" in this case) to offset 0x0D70. This addition was described in the FSUIPC History document recently -- it hasn't yet made it into the released SDK. Regards Pete

No, no no! Never! the logging facilities have always worked fully, ever since version 1.00 in 1999! They've been an absolute essential part of all the developments I've ever done, and there's never been any need to restart FS, at all. I'm sorry, I cannot see what you are doing from here, but I'm also not getting the information I ask you for. Like WHAT VERSION OF FSUIPC are you using? Can't you even tell me that please? If you can't work it out please show me a complete Log file so I can read it for myself. Not at all! The first few keystrokes are the ones which will be picked up before it is too late and Windows' Menu dialogues grab the focus. I've no idea why you only see a fleeting glimpse of the Aircraft menu -- what is dismissing it? How can it be dismissed except by you, on the keyboard, once it is called up? Are you sure you are not using some other key presses? A proper log, as I asked many messages ago, would tell me a lot! So far you've not shown me a proper log, you've not told me the version of FSUIPC you are using. I've been working my *** off trying to sort things out for you, surely you can cooperate a little more than you are doing? Please? :-( Pete

Okay then. Here's another demonstration which works perfectly here. Save this little Lua program into your FS9's Modules folder as "testmenu.lua". ipc.writeStruct(0x3110,"2UD", 1070, 0x104D) ipc.writeStruct(0x3110,"2UD", 1070, 0x46) Then go into FSUIPC's Buttons or Keys options and program any button or keypress (a joystick button would be better to demonstrate complete independence from the keyboard) to use the new control called "Lua testmenu". Okay out of the options. Now use that button or keypress. The ALT+M then F sequence sent by the Lua program via offset 3110 brings up the FSUIPC menu. Okay. Cancel and now replace that testmenu.lua program with this one: ipc.writeStruct(0x3110,"2UD", 1070, 0x1041) ipc.writeStruct(0x3110,"2UD", 1070, 0x41) ipc.writeStruct(0x3110,"2UD", 1070, 0x50) This one sends your Alt+A, then A then P. Try it, using the same key or button you already programmed. Here, this manages to do the ALT+A and A, okay, so gets to the Aircraft selection menu, but the P must arrive too late and doesn't get to the FS dialogue at all. I've got a modification to the Lua plug-in "ipc.writeStruct" facility which should deal with that. I'll tell you about that when I've got it working (it already works fine on FSX). Regards Pete

That's all wrong: 95625 FSUIPC Control Action: Ctrl=4161, Param=1070 95625 FSUIPC Control Action: Ctrl=65, Param=1070 95625 FSUIPC Control Action: Ctrl=80, Param=1070 95625 FSUIPC Control Action: Ctrl=13, Param=1070 You have the parameter as the control and the control as the parameter. You've reversed it since the last log snippet you showed, so your last tests are worthless. Why have you done that? 3110 holds the control, 3114 the parameter. Put it back the way you had it, THEN show me the log -- without the IPC write logging please! And are you absolutely sure you are using an up to date version of FSUIPC (3.85)? Pete

Why log IPC writes? We want to see what FSUIPC makes of what you are writing. I suggested logging the Key and Button actions, as I did, then you see the actual results, the key combinations being sent to FS! Yes, they are -- Intel processors are "little endian", meaning that the first byte is the least significant. Motorola processors wre the last ones I know that were "bug endian". Have you tried assigning a button or key as I showed, and which worked? Can you yet confirm, as I asked, that "Alt A" by itself actually does anything, even on the real keyboard? If it does anything on the real keyboard it just has to when the same combination is sent to FS. Pete

For FSX you must use FSUIPC4, which is not the same as FSUIPC3. Please peruse the Announcements at the top of this Forum for full information, or follow the links to the SimMarket pages, where you can purchase keys. Regards Pete

I am amazed that nothing happens, but i wouldn't necessarily be surprised if the characters after the ALT+A did anything. But if ALT+A on the keyboard invokes the menu, then so must the first write you are sending (assuming your code does have an FSUIPC_Process call somewhere afterwards, not shown above). Are you sure? I've not written a program, but I tried the same thing by assigning ALT+M keypress to a button, using FSUIPC's options, thus getting this in the INI file: [buttons] 1=P1,0,K77,24 which deals with the ALT+M, and then I added this in the INI file: 2=P1,0,K70,8 in order to send the F. In FSUIPC Button options i reloaded the button settings. Pressed the buttonlo and behold, the FSUIPC dialogue came up, fine! With the Button and Key logging enabled in FSUIPC's logging page you can see what happens: 1456484 Button changed: bRef=0, Joy=1, Btn=0, Pressed 1456484 [Buttons] 2=P1,0,K77,24 1456484 SendKeyToFS(0001004D=[alt+M], KEYDOWN) ctr=0 1456484 Sending WM_KEYDOWN, Key=18 (Alt) (Scan code 56), Ctr=2 1456531 Sending WM_KEYDOWN, Key=77 (Scan code 50), Ctr=1 1456578 Sending WM_KEYUP, Key=77 (Scan code 50), Ctr=1 1456609 Sending WM_KEYUP, Key=18 (Alt) (Scan code 56), Ctr=1 1456609 [Buttons] 3=P1,0,K70,8 1456609 SendKeyToFS(00000046=[F], KEYDOWN) ctr=0 1456656 Sending WM_KEYDOWN, Key=70 (Scan code 33), Ctr=1 1456687 Sending WM_KEYUP, Key=70 (Scan code 33), Ctr=1 1456687 KEYDOWN: VK=18, Waiting=0, Repeat=N, Shifts=4 1456687 .. Key not programmed -- passed on to FS 1456703 KEYDOWN: VK=77, Waiting=0, Repeat=N, Shifts=4 1456703 .. Key not programmed -- passed on to FS 1466015 Button changed: bRef=0, Joy=1, Btn=0, Released Encouraged, I edited this in the INI file's [button] section: 3=P1,1,K65,24 4=P1,1,K65,8 5=P1,1,K65,8 This tries to do the whole thing -- ALT+A, then A, then A againthat seems to not only get the Aircraft selection menu up, but also select "Any" in the first field. Who says it isn't? Have you tried the logging to see what it is doing? According to my arithmetic, yes. Of course you could always use "(256*16) + 65" in your program and let the compiler do the work. Regards Pete

Yes, of course. No problem. Do please point out on the site that 3.81 is not the latest version. Most of the documentation doesn't change too much of course, there just might be new facilities and options omitted. Regards Pete

Thanks. And the key file works fine here. There's only one other possibility I'm aware of. The registration is only valid for dates AFTER it was purchased, not before. It was purchased in August 2003. Are you sure your system date is set correctly on the PC? Maybe your repairers never set the date and time for you, and neither have you? Regards Pete