Pete Dowson

Unless you are using some options for joystick controls in FSUIPC4 there is no affect on the aileron or any other control from merely installing FSUIPC4 or registering it. In any case, if, as you say, you can see the aileron moving when you move your stick, yet the aircraft does not react to this, there is quite evidently something else going wrong with your aircraft model. I'm afraid there is no way that FSUIPC can come between the aircraft modelling and its actions, these are all part of the same package inside FSX and only controlled by your installed aircraft files -- files such as the Aircraft.CFG, the AIR and MDL files. Please contact the support for the aircraft concerned. Maybe it is a known problem with their model which has since been corrected with a patch. Since there is no way I know for any other part to affect this, I cannot help with anything through FSUIPC. Regards Pete

Sorry, I've no idea what is happening there. I need more information. I have absolutely no idea how a "Hagstrom Keyboard Emulator" works at all. Since all of the "Keys" assignment facilities in FSUIPC work operate using standard Windows keyboard messaging, please verify what you are assigning these keys to do using a real keyboard first. Let's eliminate the encoder, as if that is behaving differently to a real keyboard you will then need to find out why and presumably deal with Hagstrom support. Note that there is absolutely no time-related code in FSUIPC regarding how keys are interpreted. The nearest there is would be a little check to prevent FSUIPC sending repeated controls to FS (or in the case of Mouse macros, to a Gauge) faster than they can accept them, generally the frame rate. But that's in terms of milliseconds, so nowhere near your minute -- such a delay there must surely be something to do with the way the encoder is operating. Erif you "confirm" the result, it is written to the INI file on OK exit from the Options screen. Please check the INI file. Of course, if you have that set as read-only it will not remember anything, but that sounds pretty unlikely. That sounds bad. That presumably would mean Windows only sends me a KEYDOWN message. If there's never a KEYUP message then it cannot see the next KEYDOWN as a new press. It would be the same as having a Key stuck down on your real keyboard. Surely no keyboard emulator should ever leave keys pressed forever? Maybe your "minute" timeout is a safety feature on the Hagstrom to prevent such "stuck" keys? Please try to help yourself first. Two things to do: 1. Program and test everything using a real keyboard only. Only then check it on your encoder. I cannot deal with differences from the way a real keyboard is handled through Windows. 2. Use the Buttons and Keys, and probably also the Event logging facilities in FSUIPC -- see the Logging tab. You can try things and examine the log directly afterwards to see what it happening. (In fact, if you download DebugView from http://www.sysinternals.com , and run it before running FS, you can view the Log in real time, provided you run FS in Windowed mode so you can see the DebugView window). If you still have problems, or need help interpreting the log, show me. Also show me the relevant Keys section from the FSUIPC.INI file. Regards Pete

Even so, if you have a problem there's a lot of useful information in that Log file so you should sohw it to me, please. Surely you have installed FSUIPC4 before purchasing a Key for it? You are meant to install it and read the User Guide to see if you really want to buy it first. What's "the security question from MS" exactly, and how did you reply? If you refused permission for FSUIPC4 to load then it will not load -- not only that but you may have added my name to your system's list of untrusted publishers and therefore be stopped forever from using my software! Without seeing the Logs (both the Install log and any FSUIPC4.log produced when loading FSX I cannot really say. Regards Pete

No, sorry, I do not know them at all. Offset 0342 was, in FS98 and FS2000 a switch to change between Automatic mixture control and Manual (auto for folks having no mixture control). Why on Earth would you want that on a rotary? Why would you want to switch it in any case? Anyway, it hasn't been supported since, and including, FS2002, as you would see if you kindly LOOKED AT THE OFFSET LIST I provide! It is in the FSUIPC SDK. If your hardware/software doesn't support something offered by FSUIPC I'm afraid I cannot help. Please contact the support folks for your devices. However, you might be avble to use them via the axis assignments, or use offset 3110 with FSUIPC axis controls? Regards Pete

I think you are right. It'll be some osrt of cyclic buffer, internal to FS. If someone knows how to get hold of it, then maybe. Do you know how to find it? To find stuff in FS you first need to know what it might look like. It still isn't easy, of course, as FS is written in C++ with lots or heirarchical class levels, and this lends such a degree of complexity that finding anything new, without a clue, is almost guarantee to take a few thousand hours of hacking and disassembling. I would suggest either using FS video recording and playback (or the nice freeware recorder), or look for some other add-on analysis program which reads the data it needs continuously, maybe through FSUIPC. One such example which may provide what you want is Aerosoft's Flight Keeper by Thomas Molitor. Regards Pete

Yes. Any FS control (and all FSUIPC added controls except those to do with offsets) can be sent via offset 3110. Please refer to the offset documentation. Regards Pete

Hmm. Interesting. I thought navigational instruments derived wind speed and direction data from the difference between heading and track over time. Where do you get wind data from? GPSout simply supplies the altitude given by Flight simulator, which is based on whatever terrain the user has installed. The problems in XCSoar appeared to be that the altitude it displayed was NOT the one being provided, but one modified by some value. As an experiment instead of omitting the "height of Geoid above WGS84 ellipsoid" field in the GGA sentence I supplied an explicit 0.0. that seemed to fix it. It looks as XCSoar applies some "correction" if the GPS supplying it isn't explicit. I thought omitted values should be taken as zero, but maybe this isn't so. Exactly. But is omitting a value not supported by the GPS really "not handling it correctly"? It hasn't been a problem with any other moving map or GPS devices which accept simulated input. That's totally irrelevant in this case as it is the true AMSL in the simulator which is provided and this was being modified by XCSoar to an incorreect, fictitious value. GPSout does not supply the QNH value nor the altimeter read-out -- I don't support any NMEA sentences which include such information. Regards Pete

Surely the thing needing permissions etc is the target program, the one you awkwardly have installed in "Program Files"? That's the one WideClient is trying to access with messages after all. Pete

New? August 2005, nearly THREE YEARS ago? (Version 6.50). Regards Pete

UAC is a pain, a complete and utter pain. To start with it is best never to install any non-Vista aware program into "Program Files", because all those folders are protected. Maybe that's part of it. FSUIPC4's installer, when installed into FSX in Program Files, explicitly changes the permissions on the Modules folder it creates itself to allow FSUIPC4 to write its own Log and other files! Ridiculous! Installers can do thisactually any program's whose EXE has "Install" or "Setup" in the name seems to have lots more privileges. However, I still wouldn't understand why Vista stops the program which starts another (using "CreateProcess") from sending messages to it! Weird! Check the relative properties of the WideClient EXE against the target program's EXE. Maybe you have one set to run with Admin privileges and the other not. That stops it -- but I've also been informed that that stops the memory-sharing system used for the FSUIPC interface, so I would have thought nothing would connect anyway. But maybe it's one way. Maybe renaming WideClient "Wideclient Setup Not.exe" would give it the privilege to send messages? Regards Pete

I've just tried it here with Vista Home Premium running on by notebook, and it works fine. Hmm. I just had this: RunReady1=NotePad.exe KeySend1=65,8,RunReady1 and it worked fine. So, could it be something about the way you have things set up in Vista? Maybe you have WideClient running with different privileges or something? Although, since it is WideClient running your program it should be able to send it simple keyboard messages. I assume the WideFS connection is working in other ways, or is it only KeySend you are using it for? I'm using WideClient 6.763 (from the Downloads announcement above). Just in case there's a difference, could you try that version please? Regards Pete

Hmm. strange. I don't know of anything in the normal Keyboard messaging that has changed in Vista. Could you show me the WideClient.INI file please? No need to "assume" anything. If you refer to the History document supplied, you will find: Regards Pete

No manual? :shock: What do you think the User Guide is? :roll: Please refer to the Installation section in there!!! Pete

This is a definite indication of a problem in your hardware, or possibly in your software (Windows). There is no way a security hash (basically a sumcheck) should ever change from one load to the other UNLESS the bits are changing in the file (so a bad disk read or memory error), or something similar is happening to the software which is checking it (part of Windows). I would suspect your memory first and foremost. With virtually no systems RAM having parity checking these days, failing memory values can cause all sorts of symptoms. And it may be a heat senstivie issue. Not just virus-free, but tamper-free and not corrupted by bad disk or memory loading. There will never be a version without it. I advise you to get your PC fixed. Regards Pete

No, that flag works fine, just as it did in FSUIPC3 with FS9 -- better, in fact, because it works in Slew mode too. There are a lot of things depending on that (lots of other programs) and there'd be a right kerfuffle if it didn't work. Whenever you come here please always be sure to quote the VERSION number of FSUIPC you are using. If it isn't the latest it is also best to try that first -- and note that there are often later versions avaible in the FSX Downloads announcement above. And please use the Logging facilities to help you debug your programs. In fact if you go to the right-hand side of the Logging Tab you can enter 0366 as the offset, with type U16, and check the FS display option below, and you will see it change in real time on screen. If you also check the "normal log" option and look in the Log afterwards you will also see that the notifications are from SimConnect, like this: 348156 Monitor IPC:0366 (U16) = 1 ... 401500 SimRead: 0366="SIM ON GROUND" INT32: 0 (0x00000000) 401563 Monitor IPC:0366 (U16) = 0 As I said, there are a lot of things which would break if this wasn't working. You have an error somewhere. Maybe you are reading it as a 4-byte value instead of 2-byte as documented? The following offset (0368) contains a timer which is changing all the time and which will be non-zero. Please do use the tools provided to debug your work. As well as the comprehensive logging facilities FSInterrogate is also invaluable for checking things. Try it! Pete

Really? you got FSX very cheap then? FSUIPC4 is a completely new program. It had to be re-written (thank you Microsoft!). Do you work full time for nothing? Pete

Actually, it isn't under my control. Unlike buttons (which don't auto-repeat -- it is FSUIPC adding that facility), key presses sent through Windows are auto-repeated by Windows. I would have to somehow ignore messages from Windows telling me a key has been pressed again (WM_KEYDOWN). I really don't want the complication of keeping a record of which keys were already down without a WM_KEYUP message -- it is Windows job to see to all of that. However, there is a "previous key state" flag provided with WM_KEYDOWN. I'll have a look at how that behaves, to see if I can use it at all. If it shows when a repeated KEYDOWN is sent, then maybe I can add the option. [LATER] Yes, you are in luck! That flag does tell me whether it is a repeat or not, so i can add the facility. Look out for it on the next version.(s). Regards Pete

