Pete Dowson

What is "almost senior"? I am 67. Does that count? Or did you mean "senile"? And if you can only understand words with only one syllable why are you using some with two and even three? I'm afraid I will have to ignore that request as there simply aren't enough one syllabled words! Where are you "getting" not found in fs9 only cfs2". Please explain what you do and what you see. I've no idea what "getting" means in this context. If you are having problems installing FSUIPC then please do as the Installation guide instructs and save the install log, then show it to me here, in a message. If your Registry entries for FS9 are corrupt or missing (maybe you have moved FS9 without reinstalling), then you can fix that with the utility referred to in the Announcement "Fix for FS installation registry problems " at the top of this Forum. Pete

You are in a wrong thread here I think? It cannot do that. If you omit the Server name and only give the correct IP address, that's the only one it knows about. It cannot even try the incorrect IP address because it doesn't know it! It certainly does not invent IP addresses. You've made a mistake in the parameters. Regards Pete

That IP address is an Internet address, not one on your local network. That is the problem. In fact it appears to be an "OpenDNS" address as follows: This is what Windows is being provided in return for being given the name "DAVIDZYCHOWSKI" to translate. You either need to sort out your router so it gives corerect addresses, or specify the actual IP address in the Wideclient INI file. It might even work if you removed the ServerName and Protocol entries from the INI file and let the details from the Server work for you -- just make sure, as the documentation states, that your PCs are in the same WorkGroup. WideServer should provide the correct address, provided the local name is correctly translated into the correct IP address, which I believe it has been on other similar systems. For further information, please see the additional data about this "OpenDNS" problem which has been added to the WideFS documentation (get Wideclient 6.81 from the Updates announcement for this), or see the other recent threads about it, such as viewtopic.php?f=54&t=80129 . Regards Pete

No, it didn't. That is simply not possible. If the FSUIPC entry is already there it simply checks it and makes sure it is okay. If it isn't, it adds it. There are many installers which corrupt the DLL.XML file, but FSUIPC's installer most certainly is not one of them. If you want to post your DLL.XML file here I can help you fix it, but your best bet would be the AIcarrier support. After all if their installer cannot fix your problem then nothing I can do is likely to be able to. If you have no idea what your DLL.XML file is or where to find it, post the FSUIPC4 installer log here and I'll tell you where to find it. Pete

That is still irrelevant to WideFS, though it may prove fatal to some other programs you may wish to run on the Client. Pete

WideFS doesn't care at all about file or folder sharing. that's for programs needing to access files. wideFs deals in FS data and does so directly, not via files. That's okay for Explorer, but not necessarily other programs. Their access may depend on your firewalls. That shouldn't be necessary unless you insist on using different WorkGroup names. No, not without seeing the WideServer and WideClient logs. That is what they are for, to show us what is going on. Regards Pete

Yes. You do it by using a button flag. The details are in the Advanced User's guide, in the Buttons section. Look for instance for the paragraph starting "The conditions can be made to apply not to the current state of a button, but to the state of a ‘flag’ that is set and cleared by a button " For a simple dual action button the button flag associated with the joystick button you are using can be used, so you'd have just two lines in the form: 1=CP(F+j,b)j,b,.... 2=CP(F-j,b)j,b,.... where j,b are your joystick and button reference, and of course thepart is replaced by the correct encoding of your keypress (Kn,n) or Control (Cn,n). If you aren't sure about those, best program them in the FSUIPC dialogues and check the results in the INI file. This sort of more complex assignment can't be done in the FS options dialogue, but you can edit the INI and use the "Reload" button on the Buttons tab to test out your changes immediately. You don't need to reload FS all the time. Once a button is programmed like this you can't re-program it is the dialogue, only by INI file editing. Regards Pete

Engines don't cut out because of throttle changes, no matter how you've assigned them or what values they provide. The usual way they cut out is from fuel starvation. It sounds like your fuel is being cut for the right engine. On a Jet FS simulates the fuel cut-off switches using the MIXTURE, which needs to be full rich to run the engine. Any less will cut the fuel. For a prop plane any value will do, depending on the altitude, and only a full lean or close to will normally cut the engine. Given those facts I believe you have something assigned to and/or operating the Mixture 2 setting. Try enabling Axis event logging in FSUIPC, operate all of your controls, and look at the FSUIPC log prodcued to see if there are any mixture axis changes. Regards Pete

