Jump to content
The simFlight Network Forums

adrem

Members
  • Content Count

    31
  • Joined

  • Last visited

Community Reputation

0 Neutral

About adrem

  • Rank
    Advanced Member

Profile Information

  • Gender
    Not Telling
  • Location
    Switzerland
  1. Hi, I haven't used this offset before, but with my current FSUIPC version 6.08, it reads 0x6008.
  2. That was just to show you that socket.core and mime.core were being loaded somehow even with empty module search paths, so not at all intended to be used during normal operation - sorry for the confusion ­čśä I don't really understand why you'd want to change anything. 64-bit FSUIPC already includes socket.core and mime.core which are the only binary components of luasocket. For the rest, the user can just download this archive and unzip the lua folder that contains just the lua files into the fsuipc directory to have the complete package: http://files.luaforge.net/releases/luasocket/luasocket/luasocket-2.0.2/luasocket-2.0.2-lua-5.1.2-Win32-vc6.zip. No further steps are required to make it work. As far as I understand, in your 32-bit version, ltn12.lua, mime.lua and socket.lua are also part of the binaries, but that's unnecessary. By the way, I don't see any changes in the documentation - Lua Plug-ins.pdf is exactly the same.
  3. Were you looking for the bind function inside the table exported by socket.core? The bind function is in socket.lua. By the way, some parts in the packages that I uploaded are definitely not compatible with the 2.0.2 binaries, so you should be using the 2.0.2 lua files. As far as I can tell, everything is there.
  4. I would guess so, assuming that the same code snippet exists in your 32-bit version.
  5. 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. 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. 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?
  6. 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. 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.
  7. 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"
  8. 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). 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). Sure, I'll do that later today or tomorrow.
  9. 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)
  10. 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
  11. 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).
  12. 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).
  13. But are you sure it's actually launching? Does it work when you launch it manually via a bind?
×
×
  • 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.