Pete Dowson

Provided the same joystick has the same joystick number each time this shouldn't matter in the slightest. You shouldn't need to know the name or the number. Earlier versions of Windows had some identification problems with USB devices, assigning them differently each time Windows booted or each time you disconnected and reconnected the same device. Windows XP or later should give you no problems, whether you remove and reconnect them, or, better, simply keep them all connected all the time. after all Windows can handle and differentiate between something like 128 different devices. If you sometimes run FS without one of the joysticks connected, you need to take care, as next time you run it with it connected it may decide it is new and automatically re-assign them. This may give double assignments if you are also assigning them in FSUIPC. Why would you want to? Sorry, I'm obviously missing something. If you are assigning them in FSUIPC's Axis Assignments, then go to that tab, move that axis and read what it is assigned to do. Rescan for each. Yes, of course. That is the more usual way of doing things. The axis assignment facilities were a recent addition. The others have been incorporated in FSUIPC for many years and are the most used. The axis assignments were only added for additional flexibility -- especially aircraft-specific assignments, so different controls could be used for, say, a helo as opposed to a prop or a jet), and they are perhaps also a little more efficient. FSUIPC never assigns any axes on its own. It only does what you tell it to do. FS itself is the part which does automatic assignment when it sees a new device. If you want to delete your already-made FSUIPC assignments, just edit the FSUIPC.INI file and delete the [Axes] section (and any [Axes.] sections you may have created if you were using Aircraft-Specific assignments. Regards Pete

I really have no idea what they mean by the "original FSUIPC code for this signal". What signal? The throttle setting is a number. To take a similar exampler, my motorised trim wheels are implemented in the hardware/firmware with a facility to say "go to position x". All I have to do in my driver for that is map the FS trim value to the range of firmware values equating to the trim indicator movement next to the trim wheels. For motorised throttles there must be a way of telling the levers where to go. You need the driver for the throttles to map the FS range to the servo range. Simkits seem to be talking about some electrical signal? Uh? Surely their firmware will be controlling the electric signals, and their driver talks to their firmware over tthe USB link. Regards Pete

No, because there are no standard ways to do this. You'll need a driver for your servos, obviously, and you'd drive those whilst reading the throttle values from the normal FSUIPC throttle offsets, switching this action depending on the AutoThrottle setting. If the throttle inputs are via axis controls to FS your driver will need to set the flags in FSUIPC to disconnect them in A/T modes, but if you are writing direct to the throttle offsets then you need to use the added switchable offsets, as documented, not the direct FS ones, as otherwise the flag to disconnect them won't work. My 737 cockpit has motorised trim wheels either side of the quadrant, and the PFC driver drives those in all A/P vertical control modes by reading the elevator trim offset, which is used by the FS and PM A/Ps extensively. Regards Pete

Sounds like the broadcast isn't working correctly. Are both PCs running XP or only the Server? What do the logs show? Are they both in the same WorkGroup? If not try to make them so. Alternatively you may need to provide the ServerName and Protocol parameters in the WideClient.INI file. That will make WideClient try to connect immediately, not waiting for broadcasts from the Server. Regards Pete

Good catch! Thanksit was being saved but not being read back on reload. I've fixed it here and it will be okay in the next incremental release -- please check the FSX downloads Announcement next week, hopefully by Wednesday or Thursday. I am in the midst of a few other changes to get around possible problems with Vista default FS/FSX installations. Regards Pete

Yes, but is this with you running FSX "as administrator" even after restarting? Or do you have FSX installed elsewhere than the "Program Files" folder? I think the folder permissions problem is only related to the Program Files folder, which of course is used by default by FS installer. Anyway, I've sorted out a PC and gone out and bought a copy of Vista for testing which I hope to start on next week. By the next release I should know all about the problems which may be arising and can try to deal with them, even if only by better information in the documentation. Regards Pete

First, be doubly sure that you have enabled WideServer in the FSUIPC4 options (first tab, bottom right). And put FSX into Windowed mode and see what the FSX Title Bar says -- if WideServer is running okay it should say it is waiting for clients. Then check the Logs. WideServer.Log on the Server (in the FSX Modules folder), WideClient.Log on the Client, in the same folder as WideClient. Show them to me if you don't understand. I expect there is but I don't know one specifically and I certainly wouldn't understand its output. You should not need to be concerned about IP port numbers in any case, just let them default. The only additional information I'd need at this stage are what Windows versions are in use on each PC and whether you've made any changes to the WideClient.INI or the [WideServer] section in the FSUIPC4.INI files. Regards Pete

No. Just copy in the FSUIPC.DLL and your INI file from the old installation (or just FSUIPC.DLL if you want to start setting your options from scratch), then register exactly the same as you did eventually. You can use any of my programs on as many computers as you like -- they are registered to you, not the computers. Regards Pete

There's no other such reports, and the weather facilities in FSUIPC have not been changed for many versions. Is this with a registered copy of FSUIPC or not? And what version of FSUIPC? Are you sure you have no other add-ons (or add-ins) which are making use of FSUIPC? Unless you are a registered user and specifically select one of the weather options it does not actually touch much, though you could try pressing the "minimum weather" button on the first (About) Tab in the FSUIPC options. The prime purpose of FSUIPC is as a conduit for other programs, gauges and DLLs, which can change these things whether or not your are registered and independently of your option settings. Obviously, if this were the case, that wouldn't happen if you stopped FSUIPC loading. More information is needed please. Assuming everything is okay with regard to the above questions, and you are using the latest version (3.72), possibly an FSUIPC.LOG with Weather Logging enabled may throw some light on what is going on. (See the Logging tab in FSUIPC options). Regards Pete

I think there may still be problems if you set options in FSUIPC4, as it won't be able to write to the FSX Modules folder unless the permissions for that are set correctly. I think this problem only applies if you installed FSX to the Program Files folder, as it will by default. Vista appears to stop anyone without elevated Administrative priileges writing there. I've been looking for a way to set specific permissions for Modules programmatically, but I fear this is not possible, as the whole purpose of the protection is to stop (rogue) programs from altering Program installations. The alternative solution, which I am working on now, is to have FSUIPC.INI, LOG and KEY files placed in the "My Documents\Flight Simulator X files" folder, alongside the saved flights and so on. I'll make the next version check for those files in the Modules folder first, and if they are present copy them over, and from then on maintain them there. This will be for Vista only. Regards Pete

I've checked. There's no problem. I loaded the 737, set all the detentes, checked they worked, then selected the Cessna. They still worked, but of course several of the detente positions don't change the flaps as there's no corresponding detente on the Cessna. I saved that as the default flight so that it would reload with the Cessna, not the 737. Upond reloading FS, the flaps worked as before on the Cessna, and on checking the "Cl" and "Dt" buttons were still present with all the 737-suited detentes still shown and working. There is nothing wrong that I can see. Re-reading your message, you say "the little detents(dt) button in the flaps calibrating section is always off.". That is confusing, as buttons are never either "on" or "off", they are just buttons, not switches. When you first press the Dt button you get the detentes facility enabled, as shown by the column headings and the little spin control, and the Cl button which also appears to enable you to delete all the detentes and revert to no Detente calibrations, but the Dt button is always there, never "on" nor "off". Maybe you merely pressed the button but never actually set any detentes? If none are set, none will work. I will be able to tell once I see your INI settings. Please also make sure you are using the latest version of FSUIPC -- 3.72 or 4.07 at least, depending on FS version, so I know we are talking about the same things. Regards Pete

The "disconnection" cannot fail, as there is really no connection in the first place. The Open call is merely a sequence involving the allocation, via Windows, of a memory-mapped file to be used for the data exchange, followed by some FSUIPC_Reads and an FSUIPC_Process to check version numbers and so on. The validity of the "connection" is based merely on the returns, allowing for the timeout imposed by the SendMessageTimeOut call and a number of retries. The Close call merely releases the memory-maped file which is created by the Open call. The memory thus allocated is used to perform the inter-process exchanges. The same mechanism is used by DDE (direct Data Exchange) and by the debuggers. Nothing actually "connects" as such, where's no transmission or reception other than the "SendMessageTimeOut" used to notify FSUIPC (in the FS Process) of new data. The "connection" is alive until the Window handle used in the SendMessageTimeOut is no longer valid, which will be when FS (or WideClient for a WideFS client) terminates. Therefore the only way you have is to check the response to the FSUIPC_Process, just as the FSUIPC_Open does. You may want to allow a few retries, in case FS or the PC generally is being held up by some intense activity, but bear in mind this is probably already being done inside the Process call in any case. If you want to understand this a bit more, you may like to look at the source code for the FSUIPC_xxx routines you are using. I supply the C source for the LIBrary in the SDK, and the other languages have their sources too included in ttheir sections. Regards Pete

The button setting and flap detente positions are saved in the FSUIPC.INI file. They should certainly be re-established on restarting FS. Can you show me the Joystick sections of your INI file, please? There is one possibility, which I'll check here. When setting the values the number of detentes you set cannot exceed the number of flap detentes that exist on the current aircraft. Normally you'd make the settings aircraft-specific to calibrate different positions for different numbers of detentes. Can you tell me how many detentes you've set (e.g. maybe 9 for a 737 including no flaps and full flaps) and which aircaft you are loading as default? Maybe there's a problem there -- I'll check here. Regards Pete

Aha! The SimKits driver is writing 4 bytes to 0892, trying to operate the Starter. The starter is only 2 bytes, so the other two bytes (which are zero) write to 0894, which is the combustion flag. Evidently FS2004 ignored writing to this flag -- it was only an indicator, not a control. SimConnect, however, seems to allow engines to be stopped (at least) by setting the combustion to 0. This might be to simulate engine failure or flame out. I don't know. Whether they can be started by writing 1 here I don't know, but I might experiment with that. But it seems that it is an error in the SimKit driver. They should never write values using the wrong size. Will you contact them and get it put right? Pete

Actually, though I will proceed with the addition I mentioned (though only for the Direct To FSUIPC Calibs list -- I checked and the other way, via FS, is too complicated), there is already a solution which only just occurred to me. On the Axis assignments tab, you will see you can assign up to 4 controls for each axis. All you need to do is assign both the normal control (aileron, elevator, rudder) AND the relevant Slew control (Slew Side, Slew Ahead, Slew Heading) to each relevant axis. Both controls will be sent all the time you are moving the axes, which is not excellent efficiency (though I'd doubt you'd notice), but the Slew ones will only work in slew mode, and vice versa, so no harm is done. Oh, incidentally, just to complete the set, I'll make the Throttle axis pair with slew altitude too. Regards Pete

As documented, both FSUIPC and WideFS registrations need to be in the same name and the same email address. Those fields are used to uniquely identify you as the user, and only one user per license is permitted. You really needed to have made this clear when you purchased it, in the space allowed for Notes. Now the best course is to email me. Zip up your FSUIPC.KEY file (from the FS modules folder), and the details of your new WideFS registration, and I'll issue a revised FSUIPC key under your new details. ZIP and send to petedowson@btconnect.com. Regards Pete

Have you tried running FSX as Administrator? (Run As ...). I've been told that is necessary. Also if you have installed FSX to the default location in Program Files I think Vista prevents programs writing to any folder there unless you set some user (group?) permissions. There are other mentions here in the forum with solutions. If you don't set the correct permissions then no FSUIPC settings, whether registration or options, will "stick" as the files can't be written. I think this is Vista being over-protective and stopping you changing your own files! :-( I am investigating whether anything can be done automatically, but I'm afraid I am not in a position to install Vista here for a while -- maybe not for as much as six months. So I am relying on feedback. during Vista Beta testing folks using the 32-bit version managed okay with the above considerations. If you find the correct way to set adequate permissions, could you tell me step-by-step what you did, please, so I can (a) document it for now, and (b) work out if there's a way to doit automatically. Thanks. Regards Pete

I've had a look at this, and it is not immediately straight-forward, but I will fit it in. I don't want to make it occur automatically, without option, as many folks (myself included) simply don't want to use the yoke/pedals for slewing as that way you tend to have much less control and calibration is much much more important. I find the keyboard always best for slew control. Rather than have a toggle option, I will add three new assignable axis controls: Ailerons / Side Slew Elevator / Ahead Slew Rudder / Heading Slew These controls will switch according to the FS mode, but the current ones won't. I'll need to add these to both the "via FS" and the "direct to FSUIPC Calibs" lists. Regards Pete

Sounds like a typo in the data file (FSUIPC.FSI). I'll edit it here if so. Unfortunately, whilst you did enable the monitoring for the values, so we can see the RESULTS of whatever is going on, I needed IPC Write logging enabled as well, as I mentioned, so that I can see the inputs from the SimKit driver and how those relate to those changes. You will find the IPC write checkbox on the left-hand part of the Logging tab. Thanks, Pete

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