Load .dll or .so from script

[rolle]

Is this possible at all? I notice GLOBAL.require overrides the usual require and does not find my dll, regardless of where I put it.

 

I have a C library I have written that adds new input methods that I would like to use in the game.

 

I tried putting this in the outmost scope in modmain.lua:

 

local testdll = require "widgets/testdll"

 

This generates error:

 

Attempt to call global 'require' (a nil value)

[rolle]

I solved it by creating a bin/lualib folder and putting the dll there. This is ofcourse not a good solution because the directory is outside the mod refinement. Also I could change the package loader in main.lua, but I assume it is frowned upon to replace main.lua in a mod?

[simplex]

I'd strongly advise against using a shared object library; mods are meant to be sandboxed, and no added functionality is worth breaching this invariant.

But anyway, you can't override main.lua from a mod, since it gets loaded before mods are (in fact, it is it that loads mods). But why did you have to change the package loader? Wouldn't putting the .so within the mod folder, extending package.cpath and require'ing it be enough?

[rolle]

Good idea, thanks, new to Lua. I kinda agree about the sandboxing; on the other hand its quite easy to break the game by just using scripting as well

[simplex]

Good idea, thanks, new to Lua. I kinda agree about the sandboxing; on the other hand its quite easy to break the game by just using scripting as well

You can break the game very easily. I'm talking about information security, since a natively compiled library would have unrestricted filesystem access and the like.

But were you able to load a dynamic library at all? I get the error

dynamic libraries not enabled; check your Lua installation    absent

when I try it.

[rolle]

Just for interest, how is file system access more restricted in  dont starve's Lua  sandbox? Could I not just use file:write on a absolute path?

 

Yes it worked for me using the code in my first post and then placing the lib in bin/lualib. I also tested to call the code. I did not try the cpath way yet. I run windows and ROG.

[DeathDisciple]

Reminds me of something, does Steam version run in elevated mode by default? Or humble for that matter?

[rolle]

Reminds me of something, does Steam version run in elevated mode by default? Or humble for that matter?

 

No. Steam runs at the same privs as your local user. Would be a big security hole otherwise . To make auto-updates work I would assume all installs are per-user, not per-machine, but I don't know.

[DeathDisciple]

Ah. I asked because of certain discrepancies of allowed and not-allowed access, and the fact that GOG shipped with elevated privileges initially (which I turned off for obvious reasons), so was wondering if that is just the distribution thing, thanks.

[rolle]

Ok strange, wonder why they needed it.

[simplex]

Just for interest, how is file system access more restricted in  dont starve's Lua  sandbox? Could I not just use file:write on a absolute path?

The engine restricts filesystem access. An absolute path to io.open will be refused, while a relative path will only be accepted if it doesn't leave the DS installation directory. There are also other restrictions, such as the absence of os.execute and io.popen, preventing the execution of external programs.

 

 

Ah. I asked because of certain discrepancies of allowed and not-allowed access, and the fact that GOG shipped with elevated privileges initially (which I turned off for obvious reasons), so was wondering if that is just the distribution thing, thanks.

That explains the issues with customs logs and stuff in mod folders.