Pete Dowson

You said, mysteriously "I had a look at the log, but couldn't find anything that would show me any error." Doesn't the above message suggest to you that something is seriously wrong at all? Something is clobbering your FSX SimConnect -- in that log it was fine until 2526 seconds (42 minutes) into your session, so i would guess that is is something building up. I'm sorry, I've no idea what. Once FSUIPC no longer sees the regular SimConnect messages it expects, after a certain time (5 seconds with no events at all), it assumes things have gone awry and closes the connection (hence the missing Menu entry) and attempts to re-connect. As you can see from that enormous log showing umpteen repetitions of the same failure, that didn't succeed -- though it managed to re-open it never saw and results in the 5 or so seconds it then allows, on every single subsequent retry. Maybe a SimConnect log will show you what is going on (see the FSX Help announcement above). It could be some other SimConnect client somehow hogging SimConnect too much, but I’ve never seen exactly that before. There was a serious bug in the original release of SimConnect which would cause SimConnect to sieze up on certain combinations of clients, initialising in a certain order, but Microsoft did do some revisions by SP1 to work-around that 9not solved, please note -- so it could be the same thing). I remeber FSCopilot was one of the prime add-ons involved in those problems, so maybe Microsoft's work-arounds aren't working too well for you. If you do get a SimConnect log, it will be huge, so don't post it here like you did all that repetitive stuff, please. Probably best to post it with a full description of the problem to tell_fs@microsoft.com, as they will need to fix this stuff for ESP and FSXI. I can take a look as well if you like, but it isn't something I'm likely to be able to do anything about I'm afraid. Send to petedowson@btconnect.com -- ZIP it first please! Possibly FSCopilot is still written to use the RTM or SP1 version of SimConnect, in which case one possibly area of problems is memory-filling with TCP/IP queued blocks. FSUIPC uses the SP2/Acceleration version of Simconnect if available, and, by default that should be using Named Pipes instead of TCP/IP which avoids that sort of congestion. However, it is just possible that you have a SimConnect.xml file which is preventing Named Pipes being used, so perhaps I should take a look at that. For experimentation I could maybe supply a version of FSUIPC which allowed the 5-seconds-with-no-contact interval to be elongated, especially when trying to reconnect, but really if it isn't getting messages on every single FS frame (which it is "promised" by SimConnect) something is already seriously amiss -- a frame rate of 0.2 fps isn't likely I hope! Incidentally, you also said: Now neither of those add-ons use FSUIPC at all, and are entirely unrelated to anything FSUIPC does. They would have also stopped working because they too became frozen out of SimConnect. They probably do not detect this like FSUIPC does and so sit there simply not working. Regards Pete

I know the pitch and bank holds worked pretty well, but i never did get the speed control workiing that well -- it always seemed to hunt too much on the aircraft I tried it on. Some of the parameters need adjusting to suit each aircraft, separately. Why doesn't Deamfleet's 727 have autothrottle? Weren't those models so equipped? I'll look at possibly re-instating the options, but maybe in a different form. watch for a future increment in the Announcements above. You'll need to test it out in FSUIPC4 as I doubt it has ever been used. Regards Pete

