Pete Dowson

Possibly. But your "wonky" values do show a spiked input in the axis control connected offset, 0BDC -- 16383 is maximum flaps control input to FS. I can interpret log files far easier than trying to work with loads of screen shots. Please PLEASE, do you think you could possibly actually try to use the built in logging and monitoring features in FSUIPC to supply simple logs? Enable Axis and Event logging and monitor the offsets in FSUIPC's monitoring facilities, to "normal log". Then show me the result for each flap setting sequentially -- i.e. one log, no pictures please! It will also be relevant to know how you are assigning and calibrating the flaps, exactly. Pete

Yes, the =-1 tells FSX not to load it. I hadn't noticed that Registry item. I shall add code to the Installer to check for that one and correct it. I already did this for another, an "IgnoreFreeLibrary" parameter in HKEY_Current_User\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers Thanks for letting me know. [EDIT] I checked my Registry, and the "State" parameter (0x23C00) is in the path you you give but further down: WinTrust\Trust Providers\Software Publishing. Is that so for you? I'll need to know if this is variable in order to automatically fix it. Pete

The DLl.xML and the FSUIPC4 Install log both look okay, so there's something telling SimConnect not to load FSUIPC4. Check the FSX.CFG file and delete any lines in the [Trust] section mentioning FSUIPC4. If that doesn't help I'll need a SimConnect log. There are instructions in a thread in the FAQ subforum which tell you how to get one of those. Pete

Those values are direct from the SimConnect variables "TRAILING EDGE FLAPS0 LEFT ANGLE" and "TRAILING EDGE FLAPS0 RIGHT ANGLE". If you monitor those offsets using FSUIPC's monitor facilities (Logging tab), as type U16, you'll see the original SimConnect values which are received (in floating point) as well as FSUIPC's conversion into U16 format (for compatibility with FS98 through to FS9). I've no idea whether the PMDG flaps implementation uses all of the FSX flaps simulation or does its own thing, but I've looked at the data it provides in its Client Data and all that gives are left and right needle positions, for the flaps gauge. The input from the control, if it is an FSX control, goes to offset 0BDC, and the results are in 0BE0 and 0BE4. You can also get the actual index to the position, 0-8 in this case, in offset 0BFC. Do all these also show such wonky behaviour? Are you getting the problem with all aircraft or only the PMDG NGX? Pete

I need to see the file. I've no idea how to interpret that "screenshot". It's a text file, I can see if it is correct from the text, not a screenshot. Was a LOG file produced? Pete

I can't make head nor tail of that picture. What does it mean? The DLL/XML file is a plain text file. Just paste it into a message. Installing an updated version wouldn't change the DLL.XML, though it might try to correct it and possibly fail if it was already a mess. The other clue is whether an FSUIPC4.LOG is generated when FSX starts. Pete

Okay. In particular, if you could identify what offset, if indeed it is an FSUIPC offset, which that ACARS program is reading. Pete

Two points to make there. First version 4.929 is superseded and unsupported. Currently supported versions are 4.934 and later. Second, it is often not enough to delete assignments in FS -- unless you actually disable controllers in FS, it can automatically make default reassignments. If you simply disable controllers you need not delete anything, so it is easier in any case. FSUIPC can't actually do this. It isneither in control of flaps nor responsible for reporting on them. Your assignments to flaps axis or flaps controls are responsible for setting the flaps and FS reports on their positions which values FSUIPC merely exposes in its offsets. Okay, so the inputs are correct. The values reported by FSUIPC are those reported to it by FS (or in the case of FSX, SimConnect). Of course, with the PMDG NGX you might actually not be reading the FSX values but those for NGX. I don't know if the NGX uses the FSX flaps or not. But in any case the offset area provided for NGX is simply a direct copy, a gateway in effect, to the data provided by the NGX code. I don't have the PMDG aircraft installed (well, at least not a working copy), so i can't check, but you don't even mention the offsets being read. That could be crucial. No, there is no point, because FSUIPC only reports what it gets. It doesn't go around inventing data of its own accord. It is merely a window into whatever provides the data. If your problem is with the data provided by PMDG in its client Data area for the PMDG then you really need tho go to the PMDG support forum. If it is the FSX data which is incorrect then I would hazard a guess that the PMDG aircraft doen't make normal use of the inbuilt FSX flaps mechanism. You can check for either of these by testing with the default FSX 738. Pete

