Pete Dowson

Hmm. You never said you were using FSUIPC4, just FSUIPC. Unless you say "FS9" or "FSX" or the version of FSUIPC I have to guess. The INI file would be FSUIPC4.INI for FSUIPC4. There are NO files with no extension. You have Windows Explorer set to hide file extensions from you! It probably says an INI file is "configration settings" or similar. It would do the same for CFG files. There are instructions at the end of the FSUIPC Installing and Registering document for changing this Explorer setting to something more sensible. The default Delta is best for all normal commercial joysticks. It is a specialist parameter for custom devices and software controlled axes. You shouldn't ever need to touch it for any ordinary axis. Hmm. Sounds like it got messed up though, and it must have been quite a high value to stop all changes being seen in the calibration. All the Delta does is say "ignore changes less than this". Regards Pete

Okay, thanks. FSUIPC4859e test2 Remember to find the MaxSteerSpeed=60 line in the relevant or default [JoystickCalibration] section and change the 60 to -60. Regards Pete

You questions have actually reminded me of a request i received a few weeks ago, from someone who actually does pilot training for 737NG. He said that the rudder is always partially effective, even at very low speeds, but doesn't gain much effectiveness until around 30 knots or so. I didn't think of a solution to this till now, but I've devised this method: 1. Rudder effective at 10% of the pedal input up until 50% of the threshold speed (set at 60 knots default, so this would be 30 knots), 2. Above the 50% threshold mark (i.e. 30-60 knots), increases linearly from the 10% input to the full 100%. I've made it optional so that it doesn't mess folks up who've got used to the earlier system, or who are flying aircraft which don't behave in this way,. To enable it, i've simple set the threshold speed parameter to a negative one. So, eg MaxSteerSpeed=-60 would accomplish this change for the aircraft affected by this JoystickCalibration section. This change was only going to be made available for FSX (i.e. in FSUIPC4), because i've really frozen FSUIPC3 now. But additionally I'm afraid I am not able to test this change at present -- my cockpit is undergoing some changes -- so if you'd like to check it out and effectively test it for me, let me know and i'll see if i can add it to FSUIPC3 after all (albeit reluctantly). Regards Pete

You must have selected the wrong control in the assignment drop down, or you have a conflicting assignment which is interfering with that control. If you cannot see anything wrong, show me your FSUIPC INI file -- it is in the FS Modules folder. It is a Text file. Paste it into a message here. Regards Pete

I'm pretty sure that rudder, aileron and elevator checks tend to be done when static. Gentle rudder changes might be performed when taxiing to cross-check the screen indications, but the feedback then being looked for is surely in fact some directional effect on the aircraft, else what's the point? Airliner pilots don't have wing or door mirrors like cars, they cannot see if the rudder actually moves. Regards Pete

Why are you running them all "as administrator"? If you do that they cannot talk to FSUIPC unless you also run FS "as administrator". That is not really a good idea. There should be no need to run anything "as adminstrator" except when installing things. Programs run "as administrator" are on a different priority to others and they are blocked from exchanging data, so the FSUIPC interface is blocked. Both parts must be on the same priority level. The only other reasons you might get the symptoms you mention are: 1. The FSUIPC registration key is not valid, or 2. the date set in your PC is earlier than the date you purchased the FSUIPC registration. The last one can happen if your PC has lost its date (eg from a CMOS memory reset), or its motherboard CMOS memory battery is running low. Regards Pete

How do you see the rudder from inside the cabin? Are we talking here about a small GA aircraft with a rear window? Which of these have steering tillers? The only check they get from this is a graphical representation of the rudder control position on the screens in front of them. This can be obtained from the true rudder input value, supplied by FS, instead of the reduced input actually being supplied. Programs like Project Magenta use this for that display. If what you are saying is that you are not happy with the rudder response, you can use the "slope" facility in the rudder calibration -- select one with a flatter response. If you really want the rudder axis to be reduced even further than the 66% already reduced at 20 knots (i.e. 1/3rd of the way to 60 knots), you could try setting the threshold speed a lot higher -- just make sure you still have enough rudder authority before rotation unless you want to be forced to carry on using the tiller till later on takeoff roll (when you should have your hands full already!) Alternatively, if you want the proportions between tiller and rudder to be other than a linear crossover, I can only suggest that you try using a Lua plug-in. You can assign both tiller and the rudders direct to a Lua plug-in program which employs your own algorithm before sending them back to FS for actuation. If you want to proceed that way please first read up about Lua (see the FSUIPC documents subfolder in your FS Modules folder). When you know exactly what you want to do i can advise you on which FS offsets to write back to for either direct rudder control, or for calibrated rudder control as you wish. Regards Pete

