Pete Dowson

The WideClient.log is only half the story. Where's the server side? You need to also show the WideServer.log from the FSUIPC installation folder. The FSUIPC6.log file would also be relevant. Pete

I don't know what you mean by "trigger". It should load and execute automatically if loaded via the [Auto] method. There are other ways of loading it. Could you describe what you mean by "trigger"? Pete

No, nothing's frustrated me. I was just pointing out the errors. With the Lua not being loaded, it obviously cannot work. Does it work after you corrected the entry in [Auto] as i showed? Pete

That's very bad. Must be a corrupt file! The msi versions are supplied to let you reinstall. Perhaps the bad file was the reason it didn't get installed when FSX-SE was installed. Okay. Let me know, please, if FSUIPC is still okay when you back out of the Beta. If that then works then I think I know how to fix the issue of a failure to install SimConnect for others. Thomas suggested to me what might be happening. Pete

Seems that you are using FSX-SE but it has not installed its version of SimCconnect. Try running the MSI installer for SimConnect from this folder: C:\Program Files (x86)\Steam\steamapps\common\FSX\SDK\Core Utilities Kit\SimConnect SDK\Lib Regards Pete

Two things wrong there: 1. The [Auto] section is for complete commands, not a list of files. It is for Macros,as well, not just loading Lua files. If fact any control you can assign can be executed automatically as well. So the entry should be 1=Lua A320Engine The documentation does explain this, with examples! 2. You do NOT add entries to the [LuaFiles] section at all. That is where FSUIPC keeps track of which Lua files you've added. Please do NOT edit it! Pete

I know. I thought I explained, sorry. I thought the binary parts we included in FSUIPC4 ere those COREs, but they're not -- they are simply compiled versions of those 3 Lua's I'm now asking folks to install in the Lua folder. The point was that in FSUIPC4, for many purposes there was no need to install anything else whatsoever. Ooops! You are right. The updated PDF didn't make it into the ZIP! Duh! Fixing it now. Blame old age, I'm feeling more doddery by the day. That's why I'm retured, really. 😉 Thanks, Pete

Possibly. I'm not sure from whereabouts in the complex lua code that emanates. But do note that "Win32" doesn't refer to 32-bits these days. almost everything in Windows in "Win32". The main 64-bit Windows API's are still in modules with names like System32.dll and so on. The stupid bit is the %1 which should seemingly have been replaced by the name, though the name is there anyway, "passerelle" (twice in fact). That error message isn't in the FSUIPC Lua code. You found a 64-bit version of 5.1? 5.1, as mentioned in the Plug-ins document. I could have done with a 64-bit version of the Lua compiler for 5.1. Did you ever find one? Pete

The INI file you posted contains very little, not even many default settings. It looks like you truncated it before uploading. If you didn't something very weird is going on. Please try again. If that really is the extent of your FSUIPC settings and you have your controls assigned in FSUIPC then it isn't surprising that they don't do anything. However, you appear to have controllers enabled in P3D, so i assume you aren't using FSUIPC. The Log shows errors in SimConnect which certainly shouldn't occur. But more mysteriously it shows you have no controller devices connected anyway! If the only change you've made is installing Chaseplane I would say that its installation has done something pretty bad. Try uninstalling it and installing again. I'm not sure without checking, but possibly if there are no devices there's no JoyScan file simply because it isn't scanning. I don't think your troubles are related to FSUIPC Pete

Okay. Documentation updated accordingly and included in the "Latest" package in this subforum: Pete