Whether you do or not won't make any difference if you are assigning to the FS carb heat control, as it is just on or off. Does the Cherokee come with its own carb heat control? Does it heat up to different temperatures at different settings? The Cherokee I flew way back when I was learning had a thing you pulled for carb heat, but it was still really only a switch, in for off, out for on. There was no meaningful intermediate position. Regards Pete

No hard time, it isn't a problem. I just think you are rushing into things a bit without thinking it through. Just start off, as I said, assigning and calibrating those things you need. Don't create profiles until you find you have to because the existing assignments don't work. And don't assign each new aircraft to a new profile, think first which one it belongs to based on the differences you need to deal with. Then you'll be okay. Pete

You DEFINITELY want to use Joy Letters then! It is made to fix this very problem! Just make sure everything is working okay first, then close FS, edit the INI file changing "AutoAssignLetters" (in the [JoyNames] section) from No to Yes, then run FS again. All the button and axis assignments will then be by an assigned LETTER, and FSUIPC will match the letters up to the correct device by name and "GUID" (a unique ID) each time it loads. This will totally fix the cases where your Windows ID numbers change on re-boot. Pete

Oh dear, what a mess! Why are you using Profiles in any case? Do you REALLY want different axis assignments for every single aircraft? Do you really want the calibrations different for every aircraft? The idea of Profiles is so you can set up things differently for different TYPES of aircraft -- jets, props, helicopters, gliders, which all need different types of axis and certainly different calibrations. Then among jets a fighter would want different (more senstive) calibration to a large transport. The other reason for different Profiles is to meet the specific needs of different complex add-on aircraft, where some axis assignments don't work and where different button assignments are beeded because they do things differently. I've just spent an hour sorting your INI into an order where I can show you what you are, for some odd reason, doing. Start with Profile assignments. Just for the A380 you have: [Profile.A380 Wilco] 1=Airbus A380 v2 Qantas 2=Airbus A380 v2 China Southern [Profile.A380 G-XLEA] 1=Project Airbus A380-841 British Airways VC VASFMCgauges [Profile.A380-800 tomcatters] 1=Airbus A380-809 tomcatters [Profile.Abacus A380-700 v2] 1=Abacus Airbus A380-700 China 2=Abacus Airbus A380-700 Korean [Profile.Abacus A380-800 v2] 1=Abacus Airbus A380-800 China [Profile.Abacus A380-900 v2] 1=Abacus Airbus A380-900 SAS [Profile.Abacus A380-800F v2] 1=Abacus Airbus A380-800F Old House Now maybe Abacus and Wilco A380's need different assignments (do they?), but even then, why create and name a different assignment for so many similar models? Do the Abacus A380-700, -800, -800F and -900 really need different axes assigned, different buttons, different calibrations? I doubr it, and looking at the sections defining these, they all look pretty much identical in any case. You are simply making things very very difficult and confusing for yourself. Let's look at each section type in turn: AXES I compared all of the [Axes] sections and there are absolutely no differences in any of the assignments for ANY of the Profiles -- just an extra one or two in some, but none conflicting. The extras in some are Throttles 3 and 4 (which can be assigned in any case for 1 and 2 engined aircraft), and Pan/Tilt (!?). You have a Profile for the iFly 747 with NO axes assigned at all (!), just one button change. CALIBRATIONS It looks like you've gone through pretty much the whole of the calibration tab clicking "SET" on every possible control. -- yes, INCLUDING steering tiller. Not only that you have left the actual calibration values to default in most instances -- which really defeats the entire point. Why use FSUIPC to assign and calibrate and then not bother to calibrate? You might as well not be using it at all for axes or calibrations. You should be following the numbered calibration steps in the User guide. Else just don't use FSUIPC for axes. There are exceptions. These occur in most sections: Rudder=64,64,64,64 Reverser1=0,0/8 Reverser2=0,0/8 Reverser3=0,0/8 Reverser4=0,0/8 PanPitch=0,0,0,0 SteeringTiller=0,0,0,0/8 Basically the rudder is calibrated to only ever give one fixed value, 64. The reversers, pan pitch and steering tiller are calibrated to not work at all. BUTTONS Mostly all your button assignments are common ad in the default [buttons] section. you only have a few differences, but almost all of the Profile-specific button assignments are actually the same as the default ones, so those are a waste in any case. SUMMARY I was going to try and fix it all up for you, but there's so much wrong there's really little point. I think your best bet is to delete it altogether and start again, but this time with more thought. Do NOT start using Profiles unless there's a reason. Do your assignments and calibrations properly, AND only for the axes you are using, not every one regardless of assignments as you appear to have done. ONLY consider profiles when you need something actually DIFFERENT for an aircraft -- like two levers you normally use for Throttles 3 and 4 on the 747 but are needed for Mixture and Prop on, say, a DC3 or Baron. Just have profiles for those aircraft that are different. As far as I can see every aircraft you currently have a Profile for can all be treated identically. You'll find differences needs with some special add-ons like the Aerosoft Airbus and all of the PMDG range. Regards Pete