That only ever happens if you try to enter a lower number to the right of a higher one, or a higher number to the left of a lower one. The left-most number is the MINUMUM position which is used, and the right-most is the MAXIMUM number which is used. Press Reset and start again. You should follow the numbered steps in the User Guide, which are designed to get you the best results. Don't forget that a NEGATIVE number (one preceded by a - sign) is lower than a POSITIVE number! There is an error, that is why! You are mixing up left and right on the yoke with left and right on screen. This is NOT a graphical calibration system! For greater precsion the FSUIPC calibration system is NUMERICAL. Left = MINIMUM, right = MAXIMUM. Please just follow the instructions, step-by-step! Also, from your description, you are omitting the centre zone calibration, which is just as important as the extremes. Regards Pete

You haven't calibrated them properly then, or you have set the BrakeReleaseThreshold parameter too low in the FSUIPC INI file! By default it is set to 75, and this means BOTH toe brakes have to be pressed to 75% of aximum braking in order to knock off the parking brake. Or you can set it to 0 to turn this action off. You mean toe brakes. And also check that they aren't operating in reverse - i.e. 100% braking at the foot off postion and only fully off when fully depressed. Most toe brakes need reversing. That's what the REV checkbox option in the Calibration tab is for. Pete

You miss the point I think. When on the ground the blending works both ways. There's a linear blending all the way from 0 to the MaxSteerSpeed, which defaults to 60. The rudder has no effect at 0, 50% at 30 100% at 60. The tiller has 100% at 0, 50% at 30, 0% at 60. Pete

I don't believe FS9 has -- one was added in FSX I think. I'm rather puzzled about what you are asking, and why you are asking it here. However, if you want my advice and have a registered install of FSUIPC: Assign the tiller in FSUIPC "direct to FSUIPC calibration". Assign both rudder pedals to rudders in FSUIPC,also "direct to FSUIPC calibration". Make sure none are assigned in FS. Calibrate tiller and one of the rudder sets, folowing the steps in the User Guide, but also check that the calibration is good for both sets of rudders. FSUIPC will do two things for you: 1. It will manage the change between tiller and rudder according to ground speed, as documented. By default by 60 knots GS the tiller has no effect, the rudders have 100% effect. 2. It will arbitrate between the two rudder inputs, obeying the one which is providing the greatest deflection -- which will of course be the one in use. Pete

Yes, exactly! What don't you understand? If you recall, YOU said "I'm using now your more recent version 4.853" and I pointed out that is was NOT "more recent" but the EARLIEST supported version -- i.e. that there is no earlier version you would or should have been using compared to which 4.853 is "more recent". The most recent version is 4.859d, as is clear if you bothered to visit the Download Links subforum. Please do just check these things before posting support requests. Pete

What did you expect it to be? It ieven says so! 4.853 is the latest full version with installer and documentation, same as here in Download Links subforum. In fact they point to the very same file in the same place! Pete

Really i cannot support other folk's software. PM support would be the correct place. However, I can ask how you can "assign" to an offset for reading? There are no FSUIPC assignments to make a button or axis or anything else READ an offset. And what would it do with it if t could? Regards Pete

WideFS is only used by FSUIPC applications. It isn't involved in AS2012's interactions. WideClient can only talk to one server, the one which you want Radar Contact dealing with. And this can be set in the Wideclient.INI file if you don't have it automatically connecting. AS2012 will talk to the one you address in the client SimConnect.cfg file. I don't know if WidevieW synchronises the weather for its clients -- you need to check. I suspect that if you want AS2012 to suppliy weather to two FSX PCs you'll need to run two copies of AS2012. But I doubt that can guarantee precise weather synchronisation. Really, I think you need to ask WidevieW support about weather synchronisation. I'm afraid I don't know it. Regards Pete