I was trying to test with the socket examples we provide in the Lua examples ZIP. I edited the first part of testsrvr, this bit: -- This supports the "testclnt" Plug-In to test the facilities -- The SOCKET module is built into FSUIPC, but is not active until "required" socket = require("socket"); to match your code. So now the code to the failure on bind is: -- This supports the "testclnt" Plug-In to test the facilities package.path = "" package.cpath = "" -- The SOCKET module is built into FSUIPC, but is not active until "required" socket = require("socket.core"); -- Change the host name to the name of the PC running this Server -- The "localhost" name only serves local clients host = "localhost"; -- The port must match the port selected in the client and not clash with others. port = "8384"; server = assert(socket.bind(host, port)); So it is looking in whatever socket.core contaiins. Should I revert to socket = require("socket") as before? Why do you set those two paths to ""? I thought your code was part of the solution. Too much, I think. Not sure what the difference is between the vc6 and vc8 ZIPs are, but I don't need lua5.1.exe ot lua5.1.dll. Do all the others go into a Lua subfolder, like yours? There is a Lua folder within the ZIP, containing Socket.I'll try again with the contents of that folder in the FSUIPC installation Lua subfolder instead (I do wish I understood all this) ... Okay! That works! 😄 But only if I revert the Lua plugin code to what it was originally. i.e leave the paths alone and using require("socket"). I tried stripping down what was installed in the Lua subfolder, and all it seems to need is ltn12.lua mime.lua socket.lua I now think that the three binary files included in the 32-bit versions of FSUIPC are just these three modules compiled with a 32-bit version of the Lua compiler., so it might be worthwhile looking for a 64-bit version. If I can do that then I can make 64-bit FSUIPC the same as far as LuaSockets are concerned as FSUIPC4. The trouble is that the Lua code in FSUIPC is based on the 5.1 version of Lua and i think the problem we had was that no 64-bit compiler was available. Of course, the socket subfolder does contain ftp.lua, http.lua, smtp.lu, tp.lua and url.lua, but those were needed for FSUIPC4 too if you use those protocols. For now I'll just change the instructions to provide the new LuaSockets link and list those files to be used from it and where they go. Pete

You buy one on SimMarket. http://secure.simmarket.com/john-dowson-fsuipc6-for-p3dv4-5.phtml. there's a special uppgrade price -- details are there, just scan down a little. Pete

I've started doing tests on this solution, and i'm afraid I am running into problems. There are missing functions, like "socket.bind". This is with your second linked package above and also with the full package downloaded from your second link. I think the "core" being linked to in FSUIPC is only partial. The missing 32-bit binaries presumably supply the rest. Your solution appears to work provided you only use some as-yet undeteremined subset of the expected functions. So, I think I will leave things as they are for now. Thank you very much anyway! Pete

The only safe way is to disable controllers in the sim altogether. Whenever it thinks a new deevice has connected (or even reconnected) it will try making default assignments automatically. Pete

