Pete Dowson

Try uninstalling that scenery then. ntdll ijust a library of many Windows functions, used very heavily. Something is calling it with bad data. Why? The normal and reliable way to locate an error is to start off with P3D clean, completely devoid of Add-Ons. Then add them back one at a time, testing each time. You could, maybe, speed that up a little by uninstalling one half, then the other half, and proceed thnce narrowing it by halving. But that is error prone and can be misleading. Sceneries added can be eliminated by renaming your SCENERY.CFG (in the ProgramData folder) and your Prepar3D Add-Ons folder (in Documents). Most other add-ons will be removed that way too. for others you will want to rename the DLL.XML and EXE.XML files in the ProgramData folder and also those in the <you>\AppData\Roaming folder. Pete

Hmm. Interesting. I'm sorry, but I've no idea what is going on. Maybe I'll ask Aerosoft about it. I don't know who the developer is but maybe we could get him to explain it for us, as it smells like a SimConnect corruption of some sort. Maybe we can get an A320 for testing. How important is it for this to be resolved? it sounds like it has no adverse effects. If that's true and no explanation can be found we can probably simply suppress the reports. Pete

Not sure what you mean by "interject", but those are the sames of the controls you can assign to button or key presses in FSUIPC. The names in P3D will be different, but would describe the same things. The list for P3D controls is In your FSUIPC Documents folder. There is a PDF document, plus a TXT version which is re-generated for each P3D update in case any more have been added. Adding to this you would also see the additional FSUIPC controls listed later in the FSUIPC Advanced User's document, okus those for any Macros or Lua files you might have installed / running. Pete

Engines are normally shut down by cutting their fuel. The P3D controls for that are MIXTURE_LEAN for all engines, of MIXTUREx_LEAN for engine x (x = 1-4). These are standard P3D controls and are listed in the P3D assignments as well as in FSUIPC, maybe with different wording. Sorry, but the FSUIPC documentation cannot possibly list all the ways of doing everything possible in P3D. It isn't its job. (I doubt even that there's any P3D documentation which would tell you explicitly -- you'd probably need to find tutorials for the specific aircraft). The overhead panel for which particular aircraft? I don't offhand know of any aircraft which has engine shutting down facilities in the overhead, but there may be I suppose. For jets there will be a fuel idle/cutoff switch or similar, probably near the throttle quadrant. For props there will be a mixture lever or knob (usually red) which is reduced to off to cut the fuel. Pete

What about without the A320? Current version of FSUIPC is 5.153, since 9th December 2019 I think. Are you also using LINDA? So, is the A320 the common factor? Or LINDA, Or both together? I've only seen this sort of thing happen when there's something wrong with Simconnect -- normally some corruption. As a first test try adding "NoWeatherAtAll=Yes" to the [General] section of FSUIPC. That should eliminate any possibility of it being a corrupt weather file (wxStationList.bin, or one or more .WX files). It that "fixes" t you neen to delete those files and let them rebuild. Otherwise it'll need a process of elimination, no add-ons, then add them one by one. but start with the A320 and/or LINDA first in any case. Pete

There is no option related to those errors on those particular Sim Vars. They shouldn't occur as they should always be readable. Pete

If dpL is a nil value that will be because " ipc.readLvar("L:DEWPOINT")" found that L:DEWPOINT didn't exist. You can stop the error by checking whether dpL is nil before using it. If the L:Var does not exist, then you cannot write to it nor read from it. Check whether it exists by using the List L:Vars control. FSUIPC doesn't create L:Vars, it only provides facilities to read and write them. Pete

"Installing" WideFS? WideFS consists of WideServer, which is part of FSUIPC and which is simply enable afteryou Register it in the FSUIPC Installer, and WideClient, which is 'installed' on a different, networked, PC. When enabled Wideserver does little to nothing until a client connection is made, and by then FSUIPC must have been 'work' for some time. So, please elaborate on what you mean here. When enabled Wideserver does little to nothing until a client connection is made, and by then FSUIPC must have been 'working' for some time. So I very much doubt that the two things are related. In order to help we need to know what VERSION of FSUIPC you are using, and which Flight Simulator. The bet way of providing this information is to shw us (paste or attach) the LOG file from the sim's modules folder. In fact, the best thing for you to do is refer to this post, pinned near the top of the Forum: BTW, please refrain for typing text in ALL CAPITALS. It comes across as shouting, and isn't very readable. Also, please consider entitling your posts with something more related to your questions. A title like "YSRI" is meaningless and will simply not attract the right folks to help. Pete

