Pete Dowson

FSUIPC5 is not FSUIPC4. It needs a new purchased registration key! Pete

Ah, you don't have the aircraft yourself? Sorry. Pete

Sorry, but if they were calibrated for P3Dv3 then I think you did. The picture you showed for P3Dv3 has no throttles calibrated! Just press any of the SET buttons and the other options become available. Without a calibration entry FSUIPC has nothing to associated the NRZ option to. There's no difference whatsover between FSUIPC4 and FSUIPC5 in this area, only a 32- to 64- bit conversion. The real 64 bit changes lie elsewhere. It's the INI file, not INF. Pete

If this is on the same PC with the same connections, then you could have simple copied over your FSUIPC4.INI and renamed it FSUIPC5.INI. The -4096 value is the maximum REVERSE thrust. The range down to -16384 is only for throttles being calibrated with "No Reverse Zone" (a checkbox on the screen, top left -- see your pix). If you want identical behavious between FSUIPC4 and FSUIPC5, best use the same settings! :-) Pete

Probably the USB settings are wrong, with Windows power management turn on. Go to Windows Device Manager, find all the USB hubs and devices listed, right click on each, and if there's a tab or option for power management, make sure it is turned off. I suspect all you actually needed to do is go into the axis Assignments tab, and select the "reload" button. I think that would achieve the same thing more reliably and speedily, because all that will be happening is that use of the settings is causing a re-scan of the devices, which wakes them up. FSUIPC won't be "losing any settings" -- they are reliably recorded for you in the INI file. It's just that the device is not able to measure the axis positions because of lack of USB power. This doesn't affect buttons, which basically just send a simple "press" or "release" signal back, needing only enough power for the USB interface chippery. Pete

No one has any knowledge of anything new without looking for it. Did you have any knowledge of flight or flight simulators before you started looking? And look, you are very advanced, a cockpit using ProSim. That's far beyond many folks "knowledge", even many programmers and computer specialists. Most folks in the world in fact! The offsets for "on ground" and "ground speed" are easily found in the Offsets Status listing in your FSUIPC documents folder. The Lua functions required won't be many and they are documented in the Lua library document, also in that folder. There are plenty of examples of Lua plug-ins to look at in the Zip in the FSUIPC Documents folder, to see how to put them together. The wave file(s) for the sound you'd need to find for yourself, or record your own. I think by "I can not write something like that" I think you actually mean "I can't be bothered". Right? And that is fair enough. It's your choice, and for something as trivial and non-essential as a ground bumping noise, I can understand that it is easy to just give up. :-) Enjoy good flying, nevertheless! Pete

Sounds like you have the autorudder option set in P3D. nothing in FSUIPC does such things. The autorudder option is aimed at folks without rudder pedals. Pete

Not directly. You can tell from offsets whether you are the ground and what your ground speed is, but not easily whether you are on a runway (that would need location checked against a database). However, I suspect at taxi speeds you could use a slightly lesser bump sound. You'd need to program a small Lua plug-in which reads the offsets and plays wave files as appropriate,.You read offsets using the ipc library and play sounds using the sound library. Pete

You need to state FSUIPC version! If you mean FSUIPC5 then mouse macros aren’t yet supported, which is why they are not documented. Pete

By "current FSUIPC eindow" what do you mean. All registration is done in the Installer, same place for both FSUIPC and WideFS. That's only for FSUIPC5. Do you already have a WideFS7 registration from FSUIPC4 days? If so, use the same email and WideFS registration key you used with the FSUIPC4 installer. Pete

Well, if you are right about the value you mentioned, I would guess so. But possibly there are some alighment issues. If so it may be that the brake pressure needle is not at 65ED but 65EF, and everything later is 4 bytes further. I don't recall offhand whether there are any such issues, but I don't think so, else I don't think I'd have arrived at 65ED in the first place, it being an odd value for a WORD. So, I would expect just the 2 byte, yes. But just checking the flight number or whatever, right at the end, should show immediately. I think that's the way I checked back with the original NGX long ago. Pete

Sorry, I'm don't understand. Whatis this log from? What does it mean? and here: That makes no sense if you are only using the event, as it only supplies TRUE or FALSE, there are no 0, 1 ,2 ,,3 values! Please explain what YOU think that log is showing. Pete

P.S. Is it possible for you to check that the last few entries in that section of offsets (i.e. 6C8C - 6C94) would be correct if they were 2 bytes up. i.e. 6C8E, 6C92, 6C96? Please? Thanks, Pete

