Pete Dowson

As well as what Thomas says, I would certainly be wondering how it suddenly became "unregistered", because Registration has nothing to do with version numbers -- version 4 is version 4, and that's what the Registration ties to. Regarding the Installer for an updated version, it sounds likely that your registry is in a mess. Have you been using a migration program to install things for P3D? They tend to mess things up such that Installers which do understand all these FS versions get misled. When you say "it keeps looking for FSXSE" what do you mean? It looks for each version of FS which in registered as installed, but it only checks once. It never "keeps looking". It just prompts you to point it to the correct folder and EXE file for any one of those if it cannot find it where the Registry points. If you want me to help with the installation problem, you need to show me the Install log, which is always produced by the Installer and which will contain the exact reasons for what you see. You can paste it complete into a message here. Pete

Ah, that explains it. (But what is "FI" ?) A one or two line lua plug-in for each button you want to assign would work too. You just put the Lua files into the Modules folder and assign the button to "Lua <mame of plugin>". For example, to click the left hand button: mouse.click(0) To scroll the wheel forward 1 click: mouse.wheel(1) To scroll the wheel back one click: mouse.wheel(-1) I think just moving the mouse makes the pointer show, so a couple of lines should do that without moving it far from its previous position: x, y = mouse.getpos() mouse.move(x+1, y+1) Lua plug-ins run internally to FS of course. Pete

I've analysed this as far as I can get. The place where it crashes in the version of API.DLL you are using (FSX/Accel) is deep in a small routine called in many places. Without a debug trace it's hopeless. tracking back up could take so many branches reaching the calling API function could take weeks. Not only that, but the code in my version of FSX (FSX-SE build 62615) is substantially different. So I'm not convinced it would even happen at all here assuming I had the aircraft in question. You should also note that this thread started which was a different crash altogether, though there was never any relevant data supplied. It was that one to which the aircraft's author was presumably referring in his response here, some time back. Quite honestly, the aircraft author is the person best placed to sort this out. If he does identify something FSUIPC is doing which explicitly somehow conflicts (only!) with his code, then I'll gladly look at resolving it as best I can from my end. [LATER] It's just occurred to me that the very last entry in both Logs you submitted end on the line ".PLN". Now this line should be giving the name of the flight plan which SimConnect tells FSUIPC has just been loaded. But it has no filename at all! Could this attempt to load, into FS, a flight plan with no name somehow crash API.DLL? I know that DLL is involved in interpreting flight plans. It seems to me that something you are doing, or the add-on is doing, may be attempting to load a plan which is causing that process to fail. Can you check the FSUIPC log from a run with new of the FSUIPC versions you say "works"? What are the lines shortly after the one saying "Advanced Weather Interface Enabled"? I just checked, and the second log posted by the thread starter also had this ".PLN" line in it: 354031 Advanced Weather Interface Enabled 653344 Sim stopped: average frame rate for last 301 secs = 6.0 fps 653344 Max AI traffic was 23 aircraft 653344 Average weather filter write interval in that time = 37677.8 msecs 944406 .PLN 969656 System time = 22/05/2016 20:41:16, Simulator time = 17:11:03 (15:11Z) 969656 *** FSUIPC log file being closed It was soon after that line that the sim closed down. No error, just a close. The user says he didn't close it! Pete

Strange. I've never had such a thing happen. There's always a reason given -- unless the user or another program has instructed Windows to restart. There's no such code in FSUIPC. No, I am saying no such thing. Except for the remote possibility that something has actually instructed Windows to restart, I was saying that only software with driver-level privileges can cause a crash which make Windows restart. Nor I, because it cannot, and it cannot be anything to do with FSUIPC. However, everything in the FSUIPC Settings dialogue is handled by standard Windows dialogue libraries, and of course the changes on screen are handled by a video driver. I think you need to go through a process of elimination. Start by doing things without the PMDG aircraft running. Don't have anything else running apart from FS + FSUIPC. See if that still does it. If not, add things back bit by bit. Yes, exactly. I'm surprised you've not set up any generic controls already, really. You should make profile specific settings as and when you find you need them, and you can then always base them on the settings you already have. Note that some bits of some of this add-ons are probably still running even when you are not using their aircraft. I know this happens with the PMDG stuff. So we might need to take further steps. But try the easy way first. Pete

Yes, but I needed the crash data and Log for the same event. The main use of the Log is for the "Module base" and the versions of each of the FS Modules linked to. C0000005 is an access violation. I described why this is proably happening earlier. I think something in the Add-On aircraft code is using an incorrect, unchecked or uninitialised pointer. I'll see if I can track which action in API is being used when it crashed, but I don't offer much hope. We'd really need a stack trace, and that would mean running it under a debugger. If the API crash is so easy to reproduce I'm amazed the add-on author hasn't done this already! I don't have the aircraft and I'm not going to buy it to find a problem in someone else's code. Pete

Where are you looking in FSUIPC's options? You need to be more specific. The assignment of axes is done in the "Axis Assignment" tab. If that is where you are looking, and there is no response, then your joystick device is not correctly registered in Windows. Is it a Saitek by any chance? Because their installers seem pretty bad. If this is the case, please check the FAQ subforum -- the thread "fixing joystick connections not seen by fsuipc/" is relevant. But I should also ask -- why are you wanting to assign in FSUIPC? You do know you can calibrate joysticks in FSUIPC without assigning there. You can leave them assigned in FS. The most usual reason for wanting to assign in FSUIPC is for more flexibility, especially being able to create profiles for different aircraft using different controls for different aircraft types -- stick or yoke, for example. Pete

Well you certainly need to adjust that. Even during takeoff and climb they'd be a lot quieter from the cockpit. There will be parameters controlling the engine volume levels, maybe in your aircraft's "Sound.CFG"? But the engine sound is so diminished in the cockpit that you'd probably need Superman's hearing to tell the difference, especially over all the wind noise. That's possibly true, but then your previous paragraphs are rather irrelevant, aren't they? Any way, even with airframe transmitted sounds, I think you'd find that, in the cockpit (not necessarily in the passenger cabin of course) ,the wind noise overshadows all that. Pete

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