Pete Dowson

I see you also have a Saitek X52 installed. Its axes aren't assigned in FSUIPC. Aren't you using it? I suspect P3D is auto-assigning axes on that, which means controllers definitely aren't disabled. Or maybe you have installed SAitek software which is doing it somehow? The Log you supplied is cut short just after FSUIPC has initialised, so I'm not really sure why you appended it. Pete

Yes, but what did you assign it TO? And where did you calibrate it (which page of the calibration options? But you should always have a little leeway at both extremes. Please follow the steps for calibration ennumerated in the User Guide. Ah. Ok. I see you have assigned the Throttle "direct to calibration". so you actually need to calibrate. Try doing proper calibration. With the throttle calibrated on the first calibration page in the options there is no way possible to engage reverse. I am therefore pretty sure that you have not actually properly disabled controllers in P3D. Please check again. Where's your reverser assigned? It isn't in FSUIPC! So something else is processing the axes! Pete

If you have a separate reverser you should be calibrating the throttle wth no reverse zone. Then you cannot obtain reverse with it. And when calibrating make sure you have a good idle zone you can always set. If you want more assistance you will need to state things like version of FS, version of FSUIPC, the aircraft being used, and how you assigned an calibrated throttle and reverser. Pete

FSUIPC just reads the data from the PMDG iSDK interface and maps it to the offsets. I don't actually have any PMDG aircraft, so the mapping was done purely from the information supplied by PMDG, and checked for me by PMDG users. The new NGXu offsets from 6C6A to 6C97 are all mapped as a block, so if you've found two wrong perhaps they are all wrong in your setup? To check please check other offsets for me: eg the ADF standby frequency in 6C6A, the pressurization altitude values (strings at 6C82 and 6C88)and the assorted FUEL switches from 6C91 to 6C97. If those look and act correctly, then the wrong values in 6C8E and 6C8F must be wrong in the data the NGXu provides. You can Monitor the whole range of values (6C6A-6C97) by putting this into your FSUIPC5.INI file (or just editing an existing [Monitor] section): [Monitor] Monitor4=6C6A,6C97 Display=1 Then values will be logged in the FSUIPC log as they change. You can see this in real time if you enable the console in FSUIPC's Logging options tab. Pete

The "course" is also known as the OBS (Omni Bearing Selector) or OBI (Indicator), so use the controls to adjust that: 65662 VOR1_OBI_DEC 66367 VOR1_OBI_FAST_DEC 66368 VOR1_OBI_FAST_INC 65663 VOR1_OBI_INC 65664 VOR2_OBI_DEC 66369 VOR2_OBI_FAST_DEC 66370 VOR2_OBI_FAST_INC 65665 VOR2_OBI_INC Pete

Just for added clarification, the control ADF_CARD_SET is really an Axis control, best assigned to a rotary axis, not a button or switch, unless you are always setting a fixed value (which would be the parameter). For switches and buttons you have more flexibility using the INC and DEC controls, possibly with Repeat enabled for faster changes. Pete

There's only one lights offset which works for all the lights supported by an aircraft using the default lighting system, and that is 0x0D0C. That is a set of 16 bits and has one bit for each of 10 lights. Pete

It isn't only the Key you need to copy over. Do the same for your name and email. All three parts MUST be exactly as notified for your registration! They are entwined! 99.9% of ALL these registration problems are down to folks either mistyping their names or using a different form. And it doesn't matter whether your email has changed, it is the one you registered with, the one in the Key notification, which is the one you should be using. The Keys are automatically generated, they are not made with any human intervention, so the only problems really, and which very seldom arise, are those where the user has unsupported (non-ASCII) characters in their names (emails are okay in this respect as email servers don't like non-ASCII character in the email address either). Pete

No, not exactly. But you could do something with the "ipc.ask" function. Pete

Sorry, but I don't know anything about GSX L:Vars, nor therefore how they behave. Why don't you use the FSUIPC assignable control to list all L:Vars and their current values, or, possibly better, runthe supplied Lua plug-in called "Log LVars.lua" which will display them as they change. This way you can double-check your own Lua plug-in. Pete

I'm afraid so. But do first check whether there are regular controls for the things you want to assign. You mentioned "flaps, speed brake, landing gear, etc" but of course they all have normal assignable controls to handle them. Some add-on aircraft have pretty much all gauges with macro accessible switches and buttons, but, again, some don't. The PMDG Boeing series actually are supplied with a little SDK which lists all the controls you can assign, and these cover almost everything -- by ordinary button or key assignment, so no macros needed. Everything only really came together in this area in P3D4, thanks to Lockheed-Martin's cooperation in adding suitable facilities for mouse macro implementation. Pete

That will only allow you new facilities for assigning and calibrating controls and operating many other options like traffic limiting or zapping, etc etc. It would also allow you to use any of the many Lua plug-ins available to provide other services. BUT it will do nothing by itself about weather. That is a matter solely between your weather program and the flight sim receiving its instructions! So, your problem, if it really is one, should really be more properly directed to the support for the weather program you are using. Pete

Why not read the previous answer in this thread? To repeat: an unregistered FSUIPC does nothing whatsoever by itself! It merely acts as an interface into the Sim for other programs. I think you must look to the weather program you are using. That's the only purpose of installing it unregistered! Have you checked the reported weather each time? Weather conditions can affect indicated airspeed too. Maybe your weather program is setting extreme values. Anyway, you are lucky I spotted your post. You do realise you added to a 26 month old thread? Pete

You don't get any "small window" just when starting making a macro file. As the instructions say, you THEN go one to create a mouse macro for each button or switch before returning to End Macro Making. "The" control? Not more than one? Each macro file can contain all those you need for the whole panel or cockpit. You have not mentioned the version of FS you are using (FS2004, FSX, FSX-SE, P3D3, P3D4)? Nor the version of FSUIPC. Nor the aircraft you are trying to do it in. It is very hard to help you with no information at all. If you are not using P3D4 then not all aircraft implementations will support Mouse Macros. This especially applies to most recently developed aircraft models which don't use C/C++ gauges programmed with the FS toolkit. This even applies to most switch in the default aircraft. Pete

If you are using any recent version if FSUIPC, the decoding of the Event is annotated against the assignment in any case. For example: 21=P174,3,C65789,8 -{SIM_RATE_INCR}- 22=P174,4,Cx0D0086E8,x20 -{offset byte togglebits, offset 86E8}- Those comments are added automatically and replaced each time in case you edit or re-assign them. The same applies to axis assignments, thus: 0=16X,256,D,1,0,0,0 -{ DIRECT: Aileron }- 1=16Y,256,D,2,0,0,0 -{ DIRECT: Elevator }- 2=16R,256,F,x020057C6,0,0,0 -{ FSUIPC: offset word set, offset 57C6 }- 3=16U,512,F,x020057C0,0,0,0 -{ FSUIPC: offset word set, offset 57C0 }- You can also add your ouwn comments in front of this by preceding then with a ; thus: 234=P64,17,C1079,0 ; Traffic Zapper -{traffic zapper}- 235=P66,1,C1006,112 ;SayIt -{KEYSEND 112 for WideFS}- This is obviously a bit pointless in the first example, but useful in the second, where FSUIPC cannot possibly know what you've assigned in the WideFS client PC. The use of ; preceding comments is fairly widespread in Windows text files, in many INI and CFG files especially. Pete

Well, the offset number is hexadecimal. The encoding for the type of number you want is 0-7 which can be decimal or octal or hexadecimal, AND the documentation actually shows you "0x0nnnn" (for example) for a double format value. The "0x" stands for hexadecimal in C and C++. So I think hexadecimal would be good -- certainly the most obvious and easiest. Pete

The variable format required (0-7), depending how you want it, as listed in the documentation :-- This offset value only occupies the low 16-bits (LOWORD) of the 32-bit value. The high part specifies the value format. Assuming the offset is ‘nnnn’, the options are: 0x0nnnn for 64-bit double (as before) 0x1nnnn for 32-bit float (FLT) 0x2nnnn for 32-bit signed integer (SD) 0x3nnnn for 32-bit unsigned integer (UD) 0x4nnnn for 16-bit signed integer (SW) 0x5nnnn for 16-bit unsigned integer (UW) 0x6nnnn for 8-bit signed integer (SB) 0x7nnnn for 8-bit unsigned integer (UB) Sorry, can you tell us what is confusing you about that? Pete

I don't know what you can and cannot do with Python, so I can't advise. Possibly you'd get more relevant help from someone who knows Python if you posted again with Python mentioned in the thread title. From, say, a C or C++ perspective it would be far easier to do it through the offset facilities at 0D70 / 0D60. Those still involve specifying a user offset for the result. Yes, Lua plug-ins need a registered install. Pete

In unregistered mode, FSUIPC does nothing whatsoever except supply the interface used by other programs! That's the only point of installing it and not registering it. So, if you have a problem with the weather look for a weather program using FSUIPC, like FSXWX. Then stop that instead. Pete

Good! Happy flying! Pete

Glad you got it sorted. Pete

That's the important part. AI Player DLL is the part of FSX-SE which deals with AI traffic. I suspect you have a faulty AI aircraft installed. It could conceivably be a faulty airport at which an AI aircraft was trying to land, takeoff or taxi/park -- as it occurs very early in the session it would either be a bad aircraft or a problem with a parking position. Pete

Steering "Inc"? Isn't that only Increment? Surely you mean Steering Set? Steering Inc isn't an axis, it's for button assignment along with Steering dec. Steering Set is the axis one, and that can be assigned in FSUIPC too. Pete

Well, FSUIPC is receiving a notification from the Sim that it is closing, and closes itself peacefully. A crash would not do that. Type Event Viewer is the search place on screen (bottom left) and when it shows above, double click it to run it. Select Windows Logs -> Application, and then scroll down the list shown looking for a red icon labelled "Error". Find the one relating to the FSX.exe -- details are shown in the text window below when you select an item. If you find it, there may be other errors, entries or warnings below it with the same time stamp. Those may show whatever was going wrong leading to the final "error". If it wasn't really a crash, but something else wrong with an add-on which made the sim close prematurely. Sometimes corrupted code or data might do that. The only such data which FSUIPC would instigate FSX reading and processing are the weather-related files, the wxstationlist.bin file in this folder: C:\Users\<yourusername>\AppData\Roaming\Microsoft|FSX and the .wx files in your FSX documents folder (the folder where your saved flights are). If any of those are corrupted, possibly from a previous crash of FSX, then they can cause unpredictable errors when loaded. Unfortunately FSX's SimConnect doesn't check these files before use. So, you can try deleting all of those files. Another test would be to insert "NoWeatherAtAll=Yes" into the [General] section of the FSUIPC4.INI file. That will stop FSUIPC asking for the weather data. Of course this will stop any FSUIPC applications you may have getting weather data, but perhaps you have none. Pete

The log actually shows a perfectly normal shut down -- 9 seconds after everything has started okay. I think you'll need to carry out a process of elimination to find the real culprit add-on, which is apparently not actually causing FSX to crash but close properly. If you really do think it is a crash, check the Event Viewer in Windows to se what it might be. Pete