Good. Okay, so let's forget it. I admit to becoming a little impatient with folks not appearing to use common sense when confronted with a new program. I do try to make the whole package easy -- it doesn't do anything horrible or complicated to your system. It is either installed (i.e. in the FS Modules folder) or not (i.e. not in the FS Modules folder), and that is really all there is to it. Regards Pete

You only need to purchase FSUIPC4 if you want to use any of its facilities -- read the User Guide and see if you want any of them. If not, to run FSUIPC applications on a Client PC you only need to purchase and register WideFS. Sorry, I don't know it at all. Is it an FSUIPC application? If it requires GPS data input, then you'd need the GPSout facilities in FSUIPC4, which are only available if you purchase it. You'll need to know more about this "Apollo Flight Map" first. Pete

Run it? Run what? FSUIPC.DLL cannot be run on its own! It is a library file! It has to be installed into FS! Just downloading FSUIPC is not enough. Please extract the files from the ZIP, then find the User Guide. It will be called "User Guide", oddly enough. Read the Installation instructions. You obviously haven't installed it at all! Documentation is provided for people to actually read. The Installation instructions are very very short, consisting of only one step. Pete

with a program, yes, of course. You need really to wire your indicators to all switch off when there's no power. Use a double pole battery switch perhaps? The offsets 0BEC/0BF0/0BF4 are controlled from FS values. Even if you could override them they'd reset back to whatever FS set them to. They aren't really "LED" indficators, but "Gear Position" indicators, varying from full up to full down as the gear moves. Cockpit programming USES FSUIPC facilities, but FSUIPC is not specifically for programming cockpits, only for reading and writing FS data. The drivers for hardware add-ons normally contain whatever logic they need. Regards Pete

