Pete Dowson

You are still using the old "aircraft specific" facility, rather than Profiles? Either way, aircraft-specific or Profiles, FSUIPC records the NAME or title of the aircraft. It has no way of telling whether it is simply a different paint job! The best way of consolidating these things and making them automatic is to edit the FSUIPC4.INI file section which lists your aircraft names and abbreviate them. Make sure you have the [General] parameter "ShortAircraftNamesOK" set to "substring" (it has defaulted this way for a long time, but as you are still using "aircraft specific" I assume you are using a pretty old installation). For example, for all Cherokee's you'd set the name to Cherokee. For all A2A planes, to A2A. Whatever abbreviated part of the name which applies to all the aircraft you want treated the same. This isn't covered terribly well in the manuals, but the "Using Profiles" chapter would be worth a read. It's a tidier method than aircraft specific and has been around for years. It's defaulted on all new installations, but you can convert from aircraft specific too. Pete

Oh dear. Did you not read all of my message? What VERSION NUMBER, please? And I need to see the log. What you are saying happens is very odd, but I cannot help without information! FSUIPC4 has not been registered inside FS for many many years! Okay, but not necessary. You could have retrieved your key -- for FSUIPC3 of course, as FSUIPC4 did not exist 10 years ago. The purchase and registration is separate for FSUIPC3 and FSUIPC4. Pete

Yes, I understood that from way back. But you said this: From this I understood you to mean that you had tried using the normal controls and that, because this aircraft "does its own thing", you couldn't operate everything you needed that way, and were about to resort to mouse macros. I then replied saying mouse macros may not work with many aircraft and explained why. You said that the gauges were written in XML which confirmed that mouse macros would not work, so I suggested that local panel variables might (L:Vars), and that if you logged these you might find ones which would do what you wanted. And are those examples of where your aircraft does not obey the normal FS controls? It would be very unusual. Even the more sophisticated aircraft normally use the standard Parking Brake and Prop Pitch controls! Why on Earth include my own documentation in your message? !!!! Yes. You can send 8 bytes, but your "&n" is the address of a 4-byte value!!! Sorry, but if you are programming you need to learn programming. To send 8 bytes containing 2 4-byte values you'd need a structure or an array, for example: int n[2]; n[0] = 65923; n[1] = -16384; FSUIPC_Write(0x3110, 8, &n[0], &fsuipcProxy->dwResult); or, using structures: struct { int control; int parameter; } n; n.control = 65923; n.parameter = -16384; FSUIPC_Write(0x3110, 8, &n, &fsuipcProxy->dwResult); However all of this pre-supposes that your aircraft does, after all, obey normal FS controls, so how did the subject get onto other things like macros? BTW I'm not a good teacher (not enough patience nor time), so won't be trying to tech you programming any further than this! ;-) An easy alternative, if you don't understand arrays or structures, would be to set the parameter in one Write and the control in the next write, then do the Process call. In any case, FSUIPC doesn't do anything when you write the parameter, only when you write the control. Pete

Offset 3110 is for sending controls -- ones having a number and a parameter. "L:Vars" have names. You can only send them either by using Macros, or by Lua plug-ins. There's no place in the control number system for names. You seem to have changed the subject completely since your last message I replied to, above! You code seems to be trying to send control 65923, which is the axis control "Prop pitch1 Set". Not sure why you'd send that. It needs a parameter to tell the prop #1 what pitch value to set. You appear to be addressing variable n, a 32-bit (== 4 byte) value as an 8 byte value. What do you think that will do? If you are trying to send the control and the parameter in one Write, you need a structure. If you don't understand structures just set the parameter first (3114) then the control. Pete

Why not assign in the FSUIPC buttons tab to the controls for this? Depending on the radio type you may need to assign to the COM STBY RADIO WHOLE INCREASE / DECREASE and then swap standby into the USE slot using the COM STBY RADIO SWAP. Some radios don't use standby, though, so then you could use COM RADIO WHOLE INC / DEC controls. Just assign the relevant positions to the FSUIPC-added control "Autobrake Set", with parameters 0 for RTO up to 5 for MAX. Are you having a hard job finding these controls? Not sure why you are asking such simple questions. The controls are listed in the assignments dropdowns -- and in alphabetic order -- not hard to find. Also all the FS controls are listed in the List of Controls document installed in your FSUIPC documents folder, and the added FSUIPC controls towards the back of the FSUIPC Advanced Users guide. Pete

All the controls listed in CONTROLS.DLL are also listed in the List of Controls document installed in your FSUIPC Documents folder! Pete

Sorry, the last part confuses me. When you write fuel and payloads directly, is the balance changed accordingly? i.e. the CofG %MAC value?

Latest version? Unfortunately that's often meaningless. It does actually have a version number. Is it 4.938c? You do actually need to describe what you mean by "despite several installations". Why several? Have you entered your registration details at all? Did you read the instructions? All the details of what happens when you install FSUIPC4 are saved in the FSUIPC4 Install log. I would need to see that. But only if you are using the current version, 4.938c. Pete

Are you REALLY wanting to use such an old and unsupported version of P3D? You do know the current version is 2.4 don't you? Are you also using a very old version of FSUIPC4? The currently supported version is 4.938c. In order to diagnose installation problems I need to see your FSUIPC4 Install log, either from the P3D modules folder, or if it isn't being saved, from a copy you save using the File .. Save menu entry on the log screen. Paste the log into a message here. Pete

Just log the L:Vars (local panel variables) to see if you can find one you can use. You can list them using the add-on FSUIPC contorl provided, or you can use the supplied Lua plug-in for logging them live as they change, on screen. Pete

