Pete Dowson

Who are CFY? They should have applied to me for offsets to be assigned, so I could reserve them. there's no way I can avoid treading over these things, or allowing others to, if they do not get reserved space. 9000-93FF was allocated to Niko Kaan for Lekseecon, a program for the Level D 767 and 757 aircraft. Likewise 9400-953F have been allocated, and 9800-9FFF is all used for assorted FSUIPC facilities. There is some space i can allocate, but I need someone to apply for it. Pete

But these details show that even with the Orbweaver connected, FSUIPC still rcognises and assigned these devices: 157 ------------------------------------------------------------------- 172 Device acquired for use: 172 Joystick ID = 4 (Registry okay) 172 4=Saitek Pro Flight Yoke 172 4.GUID={04F9B800-3954-11E7-8012-444553540000} 172 Device acquired for use: 172 Joystick ID = 3 (Registry okay) 172 3=Saitek Pro Flight Quadrant 172 3.GUID={4667AD50-4C6F-11E7-8001-444553540000} 172 Device acquired for use: 172 Joystick ID = 5 (Registry okay) 172 5=Razer Orbweaver Chroma 172 5.GUID={04F942D0-3954-11E7-8010-444553540000} 172 Device acquired for use: 172 Joystick ID = 0 (Registry okay) 172 0=Saitek Pro Flight Rudder Pedals 172 0.GUID={04EB1200-3954-11E7-8001-444553540000} 172 Device acquired for use: 172 Joystick ID = 1 (Registry okay) 172 1=Throttle - HOTAS Warthog 172 1.GUID={04F34F60-3954-11E7-8006-444553540000} 172 ------------------------------------------------------------------- There's not going to be any change if that device isn't there or added later. Even the assigned Joystick numbers look the same as those used in your assignments, though with so many devices I think you should enable JoyLetters so that your assignments still work even if the Joystick numbers change. You say: What do you mean by "the other buttons"? Are you saying some assigned buttons work and some don't? Are you testing with a default aircraft, or the PMDG? Test with default. Just looking at your default assignments, you have buttons assigned to joystick IDs 1, 2, 3, 4 and 5. (See the list of devices above to see what they are). You don't have a Joystick ID 2, but i see you have alternative assignments in any case: 2=P2,18,K119,10 -{Key press: ctl+F8}- 3=P1,1,K119,10 -{Key press: ctl+F8}- 15=P4,7,K73,24 -{Key press: alt+I}- 16=P4,6,K85,24 -{Key press: alt+U}- 17=P2,15,K85,24 -{Key press: alt+U}- 18=P2,17,K73,24 -{Key press: alt+I}- 52=P5,2,K188,8 -{Key press: ,<key}- 53=P5,3,K190,8 -{Key press: .>key}- 70=R2,14,K188,8 -{Key press: ,<key}- 71=R2,16,K190,8 -{Key press: .>key}- except for these: 31=R2,10,K104,8 -{Key press: Num8}- 32=R2,12,K98,8 -{Key press: Num2}- 33=R2,13,K100,8 -{Key press: Num4}- 34=R2,11,K102,8 -{Key press: Num6}- 72=P2,4,K67,24 -{Key press: alt+C}- Do the axis assignments work okay? You've only mentioned buttons. Pete

The extra information I added was the "flags" part of the error message. The fact that it is zero means that the filename part was of zero length for the four calling layers before the actual "fopen" which fails. I'm really not able, with spending many days on it, to track how this arrives at the earliest layer I was able to track to. So the only way, I think, is for me to be able to reproduce it here. Unless you want a stab at debugging? You'd need Visual Studio 2015. I might try tracking top down, rather than waiting for the error then tracking up to see were it gets lost. Remind me of the Lua code doing the looading. Is this this, from many messages ago? path = ipc.get("PATH_SYS") .. "init" where PATH_SYS = linda/system/ if file_exists(path .. '.lua') then ipc.runlua(path) else _log('[START] Unable to find INIT.LUA - Try Restarting') end and you DID actually once test with "path" being logged before the runlua, didn't you? Pete

But that version was design to fix problems most X-55 users had with FSUIPC 4.964 and before. In fact one kind user donated his unused X-55 to me for working out exactly whay those problematic Saitek devices are so much trouble. It is important to provide full details so things can be fixed and move on: never retreat to older versions that have other problems. To this end please find the FS/P3D Modules folder and suppply the following files (ZIP them first if too large): FSUIPC4.LOG FSUIPC4.INI FSUIPC4.Joyscan.csv These files will help us help you. Pete

