Pete Dowson

You mean in P3D4? No!!!! The friction tables are NOT (repeat NOT) available! Pete

If your spelled it correctly, as in my amendment to what Thomas said (see above), the result should have been exactly the same -- I did say it wouldn't fix anything though because the log showed that the correct IP address was being returned by Windows. Ouch. Yes. Add-on Firewalls count as well as the built-in Windows ones! Did you check that on both PCs Neither version would affect a WideFS connection. Are you using a Wireless connection? If so that's probably the reason. Whilst the data exchanges are not heavy in terms of the amount of data, they are very freqent. At the risk of having missed frames and frames out of order, you could try setting BroadcastMode=Yes ProtocolPreferred=UDP in the [WideServer] section of FSUIPC4.INI on the sim PC, and Protocol=UDP in the [Config] section of the WideClient.INI file. UDP, unlike TCP, has no checks applied and no sequential control. I use it for things llike cockpit displays needing updating. It might not be so good if you are using things on your client to control operations on your FSX PC. Pete

Well, I checked everything, re-built and re-ran it and was okay!! Weird. Some sort of build anomaly. I've re-upoaded it. Pete

What! Checking. Somerthing's gone awry then :-(

That might be part of the problem. The parameter is: min_throttle_limit = -0.25 //Minimum percent throttle. Generally negative for turbine reverser -0.25 means 25% of thrust negatively. A 0 would give no reverse at all. You have -0.31, which is a bit higher that normal. But as far as I know that value is what you get when you send the maximum -ve value for the thrust. FSUIPC's calibration certainly limits it so in any case. Pete

Yes, I will, but I may not have time before I depart on Wednesday morning for a week's holiday. (Boy, do I need it!). Thanks. Have you posted this on the ProSim forum? Pete

That facility is already built into FSUIPC and WideFS for FSX and P3D1-3, but not yet for P3D4 (pending facilities from L-M). My own cockpit with a 220 degree FOV cureved screen from NatVis needs this facility too, so I will be pressing L-M myself for P3D4. Unfortunately the menu cannot be completely removed from the sim's screen -- it is made smaller and moved out of the way (top left), as if I remove it, Simconnect no longewr supplies the selection back to the originator. I never found a way around that. The details are in the Lua Library documentation, because it involves using a Lua plug-in onthe WideFS client PC. See the Lua library document, lookup "event.textmenu". There's even an example plug-in provided which handles a client display showing the Radar Contact type display, the normal SimConnect text line from the top of the screen (which is suppressed on that screen) and the current menu, if any. Pete

It works apart from having no gauge displayed. I was only debugging the FSUIPC calling library code and my treatment of it within FSUIPC5 so the lack of a display didn't affect me. Sorry, I don't have time at present to try debugging anything else. I'm away from Wednesday onwards, for a week, and need to get lots of other stuff done now -- a full release of FSUIPC5.102 this afternoon, and then try to do something with MakeRunways for the new add-on scenery structures. Pete

You can use the complete FSUIPC4.INI file in FSUIPC5 -- just copy it over and rename it FSUIPC5.INI. Pete

How are you trying to close them? It should be just the usual com.close, the same as you use for your VRi devices. If could could supply a short plug-in which demnstrates this, please, I'd like not to have it outstanding in a full User Release if possible. I at least have plenty of "Hid" devices, I can patch such a plug in with different VID and PID values. If it isn't so easy for you I can see if I can adapt one of my Lua examples. I think there's a one which Logs HID stuff. Pete

It would be tidier, but there's no need to go right out of your way. I have a limit of 1023 handles in a table shared by COM (com, vri, hid) and windows (ext), for all loaded threads. Provided your setup is unlikely to get anywhere near filling (leaves some for others!) then it should be fine. Incidentally, I don't suppose this error matters, does it? *** LUA Error: C:\P3Dv4\modules\linda/system/events.lua:460: attempt to index global 'JH' (a nil value) It is occurring at every LINDA start. I'll be releasing the full Install 5.102 this afternoon. Thanks, Pete

Okay. I think I've managed all three fixes. At least I hope so: FSUIPC5101p_TEST.zip Please retain this logging for any tests, good or not. i'd like to see the results. Debug=Please LogExtras=x2004 Thanks, Pete

Check your aircraft's AIRCRAFT.CFG file. Thee will be a parameter there which sets the limit on the reverse power. It is usually 25%, perhaps less, but whatever it is, that's what FSUIPC will supply for "full reverse". And the limit in the aircraft would ignore anything more in any case. Pete