Those are PMDG controls, not added by FSUIPC, and all that happens when you assign buttons to them is that FSUIPC sends the control number and the parameter you set to the PMDG aircraft, nothing more. So, either the PMDG aircraft installation is in a mess or buggy (in which case report in the PMDG support forum, OR, more likely, you have multiple assignments to those buttons. If you haven't disabled controllers in FSX, FSX-SE, or P3D (whichever you areusing), then the buttons have probably been assigned there -- if not by you, then by the sim itself. Pete

Ah, I've just found this piece of code: lua_pushcfunction(L, luaopen_mime_core); lua_setfield(L, -2, "mime.core"); lua_pushcfunction(L, luaopen_socket_core); lua_setfield(L, -2, "socket.core"); That's called (eventually) in the package library. So those binary files we built into the 32-bit version of FSUIPC weren't needed, and probably weren't even used? We just changed the paths being used to be reltive to the FSUIPC folder. All this is the result of using other folks' code without understanding it! Thanks for your help ... I know what to do now. Pete .

Of course I don't mind, whatever works best. I don't understand your changes in any case,, but then I don't understand where it is getting the access through. Sorry, where does that leave us then? With your original solution? Do you mean put your solution into our documentation? That's with this installed in a Lua sub-folder, right? If so, thanks, I'll do that. But I think we should host that ZIP here. Pete

Is it a 32-bit DLL or a 64-bit one? If you are running P3D4 or P3D5 and therefore using FSUIPC5 or FSUIPC6, you need a 64-bit DLL. Otherwise 32-bit. This is because a 64-bit process can't use a 32-bit DLL and vice versa. If you need a 64-bit DLL but can't find one, then you could consider using WideClient and running your Lua there. You can run WideClient on the same PC as FSUIPC by setting the ClassInstance parameter non-zero, so it doesn't clash. Of course you'd need a WideFS registration. Pete

No. That's the problem with memory corruption. It can have any number of effects. I've been pleading with Lockheed-Martin ever since they first released P3D however many years ago so do some sort of checking of the validity of that weather data before they use it to set their internal tables, but with no result so far. I might have another go at them. Pete

Yes, that is why I don't know how it is working. That's fine. I'll do some testing with the examples we have, just not today. It'll be this week sometime, when I will link to PCs and try some data transfer. It may be between P3D4 and FSX-SE. But in any case, if you would kindly post your (main) solution in the User Contributions subforum I would be grateful. Else, if you preferred, I could make what would effectively be a copy of your post above, crediting you. Either way would do. I'll add to it as I find out more. Pete

We probably did not need the whole log in any case. If it is that big after Zipping then it must contain a lot of repetitive stuff, of which we'd only need a sample. I can't get the file from your drive. I guess you shared it with John? Aha! That means that your P3D installation is corrupted, or is getting corrupted. The names used for the control events are the same in P3D4 and P3D5, yet it looks like SimConnect is not finding them in its list. Things to do to try to fix this: 1. First uninstall the P3D5 client (only) -- don't deactivate. 2. Then re-install the client -- there's an installer for this (an .msi file) in your downloaded P3D5 package. 3. Test again. 4. If still the same, try adding "NoWeatherAtAll=Yes" to the [General] section of the FSUIPC6.INI. This stops FSUIPC asking SimConnect to access the weather files. These files are binary and they are not checked before use by SimConnect. Any corruption in one of those can wreak havoc in memory as a consequence. 5. Test again. If then there are none of those errors, please see Although yours isn't crashing, it is still a corruption problem. 6. If nothing above helps, then please try with no other addons -- possibly one is causing the corruption. Pete

Your example works, and you are right in that is doesn't need those core.dll's. But I don't know how it is getting past the Require, because, whilst there is a socket library in FSUIPC's Lua, there's no "http" function anywhere in FSUIPC. The socket library exposes these functions: auxiliar except timeout buffer inet tcp udp select Possibly somewhere on my system there's some DLL which is being selected to meet the needs of this Lua plug-in, but unless it's in a path searched by Wndows, or is already loaded (part of P3D4 perhaps) I can't see it. So, I remain puzzled. Perhaps the real test is whether it works on a cleaner Windows system, one without all the clutter and development code I've accumulated, Also, to be properly useful, the ftp and udp methods of transferring data needs to work. Have you used those methods? I'd need to try our examples, MasterClient.lua and SlaveServer.lua. I might do this, but not today. If the binary code we built into the 32-bit version of FSUIPC was not really needed then I am also puzzled about why, from the information we thought we understood from the notes made by the original LuaSockets developer, we actually did include it. I think we need to see it tested more widely before we can really change the documentation. In the meantime, I would be grateful if you could post your full solution (not with core.dll's missing, for now at least), in the User Contributions sub-forum, and i'll then host the Zipped package here too. Thank you very much! Pete

Okay. Thanks! will try this tomorrow and try to figure out what is going on. Pete

Well, FSUIPC3 has not been changed for years. In fact it has really gone onto the unsupported list. I don't see how reinstalling anything would change anything, unless you actually deleted all the files as well. Reinstalling FSUIPC basically simply replaces FSUIPC3.DLL with FSUIPC3.DLL. It won't until you run FS2004 with FSUIPC installed. Did you delete the file and so lose all your settings? Where are the Lua files? The y need to be in the same folder (Modules) as FSUIPC and the INI, LOG and KEY files. Are they listed in the INI file? If you can't find the INI file then FSUIPC has never been run since you apparently and rashly deleted everything. Pete

Could you share your "simple http request" please, so I can try it here and see how it manages to do anything without the needed code? Please say what files you do have, and in which folders. There's some strange magic working there and I just cannot figure out how. Thanks. I am really puzzled! i never found suitable 64-bit modules to bind into the code and didn't understand enough to convert the 32-bit version. The ones in the 32-bit FSUIPC4 are "ltn12bin.lua", "mimebin.lua" and "socketbin.lua". These are most definitely not built into FSUIPC5 or 6, and there are no 64-bit versions anywhere on my system. Thanks, Pete