Is it a Joystick type of device, with buttons or axes you can assign? In what way does it "bloack" buttons. Do you mean FSUIPC still finds and assigns the other buttons, but thay don't work, or do you mean the other devices aren't found? I think that was one of the devices known to cause problems and which were eliminated. If it isn't then I think maybe it is masquerading as a joystick device? You attach a log showing a good session which does not feature the extract you show above at all, so it is really of no use at all. Please do four things: 1. Try with FSUIPC 5.103e, now available in the Download Links subforum. 2. Supply a log showing the problem, NOT one showing everything good. 3. Also show the FSUIPC5.Joyscan.csv, which is a concise summary of the scanning results. 4. Download HidScanner from the Download Links "Useful Additional Programs" thread, run that, and supply its log too, please. Pete

There's no option. It wasn't worth making an option when it is very little extra code and just one extra log line when such an error occurs. The now built in error message says: luaL_loadfile fopen error n, flags xxxx, filename "name" The flags only mean something to me. I can track where they are set or cleared a the few levels I mnaged to add the empty "" filename check to. That message will just precede the normal *** ERROR message you are getting. Pete

I've tried to do this in 5.103e (see the Download Links subforum), but I've only mamaged to check on a couple of levels above the failed "fopen" function. That it nested about 6 deep from your Lua (execurting the load in my C cde calls it directly, calling from within a Lua is complicated. Getting into the code at layers above the lowest three or four is a nightmare. Data and parameters (especially) are on the Lua stack, Working out where on the stack they are and what format everything is in is really difficult. the only was I can realistically track this down is by reroducing it here. Then I should be able to see that state at easch level. By only guess at present is that something in your Lua code is corrupting something else, and whether it matters or not is less likely here than on the system you are using. Get it to happen again with 5.103e and show me the log. i doubt it will tell me much, but you never know. Pete

You need to buy an FSUIPC5 key. FSUIPC5 is not FSUIPC4 which was not FSUIPC3. Pete

Keyboard assignments do nothing unless you use them. Test on a default aircraft first, always. Pete

As well as what Thomas says, is the axis calibrated in FSUIPC? I'm not sure now without testing, but I don't think FSUIPC can disconnect it unless it can intercept it, and it will only do that if you calibrate it in FSUIPC. If it seems "crazy" it is either because your X axis is not well calibrated, or possibly more likely because FSX is using the trim too. Pete

It isn't quite that easy. The Client Data system means requesting Simconnect to notify me or when such data becomes available. I'm not sureif I can disable it later. I'd need to take a look. In any case, the difficulties which forced me to change it was simply that I was requesting each of the three aircraft data blocks in separate SimConnect clients -- because originally, when they were in the main FSUIPC offset Client, SimConnect complained I was asking for too much data. Hopefully, with 64-bit implementation now, that won't be a factor. I'll try putting them all back in the main client first. Pete

5.103b only supports the offsets for the 747. Sorry, due to other problems (see another thread near here about the PMDG 777) I temporrily removed 737 and 777 support. I didn't put this in the change notes because I didn't realised they were released already. The difficulties were rrelated to the multiple aircraft support causing bad freezes on some folks systems. I'll be fixed this week. Pete

Yes, i undestood that. I was only suggesting replacing it with a router cofigured as a ifI externderwith it's WifI connected to the Internet. then you only have one network. Anyway, please follow Thomas's correction (which information is also as documented in the WideFS documentation, by the way). Pete

That's really a big ouch!. Why not change the switch for a router with WLAN and simply only enable its Internet connection? Why is the connection between the two computers not direct rather than going to a switch? Anyway, have you tried specifying the IP address explicitly as I said earlier? Then WideFS wouldn't case about the other LAN. Pete

So where is 10.0.0.2 coming from, as Windows itself is most certainly usually returning this as the IP address of "FLUGSIMULATOR"! Something makes it think that! Not only that, but a good connection is made with that, for a while! There's no need for the latter. If both computers connect to your Internet route, you should NOT have another connection. Or, if there are insufficient connections on the router, connect the switch to the router and both computers to the switch. It is simply a very bad idea to have two LANs! The Wireless side will connect ot the same network on the router if that is where you have wireless enabled. If you only have wireless on one of the PCs then you have a very poor router. The main thing to do is sort out your crazy networking. I don't think Aivlasoft's EFB currently uses WideFs in any case, so I don't know. You'll need to ask on their site. As for WideFS I'd strongly advise againste ever using it on a Wireless link. Sorry, I'm not sure that's relevant. I assume that is for some other reason? Pete

Ah, sorry, you should stick with 5.103 at present. When did the 777 for P3d4 come out? 5.103b only has PMDG747 client data support built in because there seems to be a problem in having multiple clients with P3D4. I don't know why, but can cause a full 85 second feeeze in the whole sim on some systems (Two of mine exhibit this, one doesn't). This is independent of whether any PMDG aircraft are already installed. I could try re-enabling the multiple clients to see if that helps, but make it individually optional for each of the three PMDG aircraft supported. One of the problems really is that I have to ask for client data for all three as I don't know which wil turn up if any. I took the decision that an 85-second freeze for any one user (myself included) wasn't worth it "on the off-chance". And I really did not know that anything other than the 747 had been released. I'll try renabling all three aircraft client data reads, with none in separate SimConnect clients. This method didn't eotk with FSUIPC3 -- Simconnect complained I was asking for too much data. I'll not be able to make this change before Monday, but please do remind me during that day. I don't guarantee it will work of course, but we can but try. Unfortunately none of the PMDG aircaft I've ever tried work fully on my systems. The P3D4 747 just hangs P3D with a black screen -- the update is worse than the first, which was okay if I loaded a different aircraft first. Regards Pete

