Pete Dowson

No, it only comes with the DeLuxe Edition of FSX. Regards Pete

I'm afraid we've never discovered how to set the airspeed directly. The offsets for this are *results* of computation, and will simply get overwritten on the next cycle. There are some velocities, accelerations, etc, in the 3000 + area which do certainly have an effect, but not precise and not maintained unless you keep writing fast enough. Even in FSX, where the facilities are already a little more comprehensive in this area, the only sure way of setting the airspeed is by an effective "restart", where the position and attitude are also needed and it it nearly as slow as loading a new flight. Regards Pete

You should please ask questions about my programs in my Support Forum, as I don't visit here so often, and answers to such questions can be found over there quite easily. [ADDED NOTE: This was posted in reply to the original posting which occurred in the FS2004 Forum]. I am told that Administrator privileges don't actually give you any rights to access the Registry, or even, oddly to write to some file areas. It seems you need "elevated Administrator" privileges. So far every one who has reported this problem has reported success when using "Run As" to run FSX to register FSUIPC4, specifying the Administator there I think. There may be other problems. If you allowed FS to install into the default place (Program Filesetc), then Vista may actually prevent FSUIPC4 (and any other program) actually writing to its own files, the INI, KEY and LOG files for example. So settings won't be saved. The answer at present seems to be to manually change the Access Permissions on the FSX Modules folder to allow you, as the user, to access those files for writing. Ugh. Vista seems to be rather over-protective. I have just purchased Vista for installation on one of my PCs in order to carry out some tests so I can document all this thoroughly. I'll be working on this in the coming week. I am looking at moving the LOG, INI and KEY files over to the My Documents FS files folder (where Flights etc are saved) to get around the access privileges problem. When I have a version which does this it will be released on my Forum, and it will automatically move those files from the modules folder if they already exist there. Please use my Support Forum for any future queries on my programs. Regards Pete

Okay, I cannot make that happen here. It is as I said. To make it clear I set the FileMon filter to "FSUIPC4.INI;FSUIPC.INI" not just "FSX" because the latter gets thousands of FSX file accesses too. The FSUIPC4.INI file (never FSUIPC.INI) is accessed initially, during FSX loading, quite a bit (naturally), then when a flight or aircraft is loaded, again when you explicitly reload values in the Options, and when you close the options (to save changes), and finally when FSX is closed. If something different is happening on your system, can you please show me the FSUIPC4.LOG -- maybe some aircraft or flight is being constantly reloaded? -- and perhaps save the FileMon log so I can see what you see. ZIP them and send to petedowson@btconnect.com. Regards Pete

Really? There's certainly no explicit code in it which does this -- the parameters are read initially (a module which is never called again), and when requested in some of the Options pages (a module only used when the Options dialogue is showing), and finally when a flight or aircraft is loaded (to check for aircraft-specific keys, buttons, axes or calibrations. I'll check it here and get back to you. Regards Pete

It sounds like the DLL's signature verification for FSUIPC 3.72 isn't working. Can you show me the FSUIPC log please? And I also need to know the version number of the PFC.DLL. Erwhat do you mean? Everytime you've moved from, say, 3.00 to 3.01 then to 3.02 etc etc? How many times have you upgraded? I need to understand. And if this has been happening for myears, why not mention it before? Hmmm. I certainly don't understand that. Neither FSUIPC nor PFC have any "memory" other than what's in those files, so if the files are made the same as they were, then the same problem, exactly, should ensue. If it isn't due to the verification checks (the main change in 3.72), which will be obvious from the Log file, then it may be a timing problem, with the PFC.DLL trying to start before FSUIPC is ready. That may just change slightly with a different order of files, but it seems unlikely. I need more information, please. Yes, it should, and it does here and always has. I am not sure why it has ALWAYS been different on your system -- every time you've replaced an older FSUIPC with a newer one? It makes little sense to me at present, but please clarify these things and we'll get to the bottom of it. Regards Pete

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