Pete Dowson

It's easy enough to find in the drop-down -- I don't know how you missed it: "Autocoord toggle". There's also separate "on", "off" and "set" versions. Pete

Two questions in one, there. First, yes, with the GFDev.dll driver correctly installed, or added to the Modules folder, FSUIPC will recognise buttons and dials on recognised GoFlight units. There's no special "tab" or options menu for GoFlight, if that's what you are expecting -- the buttons and dials will simply be recognised and assigned a joystick/button number in the normal Buttos and Keys tabs in the Options. This is described in the User Guide, which is worth perusing. You will see that the dials on GoFlight units are normally seen as 4 buttons, fast ad slow in each direction. Second, FSUIPC cannot operate functions it doesn't know about, at least not directly. It knows about all those built into FS, and many built into Project Magenta. Whether other add-ons can be so programmed depends on them. If those functions are assignable to keystrokes, then you can first make sure the keystrokes work from the keyboard. When you are happy they work fine, program them to your GoFlight units via the "Keys" tab in FSUIPC options. If you are talking about the 737NG overhead (the PMDG aircraft I tend to use), then I think none of the overhead gauges are programmable for keyboard and you have to resort to using the Mouse. There are two ways around this, one of which is available now and reliable -- using Luciano Napolitano's "Key2Mouse" program to allow you to assign keystrokes to mouse positioning and clicking operations -- and one of which ("mouse macros") I've been working on only this last week, and has reached trials stage in the current interim versions of FSUIPC (3.806 and 4.266, in the Downloads announcements above). Interestingly enough, apart from the "APchart" application, already supported through the supplied mouse macro file in those downloads, the FS9 PMDG 737NG overhead is my current main test vehicle for the more advanced mouse functions. I do have a working macro file for a specific version of the PMDG 737NG. The risks are that some of the mouse actions need code offsets which MUST match exactly the code you have installed, else they will almost certainly crash FS to the desktop. Unfortunately, as yet, I've found no way around this risk. That said, however, if they work (i.e. if the macro file corresponds correctly with the installation of the add-on you do have), then they seem to work well, and reliably. At present I have the initial version of this macro file under review in PMDG, to make sure I am not violating any copyrights. I don't think I am, but except for private tests I cannot at present release the files publicly. I am also still looking for ways to eliminate or at least reduce the risks of crashing FS when using mismatched macros. Regards Pete

I've done this in version 4.266, now downloadable via the FSX Downloads announcement above. Regards Pete

Okay. Thanks for letting me know. Good luck! Pete

