Pete Dowson

Who is "Steve"? A lot more information is needed. Like: Are you using FSUIPC? If so what is the version number? FSX or P3D? Win7, Win8 or Win10? If using FSUIPC are the throttles assigned there or in FS/P3D? If assigned in FSUIPC, to which actual controls? And have you disabled controllers completely in FS/P3D? Are they calibrated in FSUIPC? Are you using profiles with different assignments or other settings for different aircraft? If you swap throttles over, say 1 and 2, does the symptom move to throttle 2? For answers to some of these questions, it might be quicker to show me your settings -- the SUIPC4.INI file from the Modules folder. Pete

No. As clearly documented in the Lua library document (in your FSUIPC documents folder), the parameters, which are supplied by the Event function (which knows nothing about engines) is (joy, button, downup) In other words, the same joystick and button numbers you entered into the Event, and a value saying whether the button was down, or up. Since you have no use for any of those in the code in the function there's no real point declaring them. Of course. In the assignment!!! I see both ( and ) for the Event function. Where on Earth are you looking? I suggest you look at examples. I'm not here to re-document everything that is already perfectly adequately described and documented. You need to think about helping yourself. Pete

You evidently missed the bit at the end, even though you quited it again: "don't assign anything to the button release parts in FSUIPC assignments." The Luas will need to be pre-loaded as I said. They'll just be sitting there waiting. Pete

The above is the quick and dirty way. Really you could also use a timer event instead of the loop and sleep, but try the above. Remember to put the joystick and button details in the event.button line, instead of the text I've put there, and think about a shorter time than 500. There are lots of examples of Lua plug-ins provided in the FSUIPC Documents folder, and more in the User Contributions subforum above. It is easy enough to get a better feel for doing these things. Pete

function ThrottleToIdle() while true do throttle1 = ipc.readSW(0x088c) if throttle1 >= 0 then break --exit when no more reverse end ipc.control(65964) -- 65964 = throttle1 incr. Use 65965 for smaller increment ipc.sleep(500) end end event.button(joystick nmuber or letter, button number , 2, "ThrottleToIdle")

I have to format that properly to understand it: while true do throttle1 = ipc.readSW(0x088c) if throttle1 >= 0 then break --exit when no more reverse end ipc.control(65964) -- 65964 = throttle1 incr. Use 65965 for smaller increment ipc.sleep(500) end I added an "end" at the end because you appear to have missed it out, hopefully only on the copy you made here. Sleeping for a whole half second seems rather extreme. How did you arrive at such a long gap? Just the time you want between throttle decrements? You could of course simply add a small number to offset 088C instead each time, or, probably more reliably for some add-on aircraft, use the Throttle1_set control instead with an increasing negative parameter. Most of all I think it would be better to have your Luas pre-loaded, via an [Auto] section (maybe profile specific), and use an event to trigger it instead. The event.button function with a "downup" parameter set to 2 (for release) is made for the job. Then don't assign anything to the button release parts in FSUIPC assignments. Pete

No. I am pretty sure RAAS doesn't use FSUIPC at all. I think RAAS pro is causing some error or strange state on the previous (otherwise good) session, and it is that state, the one we have no theory for at all, which then causes SimConnect to do strange things on the next load. This is probably why you posted this contradiction earlier: It is misleading when the crash on load is caused by a problem in the previous session. That is still something no one has any theories about. It makes no sense, especially when merely reinstalling FSUIPC "fixes" it. In one of the earlier reports some one found running a different installer, GSX I think it was, also "fixed" it, temporarily. I suspect any re-install of any P3D add-in (i.e. one affecting the DLL loading) would "fix" it. Though we did check that the DLL.XML file was idenntical before ad after, apart from the timestamp. Have you looked to see if there's an update to RAASPRO for P3D3.4 HF3? Pete

