Pete Dowson

SimConnect is standard in both versions of FSX. If you have installed FSX it should have been installed automatically at the same time. If not you can try repairing it as described in the FSX Help announcement at the top of this Forum. Regards Pete

I'm not sure how to do that, but I'll check. An Error is "thrown" (but in the Log) when the signature verification fails -- which is what it causes. Are you saying that a message box with option to Abort FS or Continue Regardless should appear? There are problems implementing those properly in full screen mode as they can appear behind FS and make it look like a hang, though I could possibly work something out via the Menu system, like the PFC verification screen. In the case of FSX, the lack of the cryptographic services may well affect the SimConnect interface too, possibly making pretty much all add-ons, FSUIPC-using or not, appear to not work. I'll need to check whether it actually stops the DLLs being loaded, but if not maybe I should add the same explicit warning messages there. Not sure why that should behow does it report that? It does use a separate interface to FS, to read Gauge variables (very inefficientlly, I might add -- it was designed specifically just to show the Gauge variables for comparison/testing of the FSUIPC offset values as shown by FSInterrogate and FSLook2). Regards Pete

OkayI can reproduce that pushback problem here with "NoAxisIntercepts=Yes". I'll figure out what's wrong and fix it in the next interim update -- look out for it in a few days, in the FSX downloads. Meanwhile I'd like to know the reason for the "NoAxisIntercepts=Yes" setting, please? Did you have some problems with axes? Regards Pete

I only just noticed you have Axis intercepts disabled. Can you tell me why? Maybe it's related to this? Please try it with the "NoAxisIntercepts=Yes" changed to No or commented out. I'll try it here with that in place too ... Pete

I'd need to see logs. There's no possible reason for such behaviour being "sporadic" -- either the version number (and all the data) will always be wrong, indicate a corrupted DLL or a failure to verify the signature (Win2000 and Win98 may get this, and it is possible on WinXP if the Cryptogtraphic Services are stopped or broken). But that check is done at load time and thereafter the behaviour should be absolutely consistent. The version number is only established in the offsets once. That's even more an indication that there's a signature checking problem as that check was added in a late version of 3.71x. There is an IMPORTANT note in the 3.72 user guide, at the head of the Installation section, about how to check this and rectify it, and it also appears in the Other Downloads announcement above. Regards Pete

On checking the SimConnect log further, it seems that FSInn and TrackIR's connection did certainly "stall" at the same time as FSUIPC4's first stall. FSUIPC4 re-connected and stalled again, and was "lucky" the third time and continued. I added this recovery system precisely because of these events. I suspect SimConnect was a bit screwed up by then, and it may be that the Toggle Pushback continuous events were a spurious result -- one event arriving caused a complete chain of repeats. I find nothing in the SimConnect log relating to that other, unknown and maybe unused control though. I don't know wyhere that is coming from. You may have to run with a reduced number of SimConnect clients until Microsoft release the expected FSX patch, with, hopefully, these bugs fixed. Regards Pete

No, the parameter isn't relevant on "Toggle" controls. They just turn things off if on or on if off. Something is sending both those Toggles (switching pushback on and off repeatedly, AND control 66514 (which isn't assigned as far as I can tell -- and it wasn't assigned in FS2004 either). To check whether something is writing to FSUIPC4 to cause this, enable the IPC Write logging (on the Logging tab) as well. If nothing is using FSUIPC4, then these controls must be emanating from something else -- it must be internal to FSX as they are many and frequent. Doesn't FSInn reside as a DLL in FSX too? Doesn't it use FSCopilot or something? What else is in the DLL.XML file? [LATER] Ah, yes -- I see from the SimConnect log that FSCopilot.DLL is loading too. Can you try without that? Also TrackIR is running. Try without that too, please. Finally, I see from the Simconnect log that FSUIPC4's connection to Simconnect stalled after about 2 minutes of loading, and so it reconnected. When these things happen it is likely that other SimConnect clients also stall, and possibly they don't have recovery built in like FSUIPC4. The first part of the FSUIPC4.Log would have shown the errors (but you only supplied a continuation log). I suspect that at least the FSInn stopping working is part of the well known and already reported problems Simconnect has with multiple clients. you have three, all of which are quite heavy on Simconnect usage. Regards Pete

Okay. Got you. If the extra 7 bytes are similar, then it makes no difference, then, reading 121 or 128. ;-) Best Pete