Did you find time yet for this? I've been trying to make Brakes cause a problem here now for quite a while, with no success. I assigned them and calibrated them exactly like you. I also went all the way through the code lookng for anything odd which might make brakes different from any other assigned axes -- there isn't. So I'm still at a loss. One more thing in review. When I analysed these entries in your log: 39.95232 [ 1, 2383]TransmitClientEvent:ObjectID=0, EventID=66387, dwData=-16383, GroupID=1, Flags=16 < 39.95234 [1] Event: Group=2 EventID=66387 Data=-16383 > 39.95235 [ 1, 2384]TransmitClientEvent:ObjectID=0, EventID=66388, dwData=-16383, GroupID=1, Flags=16 < 39.95237 [1] Event: Group=2 EventID=66388 Data=-16383 These are two events setting Left (66387) and right (66388) brakes, respectively. no error, perfectly good. They re-occur regularly without problem. However, much later (3 mins 42 secs): > 222.61162 [ 1, 11209]TransmitClientEvent:ObjectID=0, EventID=66388, dwData=-16383, GroupID=1, Flags=16 < 222.61164 [1] Event: Group=2 EventID=66388 Data=-16383 > 222.61165 [ 1, 11209] < 222.61166 [1] >>>>> EXCEPTION=2, SendID=11209, Index=0 <<<<< Unrecognized Data Received. [ 1, 11209] I assumed that all these lines were referring to the one exchange, number 11209. But they can't have been. The "Event" which is logged IS the result of the "TransmitClientEvent", so it is okay. It looks like SimConnect.DLL then transmitted a bad block to FSX, which bears the same sequence number (11209) but has no valid type (this is the "> 222.61165 [ 1, 11209]" line, without expansion as FSX doesn't recognise it. The exception for "unrecognized data" is referring to this second, incorrect block from SimConnect.DLL. Something, and I've no idea what, is causing a problem between SimConnect itself and FSX. Why this should only occur when you have brakes assigned directly in FSUIPC4 I've no idea either, but I've now also noticed something very different in your SimConnect log to mine. There are many many Brake operations, i.e. > 1244.78564 [ 1, 56858]TransmitClientEvent:ObjectID=0, EventID=66387, dwData=-16383, GroupID=1, Flags=16 > 1244.78567 [ 1, 56859]TransmitClientEvent:ObjectID=0, EventID=66388, dwData=-16383, GroupID=1, Flags=16 These are occurring regularly even though the values being sent are the same every time. This shouldn't be happening -- FSUIPC4 ignores successive identical values, it only sends new ones when they change (although, for brakes, it always sends the pair even if only one changes). I'm thinking this is jitter on the axes, somehow being detected BEFORE I calibrate to the range needed. I'll have a look at that -- maybe I should also eliminate equal final post-calibration values. However, since most of the values are -16383, i.e. brakes off, I would like you, please, to set a proper null zone when calibrating your brakes in FSUIPC4. In other words, go back to the configuration which was crashing, but recalibrate so that you press the brakes a little, to get them off the stops, before clicking the minimum set button. The FSUIPC instructions for calibration does advise always to set a null zone to avoid jitter problems. Incidentally, one of your other axes (the Rudder, in fact) is also jittering, this one quite badly: > 1244.73518 [ 1, 56852]TransmitClientEvent:ObjectID=0, EventID=65764, dwData=266, GroupID=1, Flags=16 > 1244.73526 [ 1, 56853]TransmitClientEvent:ObjectID=0, EventID=65764, dwData=399, GroupID=1, Flags=16 The value seems to be 399 correctly, but that 266 value is recurring every few seconds. Is this your feet jittering on the rudder? If not, maybe you should consider trying a different USB port for it? Meanwhile, I'll look to see about reducing the number of identical successive transmissions to SimConnect. Regards Pete

Tell me more. Does Ctrl+Alt+4 work on the keyboard? Alt is a very difficult Key to use, because you have always to be sure to press it first -- if you do not it invokes the Menu instead. I suspect that FSUIPC issues the Alt first even if you pressed them the other way. FSUIPC has a fixed order for all the shifts -- it deliberate does Alt first just so that Menus can be invoked. Best to always avoid Alt if possible (I think I say that in the documentation someplace). Is that an ALT combination, too? When you say "nothing", does it Log nothing in the FSUIPC4 log when you enable the Button and Key logging facilities, to check? (See the Logging tab in the FSUIPC options). Please do use the facilities to check your actions. There's a lot there to help you. If you don't understand the logs, show them to me. Also show me the [buttons] section of the FSUIPC4.INI file so I can see your programming of the buttons. If the keypresses don't work on the keyboard, it is either PMDG or your assignments in PMDG. If they work, then if would either be the ALT key problem, or you. I'd need more information to be more specific. Regards Pete

FSUIPC, the program, is the same whether you register or not, and is downloadable from http://www.schiratti.com/dowson as always, never from SimMarket! Please do refer to the documentation and announcements. If you don't install it it won't be there so it cannot be used. So, yes, of course, if you want to use it you have to install it. That's all "installation" is -- copying the FSUIPC.DLL into the FS Modules folder -- exactly that one step as clearly explained in the instructions! Please do refer to the user guide. Whether you will want to re-use your old INI file on the new system depends on whether you are programming buttons and joysticks and have changed any of that equipment. The INI file stores all of your settings. When installed and you want to Register FSUIPC just re-register using exactly the same details as originally. You have those in the KEY file which is an ordinary text file. I really don't know what you are trying to go to SimMarket for in the first place? You'd only need to do that if you lost and not backed up your registration details or KEY file. Backing that up is also recommended in the User Guide! Pete

Thanks! Found it and fixed it -- an unforeseen side effect from another fix. It'l be okay in the next increment, probably 3.805 tomorrow 9monday). Regards Pete

Is that a Gauge variable? It isn't one I'm familiar with. The only panel electrics switch I'm aware of is the Panel Light switch. There's an Avionics switch, maybe that is what this variable refers to? If there's a keyboard command associated with it in FS, there must be a FS Control. If there's an FS control, that's a KEY_EVENT and can be used direct with SimConnect or through offset 3110 in FSUIPC. If you enable Event logging in FSUIPC and press the key you will get the Control logged. If it is the panel light or the avionics switch there are certainly FSUIPC offsets controlling (and indicating) these. Incidentally, if the circuit goes off when the engine is "switched off" maybe the battery is off or flat? With the engine running it is presumably getting power from a generator. Regards Pete

You don't install FSUIPC on a clinet. It only gets installed into FS. That's no error, they are both current versions and match fine. WideClient is the same for all versions of FS, but WideServer is different in FSX to any earlier FS versions. You need no help. This is merely an incorrect indication from pmFileCheck. I think it dates from the days, 5-10 years ago, when you had to keep WideServer and WideClient in step as they were developed. Please write to PM and ask them to modify their check. Meanwhile, why are you concerned? It doesn't matter, it works doesn't it? Regards Pete

API is used a lot by gauges in panels. You might want to check your add-ons. Some attempted transfers of aircraft from FS9 to FSX are known to cause problems. Regards Pete

The way in which joystick numbers are assigned is determined by Windows, and I think that just depends on which USB ports you plugged them into. Easiest probably is to unplug them then plug them in the other way round. Else edit the INI file changing all joystick 0 references to 1 and all 1 references to 0. Regards Pete

I tried to do this, but it does not seem to leave a trace in the Logfile In that case there are no FS controls to handle it, and no way to program a button or keypress for it. You'd need to use the mouse (or possibly Luciano Napolitano's "Key2Mouse" program so you can operate the mouse move/click by keypress, then program the keypress on a button). Sorry, but there is no way that "Event" logging, which is what I asked you to enable, logs readouts. It sounds like to enabled the wrong option. Please look in the Logging page, left hand side. There's one radio button only for normal events. The extract you supplied looks like you enabled IPC read logging by mistake for some unknown reason, and had some program or add-on reading a private add-on offset. I've no idea what it is supposed to be, but checking here that offset is assigned to Squawkbox, so i assume you have that installed. Regards Pete

