Pete Dowson

In the past I've written drivers for a lot of different hardware using dials and displays -- radios and autopilot/MCP controls . Some software delay and the resulting queuing action has always been present with all flight simulators since FS98 (when I started writing the drivers for FlightLink hardware). Maybe not as bad as with MSFS, but: The way i dealt with it was to maintain the local display with the correct value as the knobs, displaying the value being read from the Sim when there was a gap in the button input arrivals -- more than, say, 500 or 750 mSecs. That always worked well, no matter what the sim or aircraft. The timing needs experimenting with to get just right. But if you aren't maintaining a local display, and consequently are dependent on seeing the changing value in a gauge on-screen, then this isn't a solution for you. Pete

That is L-Ms doing, and I did read the explanation somewhere, but (sorry) I've forgotten the details. I think it's related to addons which will always be loaded ("ProgramData"), compared to those which only load when the appropriate user is logged on (AppData). If you ask on the AVSIM P3D forum I expect someone will explain this more accurately. Pete

I always liked to keep everything in one folder and my installers always broke all the rules to do so. But John is doing the right thing -- correctly abiding by Microsoft' & L-M rules. The program and its configuration stuff in your choice of Installation folder, the necessary activating Addon.xml in P3D's Add-Ons folder, in your Documents, and the documentation in an appropriate folder also in your Documents. I suppose there could be links placed to all these when they are installed, but many folks, including myself, don't like getting such a cluttered Start menu or, indeed, desktop. I tend to move or delete such additions. It really shouldn't be so odd finding documentation in the Documents folder, surely? BTW apart from the documents installed in the Documents folder, there is a document accompanying the Installer, in the ZIP you download, which provides helpful instructions and does tell you where things go. Pete

So in FSUIPC you should see the trigger button as 5, and the 'throttle' buttons would be 30 and 31, so they should all be assignable in FSUIPC's Buttons and Switches tab. Pete

Okay, thanks. I see you solved the function access using "dofile". That's another one I've never used. Perhaps you could make a more permanent place for it in the User Contributions sub-forum, with an appropriate title -- including I think mentioning that it uses LINDA. Otherwise it will scroll off into the distance in this forum. Pete

The "work around" for ipc.ask I was suggesting is by using existing Lua library functions, not replacing the code for ipc.ask. I would suggest John just keeps pressure on Asobo for working SimConnect Text facilities rather than re-write that function! There's a lot of pressure on them already for the related Menu facilities, needed by a number of add-ons. Pete

Any and all AI (and real world) aircraft will provide data in response to FSUIPC's requests, whether on the ground or not. But 'static' aircraft are usually just part of the scenery and not reported. They are just scenery objects. Pete

These operate by sending controls to the simulator, and it appears they are being queued. So, it your system quite heavily loaded? Queuing of actions in an aircraft is most usually to do with the aircraft itself and its displays. Try with a simple default aircraft to make sure it isn't that. Note that when FSUIPC logs those controls (INC and DEC I assume?) that is when SimConnect reports back to FSUIPC that the control is being implemented -- it isn't the time when FSUIPC actually sends it. There are some different log entries which can be enabled which shows the button press detection. I've never known any button press to take any noticeable time to be activated, let alone a whole second! The rotary is merely acting like a button. Try checking with a simple button instead of a rotary. Is there still a one second delay? BTW with rotaries there's alternatively a "press" and "release" action on each click. So, you should program both press and release to the same INC / DEC operation for a change on every click. Pete

Ah, I've learned something! 😉 Pete

Interesting. FSUIPC reads AI traffic data so it can populate the offsets used by many external applications. Maybe John could make a test option to stop FSUIPC7 reading any Traffic (a "NoTrafficAtAll=Yes" parameter, perhaps) as a test. If this prevents the CTDs even with all the MSFS traffic enabled then this would be good information for Asobo. Pete

I've never tries actually opening the keyboard as a device. How did you identify it for the io.open? event.key relies on FSUIPC detecting a keypress and invoking the event, so if we are receiving keypresses when MSFS has focus, which I think must be so, then event.key should work. Pete

Those two errors, yes. They basically mean SimConnect has "disappeared". If it is related to the SimConnect interaction, which is definitely possible, then probably a Simconnect log would be more informative for Asobo, but the Windows crash data sohlud get them to the point of failure, and is still the most important information. Those sorts of problems would certainly be good information for Asoso as well. But they do look like a result of MSFS being too busy on all fronts to bother with its SimConnect responses. Do you have performance problems with MSFS? The log shows that the two errors indicating the crash occurred 22 minutes later than those earlier response problem log entries, so they are certainly not a direct cause of the crash, and problem are not at all related. Has this all changed with the latest MSFS update, or, for you, has this always been occurring with other versions? Pete

