Pete Dowson

If you want to ASSIGN axes in FSUIPC you must disable the controllers in FS. If you are NOT assigning axes in FSUIPC, then just leave controllers enabled in FS. Choose one or the other, but if they are not assigned in either how can you expect them to do anything? Please do read some of the FSUIPC documentation some time. Pete

Well, since when you press "OK" all that happens is that FSUIPC tries to save your settings to the FSUIPC4.INI settings file, and it seems that fails, I'm not at all surprised the last settings aren't remembered! There's really nothing anything in FSUIPC can do, nor really any other add-on can do, which will cause a PC shutdown. In fact I've NEVER even heard of any spontaneous PC shutdown which was not caused by things like drivers -- whether video, USB, sound, etc. Really they are the only parts which are at a sufficiently low level to cause a shutdown. But then you'd almost always get some sort of report from Windows, like a blue screen., or maybe something like a disk scan on the re-booting -- often both. BTW I also think you ought to know that I don't think the PMDG NGX supports reversers using axes. You'll probably only be able to assign "THROTTLE DECR" type controls to get reverse. At least, this is what I have learned from other NGX users. Pete

Thanks for that. I hadn't noticed it! How is it used to click things on screen? I don't see this clearly in the illustrations. Is it by screen or window coordinates to move the mouse to? If so how do you deal with Virtual Cockpit use, where things are rarely ever in the same place? It's that sort of difficulty which seems to defeat the object of having a button to mouse facility. There is, or was, a program called "Key2Mouse" which folks used to use when most if not all cockpits were fixed 2D ones and you could specify coordinates of the clickable places easily. With Key2Mouse you could of course use buttons too, by assigning the buttons to the keys. Pete

This this is because the numbers in the boxes are not in increasing order, from left to right (the middle two can be the same if you don't need a stable centre range). If you follow the numbered steps in the Calibration chapter of the User Guide it will work best, calibrating from Minimum, through centre, to Maximum. Pete

No, not directly. In the whole life of FSUIPC (16 years now), there's actually never been one such request that I can recall. What would you use such facilities for? You can do it pretty easily using Lua plug-ins. There's a Mouse library supported by FSUIPC which has simple functions to click or hold / release any of the three mouse buttons, and operate the wheel both vertically and the horizontal presses where supported, as well as moving the mouse pointer, which seems rather important as a first action. Pete

I asks some other folks about this "reduction in engine noise at altitude", and I think that you are not correct about quieter engines at altitude, at least with aircraft we are familiar with.. Here's what I am told. This does accord with what I can recall from the days when I used to be able to ride in the cockpits. Pete The user talks about jets like the 738 and in this case the statement is wrong, because a "typical" climb-N1 to FL is usually in the range of 92-96, whereas while cruising at M0.72-77, N1 is usually in the range of 86-89. Nowadays I'm in the jump-seat in every week or two weeks or so for long time now, and even if I wouldn't know anything about the N1 part, I could easily say that at FL the engine-noise is simply slightly weaker, just because of the N1 difference. One thing I can tell with confidence, namely that the average noise level in the 737 cockpit is between 74 and 78 db. I have measured that several times, just out of curiosity. In the cockpit what the pilots hear is mostly the wind-noise which could even be higher due to the higher velocity compared to the climb-phase. "Scientifically" speaking there's one factor that may play a role in the scenario, that the air is less dense at FL, so theoretically the wind-noise should be a bit less, but I seriously doubt the human ear could figure out that minor difference and the speed difference adds enough to that. As in FS the jet-whine sounds are designed to be Rpm dependent, anyone could design a sound-set that suits his taste and the jet-whine is much lower at high rpm, but there's no reason for those sounds to be altitude-dependent.

But where is the Event Viewer data for me to look at, and the FSUIPC4.LOG file up to that point? Maybe I could try to narrow it down, but I cannot even start with no information. With the location in API.DLL and the normal FSIOPC logging I might just be able to track back to what function it was attempting to perform at the time and whether FSUIPC could have any involvement in that. Please make are you are using FSUIPC 4.95 at the time, as I still have mapping files for that. Thanks, Pete

As well as what Thomas said, I'm puzzled by what you mean "wiped out all the FSUIPC setting? Your settings are stored in your FSUIPC4.INI file and can only be changed by you. Can you describe in more detail what you really mean by "wiped out". What are the symptoms? Pete

Ah, Saitek. Their installers seem very prone to getting the Registry descriptions for their devices wrong. Please see the FAQ subforum. The thread "Some saitek axes only provide partial movement" may well be very relevant. Pete

Are you using FSUIPC? You don't say. If so, are you assigning in FSUIPC -- and if so, what to? (the name of the assignment target). And did you try calibrating with 0 or a little above as your minimum? That would be an easy solution -- though it wouldn't explain the problem. Generally this sort of strange one-sided input value is down to some poor registry entries, possibly made by an installer. But I've never heard of one which has -16384 as the only negative, then the normal positive range. They are usually positive only when wrongly registered. -16384 is also what you get with a disconnected joystick (or rather the disconnection of the device inside of it). So maybe your device is going wrong? Did you check it with Windows calibration? What is this "TPM" by the way? Is that the GoFlight device with Cessna type pull-push controls for the three single engine prop plane controls? Is so, isn't it using a GoFlight driver? Pete

To do hat you'd need to either pull down the menus and operate the slider, or hack into the code to see where to change it. If you can do that then I can put in a link so you can program it anyway you wish in Lua or an application. I'm way past my hacking days. If you use Prepar3D, then whilst it is still under development perhaps this proper way of doing it should be requested as a future enhancenent? The sound files for SimObjects do have different sounds for engines, but they are related to different engine modes not altitude. You would want one of them split into altitude related settings instead. Then it would be part of the SOUND.CFG file to determine when which was used. For the present the only way I know would be to turn off the sim's engine sounds and play them in an Application like pmSounds (which does have its own engine sounds but at present I don't think related to altitude) or ProsimAudio (which only works with ProSim avionics), or a Lua plug-in -- which you cculd write as well as anyone else, once you have the right sounds recorded. Pete

