Pete Dowson

The only fix is to use a different aircraft. The PMDG aircraft are notorious for freezing the sim whilst collecting the information they want to save. The only part FSUIPC is playing in this is calling SimConnect, in P3D, to ask it to save a file -- exactly as you can via the menu or via the ; key. Pete

I think the timings for virtual buttons stay pretty much spot on. the PollInterval value doesn't affect those -- that's only applied to hardware polling. The way to get the timings the same is to make sure that the repeat rate is a divisor of the poll rate -- eg in this case an interval of 40 mSecs is a rate of 25 per second, , so 25/25 = 1. If there's a mismatch, as i think the default values currently provide, then the rate for real buttons will suffer -- i.e. be slower compared to the virtual buttons. So: PollInterval=20 ButtonRepeat=25,12 is okay too, as the poll rate is 1000/20 = 50 and 50/25 = 2. And so on. All this stuff isn't normally all that important -- except when comparing rates! Earlier versions of FSUIPC did assume there was a lot more overhead in polling real buttons and so adjusted the timings to suit, resulting in the much slower real button polling. Experiments on more recent hardware (and Windows versions) showed that these adjustments could be significantly relaxed. Pete

I assume you are using something in the ProSim CDU to instigate GSX operations. Since all that is completely independent and invisible to FSUIPC, I don't really see how you can automate it very easily. One possibility I can think of it to have an FSUIPC lua plug-in which uses event.offset on offset 3110 to call a function to sleep for a little while (500 mSecs perhaps?) then sets 3110 to zero (ipc.writeUD) so that next time PSU will write it again. Pete

That's most certainly wrong. Was it a crash? Any crash details? Once you enable WideFS in FSUIPC it should stay enabled. Are you saying the problem is that this sometimes disengages all by itself? There should be no difference in how WideFS works between FSUIPC4, 5, 6 or 7, and I've never heard of or experienced any problems quite like yours. I think we will need to wait for John's return from his short break, probably Monday. Pete

Could you post something about it to the User Contributions subforum, please? There it will have a longer life and be more easily found by other users. Thanks, Pete

Okay. I can think of two ways of doing what you want. First one s to keep the "asking" plug-in almost as it is, but run it from your main program using ipc.runlua, first placing your question into a global variable (maybe called QUESTION), using ipc.set. Have the asking plug-in to display your question by reading it via ipc.get, and place the result into another global variable, say ANSWER for the main plug-in to retrieve. Then your main plug-in can use event.timer to see if the reply has yet arrived. You'd need to initialise the global ANSWER to, something not possible to be a reply so you can see when it has changed. You'd need to do this for each answer you want, maybe using a set of different timer functions. Note that each time you use event.timer it replaces the previous event.timer -- no need to cancel it. The second way would be to work it like that but in one large program. i don't think that would be so neat a solution, though, and easy to make errors in, so I''m not going to attempt to do so. Pete

Last point first. There's plenty of logging to be had, but we normally don't recommend enabling it in the first inmstance without first establishing what we are looking for. WideClient can only connect when FSUIPC is ready. That is when everything in MSFS is running and ready to fly. However, it will sit around waiting for the chance to connect. This is the first thing to note: This indicates to me that you have not tried the most obvious thing: that is to stop reliance on the broadcasts being seen, and specify the ServerIPAddr an Protocol parameters in the WideClient.INI file -- as described in one of the early pages of the User Guide. Try that first, then show both logs again if it still doesn't connect reliably. Pete

You mean the custom controls PMDG added don't include them? It sounds like they implemented their own FO Kollsman. Perhaps that dated originally from before the FO one was supported (P3D4 was it?) Not if it is internal to the aircraft and isn't in the data provided by the PMDG implementation. Pete

Okay. It might be more logical for the function to exit (by virtue of the 'end', or a 'return' -- it makes no difference), and should then continue to execute the rest of the program. If so then the event function calls would have to come beforehand. I think FSUIPC is programmed to keep track of events outstanding for the plug-in and terminate it when they are all removed. If you need to force-terminate a plug-in, whether any events are outstanding or not, you can use ipc.exit() Since that would automatically remove all events the code could just make use of that function instead of the list of event cancellations. Pete Pete

