Pete Dowson

No. You'll be fine. The only reason you need to re-run the installer is in order to enter your WideFs registration key. It will also update your FSUIPC if you are using a later installer. Pete

How interesting. Is it available as an axis in MSFS itself? It has never been so through SimConnect, so if it is in MSFS then it's yet another control they've not yet implemented an interface for. It would need requesting via Zendesk. Pete

Carb heat is either on or off. Are you seeing an adjustable heating on the aircraft? It's basically just an on/off valve which is opened to send hot air to prevent carb icing, or de-ice it when it gets iced. So you want a switch, button, or keypress assigned to it, Pete

Hi Pelle That requirement was removed some time ago (don't remember when, but probably FSUIPC4 -- because it was assumed new applications would use SimConnect directly rather than indirectly through FSUIPC). The overhead of ennumerating all running processes to identify the caller for every offset access was becoming too much, especially with modern multi-cored CPUs. and folks running large numbers of processes. We now just have to trust that makers of commercial products using FSUIPC will contact us first and agree an arrangement. Mostly that happened, but there are some notable exceptions. Pete

You should not mix assignments between P3D and FSUIPC. Use one or the other. If assigning in FSUIPC, disable controllers completely in P3D (there's an option in P3D to do this). If you don't you will get interference. I think the PMDG aircraft are designed in such a way that reverse control does not work well on an axis. Most folks use the "THROTTLEn DECR" controls to engage reverse after reducing thrust to idle on the throttle. If you want to use separate levers for reversers then you can try assigning the forward thrust throttle levers to the normal "AXIS THROTTLEn SET" controls, and either don't calibrate (calibration can mess up things with PMDG aircraft), or if you try calibration in FSUIPC set the "No reverse zone" option so the whole axis is for forward thrust. Reversers can then be assigned the FSUIPC-added controls "REVERSERn". Pete

If you start it again (eg via a keypress assignment to "lua <name>", the currently running on will be killed and your amended one loaded. It's as simple as that. If you only want to kill it without running it again, just have an assignment to "luakill <name>". The assignable controls for a lua plug-in are actually documented! Please see the PDF entitled FSUIPC Lua Plug-Ins. You evidently haven't yet used FSUIPC very much yet? All the assignable controls are listed, in alphabetic order, in the drop-downs for button, keypress and axis assignment. This is a fundamental part of the reason folks use FSUIPC! FSUIPC is well documented in the User Guide provided, and the Lua part has its own documents too. You will find lots of useful information if you look. Also there are a lot of additional contributions from users in the User Contributions sub forum above. Pete

It was reserved for a presumed 64-bit version of FSX which looked like being on the cards at one time -- but that was the aborted FSW which turned out to be anything but an FS development in any case. I suppose we could have used that slot for MSFS, which really shouldn't really be known as FS2020 (and isn't called that), as MS intend for it to be developed over more than the one year or so FSW95, FS2000, FS2002, FS2004 and, really, FSX (FS2006?) were, prior to FSX-SE. Pete

No. My N-gauge model railway is controlled via a working Commodore Amiga from the same era. Pete

So you did have it running with Flight Simulator? I doubt that Project Magenta supported that device -- in my experience PM did not support any specific hardware. I think you must have had some other drivers. Whilst that is far from cheap, there are a lot of X-Plane users to advertise to. BTW the subject of your thread ("cockbit") doesn't in any way describe what the subject is, so you are very unlikely indeed to get any other contributions, possibly missing on help from folks who know more about this. You should always entitle posts in a way which will attract contributions from folks who might help with the problem. So, don't advertise your G1000 for sale as "cockbit" or you will likely be out of luck! 😉 Pete

I assume correcting the error John spotted didn't help? Though I never dreamed anyone using FSX or later and FSUIPC would still be using WinXP, it it probably a good idea. But not specifically WinXP, also all the other old Windows versions. I started on my software back in Windows 3 days. Before that I was using non-Windows systems. I'll probably just say that no version of FSUIPC4 is supported on any version of Windows before Windows 7, and will probably not work on such versions in any case. How's that? Pete

That hardware is a lot later than anything I was involved with in PFC, and won't be recognised by any of my drivers. You'd need a driver from PFC. I suspect they only support XPlane these days? That just shows that it is a proper HID device. The PFCHid log would show if it was recognised there. But even if it sees the buttons, which is unlikely, if it features a display (as a G1000 should) then that wouldn't be supported in any case. Pete

Good spot John! I missed that. Dad

Evidently it needs something missing in WinXP. I'm not really surprised. Why "stuck"? Use 4.974. Pete

I see Thomas has seen that you did not register WideFS in FSUIPC7, which is why the log shows: Best always to check the log for error and other indications when you have a problem. Glad you are now sorted. Pete

Sorry, but your two log extracts are identical for both operations! The term "event" comes from the format names given to controls by SimConnect: "KEY_EVENTS" are controls normally assigned to keys or buttons, whether in FSUIPC or in the Sim. FSUIPC always used the term "control", historically, because these things were always tabulated in an FS module called "controls.dll". So, the terms event and control are interchangeable. A single "HEADING_BUG_INC" should increment by 1 degree, but it can be accelerated to operate in 10's if several such controls/events are sent in a short time, like a second. This is part of the automatic control acceleration applied by FS when a button or key is held to repeat. It's a built-in facility to allow larger changes to be made without it taking all day! Pete

WideClient works fine in conjunction with FSUIPC7. The WideFS part has not changed. Why do you think that it isn't working? Have you tried? Pete

As well as what John says, you should note that one "click" will be either a button 'press' or a button 'release'. So for action on every click you need not only a suitable polling rate, but also the same assignment to both button press and button release. But you don't want the 'repeat' option because the last 'click' may have left it 'pressed'. Pete

Well, I don't know either. If you didn't invent those names yourself, where did you find them and what do you think they do? If you identified where you got this stuff from them then maybe you'll find more information about them and how to use them in the same place? Pete

Which "time" do you want? The windows systems time, the one set on your PC. Or the time in the Sim? There's an "absolute time" (!!) which is probably the former, as a double in offset 0230. Local FS time and the related Zulu is given in other offsets nearby. The time in the Operating System, no matter which, is provided by the Lua os library function os.time. Most (all in most cases) of the functions in the standard Lua libraries are included in the FSUIPC interpreter, as documented in the Lua PDF provided. For Lua standard library functions please refer to Lua.org (or buy the book! 😉 ) There is a also the elapsed time since FSUIPC was started (ipc.elapsedtime) but I don't think that's what you wanted. Pete

Thomas is looking into that. I think he's determined that the problem may be identical that way too. But tomorrow we shall move further on this. Sorry, it's been a busy weekend for other reasons, not related to FSUIPC. Sorry, please be patient. We'll get to the bottom of this. I'm sure there's a logical reason, it is just trying to understand what could affect Elevator but not the other controls when they appear to be treated identically. Pete

Are you using Sim-Avionics? If so is that software running whilst you've been doing these tests? Pete

Well, this is certainly what your reported results suggest. But the strange thing then is that the code is the same. In fact the code which decides which of the inputs 'wins' is the same for the elevator, aileron, rudders and both toe brakes. It's table driven -- there's no specific code for any one of those. So I'm finding it very puzzling. We will investigate. First, please confirm this occurs with ALL aircraft (all those you've tried), including at least one default. Pete

Your Lua script calls a function called "DspShow" here: function B17_Eng1_restart () ipc.writeLvar("L:Feather1Switch", 0) DspShow("Fthr", "1 off") So, where is that function defined? It appears to be missing in your script, which is why you get a compilation error! Pete

Rather a waste of time showing me the INI file then! 😞 That's rather poor! Thomas recently converted my PFC yoke to hall effect sensors via Bodnar boards, and I get the full range I'd expect. I think you must have used the wrong impedance values. My yoke was an original PFC serial port one, via its controller board -- my complete cockpit was originally supplied by PFC. No. The delta value in FSUIPC assignments for axes causes any change less than a certain value to be ignored. The normal delta is 256, which works well. You don't appear to have changed that (it's the 256 in the INI assignment lines). Pete

I don't recall which is which, but the flatter centre is the one with the flatter (more horizontal) centre, so set it visually. Pete