Certainly, if I find anything relevant. It might instead be the use of a 5.3 version compiler. FSUIPC's Lua system is frozen at 5.1. With the amount of source changes I needed to weld it into FSUIPC's multi-thread plug-in system, I'm not about to update it. Can you find a 5.1 x64 compiler? Pete

No, but thank you for the offer anyway. I've got some different ideas to check first in any case. FSUIPC4 has been okay without this extra check for all its life so far, so it isn't desperate. I had just hoped to have separate thread checking the connection whilst PMDG freezes the system to save a flight. I think that might be doomed in any case. SimConnect itself ptrobably gets frozen too. Another idea is to suspend my time-out check when a flight is saved, until the message stream from SimConnect resumes. Detecting the latter as opposed to further messages arriving before PMDG have frozen things is the only problem there I think. Also I'll need a limit on the time allowed in any case. Maybe 30 seconds. Pete

The log shows the same FSUIPC joystick scan results both times. The FighterStick is seen and assigned as loy #0 both times. But I also see that you are loading up LINDA, and within 8 seconds of that loading you go into the Options and do your "reload" action. So maybe LINDA is still doing something for those very few seconds you allowed? Have you tried without LINDA? The only other possibility is that the device is going to sleep during the 8 minutes (nerly) it appears to take for your system to get ready. To check that waglle each axis and click each button. It should, theoretically, then wake up. FSUIPC is not doing anything different on the second scan you force than it did on the first. Best in any case to go into Windows Device Manager, find all USB devices listed, and going into their Properties. If there's a power management section, make sure the power saving is turned off. Having Windows remove power from devices, which it does by default, is the main way folks controls seem to go dead. Pete