It wouldn't be an FSUIPC option, but possibly a project for an application. FSUIPC is really a tool to enable applications. Are you sure none of the more sophisticated add-on aircraft don't get the sounds right? And isn't the main reason they are quieter in cruise because the engines aren't working as hard? It's the climbing which takes most of the fuel, after all. Surely pretty much all aircraft have lower engine noise for lower throttle / thrust settings? There are some separate add-on sound packages too. Have you investigated those? If you stopped the FS engine sounds you could have your own played by a Lua plug-in and vary the volume according to altitude. The Lua sound function library implemented in FSUIPC would be capable of doing that, in just a few lines. Of course it would need to take into account thrust settings too. Pete

You go to SimMarket and pay for FSUIPC4. Pete

No, not without removing entries from the Registry so it doesn't appear to be installed. If you use an old version of FSUIPC I cannot support it. Pete

Strange, but if that's your wish. Pete

Why's that? Will you never need any more help with FSUIPC, Offsets and so on? Have you taken offense to something I've said? When you posted almost the exact same explanation and question as you originally posted to start this thread I assumed you'd somehow missed the answers. Either that, or you had intended to post it to another Forum and accidentally posted here again. That's why I asked the question and suggested you look at answers I assumed you must have missed. I do my best to help all those that come here. I don't know any other way to help you at present except answer the specific questions you've asked. I do not know SimAvionics, and nor do I use any CockpitSonic drivers -- I do have parts of a CockpitSonic Overhead in use, but I do all my own drivers for cockpit hardware, so I can be in complete control. Mine work hand-in-hand with my PFC cockpit and with Prosim737. I used to use Project Magenta and converted to Prosim by using PM offsets where possible, modifying the contents of some if necessary to meet Prosim's needs. I also now notice you said But you failed to mention which switch you had trouble with! Pete