There's no fix because I've never known such a problem. All of FSUIPC's settings are saved in the FSUIPC4.INI file, in your FSX Modules folder, and always read back from there. There's no way it will "forget" any of this because it reads it EVERY time you run FSX. AND it's the same thing no matter whether you re-booted Windows or not. No difference. Maybe you have some other software installed which is screwing up the USB connections and causing them to change each time? I can't imagine what could do that, but if that is what is happening what would result is that the same assignments would be there but activated by the wrong devices. is that what is occurring? If so you should set FSUIPC to use Joystick Letters instead of numbers. it will then identify devices by name and link them to the previous assignments. There's a chapter about this in the User Guide. It's a good idea to use this facility in any case, whether there's a problem or not, once you have more than one control device. Regards Pete

It sounds like you have a steering axis assigned as well. FSUIPC gives priority to the steering axis at low speeds, crossing gradually over to rudder -- 100% rudder by 60 knots (default), and in the air. This is a documented facility. If you don't think this is so, please show me your FSUIPC4.INI file. Pete

It should do what you ask already. FSUIPC has no idea about time zones -- it has to rely on FS to set those correctly. It sets the UTC (Zulu time) from the Windows GetSystemTime function, and writes it to the Zulu time setting in FS. That should mean you get local time in the place set for the flight. Are you saying this does not happen? FSUIPC does not set local time (i..e. local time at the PC location). To quote the Windows documentation for the GetSystemTime function: "Retrieves the current system date and time. The system time is expressed in Coordinated Universal Time (UTC). To retrieve the current system date and time in local time, use the GetLocalTime function." I'll check here. Maybe FSX messes up the local time difference? [LATER] No, it works, and it works exactly as intended. the time you get is based always on setting the current UTC time, and relies on FS operating its time zone differences. I just loaded a flight based in Seattle and it correctly set the local time to 05:32 which is correct for a UTC time of 12:32. Pete

Many sophisticated add-on aircraft implement their own systems and their own ways of switching them. FSUIPC interfaces to FS, not to individual add-ons. You need to find out how to operate those yourself. Maybe others have already solved the problems for those aircraft -- check the User Contributions subforum. For add-on aircraft it is unlikely that any default FSX controls will be any different from what you can do in FSUIPC, and in fact FSUIPC offers many more ways than FSX. The only likely conflicts you would get if you enable controllers in FSX is with axis assignments in FSUIPC, and possible duplicate button actions. All you would need to do to check FSX alone is temporarily move the FSUIPC4.INI file out of the FSX Modules folder so that FSUIPC will make a new, default, one with no assignments. When done just put the moved one back into the Modules folder. Pete