Meaning you use all 121 bytes, every one is important? If anything the 128 byte read could be slower because of the extra 7 bytes -- it depends what they are used for. You need to understand that many of the offset values are really only TOKENS for a value -- the values may have to be obtained by more processing. No, it makes it worse if anything. Same if in your 121 bytes there are some you don't need. I don't know how else to say the same thing each time! ;-) Regards Pete

I use MixW at speeds up to 19,200, so I don't believe that can be the case. Regards Pete

There's no "search area". The list of offsets in the SDK is a simple Document. You use the search facility in your editor, or Word or Wordpad, whatever you are viewing it in. Surely you hacve searched for things in documents before? Pete

Hmmm.. Not the installer, those files are created only when you run/register FSUIPC. I'm creating the files as normal read/write files. Does Vista have a lot more file attributes? I suspect it has more to do with allowing FS to install into its default place, Program Files, which creates the problems -- from what folks have told me, anything installed in Program Files is protected against users! I've always installed FS to someplace like C:\FS9 or C:\FSX. I suspect many add-ons are going to have problems with stuff installed in Program Files. I'll do some searching for information on extra permission attributes. Thanks, Pete

I am sorry, I do not know FS-Communicator. TRUE is a non-zero value (usually 1, but anything other than 0 means TRUE), and FALSE is always zero (0). Regards Pete

A search in the Programmer's Guide for "flight director" finds offset 2EE0 immediately. Didn't you try Searching? Pete

Sounds like a SimConnect problem. Make sure you install the very latest FSUIPC4 version first (see Announcements above) then let me see the FSUIPC4.Log please. BTW, you don't need to keep editing the DLL.XML file -- just temporarily rename FSUIPC4.DLL or move it out of the FSX Modules folder to disable it. Regards Pete

I had assumed you meant with a Process call -- my answer included that assumption. So no, only ever read what you need, even if that means splitting the Read into many Reads. Each offset may invokde separate procedures in FSUIPC and FS. Regards Pete

AhI'm afraid the FSUIPC axis assignments only work to assign one axis to one control. There's no provision for having two or more different controls assigned according to the mode of FS. The Slew calibrations in the Joystick Calibs section work fine for calibrating FS's own assignments, but of course it is expecting FS to do the switching between slew axis and normal axis controls. This is a good point and I will make a note to add the Slew/Normal switching action to FSUIPC's assignments facility -- look out for this in an update which I will work on as soon as I have caught up after my holidays. Regards Pete

Where are you reading that second use of 0894? The documewntation shows only one use, -- the switchable throttle input is at 089A and has an extensive description. Can you turn on FSUIPC's IPC write logging (see Logging tab), and also set up the Monitor (Logging page, write hand side) to monitor to the normal Log offsets 0890, 0892 and 0894, all as S16 types, and do your test again, please, then show me the Log. Regards Pete

Where are you reading that in the SDK. In my copy it clearly states, in the details for offset 1400: Regards Pete

No, just read what you need. If you only need 2 of those bytes, 119 apart, use two separate reads. They are combined in the FSUIPC_Process call in any case and only the Process call actually does anything that takes time. Pete

You do not need a new Key to update from any version of FSUIPC 3.xxx to any other! Pete

Wideclient is only for a separate Client PC. MixW is to link two virtual serial ports. It can be used on any PC, client or otherwise. The GPSout facility to send to WideFS is used send the data to another PC. For the same PC GPSOut needs the Serial Port number as usual. Pete

AdvDisp is no longer needed. It is not supported any more. Please check the FSUIPC documentation and try using the new special Window facilities which work well. The window is undockable and can be moved to another monitor, but it is now an FS window. Regards Pete

Yes, but you don't have to re-enter it. Updating FSUIPC versions is only a matter of copying in the new FSUIPC.DLL to the FS Modules folder. Nothing else changes, your settings and registration stay intact. Regards Pete

No, but any program can assign hot keys which will override anthing else. In the end it depends on the order -- FSUIPC will inevitable be setting its hooks for the keys before an aircraft panel, so when the latter assigns its keys they'll override FSUIPC's. It's a "last one wins" situation. I'm afraid the only answer is to re-assign the key in the PSS aircraft. If it won't let you do that you need to find another key. That version is now 13 months old and long unsupported. You should really think about updating it -- current version is 3.72. Regards Pete