Pete Dowson

In terms of performance, and probably ease of understanding, your simplest would be the one to choose -- i.e. option 1. The other two are just making things more complicated for no good reason. Pete

Hmm, yes, it does look correct. How are you actually deciding the profile isn't working? Just by pressing the buttons? Have you been to the Buttons & Switches tab, see if clciking the Profile option there displays the correct profile in the title? Are you sure it isn't the buttons themselves not being seen? Try button logging, see what that shows in the Log. Pete

Well, the way you have it. of all of your PMDG aircraft, only these are assigned to profiles: [Profile.777-200LR] 1=PMDG 777-224LR Continental Airlines (Fictional) [Profile.737-900NGX WL]1=Boeing 737-924NGX Continental Airlines Winglets [Profile.737-800NGX WL] 1=Boeing 737-824NGX Continental Airlines Winglets Check the FSUIPC4.LOG file to see the actual title of the aircraft you are loading. It is that which it has to match. You've not used any abbreviations in the INI to enable easy matching to any livery. It must match some part of the actual name completely, so the longer the name in the INI, the more restrictive it is. Also remember that whilst Axis assignment and Calibration is all totally either profiled or not, Button and Key assignments in a Profile only override any ones to the same Buutons or Keys in the general assignments. When you look at the Buttons & Switches tab, you switch between the two, to view (or set) by clicking the Profile option. Pete

FSUIPC doesn't lose settings. They are stored in your Modules folder, in the FSUIPC4.INI file. You should back it up (make a safe copy somewhere) in case any accident, such as a machine crash, corrupts it, but apeart from that nothing but your own actions should change it. And Profiles can't actually be deleted without editing the file itself. I expect they are still there and you are simply loading an aircraft variant which was not previously registered with a profile. Did you click the Profile option in the Buttons tab to see if you could assign it? If you are still puzzled, show me the INI file. You can paste its contents into a message here. Best to use the <> button just above the edit area to enclose it. Pete

Those are numbers. You add the value defined for THIRD_PARTY_EVENT_ID_MIN, earlier in the file to the number shown. i.e. for Captain's TFC, from your extract: #define EVT_EFIS_CPT_RANGE_TFC (THIRD_PARTY_EVENT_ID_MIN + 362) It's as it says, the numerical value of THIRD_PARTY_EVENT_ID_MIN plus the number 362. It was only a matter of looking! I can't do it for you, I don't currently have access to the file. Future questions about PMDG products are best directed the PMDG support forums., please. Pete

You'd need some spare buttons -- 4 for normal buttons, tilt down, tilt up, gain down, gain up. A title reset to set it level again) might be useful. Better than 4 buttons would be either two rotary encoders giving different button outputs when turned clockwise/CCW, or even two pots seen in FS as joystick axes and calibrated and scaled to give the correct ranges. (But I'd advise against the Pot method -- it isn't so predictable as increment/decrement methods). The only place I think you can assign them in Prosim737 is in the Analog section. They are called "Weather radar gain" and "weather radar tilt". Mine are assigned to and Unsigned byte offset in FSUIPC, and a Signed byte in FSUIPC, respectively, and I just make the buttons increment of decrement those bytes using assignments, in FSUIPC, to Offset controls. I don't remember the range offhand -- I'd need to switch my cockpit PC back on to look it up. As for what they mean, it is in the words. Title tilts the radar beam up or down so you can focus on water higher or lower than your aircraft (for climbs and descents). Gain is just turning the sensitivity up and down. Too high you'll get a whole screen in red showing dense water content, too low you lose the lesser parts of water bearing clouds. Pete

Sorry. I am not known for my patience, nor certainly am I by any stretch of the imagination a good teacher. I do hope, however, that folks can read, or if not get someone to read for them. ;-) It is not really programming at all, just matching words. Words like "Float32" for instance match in both the offsets list and the Lua function list. You can even use a "search" option to find these matches. There's also a simple guide to bits, bytes, words and so on in the FAQ subforum thread About bits numbers and hexadecimal Although there's more there than you need at present, it doesn't cover 32-bit floating point (FLOAT32 or just FLT) nor "double" -- 64-bit floating point (FLOAT64 or DOUBLE or just DBL). Pete