Without seeing the Lua code itself I couldn't really comment. The state of all buttons on a single device is sent in one USB message, as are the axis positions. Things like axis positions are rarely if ever missed -- depending on the FSUIPC polling rate (adjustable), and so buttons certainly won't be unless they are so transient they are only pressed for less than one scan interval -- maybe 1/20th to 1/50th of a second (I don't recall the default rate offhand). However, you are talking about the buttons being held on for reverse, then released, so transience is certainly not applicable. Once off they are off, and if previously noted as on the change will most certainly be noticed. Are there are 4 separate Lua scripts, one for each? Are they loaded each time, or are you using the event system to trigger on the button event? There are many ways of doing things. I would need to know more about what you are doing. Pete

I think there are other programs which can list them on a Networked PC, via SimConnect, like SuperTrafficboard, but whether it will list them all I don't know. Pete

Is that your only other add-on? No more DLLs or EXE's running? No Lua plug-ins running? From the crash results you are getting, none are from withing any FSUIPC code, so I can't really do anything. We need L-M on this. Pete

Hmm. That shows the previous good session closed properly, as least there was no crash caused by FSUIPC. So the fact that FSUIPC can't even run on your next load certainly implies something wrong elsewhere. With the previous errors of the same type, FSUIPC not being entered, the cause was always traced back to a previous crash on exit. No one could explain why crashing on exit made the next load fail -- it was even happening after a system re-boot. Whilst i managed, with LINDA, to finally reproduce the crash on exit I could never reproduce the crashes on the next load -- and nor could my colleague Thomas. It is extra mysterious why an FSUIPC reinstall, with no actual changes being made to anything in so doing (only the timestanp on the DLL.XML file would be affected) seems to make it okay for one more load. Note that one person with the problem often found it was okay on several subsequent reloads. It was unpredictable. It definitely still points to SimConnect, as it is that which calls the "DLLStart" function, which is the one at the offset of the crash. I notice that the FSUIPC log announces the FSUIPC4 version as 4.960a, which was corrected afterwards, though I appear to have uploaded the build just before. I don't think there was any other change, but just in case can you download the separate FSUIPC 4.961 (not the installer) from the Download Links subforum, and use that. i don't think it'll make any difference.

That is the same error which was occurring with 4.959, and which was fixed by the 4.96 release (and a couple of interim test releases beforehand), and also fixes to LINDA, which was involved. The crash on P3D reload is actually right at the entry point of FSUIPC (offset 1F145), so it isn't FSUIPC which is crashing, but SimConnect which appears to be trying to call it before it is loaded properly. The problem is caused by P3D crashing on a previous sesion when you exit the simulator. Please check the FSUIPC4.LOG file in your Modules folder -- you'll probably find it terminates incorrectly, with no closing. Show it too me, then use the Windows Event Viewer to find details of the P3D crash on Exit, which will be different from the above one (probably in NTDLL). If you are using LINDA see if it is okay without. And make sure you have updated LINDA -- it was changed to fix some problems which were instrumental in making this failure occur. Otherwise I need a list of the other things you are running -- add-ons, Lua plug-ins, etc. Pete

TrafficLook reads the TCAS tables provided by FSUIPC, it doesn't read the data direct from FS. The range is therefore limited to the TCAS range which is defaulted at 40 nm (quite normal on aircraft mounted TCAS systems), not the 80nm of the FS "reality bubble". There's also a limit on the total number of ground and airborne traffic the TCAS tables will hold -- 96 of each, but this limit isn't applying in your example. You can change the TCAS range in FSUIPC options. See the Miscellaneous tab, lower right, and the explanation in the User Guide (page 20). If you want to see the complete traffic list you can use the official Traffic Explorer, provided in the FS/P3D SDKs. Pete

Well, there has never been an "installer" for WideFS. For FSX and P3D the ONLY part of the Download ZIP file you use for WideFS is the WideClient.EXE program which runs on the client PC. There is no component at all to install on the FS PC. All you get when you purchase WideFS, as with FSUIPC, s a 12-character Key which is used in the FSUIPC installer to enable the WideServer part of FSUIPC. Even for the client on your other PC(s) there is no installer, just the EXE file which you place wherever you like. You may well create a short-cut icon for it, but that would be on the other PC(s), not on the FS PC. I'm afraid I cannot help you at all if you refuse to believe that I, as the author of these programs, is telling the truth! I repeat, all you need to do is rerun the FSUIPC installer and enter the registration details correctly when prompted. Those will be applied at the same time in both FS and P3D. The only WideFS related button in FSUIPC's options, once running FS or P3D, is the one to enable or disable it. That will only operate to enable WideServer if a proper registration has been applied via the Installer. And again, you should check that you are using a up-to-date version of FSUIPC. Version 4.961 is now the current release. Pete

There is no button to "Register WideFS". WideFS is registered in the Installer! There is no such thing as a separate WideFS installer, and no such message saying it is already installed! WideServer is part of FSUIPC4, and is registered in the installer. You seem very confused indeed. And make sure you are using a currently supported version of FSUIPC (version 4.960 or later). Read the installation and registration guide included in the download ZIP. Pete

I'm afraid FSUIPC only supports directly those VRI devices available to me at the time. As far as I know that covered all of their original serial port (COM) based devices. I don't know anything about their Overhead. I thought it had its own drivers, because there was never any further communication to me from VRI on new devices. I also thought it was a straightforward USB device, not a COM port one like the ones FSUIPC supports. If they've provided only support for the main two 737 add-ons for an overhead which is so obviously dedicated to the 737, I must say I don't blame them. Much of the 737 type overhead really isn't applicable to other aircraft. Maybe the LINDA add-on supports this device? If not, I'm sure you could program your own Lua plug-in for it, as it will almost certainly be a standard HID device. Pete

I use a little touch screen on a networked pc on which I use Widefs with ButtonScreen enabled. That gives me all the buttons I could need. A simpler alternative might be to get a Bluetooth keyboard pad. I've seen very small ones which would fit anywhere. Pete

Not really. As far as I know there's no way of selecting entries that way implemented in FS. Do you know differently? If so how do you do it? Pete

Email me on petedowson@btconnect.com and I'll reply with a test version attached with exactly that change. Please let me know ASAP please. Pete

You'll need to ask over at the FSL site. Maybe it's an L:Var (local panel variable), which would be readable (and writeable probably). As I said before, they do NOT use the offset at all. They are using the internal FS value, which FSUIPC exposes in that offset. Add-ons which don't use such FS internals won't normally be directly readable via offsets. Pete

Almost no add-on aircraft "use" any offsets at all these days. 0330 isn't an FSUIPC-set offset but a reflection of a value in FS called the "Kohlsman" setting, which is the name of the QNH adjustment used to set the altimeter to true altitude or flight levels, or QFE, as needed. All writing to 0330 does is make FSUIPC send the Kohlsman contros to FS, just as if you'd assigned to those instead either in FS or FSUIPC, and as they are assigned in the default gauges for when you click with a mouse. Many of the more sophisticated add-on aircraft, like the PMDG 777X and 737NGX, and the FSL Concorde, do bot use the normal FS instrumentation or internal values, but program their own. I would think that the FSL Airbus is of that same class. You'll need to find the correct way to adjust your altimeter with whatever facilities they provide. Pete

That explains why no one else came across this P3D bug. I think KTS is pretty universally used, except it seems in Russia! I suppose you found that the RVR data you are supplying does nothing in either FSX or P3D? It's probably discarded. I think you can only set the general visibility, your 9999. Anyway, I'll report the bug it to L-M with the details. Thanks! Pete

I don't know. Certainly if PE has to freeze the process to do it. Though perhaps if it does it every second there's less change and therefore less totting up to do. I really don't know how it works internally. Are you measuring longer frames every second with PE doing the monitoring? If not then try setting the OOMcheckInterval in FSUIPC to 1 (though I'm not sure I let it be set lower than 10). If doing the OOMcheck in a separate thread would help, I could do that relatively easily. Off now till tomorrow -- visiting eldest's family. Pete

Er, sorry. I don't really understand what you are asking. Pete

I just went right through the documented METAR write format and tried to make one of your strings look right according to the 'rules'. This was the result I then tried using: "EGLL METAR 271700Z 320002MPS 9999M R24R/5203FT R24L/420340 SCT006 OVC019 -02/-03 Q1021" But, alas, this still crashed P3D. I do recall, back 10 years ago when I implemented the NWI, finding that the METAR documentation in the SimConnect SDK was not good enough. It omits to say some stuff, or says things are optional when they are not, and even has some things totally wrong. Unfortunately i simply don't remember any of those details these days. So, I think the next step would be to use the FSUIPC NWI facilities to set the weather, and see what that produces. It does convert the binary data set you write into a proper SimConnect METAR string which should surely still work. With Weather Logging you can see what it sends and whether that is successful. I won't have time to do this now till at least tomorrow, maybe later, so please do try this yourself and let me know. When I report the problems to L-M, as I shall tomorrow in any case, I will want to mention that the documentation is (still) sorely lacking. In fact I think it's just a copy of the original FSX stuff, just with "FSX" replaced by "P3D". Pete