Advdisplay is not supported and has not been so for several years, not on FS9 nor on FSX. It most certainly won't work on FSX. It most certainly is not. It was superseded by the special display facilities built into FSUIPC many years ago. Please have a look at the FSUIPC user guide for all the details. Pete

Of course. What else? That is the current User release. It will likely be replaced by 3.82 next week, though. There are also often later, interim releases (without full documentation) available in the "Other downloads" Announcement above. In fact there's a version 3.817 there now. But you should always first get the main release, so you have up-to-date documentation. Pete

It means you are using FS9.01 (i.e. FS2004 updated with the 9.1 patch), but with a version of FSUIPC which pre-dates it -- i.e. a very very very old version of FSUIPC which doesn't recognise 9.01 and needs to run in version 9.00 (the original FS2004). Simply go download and install the current (and supported) version of FSUIPC. Pete

There are only four possibilities: 1. The version of FSUIPC you have installed is, in fact, inadequate for what Flight Tracker requires. Double-check that it is actually 3.81 or later by going into FSUIPC options and reading the version number on screen whilst FS is running. 2. You have FSUIPC registered but with an incorrect registration number. Try temporarily removing your FSUIPC.KEY file from the FS Modules folder so that it becomes unregistered. 3. Same as 2 except that the reason for the invalid registration is that your System Date (set in Windows) is before the date you purchased your registration, which would make it invalid. In this case, correct your system date in Windows. 4. The GlobalSign root certificate is not installed in your Windows, making FSUIPC's codesigning check fail. If this is the case the fact would be logged (see the FSUIPC.Log file in the FS Modules folder. The fix for this is to run the Globalsign Root program provided in the FSUIPC ZIP file. Regards Pete