Me too, soon. If I can't do all three "fixes" I mentioned I will continue in the morning. But I would dearly love to get this sorted soon, then, because I feel I need to release a full Install package before I go away for a week. So many of the support responses Thomas and I have to attend to here are due simply to folks not knowing there are interim releases which already fix their issues. Pete

Just a spelling correction there, it would be "ServerIPaddr" not just "ServerIP", though this seems unlikely to solve it as this part of the WideClient.Log posted shows it did get the correct IP address: 30703 Trying TCP/IP host "owner-pc" port 8002 ... 30703 ... Okay, IP Address = 192.168.1.1 It does look just like some sort of Firewall block. Pete

Yes, as I surmised. I will fix this in any case -- for the same "real" handle the same "local" handle should be assigned. That will be fix #1. Fix #2 will be to stop those attempts to provide local handles for real handles with are invalid, like 0. And Fix #3, which may not be so easy, will be to work out how to free the local handle automatically when the COM device is closed by enforced killing of a thread. Pete

FSUIPC automatically kills any threads still running when asked to restart them (i.e. load them again). I'll upload a 5.101p version with some fixes to test shortly. Pete

Ah, in that case FSUIPC would have automatically closed them on its termination in any case. Actually, it should be when it has to Kill your Lua threads in order to start them again. I shall have a look at checking the Handles table then. That might explain it. I don't think it does at present. Though it seems odd that the system provides the same handle again, because those are coming from a genuine Open. Pete

On the event.VRIread calls, the handles are certainly valid ones: 128953 ### DEBUG_COM: event.VRIread Called, Assigned handle 11, Real handle=17281E24BF4 159109 ### DEBUG_COM: event.VRIread Called, Assigned handle 17, Real handle=17281E24BF4 196281 ### DEBUG_COM: event.VRIread Called, Assigned handle 23, Real handle=17281E24BF4 Each time it is referring to the handle for the device you opened two back -- refer backwards from the last mentioned above, for example. However, each "real" handle is a duplicate of the previous ones. So when the real COM device indicates a read, it finds the first such entry every time. Are you not closing devices at all? The assigned handle is only cleared when the com device is closed. I should, in any case, check for the existence of the handle already in the table, and assign the same integer. That would solve the reading problem. But I'm a little worried about why previous entries aren't cleared. Pete

