Pete Dowson

Just delete the bits to do with the TQ6 -- you'll need to check the joystick number to identify the lines. Pete

Sorry, I don't know what the GoFlight software does. I'd try it both ways and see. As far as I know the GoFlight TQ works just as a set of axes and a few buttons, so I would think it could be used directly. Only if you let either FS or their drivers assign the same functions to different axes and these interact with each other through "jitter" (unrequested changes). Evidently somewhere you have flaps assigned to that axis -- it isn't possible otherwise. Somewhere in one of the drivers or in FS, if not in FSUIPC, you have flaps on that axis. Incidentally, flaps are not a good first candidate for an analogue axis because the flaps are controlled in specific notches. FSUIPC does have a facilty for calibrating those notches, so I'd try that if I were you. But you'll also find that flaps and spoilers/speedbarake both normally need reversing -- full forward positions being "off". Make sure you check the Reverse option BEFORE calibrating. No idea what you've done wrong, there, but to be brutally honest, if I bought expensive gear like the GoFlight stuff and it didn't work, even after reading the manual, I'd first contact their support. Have you done so? Really, unless you know that your kit actually works it seems a bit pointless messing with it in FSUIPC. Get it working as GoFlight Inc intended you to first. Delete your FSUIPC INI file and start all over again. Check the assignments in FS, and especially make sure all the Sensitivity sliders are at max (full right) and the null zone sliders at minimum (full left). FSUIPC is for more accurate tuning, fancy mappings, response curves and so on, not for miraculously making things work which are already broken. Sorry. Regards Pete

If "FSC" is "Flight Sim Commander", by Sascha Felix, then I know it is used by lots of folks as a planner, moving map, and so on, and I really don't think it will be switching on your autopilot automatically unless you have asked it to. This is why I said that you proper "fix" it to refer to the FSC documentation and learn how to control it correctly. However, I've scanned through the features of FSC on their website and I can find no mention of any A/P or flight control facilities offered. Therefore it is very odd -- are you sure you don't have some other programs also running? Ah .. I've just found out: the add-on aircraft is an ultralight! Surely the makers should have set "autopilot_available=0" in the CFG file themselves! I think you should report that to them as a bug. they should have nothing declared as "available" in the CFG files if it isn't really available! That is asking for trouble, sooner or later! I still think you should find out what and why something, FSC or whatever, is trying to fly your 'plane for you, though. Pete

Oh dear. You did not read my last reply correctly, did you?! Surely you do not actually want to REMOVE the autopilot capabilities of your aircraft altogether? For that is what telling FSX to do in the AIRCRAFT.CFG file will do! The problem shown, as I already said, is your use of FSC, or whatever you are running on WideFS, to control the heading of your aircraft via the autopilot. Please read the instructions for how to use your program and I'm sure you will find the answer. The problem is surely USER error, not something in any CFG file. :roll: :roll: :roll: Pete

You enabled every single logging option!? Why? Please never do that again when asked for a log. It clogs everything up with possibly the wrong information. I was very specific in what i asked you. Anyway, these lines then, luckily, came though: 487709 WRITEex 07BC, 4 bytes: 01 00 00 00 .... 487709 WRITEex 07C8, 4 bytes: 01 00 00 00 .... 487709 WRITEex 07CC, 2 bytes: 17 0C .. 487712 *** EVENT: Cntrl= 65580 (0x0001002c), Param= 0 (0x00000000) AP_MASTER 487712 *** EVENT: Cntrl= 66106 (0x0001023a), Param= 0 (0x00000000) AP_PANEL_HEADING_ON 487712 *** EVENT: Cntrl= 66042 (0x000101fa), Param= 17 (0x00000011) HEADING_BUG_SET This shows the Autopilot being turned on by an external program, working through WideFS, and the A/P is set to follow a heading. I would think this is why your aileron is non-operational, don't you? If you want to fly manually make sure you turn off the autopilot! A real A/P should disengage if you turn the yoke sufficiently, but it seems the A/P programmed into your add-on aircraft keeps the heading no matter what. It seems you are using a program connected to FSX which you don't understand? Does this "FSC" program have an autopilot control option? I think you ought to read its manual and see what you are doing wrong! ;-) Pete

I am not an aircraft designer and really have no knowledge about how a constructed add-on aircraft deals with the relationship between its visual modelling (which you see working) and its flight modelling 9which you see not working). In fact i thought these were inextricably linked internally to FS, so it is really amazing that they can somehow be separated. However, it is obvious that your aileron values ARE reaching the add-on aircraft model, else they would not become visially effective. I'm afraid only the aircraft programmers could really even begin to investigate what then happens to the aileron values they are receiving. Get more information by all means. Try using FSUIPC's logging facilities to log your aileron axes and bank results. If you go to the Logging tab in the FSUIPC options, enter these values in the "monitor" table on the right-hand side: offset 057C, type S32 (this is the Bank value) offset 0BB6, type S16 (the aileron input value) offset 0BB8, type S16 (the aileron position) Then check the "normal log" option below. FSUIPC4 will log both the offset values and the values supplied by SimConnect. You can also set the "FS display" option if you want to see them in real time, on the screen. I wouldn't mess with any of those files -- get the aircraft maker to sort those out, if the error in there someplace. Though the fact that it seems to be okay for a while before going strange does seem very odd. Are you sure you aren't getting memory corruption or something drastically going wrong inside FS? Please make sure you are up to date with FSX (SP2 or Acceleration), and with FSUIPC4 (there is a later version in the FSX downloads announcement above, and version 4.30 is being released imminently). Regards Pete

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