You don't say where you've assigned the elevator trim, but if you have done it in FSUIPC then you should know that FSUIPC only processes axis inputs when they change. If the trim axis is preventing the A/P from altering the trim value then the axis must be jittering a little, supplying new values overriding the A/P setting. If you are assigning in FSUIPC, and so have it Registered, then you should set the option to discard the elevator trim axis inputs when the A/P is set for any vertical control modes. The option is called (surely not too obscurely ?), "Disconnect elevator trim axis for A/P " and has a full paragraph describing it in the Miscellaneous section of the FSUIPC User Guide. The fastest way to find such things it to use Search -- I found it straight away searching for just "trim". Regards Pete

None. The touchdown value is continuously copied from the current actual value, until the "on ground" flag is seen. That's all it is for, to record the last value before touching down. Not sure why you think it is a problem. You should only be reading it after landing. What's the point otherwise. Why a "problem"? As to why they may be different, maybe you are reading them at different times? You've not bothered to tell me which Flight simulator you are using, as that could make a difference too. I haven't looked at the code, but on FSX and ESP the V/S is supplied to FSUIPC by SimConnect when it changes, and FSUIPC will populate both offsets at the same time. Since SimConnect is asynchronous this may be slightly behind the true current value. On other versions of FS the V/S offset might be mapped directly into a "live" FS value, in SIM1.DLL, whilst the touchdown copy can only be copied every frame or so, and so remain slightly behind as in FSX/ESP. Regards Pete

That's serious! It could mean one of several things: 1. The downloaded package is corrupted. Check this by right-clicking on the Install FSUIPC4.exe program from the ZIP, then selecting Properties and Digital Signature. Select the signature shown and clcik for Details. It should say the signature is okay. If it doesn't, try downloading it again. 2. The signature may have been rejected by you in the past. If you've disallowed "SimFlight" at any time in the past you would need rescind that decision. Run Internet Explorer (even if it isn't your normal browser), select Tools-Internet Options-Content-Publishers-Untrusted Publishers. If simFlight GmbH is listed, select it and Remove it. 3. The cryptographic service or something else like that, needed for signature verification, is not running (disabled or corrupted) in your Windows installation. The error 80092026 reported by Windows seems to mean "crypto operation failed". Try this: http://support.microsoft.com/kb/555374 4. There's also some evidence that a particular security setting can stop all types of signature verification. Check this: http://stealthpuppy.com/windows/windowsion-failed. This implies that your Windows Update might not be working either. Actually, looking at those last two references shows than items 3 and 4 are the same. Regards Pete

If WideServer is running there is always a WideServer log file produced. It sounds like you've not installed it. Don't forget that for FS9 and before WideServer is a separate module, not part of FSUIPC as it is for FSX. The title of your message seems to indicate that you believe WideServer is not an entity in itelf. It is -- for FSX it was simply compiled into the same module as FSUIPC, but that was never done for the first 12 years. In fact WideFS first existed before FSUIPC. Regards Pete

Because you do not purchase a specific version from SimMarket. You download the current version from a website run my Mr. Schiratti, and get updates from the Updates announcement here. Version numbers are built into porgrams. To find the version number you can do one of several things: 1. Look at the documentation (though that will only give you the base version, not an update version). 2. Look at the options screen in FS. 3. Look in the Install log or in the run-time log in the FS Modules folder. 4. Look at the Properties-Version data you casn access by right-clicking on the DLL itself, in the FS modules folder. That last method is standard and applies to virtually ALL windows programs and DLLs. Please try it one day. If the key is rejected outright when you are trying to enter it, then either you have mistakenly purchased a key for the wrong product, or, more likely, you are making a mistake when entering any of the details. ALL THREE FIELDS, name, email, key, MUST be exactly correct. Use cut and paste if you cannot do it manually! It is not a gamble. It is not a game of chance. You just need to know how to enter your name correctly, your email correctly, and the Key, correctly. There's nothing else to it!! Pete

The problem with that is that you have to restart FS just to change aircraft using different controllers. FSUIPC offers that automatically, just be selecting aircraft. Regards Pete

The Delta tells FSUIPC to ignore any changes less that that so you can eliminate jitter, but it shouldn't never be used in place of a null zone for any axis! Instead of finding a "sweet spot" for the Delta, put it back to default and simply re-calibrate with the "brakes off" (minimum) point set with both brakes pressed in a little way. Similarly set the max with the brakes not quite fully pushed down. That way (the way actually documented in the step-by-step calibration section of the user guide) you still get excellent sensitivity over the range, and can always reach max braking (or whatever), without risk of accidentally engaging them. This is the very reason FSUIPC doesn't do "automatic calibration" like many drivers -- setting endpoints WITHIN the range and not at the extremes helps get the best from your equipment! Regards Pete

Good! Pete