Okay. So now the start at 5 is explained. It is because of 4 previous com.openhid's by your INITHID! 91390 LUA.0: LINDA:: [INIT] Initialising HID devices... 91390 LUA.0: LINDA:: [EVNT] InitHID... 91422 ### DEBUG_COM: AddHandle Called, Assigned 1, Real handle=17BB36F84A4 91422 ### Used handle table entries now are: 91422 ### 1, 17BB36F84A4 91453 ### DEBUG_COM: AddHandle Called, Assigned 2, Real handle=0 91453 ### Used handle table entries now are: 91453 ### 1, 17BB36F84A4 91500 ### DEBUG_COM: AddHandle Called, Assigned 2, Real handle=0 91500 ### Used handle table entries now are: 91500 ### 1, 17BB36F84A4 91515 ### DEBUG_COM: AddHandle Called, Assigned 2, Real handle=17BB358E8B4 91515 ### Used handle table entries now are: 91515 ### 1, 17BB36F84A4 91515 ### 2, 17BB358E8B4 91562 ### DEBUG_COM: AddHandle Called, Assigned 3, Real handle=17BB37D2024 91562 ### Used handle table entries now are: 91562 ### 1, 17BB36F84A4 91562 ### 2, 17BB358E8B4 91562 ### 3, 17BB37D2024 91609 ### DEBUG_COM: AddHandle Called, Assigned 4, Real handle=17BB34FB734 91609 ### Used handle table entries now are: 91609 ### 1, 17BB36F84A4 91609 ### 2, 17BB358E8B4 91609 ### 3, 17BB37D2024 91609 ### 4, 17BB34FB734 91640 ### DEBUG_COM: AddHandle Called, Assigned 5, Real handle=0 91640 ### Used handle table entries now are: 91640 ### 1, 17BB36F84A4 91640 ### 2, 17BB358E8B4 91640 ### 3, 17BB37D2024 91640 ### 4, 17BB34FB734 91640 LUA.0: LINDA:: [hHID] OnRepeats cleared for nil.... 91656 LUA.0: LINDA:: [COMM] Check File Exists "linda-cfg/aircrafts/FSX Default/config-hid.lua" 91656 LUA.0: LINDA:: [INIT] Default HID config loaded... 91656 LUA.0: LINDA:: [COMM] Check File Exists "linda-cfg/aircrafts/FSX Default/config-hid.lua" 91672 LUA.0: LINDA:: [INIT] Current aircraft (FSX Default) HID config loaded... 91672 LUA.0: LINDA:: [COMM] Checking VRI 91687 LUA.0: LINDA:: [COMM] Enabling VRI 91687 LUA.0: LINDA:: [COMM] Check File Exists "linda-cfg/aircrafts/FSX Default/config-mcp2a.lua" 91687 LUA.0: LINDA:: [COMM] ConnectMCP - Connecting to MCP Panel... 91703 ### DEBUG_COM: AddHandle Called, Assigned 5, Real handle=17281E24BF4 91703 ### Used handle table entries now are: 91703 ### 1, 17BB36F84A4 91703 ### 2, 17BB358E8B4 91703 ### 3, 17BB37D2024 91703 ### 4, 17BB34FB734 91703 ### 5, 17281E24BF4 I'll look more, for the event.vriRead problem, later tonight. Called away just now by by good wife. I think it may need additional logging in any case. Note sure what's going on here either, with apparently three calls but the first two with 0 real handles. Could your InitHID be calling com.openhid and possibly getting a zero answer the first two times? Does it "try" for devices? (I ought to tidy my code to detect that BEFORE trying to assign a local integer as handle). 91453 ### DEBUG_COM: AddHandle Called, Assigned 2, Real handle=0 91453 ### Used handle table entries now are: 91453 ### 1, 17BB36F84A4 91500 ### DEBUG_COM: AddHandle Called, Assigned 2, Real handle=0 91500 ### Used handle table entries now are: 91500 ### 1, 17BB36F84A4 91515 ### DEBUG_COM: AddHandle Called, Assigned 2, Real handle=17BB358E8B4 91515 ### Used handle table entries now are: 91515 ### 1, 17BB36F84A4 91515 ### 2, 17BB358E8B4 Pete

Only with L-M's help. It has been requested, among other things. Pete

Yes, as clearly stated in the User Guide, that is what the "Ignore" button is for! Please do peruse the User Guide. BTW there is no difference in this to the old and superseded 4.959! The current FSUIPC4 is 4.968, the current FSUIPC5 is 5.101m -- please see the Download Links subforum. FSUIPC5 is improving rapidly, you need to keep up to date. Please ALWAYS check for a later version before posting, it saves a lot of time! Pete

I've studied the code. How the handles are increasing by 6 each time is puzzling. It's as if you have three devices with both ports of the VRI=COMx,COMy pair being open each time. Though only Lua uses the short (32bit) handles, 1-1023. Could that be the case, in Lua? And then the first use of the VRI event is on the fifth opened port? I've added logging to show the complete allocation tables each time Open is called and each time event.VRIread is called. lease try this: FSUIPC5101n_TEST.zip Add Debug=Please LogExtras=x2004 to the [General] section of the FSUIPC5.INI file. This is a first step. I might need to add more logging depending on the results of that. Pete

Where? You have to keep in touch with what is going on via the Updated Modules thread in Download Links subforum. You need to update your FSUIPC5 as well. All the PFC stuff has been available for several days. Anyway I think even the "Dowson" page on Enrico Schiratti's site, the original place for such downloads, mentions PFChid64 and gives the correct link. Nevertheless you need to update to the current interim FSUIPCupdate for it to work, until I can get a complete new release put together. Pete

See my previous reply. I think your prtoblem is to do with using the PMDG 777 plus FSUIPC's AutoSave. When a flight is saved the PMDG complex aircraft effectivrely freeze the computer for seconds whilst they gather cockpit information to save. You either need to stop using AutoSave in FSUIPC with PMDG aircraft, or possibly (and this isn't guaranteed to work) extend the "SimConnectStallTime" in the FSUIPC5.INI fie. The number there is in seconds, ranging 1 to 20. Since Autosaving when using such aircraft will create disjointed flights (bad hesitations), I would recommend you just stop using Autosave -- do flight saving manually before any crucial stages of flight, like approach. Incidentally, you are still using the original version of FSUIPC5. It has been updated many times since then. You should update to 5.101m, available in the Download Links subforum. Pete