Both of those are set when the SimConnect variable "PARTIAL PANEL TRANSPONDER" is true (non-zero). The "partial panel" Simconnect variables sometimes only indicate when the DISPLAY is disabled or covered -- eg for training purposes. I'm not sure if that also includes actual unit failures, though the description in the SimConnect documentation does mention 'fail', thus: PARTIAL PANEL TRANSPONDER Gauge fail flag (0 = ok, 1 = fail, 2 = blank) You'll see in the Offsets Status list that most of those failure flags have question marks against the Read/Write columns. That means that they've not (yet) been verified as working. You can log the actual value read for that variable by simply adding either offset to the Monitor table in the FSUIPC Logging Tab -- select Normal log in the options below after entering the offset and data type (U8). Maybe this is a specific problem only in P3D? I don't know if it was the same in FSX. Nevertheless it might be worth reporting this problem to Lockheed Martin, on their support forum. Unfortunately there's no other SimConnect variable that would help. Pete

Yes, and that's why I abondoned that method. Yes, a LIB file. Rather than building it into FSUIPC I built my own SimConnect DLL with the lib built in. "Hacky" or not, it is easy enough to just find the relevant folder names (which do include the build number) in WinSxS. And this method works even when the SxS system is in a mess (I never managed to unravel some of the possible Registry messes folks get into, especially in Win Vista/7/8. It was easier in XP. Pete

Not sure what "is because of ..."? FSUIPC has to be modified each time there's a new release because the position of the places it hooks, inside FS code, changes. The SimConnect version is trivial by comparison. Surely most SimConnect apps aim at a particular version of SimConnect. like the SP1 or SP2 build. I'm still using some apps which only work with the original, 60905, version. This isn't a problem as long as the end user knows he needs to run the relevant SimConnect.msi. They are still all included with the FSX-SE install, in the SDK folder's "LegacyInterface". In facyt a third party installer could rely on that and run the relevant installer ready. FSUIPC can use any version of SimConnect it knows about. For P3D I had to build my own SimConnect DLL ("SimConnectP3Dv2.dll") and install it in the Modules folder with FSUIPC, as Lockheed-Martin decided not to install any SimConnect DLLs at all and just expect developers to build the library into their code. If you have a dedicated P3D-only program that works fine, of course, but I wanted the one build of FSUIPC to work with all. I don't use Manifests, or the automatic side-by-side mechanism. I just determine what versions are installed (by looking in the WinSxS folder), and choose the one I want to interface to -- normally the latest one which is compatible with the version of FS I find I'm running with. I link dynamically to all of the SimConnect functions, not statically. Pete

Well, nothing of mine EVER puts anything anywhere but the FS Modules folder. I don't know where you got those files, but they are nothing whatsoever to do with anything of mine! Look further for what? What on Earth are you looking for? Pete

What's the "rg" version? There are only two versions -- FSUIPC3 for FS9 and before, and FSUIPC4 for FSX and later. If FSUIPC doesn't see them then they are not part of the basic 32 buttons and 8 axes which FS supports. Are they seen by FS? FSUIPC uses the same system as FS to read the settings. Don't edit the INI, use the in-program dialogues and assign in the buttons drop-down. The controls you mention are listed by name, i.e. "Rudder left" and "rudder right" respectively, and will appear as such in the list. Pete

Sorry but I have no idea what is wrong with Win8. Pete

I thought there was already a program linking FS to Google Earth? Does Google Earth accept NMEA sentences via a serial port? If so then, yes, GPSout may work with it. Pete

You'd need to write a program which referred to a database of airports and worked out how far away you are from your chosen one. Pete

That doesn't help at all. That INI shows you using FSUIPC version 4,934. Please update. The current version is 4.938c. Pete

I don't have the PMDG aircraft or else I maybe could help. I can only suggest you ask in the PMDG support forum. It is there SDK and their set of custom controls. It may well be simply that you need to have the proper parameter value. Maybe there's one parameter for "press" and another for "release". I know many of their commands are more based on mousae operations than keyboard, so maybe the mouse-type parameters are needed, the "click" and "unclick" flags. Pete

There have been many solutions found, usually via local panel variables (L:Vars) or "mouse macros". I believe the latter method was quite successful on the PMDG 737 and the only way before they published their SDK. Browse through the User Contributions subforum here and see what folks have managed. Also I think generally most cockpit builders who might be so serious they'd set up extra monitors for displays they are not looking at would more likely opt for one of the more fexible cockpit packages such as ProSim737, Sim-Avionics, or Project Magenta (and there are others), which actually emulate the full systems much more accurately and allow use of a much more VAS and frame-rate friendly cockpit-less aircraft. Quite honestly, graphics and screens is not a subject I'm at all familiar with, and even if I had time I wouldn't know where to start. If you yourself are not a programmer I think you need to find someone who is and who is willing to take this up. Regards Pete

Do you mean using the GPSout facility in FSUIPC? If so, you can route it through WidefS on a network, as shown in the documentation. At the client end you'd need to use a program to simulate two linked serial ports, one for the GPSout data going out from WideClient, and the other for the input to FliteMap. I have only ever used Flitemap. I've no idea about Flitedeck and Jeppview. I don't know that they even support NMEA input. And I haven't used Flitermap for many years-- it became too expensive. These days I use PFPX as my planner and Aivlasoft's EFB as my moving map. Much more FS friendly! ;-) Pete

Sorry, I have no idea why Saitek installations go wrong like this. Apart from the answer supplied in the first message in this thread, thanks to another user, I can only suggest you visit the Saitek support forum. Pete

Yes. Ctrl+Shift+F4 = Mixture Rich for all engines, and Ctrl+Shift+F1 = Mixture Lean for all engines. But you want separate levers, so use the controls I already told you about, the separate ones for each engine! Pete

These are custom controls. Just work out the numerical value assigned to each name (a simple addition) and send it via offset 3110. Pete