It's the other way around. Those errors occur because SimConnect has stopped responding even to the basic request to carry on sending data. MSFS has really crashed by then, taking SimConnect down with it of course. As John says, you need to find the Windows crash data for MSFS (in Windows event viewer) and report the crash to Asobo on ZenDesk. The more folks do this the more likely the problems with be attended to. Pete

No, it doesn't know about the other installation and in any case there are no checks on the hardware itself. You must be making an error somewhere. But you can also just copy the FSUIPC7.key file from the one PC to the other. Pete

Perhaps the OP could emulate ipc.ask by using the wnd library facilities and trapping the reply keypresses with event.key? Pete

So it seems I don't understand your original question: So, the "functions" you mean there are evidently not controls to make things happen in MSFS. Reading further it seems you want to access functions in one Lua plug-in from another. But your first question definitely concealed that request I'm afraid! I think you need to import the other Lua into yours. That's something I've never done,, but I think you use "require". Best to refer to the Lua reference website, or the book if you have one. You are doing more advanced stuff than I in any case, using arrays or functions, so continue your research. Or you could ask on the LINDA forum. I'm pretty sure LINDA makes use of these mechanisms. Pete

If you mean what does WideFS do, it allows the main FSUIPC programming interface (the access to offsets) to be extended to any networked Windows PC. Pete

Yes, it does (and that restriction is documented). Folks needing more use a Lua plug-in to heal with the HID device instead. HidDemo.lua, supplied in the Examples, sends up to the max of 256 buttons for a device using Virutual Button offsets in FSUIPC for easy assignment. Pete

I don't know LINDA, sorry, But to "access functions in MSFS" you use the controls or events. From Lua that would be via the ipc.comtrol function. Please refer to the Lua library documentation. I don't understand why you want functions for them when they are just simple numbers as parameters in that function. See the Controls List for the numbers available. Of course not all yet work in MSFS yet. MSFS is still a work-in-progress. Pete

What number buttons do these show in Windows game controller properties for that device? FSUIPC only supports 1-32 (shown as 0-31 in FSUIPC). for more you'd need to resort to a Lua plug-in. I don't know about LINDA though. FSUIPC doesn't support the mouse for assignable inputs. You can use mouse buttons and movements in Lua plug-ins. Again i don't know about LINDA. Pete

Glad you worked it out, but do also please note that those facilities are described in the User Guide, along with lots of other helpful information. Pete

I'm afraid I do not recognise the TXT file you attached -- I don't know SIOC and cannot support it. Is there a separate support Forum for that? Pete

You'd need to provide details of how you have it assigned. You also might want to ask on the Project Magenta support forum, as we don't support PM itself here. If, as you say, the same way of handling it works well with the heading and course setting, the difference with the IAS/Mach values maybe more to do with how PM handles that. Pete

First off, you are misunderstanding the types of values. In these lines ipc.writeUW("66C0", value) ipc.writeUW("66C1", value) ipc.writeUW("66C2", value) You are reading a 16-bit (2-byte) Word (UW = Unsigned Word) into successive BYTES, 66C0, 66C1 and 66C2. So the next byte is being overwritten each time. If you want to read Words you need to allow 2-bytes for each -- so 66C0, 66C2, 66C4 etc. Or, if you only need 8 bits (for values in range 0-255) then use ipc.writeUB instead. However, are the aileron and elevator LVars the actual poistion values? If so they would be Signed, not Unsigned (with 0 as centre). So you'd need SW instead of UW in any case. Second, you are misreading the definition of the functions being called: function ap_on("L:QW_MCP_L_AP_Button", value)function servo_ai("L:QW_aileron_left", value)function servo_el ("L:QW_elevator_left", value) The parameters are places which RECEIVE values from the Event. You do NOT provide the variable name -- the Event does! Just define your functions as function ap_on(var, value)function servo_ai(var, value)function servo_el (var, value) but it would be far more efficient for you to use the value supplied. The value has already been read by the event and supplied for you, yet you do: value=ipc.readLvar("L:QW_MCP_L_AP_Button") value=ipc.readLvar("L:QW_aileron_left") value=ipc.readLvar("L:QW_elevator_left") which just overwrites value with the same value! Just delete thse lines! If you really don't want to use any of the parameters supplied for you you can define the functions with no parameters -- (). Also, you are not actually running your plug-in in any case. This is wrong: [Auto] 1=ap_qw The Auto sections are for commands to be executed automatically. "ap_qw" is not a command, but a filename. It should be [Auto] 1=Lua ap_qw which is the command to run that Lua file. The documentation does show this . In fact, I think most of these errors are caused by a lack of reading, perhaps more carefully, the documentation and examples provided. Finally, try using the facilities to log LVars so you can see the values you should be using. There's an assignable control to list them, and a provided Lua plug-in to monitor them and log changes as they occur. Pete

We cannot analyse crashes in MSFS code as we do not have the source and we are not responsible for it. You need to send all such reports to Asobo / Micraoft, on Zendesk. It seems the latest version of MSFS is very unstable, not just with FSUIPC running. Pete