Pete Dowson

I for one don't understand. You say: But what folder did you tell the Installer to put FSUIPC6 into (which of course will be where the INI file would go)? Normally the Add-Ons folders are just for the Add-On.xml files telling P3D to load the program, though I know a lot of folks just let all their add-ons install there too, so allowing the system drive to grow and grow. This part i'm afraid I'll have to leave for John, as I don't know how the new Installer detects your registered user "Documents" folder, because it there there where the Add-on XML should go. For added information, where does the "Documents" entry in the "This PC" section of the Explorer take you? I thought it always took you to the Users\<user name>\Documents folder, which is certainly where all other programs looking for document-installed files would go. So, in your case, C:\Users\Terry\Documents seems to be the correct place, and in fact must exist. What is your "D:\My Documents" doing, and how is that accessed as the 'official' place? You see how this appears rather confused? I think you may be confusing Windows, which in turn could affect many installers and other programs. I'd be very interested to know how P3D knows to look in an unofficial place for the add-on.xml files, or, indeed, to save and retrieve scenario files. Pete

You posted this in the FAQ subforum, one clearly marked, in red, "Not for support requests". Please always post in the correct place! You really need a weather control program such as Active Sky, or an Instructor Station program like FS-Flightcontrol. Setting weather in FSX should work, but you'd need to set it at all local weather stations AND stop weather changes (a slider in the options). But the job is a lot easier and more reliable using an external program. For more specific answers you should ask such a general FSX question in one of the FSX Forums, such as the one on AVSIM. This Forum is for specific support for FSUIPC and WideFS. Pete

This sounds like the occasional flicker problem others have reported with P3D5 (including parts such as the menu bar, when displayed). I think Thomas has seen it with the menu. I am just lucky I suppose, having never seen such a problem. I think he said it seemed to be fixed with the HF2 update (Thomas?). Are you using the Enhanced Atmospherics in P3D5 by any chance ("TrueSky")? I'm not (because the effects are not good for airliner flying, totally unrealistic from above but okay below). Maybe those who get the flashing windows (whatever they are) are using this Beta facility? To narrow it down, try changing some of the settings in P3D, and maybe run it in a different mode -- Windowed / Full screen, just to see if such things have an effect. I think it needs reporting to L-M but it probably needs some supporting information. As an added puzzle it does seem odd that the flickering only starts after a few minutes. I wonder if it is, therefore, related to the GPU VRAM texture optimisation L-M added for HF1, which is still in HF2 of course. So, also try with "Dynamic Texture Streaming" turned off. Pete

As John says, they certainly indicate serious corruption in memory. They are errors reported by SimConnect, saying that all those built-in Key Events ("controls") are unknown! The only type of memory corruption we are aware of which is sometimes only detectable when FSUIPC is running is caused by bad weather files: the wxstationlist.bin in the P3D AppData folder, and/or one or more of the .wx files in the P3D Documents folder. These are binary files which are read unchecked by SimConnect when FSUIPC asks for weather details. This is why the "NoWeatherAtAll=Yes" parameter, in the [General] section of the FSUIPC INI file, helps, as it stops FSUIPC asking SimConnect for the weather data (and stops providing applications any weather data as a consequence). If that step is no longer working, then something else is causing the corruption. Maybe something else you have running is reading the weather. Obviously getting FSUIPC to stop asking for weather won't affect them. So, there are two possible paths for you to follow: 1. Start P3D with no add-ons at all. Disable them all. Then add them back one at a time. It may be that something you are running is not compatible with HF2. 2. Try deleting that wxstationlist.bin file and all of the .wx files. Note that there is no way the simple update from HF1 to HF2 would make this happen except for the possibility of an incompatible addon (even addon scenery). Pete

The form "!number=" is a way of incorporating comments into fixed positions in the file. I don't know how you got one on a section title -- I can only think there were, somehow, two copies of it so one was "marked out". No. Delete the !1= section altogether to avoid any future confusion, but best first to briefly scan through it to ensure you are not losing anything important you may have once set which isn't also set in the operating section. Pete