Most aircraft naturaly fly at their most efficient cruise speed slightly pitch up. If you pitch down (eg to level) you will need more power and so consume more fuel. Try the effect of making small throttle changes and you'll see. You'd probably be dealing with changes in the order of 5 degrees and more. For meaningful feed back via tones it is probably not enough just to use the pitch alone -- flaps, gear, and thrust all play a part. Pete

FSX SE is a 32-bit program. FSUIPC is s module which runs inside FSX, so it has to be 32-bit. This is all nothing to do with whether Windows is 32- or 64-bit. That only means you can also run 64-bit programs (eg like P3D4). About SPAD? You'll need to find the SPAD support forum. Pete

"Put in"? I think you must have read that MS wishes to coperate with developers. I would have thought that would imply some sort of an SDK, wouldn't you? Please just check on Flightsimulator.com, as I do. I think MS talk openly there about an SDK. Pete

Please see the FSUIPC4 User Guide. The "THE EASY STEP-by-STEP WAY TO CALIBRATE YOUR CONTROLS" section starting on page 47 covers this -- scroll down to the third paragraph in "NOTES and EXCEPTION" on page 48. BTW, I am 76 years old. 74 is not too old to understand whatever you wish and whatever interests you! Pete

FSIUIPC has nothing dependent upon where you are in the world. I think you have a corrupt weather file with a corruption causing the hang or crash somewhere in the part of the weather data referring to N America. Delete the wxstationlist.bin file from your AppData\Roaming\Microsoft\FSX folder for the sim. Next time FSX is loaded it will make a new one. It would also be wise to delete the .WX type files from your FSX Documents folder (where the flights are saved). Corruption of these files can cause SimConnect to do unpredictable things when they are read. The reason this is sometimes only a problem when FSUIPC is active is that in requesting weather data FSUIPC causes SimConnect to read them. The DLLStop message simply means that SimConnect has started closing down the Sim and has called FSUIPC so it too can close tidily. Pete

Yes, but even if you read it as an integer (eg conversion via the "atoi" library function) then you'd at most only be 1 foot out. It was changed to allow the automatic correction of the altitude 'bugs' introduced by the P3D4.5 HF2 to handle altitude changes in layers differently. It was requested for FSAeroData. Sorry this had an adverse affect on your software! 😞 It didn't appear to do any harm as it was natuarally assumed that programs would either convert it using XML tools (which should be immune to the change, no?), or would at worst treat it as an integer up to the '.' which would terminate a loop looking for decimal digits. Of course, I suppose that '.' might be treated as a thousands separate by some non UK/US ways of handling it. But looking at your results was that '.' simply discarded? Pete P.S. From the Release Notes in the Download Links subforum: -- Version 4.891 provides altitudes accurate to 2 decimal places in the Runways.xml file (only).

Sorry, but is the cocumentation for the function not understandable? If it isn't maybe I should get it improved. As for techniques for using events I'm sure there are plenty of examples available, if not so many in the supplied ZIP, certain in the Forum (mostly in the User Contributions I think). Your questions were not really asking about how to use events, but more as if you hadn't seen the existence yet of event.control. Pete

So, use event.control as I said! The one you "missed" as I pointed out in my earlier reply yesterday. That is exactly what it is for! Pete

It isn't "event.control(65823, 1)"!!! Please do read the documentation! The second parameter it the name of the FUNCTION you want to be called when that event occurs! In that function you can checvk the parameter and act accordingly! Pete

You missed the first line (see the earlier posts for which the later ones were edits): Windows Registry Editor Version 5.00

Do the flaps work fully using the normal P3D default assignments for them? F5 FLAPS_UP F6 FLAPS_DECR F7 FLAPS_INCR F8 FLAPS_DOWN If not then check the A320 documentation or FSLabs support for how to operate them. If they only work using the mouse, then you might need to create mouse macros for them instead. To be sure your assignments are correct 9and theylook ok to me) you can always use FSUIPC's logging -- in this case, enable event logging. Pete

Yes, it was an error in my cutting and pasting. I didn't send a correction becuase it got sorted by the time I looked again after realising the error. If those are the correct VIDs and PIDs, then those entries are the only ones I know. Well a Registry backup is always a good idea before trying any editing on it, so that's okay. Feel safe. Pete

You missed "event.control". The functions in the event library are listed in alphabetical order. It's on page 24 in my copy. Is you Lua code sending those controls? If so, no need to detect them as you'll know. Pete

