Put Lua C API in Export Table?

[Olipro]

Assuming any developers read this - Would you consider exporting (into the export table of the PE) the Lua C API functions so that they can be invoked either with a simple GetProcAddress() call or if you include a generated LIB for dynamic linkage, even better. Obviously with the included PDB it's trivial to identify the functions to hook at runtime, but that's ugly and I'm hoping will be made unnecessary.

This would open up a lot of opportunity for interfacing the game with other programming languages and frameworks. My first thought was creating a hook-in to .NET for easy creation of a windows forms GUI for mod development/testing/messing around purposes. Although interfacing it with MRuby would be equally interesting, or integrating the in-game chat with Twitch/IRC.

[Moonheart08]

Great idea! Integrateing ASM/C/C++/C#... Etc etc into the game would be really helpful.

[Rseding91]

That's not likely to ever happen. The potential for desyncs, crashes, save corruption, and just malicious mods in general is far too high for any benefits from exposing that portion of Lua in Factorio.

[Olipro]

That's not likely to ever happen. The potential for desyncs, crashes, save corruption, and just malicious mods in general is far too high for any benefits from exposing that portion of Lua in Factorio.

"Malicious Mods" is a bit of a stretch - someone willing to do that can simply make a mod that hooks the C API via runtime injection and then add their malicious code later on.

As for the desyncs, crashes, corruption etc. issue - Presumably you would have a folder for loading native mods and, if such a mod is found, indicate to the user a set of strong warnings about the possible risks.

Either way though, whilst you're entirely correct about such risks, they're there whether Factorio has 1st party exposure of the Lua C API or a third party shim.

[ratchetfreak]

That's not likely to ever happen. The potential for desyncs, crashes, save corruption, and just malicious mods in general is far too high for any benefits from exposing that portion of Lua in Factorio.

"Malicious Mods" is a bit of a stretch - someone willing to do that can simply make a mod that hooks the C API via runtime injection and then add their malicious code later on.

As for the desyncs, crashes, corruption etc. issue - Presumably you would have a folder for loading native mods and, if such a mod is found, indicate to the user a set of strong warnings about the possible risks.

Either way though, whilst you're entirely correct about such risks, they're there whether Factorio has 1st party exposure of the Lua C API or a third party shim.

The better option is to expand the lua api so that everything you would want to turn to the C-api for is achievable through the lua api

[Olipro]

That's not likely to ever happen. The potential for desyncs, crashes, save corruption, and just malicious mods in general is far too high for any benefits from exposing that portion of Lua in Factorio.

"Malicious Mods" is a bit of a stretch - someone willing to do that can simply make a mod that hooks the C API via runtime injection and then add their malicious code later on.

As for the desyncs, crashes, corruption etc. issue - Presumably you would have a folder for loading native mods and, if such a mod is found, indicate to the user a set of strong warnings about the possible risks.

Either way though, whilst you're entirely correct about such risks, they're there whether Factorio has 1st party exposure of the Lua C API or a third party shim.

The better option is to expand the lua api so that everything you would want to turn to the C-api for is achievable through the lua api

If what you are suggesting were achieveable, Lua itself would not need a C API.