You will need to reverse one of them. The values received from a USB joystick driver are whatever that driver wants to send. I don't see anything like that as "impossible". You'd need to reverse one of them, the one which you are adding 8192. As the Advanced User's guide tells you "... to multiply the axis value by . This can be a fraction, such as 0.5 (to divide by 2), and it can be negative, to reverse the axis direction." So try ,*-0.5,+8192 ,*0.5,-8191 That can only happen if by editing it you've made the line invalid. Something you are doing is wrong. Show me the edited [Axes] section, before you go back and reload. Of course it can be complex trying to make a device do something it is not and never was designed to do. But it isn't really as difficult and as complex as you make out. Regards Pete

Strange, because FSUIPC doesn't treat any axis differently than any other. Have you made sure that Windows USB power management is switched off? That's the usual reason for unseen axes -- the USB driver doesn't pick them up initially because of power cut of to the chips. FSUIPC doesn't do anything differently initially as compared to when you go into the options. It's the same routine. Are the toe brakes properly calibrated? Or maybe they are operating digitally? If they are only providing two values -- off or full on -- you would need to operate them a few times before FSUIPC will start to use the values. This applies to all axes, it needs to see 6-12 changes before accepting a "good" value. This is to make sure it doesn't use spurious values generated by some joystick drivers whilst initialising, which otherwise cause some havoc. You could also try updating to 4.616, available here in the Updates announcement. Although there's nothing specifically changed in this area, a lot of other things have. Regards Pete

But that's not going to change at all, is it, no matter how you configure them? Yes, those should work okay. No need to close FS. You simply need to use the "reload" button in the FSUIPC Axes tab after you've edited the INI file, then go to calibrations and calibrate. Yes, of course. You should ALWAYS calibrate. You need a decent sized null centre zone so feet off the rudder is always centred, and you should have a dead zone at either extreme so you know you can always reach max deflection no matter what the hardware reports. You don't do anything like that. Please look in the User Guide and follow the steps, one by one. They are numbered. It never deletes anything until it re-writes the settings when you press OK to exit. You simply use the Reload buttons -- there's one on each of the assignments and calibrations pages. Any time you edit the INI manually, just reload the settings. That's why these facilities are provided AND documented for your use! In any case, how is this more complex method of assignment and calibration going to help change the fact that the "Brake goes very hard to push in, and the Accelerator easy, also this pedals are close together, so not very comftable."? I don't understand how any of this helps you. It just makes things more complicated for you to no end purpose. Regard Pete

If it works. But are you sure it isn't just coincidence, that this time you simply you had it synchronised to start with? All of the TOGGLE controls just TOGGLE (i.e. change the state) as far as I know. I've never found one that SETs instead. It doesn't make a lot of sense when you know that a parameter of 0 toggles for certain, as you proved originally. Pete

If you are using that control you must synchronize the FS setting with the hardware switch. Use the on-screen switch to do this. Save a flight with the switch off, always close down FS with the switch off so when you load next time they are in agreement. There is no other way with TOGGLE controls, unless you write a Lua plug-in to test the battery state first, or use one of the Offset controls to write to the battery switch offset in FSUIPC. Both of these are a little too advanced for someone just starting out, I think. Pete

NO! Why are you editing the INI file? Run FS. Get to flight mode. Look in the Menu. You should see "AddOns". Click it. select FSUIPC. Then you will get a set of tabs which allow you to set FSUIPC options and make assignments and so on, WITHOUT touching the INI file. FSUIPC does that for you. Please please please do look a little more at the FSUIPC User Guide. There are pictures in there showing you the assorted options pages. You assign Buttons in the Buttons tab, Keypresses in the Keys tab, Axes in the Axes tab, and do calibrations in the Joysticks tab. You only have to go to the INI file to do complex things, not easy stuff like assignments!! You will see that everywhere you can assign an FS control you can also set a parameter. It isn't hard to find where, it is actually labelled "Parameter", which surely isn't very obscure? :-( Pete

That one takes a parameter: 1 for Engine 1, 2 for Engine 2 and so on. Regards Pete

Thanks. 4.616 is up now. Best Regards Pete

I've found it and fixed itget 4.616 when it's up, soon ... It turned out not to be anything directly to do with the VRi facilities, but the CLOSE option on the Run parameter for the SerialFP2 program. Any "run" parameter for any program with a "CLOSE" option would have generated the same error. Due to a stupid typo it was sending a WM_CLOSE message to the Desktop instead of to the program it should have been closing! I never realised something as easy as sending WM_CLOSE to the Windows desktop could result in it actually trying to do so! In WideClient in order to close down client PCs I have to go to quite extraordinary lengths, comparatively speaking! The "KILL" option for the Run parameters was okay, oddly. Regards Pete