I'm not sure they have FS controls assigned to them. You can check easily enough -- enasble Event logging in FSUIPC (Logging tab) and click the ckock buttons. Check the log, see if there's any relevant controls logged. I've a feeling these are local functions to the gauge, with no externally accessible controls. Tomorrow I might check to see if they are amenable to the new facilties I added in FSUIPC for mouserects, but I fear they are non-standard, or XML. Regards Pete

Okay. It sounds like the 392 bit was just a misleading worry (a red herring). However, in case it is contributing to the problem I will go ahead and remove it from FSUIPC -- sorry, it will be monday or Tuesday now. If you load the CDU using a "Run ..." parameter in WideClient.INI, you can direct keystrokes from a KeySend to it even if it has not got the focus. This is a standard facility of WideFS. Regards Pete

Not mine. I'm afraid I don't know C# at all. It doesn't look anything like C or C++, and I don't like "managed" languages at all, too much stuff between me and what I want to do. Can't you just try opening again? The C code I supply (the source for the library) actually does lots of retries in any case, over a period of many seconds. Of course you don't want to hang the PC -- if you take the processor then FSUIPC, running in a different process, won't be getting time to respond and connect in any case. It is only a Message it is looking for, but you have to allow time for that. So, the normal way would be to continue to attempt to connect on some sort of Timer message from Windows, sleeping (relinquishing the processor) in-between times. You could display a little amodal dialogue saying "trying to connect ..." with an "Abort" button too. Regards Pete

Yes, provided the device will signal more than one button pressed together. Some, like the game port CH flightstick, do not -- only one button is ever signalled at a time. You should be able to check this in Game controllers. Show me what you tried. Regards Pete

Sounds like you have something really messed up. If your devices are the same (drivers, calibration etc), and your FS configuration the same (assignments etc), and the version of FS is the same (FS9 or FS9.1, whatever), and the FSUIPC.INI file is unchanged, then 100% of everything is the same -- so it must act the same. This is ordinary everyday logic. If some things now do not work, if they are different, then they are not the same, so you have changed or forgotten something. If you are sure the FSUIPC.INI file is the same, then it is not related to FSUIPC. You must look elsewhere. You mention PFC as one of the devices. Is that using my PFC driver? If so you probably forgot to install it or its INI. It has its own INI with the same consideration. Pete

