Pete Dowson

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

Those indicators, where they work at all in default aircraft, are operated by code in the relevant gauges checking the conditions under which they are lit. All such conditions are discernible from examining other values. The same applies to add-on aircraft, only more so -- the very sophisticated add-ons do the whole logic like the real aircraft. This is also done, for instance, in pmSystems logic. I don't know how programmable FSBus is. Maybe you can still do it? Otherwise you'd either have to write your own logic, or use something like pmSystems. Regards Pete

Well, I can change it for FS2004 only and check to see if I can measure any performance impact. Or I can release it as an interim update and if no one complains it must be okay! ;-0 Leave it with me for now. I'm in the middle of a couple of other things. I'll get you an interim update done within the next couple of days or so If it isn't desirable I'll look at alternatives for you. Regards Pete

The only times this sort of thing has happened is when there's some other process going on in Windows which is interfering. We've never really solved it fully, but examples of programs which mess it up are Windows Blinds Kensington Mouse Drivers Faulty Video Drivers. I don't know why they interfere just with this part, which is only a standard Windows dialogue. Try running FS in Windowed mode. Otherwise it is a matter of eliminating other programs / processes / services one by one till the answer is found. Since you already have an FSUIPC registration, then to get round your problem you could open the FSUIPC.KEY file (in the FS Modules folder), and add the line "WideFS=xxxxxxxxxxxx" in the [user] section, where xxx... is your WideFS7 key. Regards Pete

But in those examples the heading changes not reflected in the ADF bearing were only a few thousandths of a degree (9 and 13 thou for the two sequences), surely not enough to register on any normal ADF gauge? Isn't thiss simply the result of an "epsilon" setting deciding whether the change is sufficient? I can delve into the code, but So are you saying that you notice jumps in a fast turn but not a slow one? Also "five times slower" doesn't mean anything useful in itself -- for instance, the heading could be changing several times per visual frame. It is a direct read-out from memory whereas the ADF data has to be read by calling functions in FS internals. I have looked at the code and the ADF data is read at the same frequency as most of the other "fast" variables I have to get procedurally: NAV radials, CDI, GSI, HSI, that's every 4th FS frame. For a good frame rate that should be barely noticeable, unless maybe you have a very much enlargened ADF needle display? I could "promote" these values to once per frame, but I am a little reluctant to do so because of possible performance deterioration. Could you explain more about your unusual needs please? Regards Pete

Are they so different from any ordinary controls? I don't have any of these. If someone who has them wants to provide a guide I will certainly host it. What is wrong with following the steps in the User Guide to do this? They are aimed at ordinary non-computer literate users and have been quite well received now for many years. Have you even tried? what is it you don't understand? I spent a lot of time writing and developing the user documentation. It really does upset me that no one reads it and wants personal tuition instead. There is really no way I want to repeat the same stuff here, but seeing as that is the best achieved in instruction so far, what else could you be expecting? Regards Pete

Where's the full Install log showing it, then? There are three versions of SimConnect -- RTM, SP1 and SP2. You should always have the RTM one istalled, as this is the only one guaranteed to be there (it is installed with FSX from the DVD), and it is needed to run FSUIPC4 -- and many other Add-Ons. The tools are different. The tools for RTM are loaded by RTM's SimConnect, The tools for SP1 by SP1's SimConnect and so on. There are different versions of the tools for each, and you have to have the right ones. I cannot afford such complications for FSUIPC. It would multiply the support load threefold. There is one current version of FSUIPC4 at any time. It is loaded by the RTM SimConnect (the only one that should, in a correct installation ALWAYS be there), and then it changes to the latest version it can find. Please refer to the FSX Help announcement and try to repair the RTM SimConnect as it says. Regards Pete