Er ... look. You've not even got the first point correct, reading the correct value types as I instructed and which should be really obvious: AoAindicator = ipc.readSW(0x2ED0) You are reading a 16 bit signed word (SW) for an offset clearly documented as a double (FLOAT64), which is obviously read using the ipc.readDBL function. You only had to look thngs up!!!! rollrate = ipc.readSD(0x0384) SD = signed DWORD. But this is documented as a 32-bit float (ipc.readFLT). And on it goes. You've apparently not bothered to look them up to ascertain what they are now what the correct functions are to read them! :-( Pete

That's the FSX MENU. And, no, PFC would not have been in the main menu, but it would have been in the Add-ons menu (drop-down) if and only if you were using one of the PFC DLLs I mentioned. But buttons wouldn't be assigned there -- the PFC DLLs have pre-determined uses for all the buttons and switches on the PFC devices they support. They look like standard Windows-recognised joysticks for which you wouldn't use any PFC DLLs. You can assign buttons in FS itself or in FSUIPC. If you don't understand FSUIPC, and can't read the User Guide, why not just do it all in FS? You'd need to have purchased FSUIPC to assign there in any case. Pete

Once the correct offset is found, there are really only two things to get right: 1. The TYPE of variable being read. Many of thoseI listed are 64-bit (double) floating point values. Only the flaps values are integers, in 16-bit unsigned "words". 2. The arithmetic, which is Lua follows standard maths rules, division (/) and multiplication (*) following left to right rule unless parentheses () are used. Junior school stuff. Just paste it into a message here. Pete

There's been no change in any of that part of FSUIPC since long long ago. In any case, all buttons, axes, POVs and sliders are read as one data set from DirectInput. There's no way to separate these. I've no idea what you mean by " the PFC-Button in the taskbar of the FSX isn't aivailable". What is this "PFC" button? Which "task bar" is this. I thought only Windows had a "task bar"? Are you talking about FSUIPC's "Buttons & Switches" tab, which is where you program buttons? There's no "PFC" button in any version of FSUIPC. PFC.DLL is only for FS9 and before, for the serial port PFC devices which need a driver. PFCFSX.DLL is for FSX and P3D, and again, only for PFC devices needing a driver -- neither are used for those devices which are in effect standard Windows joysticks. I don't have any of those, but documentation with your devices surely gave you instructions? Else maybe you need PFC support. There's also PFCHID.DLL which is for their more sophisticated consoles which have features not supported via the normal Windows joystick interface. Pete

Never heard of anything like that happening, and quite honestly I don't see any way it could at that stage. The joysticks are scanned initially, on loading, and (unless opted out) each time you enter the FSUIPC Options, but never whilst actually using the options. What I think is happening, and which is what is confusing you, is that you have these devices on 3 and 4: 3=Saitek Pro Flight Yoke 3.GUID={269DA5B0-18C3-11E0-8001-444553540000} 4=Saitek Pro Flight Quadrant 4.GUID={10B71790-2C2A-11E3-8001-444553540000} I think one or more of the buttons on your yoke is giving spurious "pressed" signals. Maybe its connection is bad, or the power it is getting is insufficient (it needs a powered hub I think, if not a good USB power from the PC). If neither of these things then it is faulty or just plain dirty. To test this theory, just temporarily unplug the yoke. (Remember which USB socket though). Pete

Well, it's a really bad idea to have ProSim on the desktop (or any application program really). . How are all of its subfolders managed there? Short cuts are fine there, but whole program structures? Ugh. Anyway, I can't help without data. In the same Modules folder you fond FSUIPC4.INI there will be a log file, FSUIPC4.LOG. Open that in a text editor and paste the whole content into a reply here. Also it might be as well to do the same with your FSUIPC4.INI file. Pete

Did you try searching the offsets list provided in your FSUIPC Documents folder at all? I found these pretty quickly: AoA (searched for "AoA"). same as "incidence alpha", offset 2ED0 Sideslip angle (searched for "side slip"), same as "incidence beta", offset 2ED8 Flaps in degrees: there's a whole set of theses for the different flap sections, see 30F0 - 30FE Roll rate (searched for "Roll"), offset 30B0 Yaw rate (searched for "yaw"), offset 30B8 Please do try using search facilities in your PDF viewer. They work quite well, though sometimes you need to think of alternative search words. As for force to move the controls, I don't think this is simulated at all. And surely it varies according to aircraft design. On many airliners these days is it simulated/generated in any case, not real. You'd need to derive it mostly from aircraft specifications I would have thought. Pete

Most everything in the NGX is switchable using PMDG's custom controls. You have to find it in their list of controls (it's in the .h file in the SDK which is installed with the NGX), and assign the number you come up with in FSUIPC as a <custom control>. I think the file is called PMDG_NGX_SDK.h. I don't use PMDG aircraft myself, but I did encounter this file when working on the support in FSUIPC for read-outs supplied (when enabled by the user) by the SDK -- hence the document about this installed in your FSUIPC Documents folder (within the Modules fold in P3D). I'm pretty sure there's a complete set of "EVT_EFIS ..." controls, one set for each EFIS (Capt & F.O.). I'm surprised you haven't already found any need to use any of the others for the rest of the EFIS and MCP functions. Or does the hardware come with a driver already programmed to use these control features in the NGX? Pete