When you detect the return character just cancel all events and do a ‘return’. Didn’t John’s do that? Pete

This part of the code: while k <= 3600 do k = k+1 wnd.text(w, "Count = "..k) ipc.sleep(1000) end is a loop which makes the Lua stay executing that sequence for 3,600 seconds. Events can only occur when the Lua program relinquishes control, so therefore waiting for the next event. You should never use such loops in an event-driven plug-in. Put that code into a function and call it with event.timer(1000,"<function name>") instead. Pete

MP traffic has never been supplied in the SimConnect information in any version of FS or P3D. THere used to be a program or add-on for VATSIM (I think) which did inject the other user aircraft into FSUIPC's traffic data tables, so that FSUIPC applications could read it, but I think all that more or less died out a while ago. You could test also with LittleNavMap's traffic reading. It is a 32-bit program and usesthe older FSX SimConnect library to interface to MSFS, whilst FSUIPC7 uses the new one supplied in the MSFS SDK. We expect the latter to develop gradually in the future, so it's the right choice. Pete

This is the proper (and only) forum for FSUIPC and WideFS support. If you want assistance try starting again, explain your needs clearly, and don't insist on personal phone calls. That is not the way things do or should work. I'm closing this thread. If you decide to be more reasonable please start another thread and provide the information we need to help you. Pete

SimConnect Text facilities aren't working properly at all in MSFS. That's the reason John used the Lua "wnd" library to create a window instead! Pete

Please try this version, and confirm it's okay on your Surface Pro. FSUIPC4.DLL Just replace the same module in your FSX "Modules" folder. I couldn't remove the entry in the Registry for the non-existent XBox 360 controller -- it just gets put back immediately. In FSUIPC as it was the fact that it is registered but not existent caused an internal device count to go wrong and crash FSUIPC. That is what I have fixed. So the spurious device entry will still occur but won't result in an added device. Pete

Yes, exactly (as I said). Pete

"return" is used in Lua to terminate the function other than at the 'end', otherwise the latter does the job. Same in C/C++ -- you only need the return for functions returning a value or to terminate before the end. Pete

May be best to give your modified one a different name? Pete

Hmm. Odd. I wonder why I did that? Pete

You'll need to provide a lot more information, like basic stuff: which flight sim? which version of FSUIPC? Plus show your FSUIPC settings (the INI file) and the Log you are looking at. Pete

If you are using renamed and edited copies of the HidDemo.lua, find the line which addresses the virtual buttons. In the original Lua this was: ipc.writeUD(0x3340 + ((i-1) * 4), buttons) This addresses the virtual button offsets 3340 onwards, with 3440-3443 being Joy#64, 3444-3447 being Joy#65, and so on. So, if your previous plug-in used up Joys #64 and #65, the second plug-in needs to address #66 and following, so change the 0x3340 to 0x3348. If you are already using #66 too, add another 4 -- and so on. Pete Oh, I see you just received other replies too.

You need to fix problems in the original FSX release by applying the updates. You should be on SP2 at least. A lot of bugs in the original release were fixed. https://www.microsoft.com/en-gb/download/details.aspx?id=8986 Pete

Please see if WideClient.exe will run on your device first. It does depend a lot on standard Windows functions and i'm not at all confident that the Windows you have running on an Android device will support them all correctly. The registration is only to enable the server end, which is built into FSUIPC. If WideClient does run (it just won't 'connect') then you purchase your registration in SimMarket. Just search for WideFS7. Pete

Strange. Most encoders make a contact (button push) on alternate 'clicks' with the "release" on the intermediate clicks. I wonder how yours pulses instead. Is it perhaps related to the circuitry? (I assume there aren't 100 clicks every second whilst you are turning it). If it can go that fast, that's fine. The only damage it may do is cause performance issues because of the increased demand. Pete

Load up the FSUIPC7.INI file into an editor like Notepad. The file will be in the folder you installed FSUIPC7 into and Windows will probably call it "configuration settings". Look for the section headed [Profile.<name>], where <name> is the name you gave to the Profile you are using. In that section will be the names of all the aircraft using that profile. Just replace all the lines for the Cessna 172 with one line which provides a short name which occurs in the full names of all of your Cessna 172's, maybe just: 1=Cessna 172 if, indeed, that string is part of every name. Pete