I don't see much wrong with your settings, but you have the same settings for all aircraft, no profiles for different aircraft. You have throttles all set (twice in fact) for the separate throttles system: 7=2Z,256,F,66423,66426,0,0 -{ TO SIM: AXIS_THROTTLE2_SET, AXIS_THROTTLE3_SET }- 8=2R,256,F,66420,66429,0,0 -{ TO SIM: AXIS_THROTTLE1_SET, AXIS_THROTTLE4_SET }- 9=3X,256,F,65820,0,0,0 -{ TO SIM: THROTTLE1_SET }- 10=3Y,256,F,65821,0,0,0 -{ TO SIM: THROTTLE2_SET }- 11=3Z,256,F,65821,0,0,0 -{ TO SIM: THROTTLE2_SET }- First, it generally is not a good idea to have multiple assignments in this way unless you have a good null zone at the Idle position, and make sure the unused throttles are not moved. Second I think those two assignments to two throttle controls each could be done better by using the mapping provided for that purpose, but that would involve using profiles -- which I think is the better way in any case -- and in fact usually one of the main points of using FSUIPC. There's really nothing inyour axis assignments (at least) which could not be done in the P3D assignments. You can still calibrate in FSUIPC when using those. Finally, to your problem more specifically, I suspect that the A2A cub needs you to assign to the generic throttle (AXIS THROTTLE SET) -- the one calibrated on the first calibration page in FSUIPC's tab. Either that, or just not calibrating in FSUIPC. This is because one of the main advantages in FSUIPC of assigning to the 4 separate throttles is that it sends these on to the simulator as the old (FS98 dated) "THROTTLEN_SET" controls. It does this as those are the only ones providing a reverse range. But some aircraft are programmed in a way that this causes adverse effects. However, in the [JoystickCalibration] section you'll find this parameter: UseAxisControlsForNRZ=No If you have set "no reverse zone" for the throttles, which I assume you have, then setting this parameter to "Yes" instead of No might fix your current problem. I don't know -- it depends on how the A2A Cub has been programmed. If that's all you want to fix it is worth a try. Otherwise I suggest you set up your first profile, one for the Cub, and use the generic assignment for the throttle there. this is worth doing as I'm sure you'll find reasons for other profiles in the future. Pete

Sounds like your settings in FSUIPC are all wrong. Without seeing your FSUIPC5.INI file we cannot help further. Just having FSUIPC installed and running won't change anything, so we need to check what you'd done. Have you any problems with other aircraft? Pete

Are, they are numbers. R just stands for Reference, X is for heXadecimal, 9f260 is the offset in the Gauge file to the function to be executed (which is why mouse macros have to be re-made if you update the aircraft), 55cc is a check value, to make to sure memory at that point is correclty indicating the entry point to avoid a crash if you do update), and 22 is the mouse action code -- see the list in the Advanced User's guid. No, because there's a lot more to it than simply causing a jump to that part of the code. That uses "L:Vars", which isn't in any way the same as calling a function normally called by a mouse click. There are lots of things which may be indicated and controlled by L:Vars, and these often do overlap with the mouse click spots in a cockpit. Where they do the job you want they are more relaible than Mouse Macros and will normally be okay across updates. There's a spacial control you can assign in FSUIPC to list all the L:Vaars in a cockpit, and their current values, and, better, a Lua plug-in you can run to monitor changes in them and show these on screen ("Log lVars.lua"). BTW in P3D4, Lockheed Martin kindly made the "mouse macro" method officially supported with new facilities, and these thereby became more reliable and don't necessarilty change just with updated gauges. Before this the facility was most definitely an ugly hack. Pete

There's no difference whatsoever in how FSUIPC treats the elevator assignments and calibrations compared to those for the other flight controls. It's all the same code, only the name of the control is different. So, there's something odd in the way the elevator is wired, or in your assignments and calibrations. Looking at your assignments, in the INI file, I see: 0=0X,309,D,1,0,0,0 -{ DIRECT: Aileron }- 1=0Y,1,D,2,0,0,0 -{ DIRECT: Elevator }- 9=3X,356,D,1,0,0,0 -{ DIRECT: Aileron }- 10=3Y,185,D,2,0,0,0 -{ DIRECT: Elevator }- Why those very odd Delta values? Those are the minimum changes before they are acted upon. With a 1 it means every single minute change will cause FSUIPC to attempt to honour it. This is normally only used for digital controls where the specific values are needed -- e.g. setting a heading with an axis. I strongly recommend you set them all back to 256, like the rest of the assignments. The log would only have been of interest had you enabled axis logging first and the done a elevator test. It would have been a huge log with a delta of 1 of course, so I would have asked you to change that first in any case. Pete