Jump to content
The simFlight Network Forums
Sign in to follow this  
Jason Fayre

has any solution been found for lua sockets in fsuipc 6

Recommended Posts

Hello,

I'm writing a LUA script for controling the A2A bonanza for my Talking Flight Monitor accessibility software.

Has any solution been found for using lua sockets in p3d v4? I know that the existing LUA implimentation won't work. In the FAQ, there is a solution posted, but the proper DLL for 64-bit isn't available.

What is the best way for communicating between my external software and a LUA script? I can use reserved offsets, but that may not give me enough space. I need to pass strings to my applications to be output with text-to-speech when l:vars change.

I tried just using l:var read/write calls in my application, but had some strange results. This was possibly due to a problem with the pyuipc python module.

I would rather not force my users to purchase WideFS if they don't need to.

Any suggestions would be apreciated.

 

 

Share this post


Link to post
Share on other sites
1 hour ago, Jason Fayre said:

Has any solution been found for using lua sockets in p3d v4? I know that the existing LUA implimentation won't work. In the FAQ, there is a solution posted, but the proper DLL for 64-bit isn't available.

You could consider using WideClient which remainds a 32-bit program. If you aren't using it already on a Network then you can use it on the same PC as the sim by setting the ClassInstance parameter to a non-zero value. Of course this would require a WideFS registration.

1 hour ago, Jason Fayre said:

What is the best way for communicating between my external software and a LUA script? I can use reserved offsets, but that may not give me enough space. I need to pass strings to my applications to be output with text-to-speech when l:vars change.

You could apply for dedicated space. Or possibly space shared with other applications with which it would never be used.

1 hour ago, Jason Fayre said:

I would rather not force my users to purchase WideFS if they don't need to.

Ah, I didn't see that before I wrote my main suggestion.

Is your application freeware? If not then forcing the purchase of WideFS might be an alternative to coming to a commercial relationship with us.

Pete

 

Share this post


Link to post
Share on other sites
1 hour ago, Jason Fayre said:

Has any solution been found for using lua sockets in p3d v4?

These are from my LuaRocks installation: luasocket64.zip

Share this post


Link to post
Share on other sites
6 minutes ago, adrem said:

These are from my LuaRocks installation: luasocket64.zip

If that works with FSUIPC5 and 6 can we host that here? Where's it from?

Pete

 

 

Share this post


Link to post
Share on other sites

So what would I need to do to get this working on a 64-bit install? Do I still need the lua socket library from somewhere?

Share this post


Link to post
Share on other sites
Just now, Pete Dowson said:

If that works with FSUIPC5 and 6 can we host that here? Where's it from?

Pete

 

 

Sure - I've built them on my machine using luarocks.

Share this post


Link to post
Share on other sites
9 minutes ago, adrem said:

Sure - I've built them on my machine using luarocks.

Thank you!

Pete

 

Share this post


Link to post
Share on other sites
15 minutes ago, Jason Fayre said:

So what would I need to do to get this working on a 64-bit install? Do I still need the lua socket library from somewhere?

Good question. Ive downloaded adrem's ZIP and had a look and it just seems to be core.dll's. I'm afraid I don't know how to use those.

19 minutes ago, adrem said:

Sure - I've built them on my machine using luarocks.

adrem, do you have an example of how to use these in a Lua plugin in FSUIPC5 otr 6?

Thank you! All this internet protocol stuff is a mystery to me! 

Pete

 

Share this post


Link to post
Share on other sites

Oh, I thought Jason only needed the binaries. Here's the complete package: luasocket.zip

You can 'require' it straight away if you unzip the content into FSUIPC installation\Lua.

@Pete Dowson I'm not actually sure if the binaries are needed at all. Could it be that they're already included in FSUIPC? Otherwise, I don't understand my this works on my system:

package.path = ""
package.cpath = ""
assert(require "socket.core")
assert(require "mime.core")