The Axis controls assigned in FSUIPC are EXACTLY those assignable in FS itself. If you don't calibrate then they are simply sent to FS and act EXACTLY THE SAME. If you have calibrated , check what you've done there. Note that you must test spoiler axis operation in the air. FS deploys full spoilers if it sees any input when on the ground. Pete

There cannot be a Master Offset List. Every product or driver using FSUIPC may do its own thing. The built-in Flight Sim offsets are documented in the list in your FSUIPC documents folder. Pete

Why are you posting the same original question? Please see the answers already given, above! Pete

But I thought you said CS was working with PM? If so then presumably the offsets it uses are still configured in its driver CFG? OH control by PM is in pmSystems, so the offsets are listed in SYSVAR.TXT, as I said. You can log IPC reads and writes, if CS is only using those, but the log might get very big. Make sure nothing else is running which uses FSUIPC offsets. Pete

AP Master is assignable in FSUIPC! All FS controls, plus others added by FSUIPC, are assignable in FSUIPC! It provides a big superset of controls! There's a complete list if FS controls supported in the FSUIPC documents folder. Your second question is very confused. Which axis didn't work? You need to try to be clearer. Also the PMDG 737 and 777 addons do not use the FS autopilot, they implement their own. You will probably need to use whatever keystrokes they assign -- or the custom controls they have provided and listed in their SDK, which is installed with the aircraft I think. And for some of your questions you'd really be better off in the PMDG support forum. Pete

Also you can download the PM offsets list from the PM website. http://www.projectmagenta.com/downloads/?category=1 The details of the areas used specifically by pmSystems are listed in the SYSVAR.TXT file included with pmSystems. Those two documents are all I ever had for PM, and when I converted to ProSim737 (which otherwise has its own hardware drivers) I simply reused or adapted the same ones. Pete

Not really. The best would be the debuggers withing software development tools, like Visual Studio. But in cases like this you wouldn't know where to begin, and WarpD has already trapped the error at least once in a debugger and hasn't figured it out. The only way I know, especially with the sorts of errors which are due to unallocated memory access, is to undertake a thorough process of elimination. From what you found earlier I think you may have pretty much done that -- it's likely to be either bad data (especially indicated because of that comment of yours " I tried deleting this in the FMS flight plan and got an immediate crash", which in fact eliminates FSUIPC straight away because there is no way FSUIPC is involved in private interactions between you and any aircraft's FMS). Again, the other comment where you got a much earlier crash after changing something involving FMS data reinforces this (" I restarted the sim and this time tried to modify the ALTO altitude constraint from 2580A to 1000A. The sim crashed rolling down the runway on takeoff"). This so much points towards a possible error in the FMS treatment of data, or possibly erroneous data, that I'm rather surprised that WarpD hasn't decided to put some additional logging into that code in order to narrow it down within. That's what I'd do. Pete

If they are analogue brakes, then this is most likely because they are reversed. Nearly all the toe brakes I know are full on when released, full off when fully depressed. Just use the REV facility in calibration. "couldn't find it"? What what is wrong with "AP MASTER"? That operates the FS default A/P master switch. If you are using an add-on aircraft, you probably need to refer to its documentation. For FSUIPC always test on a default aircraft. ALL of the systems controlled by FS controls operate on FS aircraft, but not all work on add-on aircraft, especially the more sophisticated ones which do their own things entirely. Pete

All the above results seem to immediately point to something related to the database handling, yet at the end you conclude: The only likely difference in any recent version of FSUIPC is that the memory arrangement of data is likely to be different. If there is an error somewhere else which references incorrect memory locations, perhaps because of data poointer corruptions or uninitialised variables, then whether a crash results depends purely on whether the memory so referenced is actually valid in the current process -- i.e. it is an allocated region of memory and has appropriate read/write access enabled. Small differences in memory arrangments because of updated modules can make the difference betwen such erroors crashing or just possibly creating a blip which goes unnoticed. BTW I cannot support versions earlier than the current released installer package, which is 4.953. There is a later one available in the Download Links subforum (4.954c) which you could also try. You never know, another small change in meory arrangement could make another difference. Pete