There isn't such a function provided in FS itself, so there's no FS control for it. Are you using an add-on aircraft which has Traffic display for the ND? Pete

Okay. Thanks. The initialisation details show that everything is in order. It might be a bug in P3D3.1, but it works here in a later Beta for both FSUIPC button and FSUIPC keyboard assignments. It might be worth reporting it to L-M on their Forums in any case. As you've noted, it isn't anything in FSUIPC. FSUIPC does nothing different in P3D than it does in FSX.which worked well for you. Pete

Sorry, there is really nothing at all in FSUIPC which will interfere with EZDOK. And when it is running unregistered it is effectively doing nothing at all except servicing any applications asking it for data. You need to take your problem to EZDOK support. Pete

You've sent a continuation log instead of a normal initialisation log (why? Did you press "New Log" for a reason?). This removes a lot of essential initial logging which is always needed on any report. One of the things missing is the version number of P3D. If you are not using the current release, 3.1, then that could be the reason for the problem. I'm currently Beta testing a newer release and it definitely works fine in that. Pete

First, please look in this Forum near the very top of the entries, at the pinned thread entitled "P3D Version 3: FSUIPC menu entry not appearing". If you are talking about P3D version 3, is this applicable to you, and if so have you done what it advises? Otherwise, if that isn't applicable, or you've already tried it, look in the P3D subfolder called "Modules". Is there a text file called "FSUIPC4.LOG" there? If so please open it in a text editor (eg Notepad) and copy and paste its entire contents into a reply here. If there isn't such a file, the FSUIPC has not even been loaded. In that case please do the same for the file called "FSUIPC4 Install.Log". Pete

No, you are right. I was looking at it too simplistically. Pete

Another option would be for the plug-in to supply your function with the name of a variable it has previously defined which you could then change. Unfortunately that way doesn't allow events on changes so the variable would need testing n a loop or on a Timer event. Pete

Let me know which they are. If there's an FS control for it, then an offet isn't always justified. Controls can be sent by offsets too. I don't know what Eric has done -- maybe he's hacked into the Wiclo code, or maybe he's written code to handle internal variables using the Panels interface. In the latter case they might be L:variables, which you can access using FSUIPC macros or Lua plugins. If it was done by hacking then you'd need to be able to do that and write a program to make use of the findings. Pete

Ah, you should have mentioned SIOC. That makes it clearer. Yes, of course the FS9 avionics switch has an offset. Not sure what you mean by "thrust rating aso". But if, as you say, all of the switches in the Wilco add-on aircraft are actually also in FS -- i.e. there are no extra ones which FS doesn't provide itself -- then there is very likely to be an offset for it. Have you looked? There is a list installed in the FSUIPC Documents folder, or if not it's available in the FSUIPC SDK. If there are any switches in the Wilco aircraft which are not covered and do not have FS controls for them, if they are only accessible by mouse for instance, then there is no way really to use offsets directly. You'd need to have some sort of Lua plug-in or other program to interpret changes to user offsets (66C0-66FF are free for user applications) ad either invoke mouse macros or actually move and operate the mouse pointer. Pete

No, but the indication I would get from FS is a freeze followed by a flight reset. I don't see any on-screen notifications, most because I inhibit them but also because out of my cockpit window a lot of the outside view isn't in view without me specifically looking. If it is reproducible at the same airport & runway, then I'd suspect the scenery having an issue. If it isn't scenery or an AI collision (maybe from behind or unseen over to one side) then it has got to be an aircraft overstressed occurrence I think. In FSX and P3D the offset is protected from being written to by applications. If it is reproducible you could enable offset 0840 monitoring (FSUIPC Logging tab, right-hand side), logging changes to the FSUIPC4.LOG file -- that would show the SimConnect event occurring. Pete