Well, that's astonishing! You have something very wrong somewhere. Here, on several different systems, it is not possible to see any difference between the speed at which the FSUIPC assignment operates and the direct assignment in FS. And after all, the exact same control, "PAN VIEW" is used in both cases. Have you checked that it isn't a problem with the device? Does it work fast if you assign in FS instead? Are you checking it on a default aircraft, in case it is a problem with an add-on aircraft? In case it is a problem with your assignment in FSUIPC, please show me your FSUIPC4.INI file (or are you using P3D4? If so it's the FSUIPC5.INI). From the Modules folder. There's no real inoformation in your post. Please ALWAYS state both the version of FS and the version of FSUIPC. In fact, if it isn't the latest supported version, please update first and re-check. Pete

Sorry, I've no idea about C#, and really cannot do the programming for you. I can answer specific questions about FSUIPC and its offsets, but first you need to find them in the Offsets Status document (in your FSUIPC Documents subfolder) and read what it says about them. Are you using Paul Henty's .NET DLL for your application? Because you should. It makes things easier for such languages. And he has his own support in a subforum above. Pete

What document are you looking at? Here, my copy reads like this: Rain Protection 64F8 2 BYTE x 2 APU_annunLOW_OIL_PRESSURE 64FA 2 BYTE x 2 APU_annunFAULT 64FC 2 BYTE x 2 APU_annunOVERSPEED Ah, thanks! I have never been able to check the offsets myself, being dependent upon folks who have the 747 and can actually make it load. All feedback before this has said they were okay. Rather surprising no one has mentioned this one all this time! Any others, after that, at all? Pete

event.comconnect, not event.devconnect. Did I document it wrongly? Let me check ... oops! Yes I did. Sorry! Too hasty with documentation. Never did like doing it. Not fun like programming! Will fix that immediately! Pete

FSUIPC 4.971b and 5.121c are now released -- see Download Links. The Lua facilities to check HID device connection status have been added.

Possibly. Are your other views docked or undocked? Multiple windowed views are all part of the FS process. It's a long time ago when that option was implemented, but I think that what it does is switch focus back to FS itself when it currently is on another process altogether. The keyboard focus actually needed for FS to receive the keypresses is the FS window procedure within FS, of class "FS98MAIN", which processes all Windows messages. It is to that "main window" which the keyboard focus is changed IF it isn't already there. So, tell me, are you sending keypresses to FS for it to process which it isn't processing because of focus being elsewhere? Oh, BTW, that option is much older than "early 4.x", ;-) Pete

I think it does mention that only one event is queued. Here at least: But note that, whilst FSUIPC does keep track of separate events, it does not queue multiple identical events. If a button is pressed 20 times before you process it, you only see it once. Therefore if you are monitoring things which can happen repetitively you will need to keep your processing short enough if you hope to catch them all. I know that doesn't mention the com problem at all, but then there's this in the description of event.com: Your program doesn’t need to perform any reads itself, thought there’s nothing stopping it—and it may be wise if there’s more expected And this in the com.readlast description: This function might be useful in polling situations where the rate at which data arrives might exceed the polling rate or capabilities of the Lua system. HID joysticks scanning is a prime example. Rather than process older records and get a larger unwanted lag that is necessary it enables an efficient way of only processing the most recently received state. Maybe a note added there to say "but if you want to process all of the inputs piled up, loop using com.read, do not use com.readlast". Is that the sort of thing you wantr? Pete

How curious. I can only think that the full screen window position and size values are given in units corresponding to one resolution, and the the other resolution for the Windowed alternative. I don't think I can automatically cope with that! However, if that's the only cause of the problem I may default to "Yes" for the FSUIPC rather than "No" and just have advice to disable it if it isn't working correctly on the way your system is set up. I will have the interim update ready tomorrow. Check the "download Links" subforum above in the afternoon. It will be version 5.121c. Pete the

That would be nice, I suppose, but very messy to implement in FSUIPC, and, I think not really worth it. To do that it would have divide up the incoming comms data stream into the requsite length chunks, and build up a queue of events which refer to this data, maybe re-buffering it, of possibly unlimited length, and deliver them one at a time. And each time it has to wait for the current actions of the plug-in to finish, so it goes dormant, and then wake it up again. That could make your actions even for dislocated for the triggering events. The would also be against the entire method currently used for the event system. There's only ever a maximum of one outstanding event per type of event, per plug-in. Pete

Ah, that's interesting. I'll check here. FSUIPC's latest (since 5.121 actually) does not actually SET the position of that Window in anything but full screen mode. So what is likely happening is that P3D is trying to draw it in the position it should have been -- ie. starting much further to the left on the actual screen, butcannot set the left border outside its now smaller window. But why anything changed with 4.1 compared to 4.0 I don't know. Can you go into full screen mode, please, and there change that display to whatever you want -- wider, taller, in a different position. That should work and be saved. I'm not sure I can do anything about Windowed mode though. How often do you swith between them? If a lot then I think you will need to wait for my interim updte, then disable the facility. I tend to only use P3D in full screen mode, and I implemented the facility (which was requested) because it was so irritating that whenever I moved the windows to where I could read them, and AWAY from messing up the main forward view, from my cockpit window, next time I loaded P3D it was back to its normal place and size! I only go into Windowed mode to access other programs, returning to full screen afterwards. Pete

By "variable" I take it you mean "control", as otherwise the above makes no sense. I do not use or have PMDG aircraft, so I can't really help specifically, but I'm pretty sure that there's only one PMDG control for each function. You use the parameter to it to tell it what it is you want to do. I think it emulates what the mouse would do. With PMDG dials, don't you get a little mouse cursor indicating turning, and you then use the left button for decrement and right for increment? The controls are similar. I would have thought you'd already encountered this for things like MCP speed, altitude, V/S etc. The parameters are not simple 0's and 1's. I think that .h file has a list of values equating to different mouse actions. Take a look. Pete

You need the Protocol parameter as well -- with broadcasting it gets told the protocol by the Server (which can be overridden by the local parameter). But without broadcasts it definitely needs both IP Address (or Name) AND Protocol. It won't work with just one of those. (This too is as per documentation). I don't know why elevating it stops it receiving broadcasts. That seems a bit strange. Pete