But I gave you explicit instructions on where to find that information. did you not read my reply? Don't bother to contact me with any questions or logs if you aren't using a current version. There's no way possible for me to support old versions. By not bothering to show me the original failure log, nor tell me the Windows crash details as I asked, you are simply perpetuating a possible problem for others. I'd rather fix things than ignore them! :-( Pete

I don't know without more information. Does selecting "Yes" to carry on and run it stop you actually running FSX? If not it is likely to be the well-known SimConnect timing bug that was never fixed in FSX -- see the FAQ subforum, about this. It should fix itself of its own accord if you persist. Otherwise, is there an FSUIPC4.LOG produced in the FS Modules? If so please paste its contents here. And I need the information from Windows about what it thinks happened. There will be details in the Windows even viewer. For that use the "search programs and files" edit area bottom left in the start bar, enter "event viewer" and when it appears select "Windows Logs" then "Application". Find the line referring to an error in FSX, select it, and give me the details. I also need to know what else you have being loaded -- i.e. a list of add-ins which will be loading initially with FSX. Pete

It sounds like either it isn't assigned at all, or assigned to the wrong control, OR the rudder is broken. You only need to assign for different aircraft if you want to use Profiles. Are you using Profiles, and if so, why? Why are you ticking profile specific? If you don't know what you are doing it is best not to go around doing such things. If you do, and you've already been making assignments or settings, it asks if you want to save those first as settings for all aircraft -- if you say no they will become specific. You do NOT need to have everything set specifically for each aircraft. You need to think about why you are doing what you are doing! What sort of assignment? Any axis, button or keypress assignment can be deleted in the Options dialogue, easily. Why mess with the INI? You'd only need to edit the INI if you wanted to remove an aircraft from a profile -- you do that by deleting its name in the [Profile.<profile name>] section. Pete

The Lua facilities built into FSUIPC do allow any USB-based HID device (HID = Human Interface Device) to be handled. It is a programming task though, and needs first an investigation into what the devices are returning and second the writing of the Lua code to do the job. LINDA is a package which I think does that job for you for some devices. I'm afraid I do not know if it already comes ready for the devices you have. LINDA is an add-on package which is not from me, and since I don't use it I know little about it. I think it has its own support forum and I would advise you to ask there. The program I mentioned, SPAD, is also a third party program, and I think this makes the Saitek switches and buttons visdible and programmable in FSUIPC.. That might be an easier option, but I don't know that program either. Regards Pete

Doesn't the normal mixture control work? Are you sure this is an FSUIPC question at all? Best to test your controls with a default aircraft first. What do A2A say? Do they have a support forum? Pete

Make sure your controls work correctly with a default aircraft first, AND first with normal setup in FS. FSUIPC only adds more precision, it does not do anything substantially different. ALWAYS make sure things are okay with everything normal first. Saitek controls seem to be very liable to incorrect or corrupt installations. If the levers are not all consistently working similarly then it is likely to be one of the all too frequent registry xcorruptions their devices seem sensitive to. I'm afraid I can't help with that -- you'll need to go to Saitek's support forum. Those Saitek devices are not supported directly by FSUIPC at all. They are completely non-standard. I think there's a program called SPAD which enables you to use the buttons in FSUIPC, but I cannot support either the devices nor SPAD. FSUIPC's support extends to all normal joystick type connections and GoFlight devices, but Saitek are no friends of mine I'm afraid. Regards Pete

The Windows event viewer will give crash details including the module name and location within it. That's the first check. I noticed you were using the iFly 737 -- are you sure that is P3D compatible? Not all FSX add-ons can be transposed to P3D without adjustment. Pete

Probably because they aren't simulated in FS. I've never even heard of "twist grip". If you are using an add-on aircraft which simulates these things you would need to find out how to get the correct information. Panel failures are not system failures, they are simply where the instrument on the panel is off for some reason -- usually to do with training exercises. The underlying systems may still be working. Your warning panel is to do with whether systems are working correctly or not. Fuel warnings are usually for things like low fuel pressure, normal if the pumps are off, for example. most of the warnings you need have to be derived from specific conditions related to the system. FS by default hardly simulates any subsystems in any detail. Add-on aircraft like those from Aerosoft and PMDG, and add-on cockpit software like SimAvionics and Project Magenta, implement systems, and those add-ons may not use FSUIPC offsets (the add-on avioincs systems usually do, but not add-on aircraft). So, you really need to find out how to get the information from your AS 350 software, not from FSUIPC. Maybe it's all in Local panel variables (L:Vars) which you can read using FSUIPC's Lua plug-in facilities. I can't support old versions in any case. Current is 4.934. Pete

You are using an older version of FSUIPC and one I cannot support. The earliest supported version is currently 4.934. Assignments and settings never change when installing new versions. Nothing changes except you get updates to the program itself, documentation, and example plug-ins and the like. Pete