Good flying!

One definite problem is that you are running the original version of FSX, the bug-ridden one which was subject to two major updates, SP1 and SP2 before Microsoft abandoned it. You really do need to update to at least SP1, but instead go to SP2 whilst you are about it. This problem is actually made worse because you appear to have installed all three versions of SimConnect -- not only the original one released with and installed by the original FSX release, but also the SP1 and SP2 versions. Naturally FSUIPC will try to use the latest one you have installed which won't be compatible. Note that after DoveTail Games gave up developing FSX (as FSX-SE, the "Steam Edition") Microsoft took it up once more and not long ago released another version. So you are really well out of date. After getting things updated (either to SP2, or to FSX-SE which would be even better and much improved), when you try again, if you still have a problem please not only povide the Install Log but also see if the run-time log is there, FSUIPC4.LOG. Because if FSUIPC even attempts to run, it will be there too. Don't try FSUIPC4_Loader. That was only to get around an incompatibility in loading order with a couple of other old add-ons. Pete

Okay. With the interlock implemented and your modified Lua script I have had it running with the 100 threads for over 60 minutes now and no failures of either type. I'll provide the mods to John to incorporate in the next update. I'll release a WideClient update withig the next day or two. John may want you to verify the build with an interim update before he releases it. Pete

John agreed to put it into FSUIPC6, at least, so i've done the code change to test, and used your original Lua script above to try to force a fail. It got to having the 100 test Luas running but my PC (a 7700 running at 5GHz) was by then so sluggish with so many threads running that I turfed it off. How many did you get to before it failed, typically? And what do you expect the loop at the end to do (the loop forever reading a global called "myvar" which was never written)? If this is a good test I'll send the change to John for including in the next release. Pete

Not so peculiar. The addon.xml file is NOT necessarily where FSUIPC6 and its files are. Those xml files are to inform P3d about the add on so it will enable it. FSUIPC6.DLL will be in the folder you told the installer to install it in. The FSUIPC6.LOG, FSUIPC6.INI and any other files you make or use (macros files, Lua plug-ins) will all be there, alongside FSUIPC6 itself. Pete

Ah, I see. Thank you. I wouln't have implemented them as they are because they are used in every reference to the Lua stack. Since in the FSUIPC/WideClient implementation each Lua thread is separate except for the common use of the 'global' stack, it is only for the "get" and "put2 operations than the interlocak is needed. I'll mention it to John, see if he would like to implement this safety measure in FSUIPC6. Pete

Or, as I more usually do, just put the push and pop calls into their own critical section, preventing thread swapping in the Lua code doing the push and pop. However, the Lua push and pop functions already have locks on them (lua_lock and lua_unlock calls either end) so I never thought it necessary. However, looking through the source I see this: #ifndef lua_lock #define lua_lock(L) ((void) 0) #define lua_unlock(L) ((void) 0) #endif which is very strange. I'd not actually believed they did nothing! I wonder why they aren't used. I'm very puzzled. They are used in a huge number of places. Maybe it's something to do with efficiency v reliability? Pete

You posted th sae message last Saturday and I replied then. Please do not keep reposting the same question. Read the answers and respond to those instead!!

Can you understand enought of that to explain what is happening then? If that source reconstructed (in a debugger?) from our binary or located some other way? Do you have the Windows crash information? Version 6.08 of FSUIPC? Or WideClient? I'm still not sure what I can do about it. Pete

Can you explain your thinking? FSUIPC is just using the facilities in Lua combined with those for threading in Windows. Yes, a global variable can be "set" in one thread whilst it is being "read" in another. A timing difference of a few milliseconds can make a difference. But this can occur in any case. If you were getting partially wrong values -- part of a variable being written whilst part was being read, i could understand your concern -- wrong values. But as this isn't the case, what is your thinking? I don't really see how any such problems could cause access violation crashes. BTW what happened between the 8th January and now? Been on a long holiday? 🙂 Pete

