Pete Dowson

Yes, and there are threads about it here and in the dedicated MSFS subforum above. The problem has been reported to Asobo, but it might help emphasise the matter if you could also report it via Zendesk along with the Windows crash data for MSFS (they won't be interested in the subsequent crash which that caused in FSUIPC7, but certainly John will want to look at that though as a separate matter. Currently it seems you can alleviate the problem (though not eliminate it) by setting "ProvideAIData=No" in the [General] section of the FSUIPC7.INI file. This reduces the amount of SimConnect interaction -- it seems that MSFS doesn't survive well with too much, and FSUIPC is pretty intensive in that. I expect ProSim adds a lot as well, whether you run in FSUIPC or SimConnect mode. The only drawback with not reading the AI data is that some programs (not sure about ProSim) will not get the traffic information they need for such things as TCAS warnings or ATC operations. This problem seems to have been introduced with the last update to MSFS as CTDs were far less likely in previous releases. Pete

You could try a different assignment method. You haven't said how you are currently assigning: 1. Direct to FSUIPC calibration: throttle 1 and throttle2, plus calibration? 2. To the FS control "Axis throttle1 set" and "Axis throttle2 set"? With or without calibration? 3. To the FS control "Throttle1 set" and "Throttle2 set"? With or without calibration? So, with calibration thought of as optional, there a 5 choices there. One will work for sure. I suspect the problem is similar to that which affects PMDG 737 users . Best to create a separate Profile for the iFly so you can change things for it without affecting your other aircraft. Then try each of the 4 options you are not currently using. Pete

I really couldn't say. It is not possible for us to test FSUIPC with every add-on. Are all those functions using normal FSX controls/events? You can use an unregistered install of FSUIPC to log events and check. If the operations you wish to control are exposed in any way then, yes, a registered FSUIPC can let them be programmed for joystick or keyboard control. Also, it should be possible to use "mouse macros" in FSUIPC to control things be emulating what the mouse does for you on the panels. When you install FSUIPC you will also get the full documentation. I suggest you do that and read up the details of what FSUIPC can do if you purchase it. You should also post your questions in the appropriate PMDG user forum. Other users would be able to help more than we can. Pete

Yes, just right click on the FSUIPC7.EXE and in Properties-Compatibility, select run as administrator. However, I don't understand why ProSIm needs to be run as administrator. Is this specifically with MSFS? What happens if you don't set it to run that way? I use ProsimB738 v3 with P3D5.1. With multiple views to fill my 210 degree FOV screen there's no way yest for me to use MSFS. Pete

Why not simply use the C DLL to access the Windows functions not exposed in the Lua libraries provided, and leave all the Lua stuff in the Lua script. Which Windows functions do you need? You don't show any there. Doesn't the 'L' in your LuaL_error call (and the others) refers to a structure created in your loaded Lua interpreter. The structure used within FSUIPC is not at all the same. I suspect trying to use it will just cause even more problems. Why not simply return the error to the calling Lua script and use ipc.log to log the error and then terminate the thread. That's all the C function LuaL_error would do in our implementation. Pete

This is not covered inthe manual because it has never been a normal requirement. Most folks either have a reverse zone on the main throttle axis, with an idle zone somewhere above what would otherwise be the fullback idle position, or use a button sending "throttle decr" to obtain reverse. There have been plug-in Lua scripts to do what you want, and there are probably some in the User Contributions subforum above. However, I believe that MSFS, unlike previous versions of Flight Sim, does provide a control to switch over the throttle to reverse. I've read about it somewhere here, probably in the MSFS subforum, which is probably where you should have posted. I expect John, who is dealing with MSFS, will be able to assist you. Ah, I see John has actually replied in the time it took me to write this! Pete

The letter entries don't change because they relate to your assignments. So you have used, at one time or another, 3 devices, as described by the T, P and Y lines. The additional lines, the ones starting with numbers, denote the single device found to be connected at the time the JoyNames section was re-written. That device appears to be the Saitek Yoke, but with a mismatching GUID. So, effectively, in this session (or this stage of the session, because you may have connected more devices later) you have no devices at all currently active in FSUIPC assignments. I thought I'd explained clearly why there are bother letter= and number= lines. What part of that did you not understand? Pete

The Lua C functions are internal to FSUIPC and many of them have been modified for fuller integration. The LuaL_error function simply terminates the thread and adds a message to the FSUIPC or Lua log. The C functions are not exported. I really don't see the need. Why not implement your own error reporting function since you are making a C program? I'm also a bit puzzled as to what you are writing a C program yet wanting to use it within the simple scripting facilities FSUIPC provides. You seem to misunderstand why the facilities are provided. Pete

Seems that the author of the original hasn't seen your pleas for help, and this being a Reference subforum, not a support forum, you might not get any other replies. The author is cleverer than I with respect to Lua programming. I don't know much about "Assert", and I didn't even know you could have arrays of functions. However, looking at your Lua file I can't see any sign of the functions referred to in the Array: btnFunc = { { 7, 1, "DeIce_PITOT_on", "ignore", "DeIce_PITOT_off"}, { 7, 2, "G1000_MFD_SOFTKEY12", "ignore", "G1000_MFD_SOFTKEY11"}, { 7, 3, "MasterCaution_reset", "ignore", "MasterWarning_reset"} } That seems to list 7 distinct functions which are nowhere to be found! Looking at the author's original files (and there are TWO ofthem), the shorter one included these lines: dofile([[.\LINDA\system\common.lua]]) dofile([[.\LINDA\libs\lib-msfs.lua]]) dofile([[.\LINDA\libs\lib-fsxcontrols.lua]]) dofile([[.\TripleUseAssignments.lua]]) function ignore () end Here I can see the "ignore" function, and I assume the others are within those LINDA files. Evidently you have removed this stuff and hence have a result which includes none of the functions needs to make it work! If you are not using LINDA then I guess you need to supply those functions yourself. Write them in your Lua. Pete

Thanks for the suggestion. Maybe the OP can confirm, but I thought he mentioned that he was unplugging them himself? Pete

There's no way I know you can do that. Why would you try that? In a C DLL you surely can use Windows functions directly? Sorry, that's all beyond me. Yes, I'm sorry. But I think there is far too much complication involved. There are a lot of internal structures wrapped around the Lua threads. It would be a huge amount of work and very error prone. In addition of course there is still a lot of development work ahead for us on the MSFS front. The Lua facilities are provided as a way of extending FSUIPC's facilities by relatively simple scripts. I think if you are going to need to do the sorts of things you are implying then you really should be writing a complete external program, not an overly complex plug-in script. Pete

I think John will need to see an FSUIPC7.LOG file. A complete one, unlike the first you posted -- one where you actually used MSFS and got to a proper close down. BTW i use the Run and RunIf facilities a lot (including for example ASP4 like yourself), and I have always needed to use the "" around the full pathnames. Not that this includes the program name -- i.e " before the drive:\ part and another after the .exe. I also tend to use the "READY" keyword, to only run the programs when the Sim is ready to run. This works so much better for most programs. However, I'm using FSUIPC6 with P3D5.1 (I can't use MSFS on my cockpit because of the 210 degree curved screen and the multiple views needed to fill it without distortion). So maybe, in FSUIPC7, there's a difference to do with the state of MSFS at the earlier time. Pete

John is trying to help you but I think you are still missing something. In your [JoyNames] posted above, nothing is duplicated. For each assigned device there should be two lines -- letter= and letter.GUID=. Those store the details at the time they were found and assigned. The entry number= and number.GUID= refers to the details found in the Registry in this session. In order for FSUIPC to use your assignments for the correct device it matches up the number lines to the letter lines. In your example it cannot do that because the GUID has been changed by Windows because it has seen it as a different device. This may well be to do with you using a different USB port, or it may be down to the vagaries of a USB hub if you are using one. GUIDs can also change with some Windows updates, but that shouldn't happen except on major updates. If they have changed, then to preserve your assignments just make a copy or the number entries and replace the number by the correct letter, then delete the older lines with the wrong letter. If the only change is the GUID you only need to do that for the GUID line. The only way for FSUIPC to make sure it is using the correct assigned device is via the GUIDs which are, after all, intended to be unique assignments for that device. The fact that Windows can change them is very annoying, but can be avoided by NOT unplugging them, and certainly not plugging them into different ports. Pete

Just checked. They were on version 7.1.5.7 dated 28/03/2019, and the mini PCs are on Windows 7. I updated to the current WideClient, 7.1.5.9 dated 25/06/2020, and they still boot fine. This is with them placed in the StartUp folder. I also just check on this PC (my development and main Internet PC) which is on and up to date Windows 10 (2004 Build 19041.746) and it's okay on that too. I have another which is on 20H2 Build 19042.746, so I'll try it on that too. However, I'm now thinking it must be related to whatever it is you ask WideClient to do when it loads, so I can't reproduce that. [LATER] It works fine in Start-Up on the Windows 10 version 20H2 PC as well. So, conclusion: I definitely need to see the Windows crash details, as requested, but I'd also need to see your Wideclient.INI and, ideally, the WideClient.LOG file from the newer version after the crash. Pete

Hmm. that's very strange. Can you provide the two version numbers for me, please (right click on the EXE, Properties). It would be useful for me, still, to see what I asked for - the windows crash details (Event Viewer - Windows logs, Applications). It must still be in the list of events in there. f I can locate the problem I'd like to fix it to help any others encountering similar problems. BTW I have a network of 5 PCs for my cockpit, all autostarting WideClient. I'll check their version numbers too -- I might not have kept them all up to date (4 of them are mini Pcs built into a cockpit and have no keyboard nor mouse, so are managed over the network). Pete

I think you need to ask about this on the P2A forum. But first try making sure you have pressed the "fly" (or is it "fly now" ) and are actually on the point of flying. Pete

If you are using the current (latest) version of FSUIPC7, then FSUIPC7 is automatically loaded by MSFS when that is running. So, in that case don't try running it again! You don't need to! Pete

Thanks. The Server certainly never sees the Client. I think it must be a firewall issue. Pete

The log simply shows that the Server isn't seeing the Client. This could be to do with the firewall on either PC. On the client you must allow WideClient through. On the Server, FSUIPC7 and, if possible, WideClient. The fact that the Broadcast from the server is seen (providing the Server name "DESKTOP-I1IEAU4", and its IP address 192.168.1.76 is encouraging. However, it looks like the Server isn't seeing the requests from the Client, so it definitely looks like a firewall problem. You could try (temporarily) disabling the firewall on each machine in turn to see where that is occurring. You didn't provide the WideServer.LOG file as requested, though. That may show more. Pete

No. Just FSUIPC on the main PC, and WideClient on the Client, as per the instructions (the Installation section on page 3 of the WideFS User Guide). There's no such thing as "WideFS.exe", so i assume you mean WideClient.exe. That's just WideClient.ini, not a log, and it shows you haven't tried all of the suggestions in the user guide, page 4. This part: Configure your Network IT IS IMPORTANT FOR ALL USERS TO READ AT LEAST PART OF THIS! Scroll down to the paragraph starting "... However, if you find the connection is still not happening". Try the suggestion there. Finally, in order for us to help with problems we need not only your settings (the INI file) but also the Log file. That is why a Log is produced, to show what problems might occur and help fix them. There will also be a WideServer.Log file in the folder where you installed FSUIPC. Pete [LATER] Oh, I see John replied simultaneously, saying much the sam thing!

If you read or write the whole value you are getting and setting 8 lights. To get notified of a single bit change, like the 08 (2^3) bit, use event.offsetmask(0X0D0C, 8, "UB", "function name") To SET one bit (or more) use ipc.setbitsUB. There are also functions to clear a bit (or more): ipc.clearbitsUB, and to change/toggle one or more bits: ipc.togglebitsUB. All these would be more efficient than reading/writing the complete value and using the Logic library functions for these basic things. It really is worth your while browsing the Lua Library document so you can see what is available. Pete

It is generally not a good idea to put it there. It needs to be able to read and write to its own folder, and the modern windows rules normally prevent that, requiring program data to go to a suitably named folder in AppData or ProgramData folders. I'd put WideClient into something like C:\WideFS. Well I don't know what is doing that, but it isn't WideClient. Visible=No in the [config] section of WideClient.ini? Sounds like something is overriding the Hide instruction sent to Windows. I assume you mean WideClient? Please show me the windows crash details (Event Viewer - Windows logs, Applications). Without that I have no chance at all in knowing why it crashed. You said that WideFS (meaning WideClient?) goes "out" but ADIRS crashes. Are you sure of the order. Maybe it is ADIRS crashing which "takes out" WideClient. Are you using the facilities in WideClient to load ADIRS? I think you need to show me your WideClient.INI file. Also, please describe what the "Upgrade" to the PC was. Do you mean a complete replacement PC? Do you have more that one program starting automatically? If so please check if they load in the same order as they used to. Maybe there's some unwanted interaction. Pete

I think you would need to have an aircraft with no panels or graphics at all. I think this means either creating oyur own add-on aircraft for MSFS, or editing files related to an aircraft you choose and editing them accordingly. But this is not at all the province of FSUIPC and neither John nor i are able to advise in any further detail. Perhaps you might get advice on the AVSIM MSFS or on the MS MSFS general forums? I do know it can be done because ProSim have just recently done it for their 738 model (ProSim provide all of the instrumentation on external modules). One way does occur to me and I have seen it mentioned on one of those Forums, and that is to set the pilot's viewpoint forward of the aircraft. But don't ask me how that is done. BTW I am staying with the excellent P3Dv5 until MSFS is mature enough (maybe in 2022? 😉 ). Pete

That makes no sense, unless you meant to write "it seems that the DLL is not transmitting the key"? There's a drop down list of controls you can assign to, other than the selection for Key Press. However, it occurs to me now that the list may only contain true Sim controls, not the added ones from FSUIPC. i'll need to check that too. Ah, good. Actually that is the way I use the DLL. Not only the buttons but my axes too. It certainly seems that it doesn't (it probably transmits that 'nul'). The assignment, though saved in the INI file, is getting lost internally somewhere. I'll try and figure it out, but at least it doesn't have the previous urgency now. Thanks. Pete

And did it work, sending DEL, for all that time? I've compared the code for key assignments between the older 32-bit version and this 64-bit version (assuming that's what you've changed) and it doesn't appear any different. It could take me several days to get to the bottom of this, because the only PFC equipment i have is built into my immovable cockpit in another room. I'm going to have to set up some remote debugging facilities to see what is wrong, then wait till my wife is free to sit in the cockpit and press the button when I shout up to her.)it's upstairs in a spare bedroom). Two things you could look at for me, to help, please. Try assigning something more ordinary, like a letter key. I know you can't use it for PTT, but just see than what is logged. Another thing to try is assigning to the button in FSUIPC instead. I think that is possible (but i'll verify tomorrow). Finally, instead of assigning directly to a keypress you could try assigning to the FSUIPC control (in the drop down list) called "Key press and release", with a parameter of 46 (the keycode of Del). Pete