Thanks. Looks pretty standardif there is a problem in FSUIPC4 you'd think many others would have tripped over it (me too, come to that) But I'll try some rigorous all-out Brakes testing. No, that shouldn't matter as the calibration process starts by ensuring the value is in range. Otherwise it can't calibrate. No, because those errors are occurring on exactly the same data which is not failing elsewhere in the same logs. The only possible explanation for this is something going wrong with the data between SimConnect and FSX (where it is using TCP/IP or Named Pipes -- Named Pipes in your case. This is why I suspected memory, as pipes are simply shared memory areas. Okay, thanks. That would be very useful, as it seems rather unlikely that I will be able to reproduce the problem here -- which I would need to to narrow it down. Regards Pete

As long as you re-registered, yes of course. The INI file is where all of your FSUIPC settings are kept. Pete

FSUIPC4 uses DirectInput for its axis reading, and this gives it access to up to 8 axes per joystick. The FSUIPC3 version still uses the old Windows joystick interface, and is limited to 6. Hmm. It seems that the Saitek drivers provide the axis called "S" in DirectInput as "V" in the old interface used in FSUIPC3. You have 6 axes assigned in FSUIPC3. That's actually the most it can see, so you'll never get another there. Sorry. Regards Pete

Yes, sorry. I found that FSUIPC4 is doing it initially and then every 7.5 minutes, whereas FSUIPC3 does it only after 7.5 minutes. Well, it should be about 7 minutes, not 3, according to my code. As i said, this is there at PM's request, and it happens on FSUIPC3 too. The only difference is the one I mentioned above and before. I have asked Enrico why this was required, and he cannot remember either, so I will probably take it out. It is odd that many folks use these offsets and FSUIPC3/4 have been doing this for years with no one mentioning any problems. I'll remove the code in the next updates. It might not be for a few days though. Regards Pete

Strange. The brake axes aren't treated any differently to the others. I wonder what is going on? Could you show me the Assignments and Calibrations part of FSUIPC4.INI, if possible in the configuration which was causing the crashes? In your workaround are you still calibrating the brakes in FSUIPC? I'd like to know if it seems to be just the calibration, or the direct assignment. Did you ever try FS assignment, but not "direct to calibration", but via FS and still calibration in FSUIPC? You see there are so many combinations: 1. Axis assign in FSUIPC, Direct to FSUIPC calibration 2. Axis assign in FSUIPC, sending to FS, no calibration in FSUIPC 3. Axis assign in FSUIPC, sending to FS, calibration in FSUIPC 4. Axis assign in FS, calibration in FSUIPC 5. Axis assign in FS, no calibration in FSUIPC I'm not asking necessarily for you to test each, but if you have tried them I'd like to know which you found to be a (possible) problem. Right. Understood. But I'd like to conduct some intense testing here using the same brake configuration as you if possible, just to make sure it isn't something in my code. Regards Pete

593 is hex 0251, which is PM's encoding of "Ctrl Q". Both FSUIPC3 and FSUIPC4 write this every 7 minutes or so, at PM's request, and have done since around Feb 2003. Ctrl Q should make the CDU terminate. It is to do with PM's demo mode I think. It also writes 'Q' to offset 542A at the same time, to terminate the Glass Cockpit. No offsets are "used by FSX", they are all memory owned by and maintained by FSUIPC. All of those assigned for Project Magenta use are reserved for Project Magenta use, though that doesn't stop anyone from writing to them. Please persist with PM support. I'm sure they are the only folks who can help. as far as I know the action of FSUIPC writing these values is still correct, but I'll double check anyway. I wouldn't have thought it was this causing you the problem -- unless you are running PM in demo mode, i.e. not purchased yet? [LATER] I do note one thing different with FSUIPC4 from FSUIPC3 -- the values are written within the first minute, then every 7 minutes or so, whereas FSUIPC3 doesn't write them for the first 7-8 minutes. Maybe I need to make FSUIPC4 do the same. Regards Pete

Try 3.804, from the Other Downloads announcement above, and let me know. Regards Pete