Buttons on joysticks 64 ff are supported via offsets. There are similarly virtual axes on these joysticks, addressed at offsets 3BA8 ff. However, I cannot see how any such provision can solve your problem. FSForce will be accessing the joysticks directly into the Windows or DirectX API, not via an intermediate program accessing FSUIPC offsets. Just see what it says in its description: "Programmed using the latest in DirectX technology" To redirect any of its operations you'd need a driver-level program which hooked into DirectX below thw Windows API. As I said before, in fact. Regards Pete

What's the difference between a "virtual joystick" called A and one called 206? The code is already there in FSUIPC to handle joystick letters permanently. To handle numbers instead seems pointless when it isn't doing anything differently. Additionally, pretty much all possible Joystick numbers (to fitr the fields i have for them) are already taken. What with all the Goflight and PFC serial devices being assigned numbers locally, plus each WideFS Client's button connections having 1,000s additions to distinguish them. How would "FSForce" know about 206 and where would it address it thus if it is internal to FSUIPC? If what you are really referring to is a virtual device, in Windows, then the programming of such things is way outside my area of expertise, and needs something of much greater privilege (driver level) than a mere module running inside an application, as FSUIPC is. Regards Pete

What "same problem"? You've not mentioned any problem yet! 4.853 is not "a more recent "version, is it the earliest supported version. The latest is 4.859d. See the Download Links subforum. You have mentioned no issue at all! I have no idea what you are talking about. Mouse macros work if the add-on gauge DLLs support them. It is all to do with how the gauges are written by the add-on makers. Few FSX gauges support them because many are now written in XML rather than using the orginial FS C/C++ gauge SDK. However, I see that, in the User Contributions subforum, there is this thread: "PMDG MD11X commands (upd.16thDez09)" which contains many mouse macros for the PMDG_MD11.DLL,which I assume is the main gauge support for the PMDG MD11. However, if PMDG update that gauge you will have to re-generate all of the macros because the addresses embedded in the macros will no doubt change. Regards Pete

Better than 'mouse macros' with the update to the NGX in which the SDK was supplied PMDG enabled all operations to be performed by proper control assignments. The current version of FSUIPC allows these special controls to be assigned, by number. Please do refer to the documentation installed in your FSUIPC documents folder, and in your PMDG 737NGX SDK folder. There are also some good solutions for the NGX posted in the User Contributions sub-forum. Regards Pete

Okay. It was easier than I thought. Go get version 4.614. Regards Pete

Just log into your SimMarket account and retrieve the details, as explained in the FAQ on this subject in the FAQ subfoum. Pete

It is not related to fSUIPC at all. It is a really well-known bug in the Saitek installation and is fixed by a Registry change. Please check the Saitek support site. I really cannot support their products. Regards Pete

I think that could be worse in many cases. The reason "computed starts" were made was because many "Start" positions included in the BGLs / AFD files themselves were not on the runway at all, but often at hold positions off to the side. This made a mess of programs trying to compute accurate approaches and so on. However, I could possibly add the original AFD starts in as well ("FSstartLat" and "FSstartLon" or similar). However, it isn't straight forward as this data is not currently retained, only logged (the TXT file you found them in is just a log of the complete analysis). I'll have a look. It means extending all the structures used in the sorted results to include the extra data. Pete

Seems it correctly creates the sound object and tells directOutput to play it, but it never gets notification back, to say, for instance, that it's finished as in my case: 4648 Sound: Id 1, PlayNow("CabinAlert") 24648 Sound: Id 1, PlayTheSound("E:\Prepar3D 14\Sound\CabinAlert.wav") 26349 Sound: Id 1 DeActivate: sound not playing now ... 26349 Sound: Id 1 EndPlay: releasing buffer 26349 Sound: Id 0 EndPlay: all done! With everything working fine here, and no correct action in your setup nor error report, I'm afraid I've no way of knowing how to help. There must be something screwed up in your system, but whether it is sound drivers, Windows DirectX or is related to something wrong in the P3D installation there's no way I can tell. Sorry. All I can suggest is reinstalling or updating DirectX, and your windows sound drivers, and maybe even P3D. Regards Pete

The usual reason is USB power management -- you need to turn it off on every USB hub device in the Windows Device Manager. If you are using Windows 8 there appears to be a bug in that which also results in this behavious. If you want any further help I would need at least the version number of FS (you don't even mention whether it is FS9 or FSX or some older version altogether!), and of FSUIPC, and details of the assignments from your FSUIPC INI file. I'm not sure what you mean be "calibrated buttons" -- buttons aren't calibrated at all. Pete