Pete Dowson

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

Full guidance is provided in the Joystick calibration section of the FSUIPC User Guide. There are numbered steps giving full help, much more than I can give here. Please just follow them. I can look them up, of course, as can anyone who looks in the documentation provided in the FSUIPC SDK. But why do you want these? For FSX there is no FSUIPC.INI file, but an FSUIPC4.INI. And it is not supplied or installed, but generated by FSUIPC4 every time it is run. If you have FSUIPC files in places other than the FSX Modules folder you may have put them there yourself. Neither FSUIPC4 nor its installer does. Regards Pete

Okay. the problem appears to be that FSUIPC thinks you have an bad key, one made by a pirate hacked key generator. To prove this try removing your FSUIPC.KEY file from the FS Modules folder, to make FSUIPC unregistered -- I think you will find the red crosshair returns to AFCAD. if you believe you have a legitimate key, please ZIP up the FSUIPC.KEY and send it to petedowson@btconnect.com for checking. I do see a purchase made in your name (with a different email, which shouldn't matter) way back in August 2003, meaning you should have a good key, so I will need to check it out in any case. Is there any possibility you could have picked up a pirated registration file during your system's rebuild? Did you re-enter the registration yourself? Regards Pete

Thanks -- I think the issues I have with the 180.xx series of drivers must only apply to the 64-bit ones. I'm sure if there were such serious problems with the 32-bit ones they'd have been fixed by now, or there would be a mighty outcry from angry users! ;-) Regards Pete

I can't without more information. Does the FSUIPC.LOG file show any problem at all? Load FS, run it till ready to fly, then close it down. Paste the Log in a message here. Please also tell me the version of Windows in use. Regards Pete

You must have selected the option to Delete the previous registration, which is present to make it easy for folks who need to change one to match the other. The two other options are to enter new registrations, or merely to check them. And all three options can be bypassed by simply opting to cancel that specific offer. The installation will complete without touching or looking at any keys. In other words you have total flexibility. It only does what you ask it to do, no more and no less. There is no such message, and there have been absolutely no changes to the registration system or the keys between 4.28 and 4.40. In fact there have never been ANY changes whatsoever in registration apart from the movement of the place to register from the FSUIPC options to the installer. If your keys are no longer accepted it can only be because they have been explicitly withdrawn by request of SimMarket. If you believe this not to be the case, please ZIP your FSUIPC4.KEY file and send it to me for checking. Send to petedowson@btconnect.com. Unless you keep your version of FSUIPC4 up to date you will get no support. Regards Pete

I've had a lot of problems with the 180.xx series of drivers, so much so that I've changed back to my last really good set, 177.xx (can't recall the xx offhand). I've even had to swap out my GTX280 card for a 9800 GTX+ in order to do this. The symptoms of the problems with 180.xx drivers were Blue Screen of Death crashes in an nv....dll, infrequent but often enough to drive me up the wall, and, in full screen mode, black screen hangs in FSX when I used some of the menus, like aircraft selection. This was the same on two different systems, but both running Vista 64. I never had any problems till I moved to the 180.xx series drivers. I really don't know what nVidia are doing. :-( Regards Pete