Pete Dowson

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

I think when you ask Windows for such information, it has to go into a loop adding up the memory for each individual block, and also remembering the largest. If may even concatenate adjacent free ones at the same time, but I'm not sure about that. I might consider putting the OOMcheck facility into a separate thread. I'm not sure that will help, though, because I suspect Windows has to freeze memory allocation (and freeing) while it counts up, and that probably freezes the whole process. Pete

Okay. Yes, it most definitely is a bug in L-M. Not sure why it affects the sorts of METAR strings you are sending and not those that FSUIPC and programs like Active Sky send successfully, but I think it must be due to something not abiding by the "rules" for the strings set out in the SimConnect SDK documentation. I'll report it to them saying if the string is in error then the erroneous parts should be ignored or signalled in the log, but should never cause a crash. Meanwhile, I think it would be a good idea to examine your METAR strings in relation to the documentation. It may just be that whereas FSX is lax in checking, ignoring errors, P3D is checking -- but then going wrong when it finds an error. Of course it shouldn't crash, that's a bug, but if you want to find a solution meanwhile, check against the documentated allowed formats. I might try to do this too. Pete

Ah, 10 seconds is a good clue. There's nothing requested from SimConnect which is that long an interval. Try disabling the OOM checking. That asks Windows to supply the free memory and the maximum free block every 10 seconds. You can change that using the "OOMcheckInterval" parameter (it's in seconds), or disable it altogether using "OOMcheck=No". The only other one is the broadcasts by WindeServer to tell clients it is there. You can turn that off in the [WideServer] options with "AdvertiseService=No". If you don't use WideFS that won't be happening anyway (and your default INI won't have it enabled in any case). Pete

Ah, I forgot you said it was okay in FSX. So that does indicate that it may be a P3D bug. I'll use your strings here and what response I get. If it looks like a P3D bug I'll report it to L-M. Pete

First of all please update to the currently supported version, 4.96. What do you mean "many before the write"£. What do you do with the strings that you don't write? This makes no sense to me. Anyway, I don't think your strings are in the correct format for sending to SimConnect. It doesn't use standard METAR notation, but a variation of it. You need to refer to the SimConnect SDK details for the correct formatting. I'll try to help when I have some time. Maybe I can correct one of your examples for you. But another way would be to examine the SimConnect log file with a working weather program running, or just when using FSUIPC's own NWI weather interface, which does the conversions into the correct format for you. If you use the FSUIPC facilities the Weather Logging in FSUIPC's Logging options will show what it is writing, (and reading) in the FSUIPC log file. Note that the SimConnect reading and writing formats aren't quite the same. They are very different for upper wind and temperature layers, for instance. Pete

What are you using FSUIPC for? What is does depends on what it is asked to do. What is the frequency of these "longer frames"? (Sorry, I can't read the data on your pictures. Why didn't you simply cut and paste the text?) FSUIPC is receiving changes to the data is provides to applications every time it changes, and the timing of that is up to whatever changes the data. Obviously things like the time changes every second, so that's one data item per second. When flying many things are changing much more, many at least every frame. FSUIPC asks SimConnect to send data when it has changed by a certain amount, or more (the "delta" in order to cut down -- after all many values aren't needed on every miniscule change. This has been finely tuned over the years to give the best results in terms of both performance and smoothness. To discover if it is SimConnect supplying data which is worrying you, try enabling SimCcnnect logging and see if the log timings match your occasional longer frames. Take care, a verbose SimConnect log gets very very big! The only other things done would bt button and joystick axis scanning, but with a default settings file that won't be happening as there will be no assignments. BTW whenever you submit a question or problem I need to know the VERSION numbers of both FSUIPC and FS! Pete

As I said, I never had success over wireless either, though they did connect, with difficulty. The problem is that WideFS needs continuous connection and you often just don't get that with wireless. It's okay for most ordinary data access. It isn't the capacity which is the problem, just the continuity. Did you ever test it with a wired connection instead? Pete