And why do you think FSUIPC and WideFS logs would be any good? There is nothing to indicate they were anyway involved. There is one odd thing. Yiu ServerPC si this, correct? Date (dmy): 30/06/17, Time 19:26:26.215: Server name is FLUGSIMULATOR According to the Client log, which srts over 16 minutes earlier (or atre your sysm clocks different?), the IP address of that server is 10.0.0.2:: Date (dmy): 30/06/17, Time 19:09:56.300: Client name is BOEINGSYSTEM 78 LUA: "F:\Wide FS\WideFS6999z4\Initial.LUA": not found 109 Attempting to connect now 109 Trying to locate server: Protocol not yet decided 109 Failed to connect: waiting to try again 1109 Attempting to connect now 2109 Server = FLUGSIMULATOR 2312 Trying TCP/IP host "FLUGSIMULATOR" port 8002 ... 2312 ... Okay, IP Address = 10.0.0.2 2312 Connection made okay! 8406 New Client Application: "Prosim737" (Id=7020) 13234 New Client Application: "ProsimMCP" (Id=6996) 15953 New Client Application: "CFY_TQ Console" (Id=4740) 22187 New Client Application: "sioc" (Id=5116) and the session actually fully launched a few seconds later (8 to be exact), still 16 minutes earlier. That session continued to a normal "shutdown" request was received from the Server, here: 646328 Received shutdown offset code = ADBC 646328 FS closing down (param=ADBC), disconnecting in other works, 10 minutes later. So that represents a good session before the Server log starts. Which is fine. WideClient wasn't closed, but presumably also the ProSim and other programs were not closed either. That's not a good idea. If you restart the Sim it is always best to restart any client applications if yoy want to avoid trouble. That second session seemed to have great difficulty. Naturallty there's the period before the server was ready, and WideClient continued t try to connect using IP address 10.0.0.2: 653984 Trying TCP/IP host "FLUGSIMULATOR" port 8002 ... 653984 ... Okay, IP Address = 10.0.0.2 655015 Error on client pre-Connection Select() [Error=10061] Connection refused but moving on to 16 minutes from the start, to match the Server log start (millisecond count of over 960000), by the time it thinks it successfully connected:: 1005968 Server = FLUGSIMULATOR 1005968 Trying TCP/IP host "FLUGSIMULATOR" port 8002 ... 1005968 ... Okay, IP Address = 10.0.0.2 1006984 Connection made okay! 2544406 New Client Application: "Whisky" (Id=3296) the first application it loads automatically is "Whisky". How is this possible when it didn't attempt to do that above? In the same session of WideClient, it cannot change the parameters. It then proceeds to get into communications difficulties again, as if the Server has closed or crashed. That was less than 3 minutes later, which doesn't match the Server log at all. However, all the above pales into insignificance compared to the last weird inconsistency: 4556843 Server = FLUGSIMULATOR 4556843 Trying TCP/IP host "FLUGSIMULATOR" port 8002 ... 4556843 ... Okay, IP Address = 10.0.0.2 4556859 Connection made okay! 4575062 Timed out response: connection assumed lost! 4575062 Ready to try connection again 4575125 Timed out response: connection assumed lost! 4576078 Attempting to connect now 4576078 Server = FLUGSIMULATOR 4578328 Trying TCP/IP host "FLUGSIMULATOR" port 8002 ... 4578328 ... Okay, IP Address = 192.168.1.153 4578328 Connection made okay! How does the Server's IP address suddenly, in the space of 22 seconds, change from 10.0.0.2 to 192.168.1.163, not even on the same network!? I don't know how that can happen, but it does indicate something very odd indeed with your Network. Have you got more than one connection between the two PCs? If so that is definitely NOT a good idea, especially if you expect ProSim software to be able to control the sim in any meaningful way. Also, to stop Windows supplying the IP address out of its own references it might be a lot better for you to use the ServerIPAddr and Protocol parameters in the Client INI file to set it yourself. The FSUIPC log is not relevant to this, and none of the logs are at all relevant to your server PPC crash. You'll need to look elsewhere for the answer to that. Pete

It is weird. A completely unrealted change in the same version, to have a separate thread monitoring certain non-aircraft related events (just timers in fact), to see if the SimConnect connection has actually failed or was instead was simply being held up for a long time because of things like PMDG files being saved (eg on AutoSacve), had the side effect of preventing a number of other simConnect events being signalled in the main thread. It makes no sense to me, but it applies in P3D1-3 as well. For now I'm removed that little precaution. Please download FSUIPC4969c.zip. Pete

Are you using the current;y supported version, 5.103? What "old" codes are they? If they weren't for WideFS7 (the FSX and P3D1-3 version) they won't be valid. Not needed for latest installer, and in any case those were in case you name was different. Do NOT post codes here. If you can give me the order number(s) for WideFS7, or your email address, I can check if you like. Pete

Well, nothing is different in the Lua interpreter and loader side -- EXCEPT of course that it's recompiled into 64-bit, of course (else it cannot run within P3D4). I would guess that your compiled Lua isn't 64-bit compatible. In fact that seems quite likely as I would assume they include compiled machine level code. See if there's a 64-bit version of the compiler. Pete

Thanks. I've found what the issue is. FSUIPC isn't seeing the notification from SimConnect of the change of aircraft, so it assumes it's the same one. Investigating now ... Pete

No, you've sent me my own DLL file, the one I provided for you to test!!! Pete