No, FSUIPC follows the GUIDs. Sometimes Windows will assign things differently. This normally only happens after a re-install, but also occasionally because different USB sockets are used. The Autoassigning action operates when a new device (additional ID number and/or GUID) appears, as when you add devices. Pete

Does VRI offer no support now? Sorry, i don't know what else to advise. I expect that if the devices are working that it would be possible to write a driver for them, ignoring the incompatible VRI drivers, but that is a real project -- and one to be undertaken by a programmer with access to those (I assume) discontinued devices. At present your best bet is VRI. Pete

There's no built-in support for VRI devices in WideFS or in the Lua library. WideClient does support the COM library (as documented in the Lua Library document), so you could program the business of reading and writing from and to the VRI devices, but it would be a full blown programming job. Have you tried the older driver, SerialFP2? Perhaps that isn't using things messed up by Win10. I know the COM port code in FSUIPC is good under Win10 as I use it quite extensively for my PFC cockpit hardware and Cockpitsonic forward overhead. Also with a COM port based Aerosoft (Australia) Piper Arrow III cockpit. That's on two different PCs, one running vwesion 2004 of Win10 and the other 1909, both fully updated. Pete

The Lua sequence would simply have three parts: First action Delay Second action For example, sending controls: ipc.control(control number, parameter) --send first control ipc.sleep(2000) --wait for 2 seconds ipc.control(control number, parameter) --send second control The control numbers are listed in the List of Controls document provided (or, for FSUIPC added controls, near the end of the Advanced Users document). There are many other things you can do instead of sending controls -- eg key presses. See the Lua library document. Save the Lua script as a file (eg "twoactions.lua") into the FSUIPC folder. Then assign your button to Lua twoactions, which will appear in the assignments dropdown after you use the "reload" option on the button assignments option tab. Pete

Ah ... are you sure the FSUIPC facilities work with it? I only ever saw SerialFP2. I thought the later software replaced all this need for FSUIPC involvemet, that they supported the devices properly? Yes, I see that. but there's something wrong with what is transferred to them from your VRI driver. Sorry, I dodn't know what to advise. Surely somthing must have changed a few days ago to make your results change. You need to determine what that was so it can be rectified. Harware problem, COM port or driver? A bad Windows update? Pete

No, not really. We haven't had any experience with the original COM port series of VRI devices since way back when they were still current. Is VRSim the current driver? What has changed on your system since you had them working? Pete

No, that's the device scan. The logging of Events, if you enabled it, will go into the regular FSUIPC4.LOG file (in the same folder). Pete

Why? You don't need to use any compatibility mode for FSX or FSUIPC, We need more information please: 1. Actual version of FSX 2. Version of FSUIPC4 you are trying to install. 3. If there is a Log in the FSX Modules folder please show that. There may be two logs -- one from the Installer the other from FSUIPC itself. Pete

No, the Lua event library functions provide a way to call a function in a previously dormant plug-in, one just waiting for such an event. If you want to check for key presses in an active loop use the Lua flag system. Assign that key press to set the flag (LuaSet <plug-in name> with flag nimberas parameter) and test for it by ipc.testflag in your loop (or of course LuaToggle). Things like button presses (on scanned joysticks) can be tested without such complication, but you can't expect FSUIPC to maintain a note of every possible key press in case somethnig tests for it. And even if it did, when does it clear it down? How many running plug-ins might be waiting for it -- but not able to test immediately because being busy? The short answer, of course, in that there's no "interrupt system" available in Lua. That would really need multiple threads within the multiple thread system which are the individual plug-ins! Pete

You are currently assigning to "SIMCONNECT MENU" controls in the Buttons & Switches tab in FSUIPC Options. If you look on the left side of that options tab you will see you can make buttons send keypresses instead. Keypresses 0-9 are what are normally used by users with a keyboard to select entries in a Simconnecvt menu. There's nothing wrong with you doing the same, but via a button or switch. Use what works. Pete