EDIT: It says on page 2 of FSUIPC Lua Plug-Ins.pdf that these modules are included, but not with FSUIPC5 (it says nothing about FSUIPC6 which is what I'm using).

Share this post


Link to post
Share on other sites

Perfect. Thanks! I'll take a look at this later today. I may be able to get away with using offsets, but this gives me a lot more flexibility if I can get this working.

 

Share this post


Link to post
Share on other sites
3 hours ago, adrem said:

I'm not actually sure if the binaries are needed at all. Could it be that they're already included in FSUIPC? Otherwise, I don't understand my this works on my system:

I'm note sure either, but I think the clue is using 

assert(require "socket.core")
assert(require "mime.core")

rather than the Lua plug-ins PDF way:

require("socket") for Sockets support, and/or
require("mime") for Mime support.

I think requiring for example "socket.core" is pointing it to the core.dll in your socket folder, and the same for mime.

Quote

It says on page 2 of FSUIPC Lua Plug-Ins.pdf that these modules are included, but not with FSUIPC5 (it says nothing about FSUIPC6 which is what I'm using).

Ah, that needs updating (along with probably many references elsewhere). It' the sSame in FSUIPC6. We didn't bind either core dll's into 64-bit FSUIPC because we couldn't find versions which were compatible with the version level of Lua we are using, and updating the complete included Lua code was a fearful amount of work we couldn't contemplate.

If your solution works, I'd like to host the file package here and post your help in our User Contributions subforum. Of course I'd rather you did the latter job, if you wouldn't mind. If you could do that first, I'd upload the file package and change the link in your post accordingly.

Would that be okay?  Pretty please?

Pete

 

Share this post


Link to post
Share on other sites
3 hours ago, Jason Fayre said:

Thanks! I'll take a look at this later today. I may be able to get away with using offsets, but this gives me a lot more flexibility if I can get this working.

Please confirm if you do get it working.

Thanks,
Pete

 

Share this post


Link to post
Share on other sites

In any case, the document says that you were unable to find the compatible 64-bit versions of these modules, but it seems like they're there after all - just the core submodules. If I delete the core dlls from the luasocket folder, it's still working (I tried a simple http request).

Share this post


Link to post
Share on other sites
6 hours ago, Pete Dowson said:

We didn't bind either core dll's into 64-bit FSUIPC because we couldn't find versions which were compatible with the version level of Lua we are using,

Are you sure about that? How was I able to import the modules after removing the module search paths (package.cpath = "") and even physically removing the dlls, if they hadn't been preloaded in Lua already?

Moreover, even if I have the dlls in the right folders, it's not them that are getting loaded. Their version is 3.0, but the _VERSION field of the loaded module says 2.0.2

Share this post


Link to post
Share on other sites
11 hours ago, adrem said:

In any case, the document says that you were unable to find the compatible 64-bit versions of these modules, but it seems like they're there after all - just the core submodules. If I delete the core dlls from the luasocket folder, it's still working (I tried a simple http request).

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.

10 hours ago, adrem said:

Are you sure about that? How was I able to import the modules after removing the module search paths (package.cpath = "") and even physically removing the dlls, if they hadn't been preloaded in Lua already?

Moreover, even if I have the dlls in the right folders, it's not them that are getting loaded. Their version is 3.0, but the _VERSION field of the loaded module says 2.0.2

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

 

 

Share this post


Link to post
Share on other sites
4 hours ago, Pete Dowson said:

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

Unzip the second archive I've uploaded here into FSUIPC Installation\Lua, then delete the dlls from the core and mime folders. Try this code:

local http = require "socket.http"
local google = http.request("http://google.com")
print(google)

 

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites
1 hour ago, Pete Dowson said:

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.

If you unzipped the lua files into the Lua folder, it's expected that it would load socket.http since the Lua folder is inside package.path. The require function also searches subfolders using the dot as the separator. The http module then requires mime.core and socket.core (via socket.lua) which usually come as dlls.

Besides FSUIPC, I have two other instances of lua interpreters - a standalone exe and inside an in-sim dll. In neither of them does the same magic work.

When you call require, it goes through the module searcher functions that are inside the package.loaders table. In a vanilla Lua, there are 4 of them, but your Lua has 5. It is the first one that successfully loads these mysterious core modules and I don't think it's part of vanilla Lua because it doesn't work as documented (package.preload is empty).

1 hour ago, Pete Dowson said:

Also, to be properly useful, the ftp and udp methods of transferring data needs to work. Have you used those methods?

Sorry, I'm not really familiar with any of the network stuff either, right now I  have luasocket installed only because it's required by another library (it only uses the tcp function).

1 hour ago, Pete Dowson said:

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

Sure, I'll do that later today or tomorrow.

Share this post


Link to post
Share on other sites
3 minutes ago, adrem said:

The http module then requires mime.core and socket.core (via socket.lua) which usually come as dlls.

Yes, that is why I don't know how it is working.

4 minutes ago, adrem said:

Sorry, I'm not really familiar with any of the network stuff either, right now I  have luasocket installed only because it's required by another library (it only uses the tcp function).

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

 

Share this post


Link to post
Share on other sites
47 minutes ago, Pete Dowson said:

But in any case, if you would kindly post your (main) solution in the User Contributions subforum I would be grateful.

If you don't mind, I'll modify socket.lua and mime.lua like this to make them load the dlls (so that the binaries are the same version as the lua files):

local socket = package.loaders[4]"socket.core"

socket = type(socket) == "function" and socket() or require "socket.core"

Share this post


Link to post
Share on other sites

Actually, the dlls crash with an access violation error 😄 I tried with a standalone interpreter - same result.

The culprit is linking against the lua core statically (of course, there's no other option with FSUIPC). If I link against the standalone interpreter's dll import library, it works just fine with the standalone interpreter.

I personally don't see a problem with just leaving things as is and amending your documentation, since it obviously works with 64-bit.

18 hours ago, Pete Dowson said:

Perhaps the real test is whether it works on a cleaner Windows system, one without all the clutter and development code I've accumulated

I remembered that I helped a guy who uploaded a lua plugin for FSUIPC by giving him the luasocket library. The plugin has been downloaded 900 times and no one complained, so it works on a variety of systems.

Share this post


Link to post
Share on other sites
19 hours ago, adrem said:

If you don't mind, I'll modify socket.lua and mime.lua like this to make them load the dlls (so that the binaries are the same version as the lua files):

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.

3 hours ago, adrem said:

Actually, the dlls crash with an access violation error 😄 I tried with a standalone interpreter - same result.

The culprit is linking against the lua core statically (of course, there's no other option with FSUIPC). If I link against the standalone interpreter's dll import library, it works just fine with the standalone interpreter.

Sorry, where does that leave us then? With your original solution?

3 hours ago, adrem said:

I personally don't see a problem with just leaving things as is and amending your documentation, since it obviously works with 64-bit.

Do you mean put your solution into our documentation?

3 hours ago, adrem said:

I remembered that I helped a guy who uploaded a lua plugin for FSUIPC by giving him the luasocket library. The plugin has been downloaded 900 times and no one complained, so it works on a variety of systems.

That's with this installed in a Lua sub-folder, right?

On 5/15/2020 at 7:28 PM, adrem said:

the complete package: luasocket.zip

If so, thanks, I'll do that. But I think we should host that ZIP here.

Pete
 

Share this post


Link to post
Share on other sites
29 minutes ago, Pete Dowson said:

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.

That code bypasses the loader function that loads those magic modules by directly invoking the loader function that only searches for dlls using the package.cpath paths. Now, as I said, the dlls turned out to be unusable because they crash.

29 minutes ago, Pete Dowson said:

If so, thanks, I'll do that. But I think we should host that ZIP here.

I recommend that you host or post the link to this instead: http://files.luaforge.net/releases/luasocket/luasocket/luasocket-2.0.2. What I posted was version 3.0 while the magic core modules are 2.0.2 and I have no idea if the newer lua files are compatible with them throughout.

29 minutes ago, Pete Dowson said:

Do you mean put your solution into our documentation?

I meant saying in the documentation that socket.core and mime.core are included in 64-bit FSUIPC so the user just needs to unzip the luasocket 2.0.2 lua files into the lua folder. 

Have you tried looking in your code whether you have customized the package loader functions?

Share this post


Link to post
Share on other sites
15 minutes ago, adrem said:

I meant saying in the documentation that socket.core and mime.core are included in 64-bit FSUIPC

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?

 

17 minutes ago, adrem said:

Have you tried looking in your code whether you have customized the package loader functions?

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

.

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.