Yes, all that is exactly correct, and what you would expect for a knob which clicks once for "on to off" and again for "off to on". It doesn't matter at all how many times you have to click it to have it recognised in the dialogue! Why do you think that is of any relevance? Think of it like a toggle switch -- FSUIPC will see it when you toggle it on, but not when you toggle it off. The dialogue is designed to work that way to avoid false readings. All it needs to do is see it, and it IS seeing it as you just said! That doesn't mean you cannot program it for for "press" and "release" EXACTLY as i explained!! :-( Why didn't you just go ahead and do it instead of making life so complicated for yourself unnecessarily? Regards Pete

Assuming you really mean "serial IN" (for the GPS would need to RECEIVE data from the PC), you need to know that the "S" in "USB" does stand for "Serial", and it is probably the serial connection you need. On the PC USB ports have a strange name (not "COMn") which you'd need to determine -- I think there's an example in the GPSout docs. The usual problem is that the connection to the GPS on the PC will be taken up by an Active Sync or other program, installed to enable you to download routes & maps and upload tracks. I think you have to stop that running to free up the port. Regards Pete

Just the reference would have done, you know! :shock: Phew! That's really old stuff. Over three years since I did that, not touched it since. The bit that says "My testing facilities are still in place" was true then. Sorry, obviously I forgot to remove that. The testing facilities were only intended to be in place for a limited time, basically till I'd finished testing, maybe a wee time after. And this was on FSUIPC3 only. The testing facilities were there for testing, I naturally didn't expect folks to actually USE them for real, even then only to evaluate the facilities to see if they looked worth using for their programmed autopilots. I doubt they've ever been tested in FSUIPC4 as I don't know anyone who ever used them (till now, it seems). Checking my code I see this facility is still enabled in FSUIPC 3.81, but I'm not sure that it has ever been in FSUIPC4. Did you use it in FSX, and if so in which FSUIPC version? More to the point, did it still work? How and why are you using them? I can probably re-enable the testing facility, but if there's a genuine real use for the added controls as they stand I should be considering enabling them by default, not via a Debugging Test facility -- or at minimum by something sensible like "EnableAddedHoldControls=Yes" in the INI. Regards Pete

The default delta of 256 might cover any minor jitters. Modern digital joysticks on USB ports are a lot freer of jitter in any case. The main things which used to cause this (dirt, temperature, humidity, fluctuating power supply?) don't seem to affect the modern kit much. so it would be worth a try. To see exactly what your kit it doing, temporarily enable "Raw" mode in the Axis assignment and watch the input values. Regards Pete

You don't have to assign unused axes to anything. just don't assign them. That will actually save FSUIPC time reading themn and sending values to FS to do nothing useful. You could assign both to the same functions at the same time. This will work fine PROVDED that when left alone, untouched, they provide no changed values (or, with FSUIPC's assignments, that the changes are within the "delta" value, below which changes are ignored). The easiest way is to create an extra variant of the aircraft in the AIRCRAFT.CFG file, making some change or addition to the Title so that FSUIPC will select the correct settings automatically. e.g. just duplicate the [Aircraft.0] section as [Aircraft.1] and add "Yoke" to one title and "Joy" to the other, then use this difference to identify the aircraft. If you are already using a short-name section (substring) for this, obviously the change will need to go next to it in the title. Regards Pete

There's no easy way to do that. You are really talking about 4 separate buttons. You could do it by using two flags I suppose, with some complicated logic, using parameters edited direct in the INI file, but there is nothing geared to what you want to do. Are you sure you want to venture into such strange fiddles? Start by programming the button to set your 25% in the FSUIPC options. i.e Control "Traffic Density Set" with parameter 25. Then look in the INI file. In the [buttons] section you'll find a line like 1=P1,1,C1008,25 The number on the left is simply a parameter sequence number. The "P1,1" here says "Press joystick 1, button 1" (yours will be different. 1008 is the internal number of the traffic Density Set control. Now you need to use two flags to give you 4 alternatives. Flags are nominally associated with buttons, but they don't need to be real buttons you actually have, so I'll choose buttons on joystic 15: buttons 0 and 1. Make the first parameter conditional on both flags being off: 1=CP(F-15,0)(F-15,1)1,1,C1008,25 The red parts I've inserted make this conditional on those two flags being clear (the '-'). Now, on the same condition we need to set one of those flags in order that the next time though you get a new result: 2=CP(F-15,0)(F-15,1)1,1,C1003,3840 The 1003 control is "set flag" and the parameter 3840 is 256 x 15 (the joy number) + 0 (the button number). Now the rest follows similarly: 3=CP(F+15,0)(F-15,1)1,1,C1008,50 ;Flag 0=ON, Flag 1= OFF, set 50% 4=CP(F+15,0)(F-15,1)1,1,C1003,3841 ; and set Flag 1 ON 5=CP(F+15,0)(F+15,1)1,1,C1008,75 ;Flag 0=ON, Flag 1= ON, set 75% 6=CP(F+15,0)(F+15,1)1,1,C1004,3840 ; and set Flag 0 OFF 7=CP(F-15,0)(F+15,1)1,1,C1008,100 ;Flag 0=OFF, Flag 1= ON, set 100% 8=CP(F-15,0)(F+15,1)1,1,C1004,3841 ; and set Flag 1 OFF After steps 7 and 8 it's all back to the start again, for 25% next press. Pete

Okay. That's interesting, but I still don't understand it. I've always had all my axes (not from CH equipment though) sent "direct". It is more efficient, if you are calibrating in FSUIPC, because the other method involves three times as many messages flying about between FSUIPC and SimConnect -- one lot to send the axis values to FS, then the same stuff being sent from FS to FSUIPC for calibration, then back from FSUIPC to FS after calibration. With "send direct", your axis values are calibrated then sent to FS, by-passing the circuitous route. One set of transfers, so it should be simpler, less error prone, and three times more efficient! In theory. So, now I have to find out what there is about that which could possibly make a system crash. Pete

Isn't this a matter for GoFlight support? If you've programmed it in FSUIPC (why?) then you probably need to program both the "press" and "release", as most rotaries send an "off-on" and an "on-off" alternately, hence the two "clicks" to the next "press". Pete

Ah. There you are then. FSUIPC can handle 70 keyboad presses, no troubles. ;-) No, I understand, but your question was why can't FSUIPC see the 70 buttons on your device, and the answer is now made clear -- because they don't look like buttons, but keypresses. Use the "Keys" tab in FSUIPC, not the Buttons one. I assume that this "Mjoy Mapper" is the driver provided with your hardware, so it knows how to read the buttons. It converts them to keypresses, so, effectively, that's what you have to use. You have no choice. If you want anything to recognise the buttons as buttons instead you'd have to go back to the makers and ask for an appropriate driver for their hardware which does such things. Not you, perhaps, but whoever designed and built the hardware. Who else could do it? Who else knows the hardware? FSUIPC can only handle hardware it understands, or which Windows understands and handles for it. There are defined interfaces for this, and FSUIPC uses them. If a hardware manufacturer wants maximum flexibility for their product they need to consider what interfaces to support, and then provide the appropriate drivers for them. Evidently, for your hardware, they thought providing a keypress capability was sufficient? Regards Pete

FSUIPC uses interfaces it knows. I cannot use interfaces it doesn't know -- you figure it out! You say "the only way you can read" these 70 buttons is by using this mapper -- how do YOU read them? What known standard interface are YOU using? I can design my own hardware with any amount of switch capability and write my own driver for it, but unless that presents itself to Windows in a standard way, the only way anyone else can ever use them is by using some SDK or interface I tell them about, for my specific design. That doesn't answer any question at all, it simply avoids it. how are YOU reading the buttons??? Saying "by MJoy Mapper" means nothing to me, that isn't a standard Windows interface, is it now? Yes, write a standard Windows HID driver (HID = Human Interface Device) to present the device to Windows as a number of standard joysticks, exactly as the EPIC driver does. Regards Pete

Don't the calibrations work for any plane? Surely once you have the min/max/centre and response slope sorted, the same applies to all -- well, all except helos possibly? You don't have to "undo" anything -- just save a copy of your FSUIPC.INI file someplace. Everything you do is saved there, no where else. I thought I said? Last change. I'll repeat the relevant bit from my last message: Depends how much you move it -- if more than the Delta, the bank will be affected immediately (until the next change from the one you are using). The innards don't know where the values are coming from -- they are simply thrown at it by the multiple axis assignment. Pete

Why is telling the straight truth, that you don't need to change anything, unhelpful? I don't understand. How does altering one recorded detail in one little file on your disk let anyone know anything? Unlike other complex systems, FSUIPC does not touch the Internet. It doesn't "tell" anyone about you. It isn't spyware or anything so complex. It keeps itself to itself and just works by a key tied into an ID (any old ID) which you yourself chose originally. I hate all those complex systems. With FSUIPC to remove it you just delete it, to install it you just do. Nothing complicated, nothing to misunderstand. I don't know what's got you so aggravated -- you evidently like over-complex systems? :-( On your second insulting message, Why are you saying it is "flakey"? It works perfectly and easily and has done so now solidly for five years, without there being anyone like you before. If you want to re-re-register you can simply delete the KEY file (which contains your registration) then re-register with whatever Name/Address/Key you wish, provided those are properly purchased and are therefore tied together. I really don't understand why you think you can simply change your ID and expect the same Key to work, nor why, just because it is a nice, simple, completely self-contained system, you call it "flakey"! Can you explain yourself, or do you just like being rather offensive? Pete

That's 32 buttons on each of up to 16 joysticks. Neither the Windows joystick interface nor DirectInput can cope with that, so how are you reading them in Windows? If you have your own driver it must have a non-standard API, so how on Earth could FSUIPC handle it? It only knows DirectInput and the main joy API. The EPIC card had up to 512 buttons. It looked like 16 joysticks to Windows. 16 x 32 = 512. How are you currently getting 70 buttons read on one joystick via a standard Windows interface?? Regards Pete

I don't really think that's very relevant. I only found out by swapping memory chips. Don't forget, there's no parity checking on the current DDR memory in most motherboards. Stress testing doesn't properly test long-term retention nor pattern interference. The best way always is to try alternatives. Pete

If you change your address in the registration the Keys will not be valid and you will have to buy new ones. Why on Earth do you want to change them? The Name, Address and Keys are tied inextricably to each other. There's never any need to change any of that. The name and address is only there to ensure the key is unique and belongs to you. It is never used as an address. Regards Pete

Can you give me details of the references you are using, please? As far as I remember these there was a temporary testing facility I added for this, for Enrico Schiratti, when he was thinking of implementing a new autopilot, but I don't recall releasing them generally nor maintaining them through to FSUIPC4. I wasn't aware anyone was using them. Incidentally, please never just say "latest FSUIPC4". That's meaningless -- I've had cases where folks have said that and it turned out they were using a year-old version. they'd not seen an pdate on whatever site they went to, and they never referred to the "supported versions" announcement in this Forum. Please ALWAYS quote the actual Version number. It is easy enough to find, after all, being displayed in the Options, logged in the logs, etc. Pete

Two possibly relevant stories to relate. First, one which happened to me this week: I'd updated a PC with new video Card, DX10 capable, installed vista 64, and was about to upgrade memory from 2Gb to 4Gb. Between each step I was re-testing FSX + FSUIPC4 + my cockpit drivers (working through Axis assignment & Calibration in FSUIPC4). I suddenly noticed, on Tuesday this week, that on one particular Joystick Calibrations page, one of the normal "min" Set buttons was always disabled and the two right-most axes couldn't be calibrated because the main Set buttons did nothing. Now nowhere in my code do I enable/disable Min/Centre/Max "Set" buttons, I only ever change whether they are visible or not. And I've no idea what the non-operative Set buttons were trying to do. So it was a struggle. Annoyingly, with a Debug version it didn't happen, nor with a previous version. Thursday after wasting nearly three days looking for an impossible software bug, I gave up. I decided it was impossible for these things to happen UNLESS some pixie was actually change values (bits) inside memory ..... Clunk! Memory! Luckily I had another pair of 1 Gb sticks (as I said, I was about to upgrade from 2 Gb to 4 Gb), so I swapped them over. Bingo! no more weird inexplicable problems! The second story is actually more elongated, a long thread here relating to a crash which was occurring in FSX on longer flights. It seems it all started when wind smoothing was added to FSUIPC, so this was under suspicion. All sorts of things were tried, till, finally, the fault went "solid" and turned out to be a memory problem also -- new memory chips and all was well. All I'm trying to point out here is that when things worked once and then don't for no apparent reason, it is not always something you've done, and not always a software bug. With two recent incidents both costing a lot of time and both down to memory chip problems, I am beginning to wish PC memory never started leaving off the Parity checking. My new PC, just arrived today, has parity checked memory. I realise it might be a bit slower but in the long term it might save me a lot of bother! ;-) Regards Pete

I don't know, there may be. I use a program called "FlightKeeper" which logs loads of things, not just track. Regards Pete

I don't know of any software which will do exactly that, not send a mouse click without previously moving the mouse to a given location. Though you could check Luciano Napolitano's "Key2mouse" to see if it has such a provision. I don't know. But if you are trying to do away with the mouse, how will you move it to the right position before the click? For specific places on screen you would need Key2mouse. It allows you to assign a Key to a mouse. Then, in FSUIPC, or maybe your joystick driver, you can assign that keypress to a button. FSUIPC's "mouse macro" options allow buttons or keys to operate some (not all) mouse-only functions without the screen being involved at all. Regards Pete

FSUIPC cannot easily itself cause FSX to crash -- all cases so far have been either due to the actions of programs using FSUIPC or to bad FSX data which just happens to be accessed more thoroughly or frequently when FSUIPC is running. The prime instance of the latter are the weather files associated with flights which are notorious ofr crashing FS when corrupted. This shows FSX crashing immediately on loading the Flight c:\documents and settings\mhf\my documents\flight simulator x files\Chap_10_Lost_and_found.FLT Previous to that it had loaded three flights quite happily. When you say "entire tree", can you explain, please. Obviously you cannot mean exactly that, as that contains most of your system information, not just flight sim stuff. In particular, it is important to note that for a clean install there are at least THREE FSX folders needing removing in the Systems area: 1. The "My Documents/Flight Simulator X Files" part you presumably meant. 2. Your "C:\Documents and Settings\mhf\Application Data\Microsoft\FSX" folder, where your FSX CFG and other vital files are kept 3. Similarly the "C:\Documents and Settings\All Users\Application Data\Microsoft\FSX" folder, where the scenery configuration goes. Also, because SimConnect is a "side-by-side" system installation, is doesn't get uninstalled. I think the only way to be sure a corrupted Siconnect is replaced is to actually delete its folders -- as described in the FSX Help announcement above. When you uninstalled FSX did you also delete any folders left behind? With the Modules folder having been added by FSUIPC's installer, the FSX uninstaller won't remove it, so the re-install would not have given you a "default" FSUIPC. You'd need to delete the folder entirely then rerun FSUIPC's installer. There's really no other information in the stuff you've provided to indicate what might be happening. Something is either corrupt on disk, or is getting corrupt in memory. Things like a memory fault can give results like this, so after thoroughly eliminating possible software suspects it may be time to look at the hardware. The fact that it all used to be okay then suddenly started doing this consistently does smack of something getting broken or failing. Regards Pete

Do you? On flight sim, you can left or right click anywhere. What is it you want to do? Ermost add-on gauges and some default gauges have mouse-only functions, yes. The default RIM is one such. But yyou can use left click from the mouse. Inn fact that's all you can use, so I'm not sure how you say you cannot? I assume you mean Luciano Napolitano's "Key3Mouse" program? What is not like it? In recent versions of FSUIPC I've provided a facility to generate "mouse macros" to allow some (not all) mouse-controllable functions to be added to FSUIPC's control list, for assignment to keys or buttons. Have you looked at this? Regards Pete

There's only ever one actual contact no matter what -- Sending a message, using "SendMessageTimeout" (the timeout is there to prevent the application hanging if the receiver never replies). The application first needs to get the window handle for window class "FS98MAIN", which is FS. The Message sent provides an Atom ID, registered with Windows, which allows the memory filename to be reconstructed by FSUIPC so it can open the same memory file, already created by the application. That's it, nothing else. If the application can't connect, as if it never sees FSUIPC, it is surely because of one of these reasons: 1. Windows prevents higher privileged Windows from being detected (which I certainly cannot believe), or 2. Windows refuses to allow messages to be sent to them and forces them to timeout instead (which I also find hard to believe), or 3. Windows allows all that but won't allow FSUIPC to open the memory mapped file. Actually, there's a way of finding out. If you go into FSUIPC's Logging options and enable IPC Read and Write logging, it logs any errors trying to establish the connection when it receives the message. If it never receives the message then one of 1 and 2 above are correct. Otherwise there should be an error, one of these: IPC ERROR: zero Atom Id IPC ERROR: Atom Id not recognised IPC ERROR: Offset >= 65534 IPC ERROR: Cannot OpenFileMapping (Error=N) The third is a simple data error and not likely here. The last is the one I suspect. The error number will be one of Windows system error numbers. Regards Pete

Ah, my error in trying not to make the User Guide so large and encyclopaedic that not even the one person who currently reads it would! ;-) In fact the release notes for the release in which it was provided (now part of the History document) explained it in a little more detail: I'm always a bit reluctant putting all that sort of stuff into the user guide. It's too big already. I'd need to start taking facilities out! ;-) But maybe, in this case, I'll add the word "single". Won't make it significantly larger. Does that happen? Just because MyTrafficX doesn't use real-world schedules doesn't mean it has unrealistic placements. i've found it pretty good in fact. Also, with ONLY real world "schedules" you get no unscheduled flights, charters, etc. MyTrafficX seems to cover a lot more, just not actual schedules. If you do get wrong airlines in places, let Burkhard know. He's very responsive and his support forum is very close. Regards Pete