Loading lua files manually

[Rick]

I need to be able to load lua files in code at run-time that doesn't use import at the top. I have a cut scene script that you specify the lua file that has the cut scene in it as one of the editor properties. I then use dofile() and in the editor this all works great. However, when we publish the lua cut scene file ends up in the data.zip file and dofile() doesn't know how to load it from there so it fails.

 

TJ and I have a game coming out today on the gameplayer and the intro sequence is hacked together and I did the import at the top of the intro sequence in my cut scene script just to make it work so we could release it, but that won't work when we want multiple cut scenes in our game.

 

So is there a way to load a lua script during run-time that isn't import at the top of the script and have that work when published?

 

Josh, perhaps you can rewrite dofile() like I'm guessing you did import so that it handles the lua in zip files when published?

[reepblue]

This is because dofile() is not apart of the Leadwerks Filesystem. I've had similar issues loading xml files. Did you try using Execute file of the interpreter?

 

Interpreter:ExecuteFile("Scripts/myscript.lua")

[Rick]

I see no documentation link of Interpreter in the API reference. I'll give this a try though thanks.

[reepblue]

If you have the standard edition, if you look at the header files, you can see what functions are exposed to lua, and I think you can expose a functions yourself with tolua++ if they are not already. Not every function that's accessible in lua scripts is documented.

[Rick]

In this case we are using Game Launcher so exposing isn't an option, but just annoying these aren't documented. I never go to the header file. Shouldn't have to, but thanks for the info. Will try that function.

[Josh]

The official API is the stuff that is guaranteed not to change. There's a lot more than that, but it can be in flux, not work correctly, may change, etc. Or in some cases it's just too complicated that I don't want the user to have to worry about it.

 

In the case you describe, would it work to import a file with a function in it, and then call that function when you want the code to be run?

[Rick]

In the case you describe, would it work to import a file with a function in it, and then call that function when you want the code to be run?

 

That's what I'm doing right now as a workaround. It seems import only works at the top of script and not inside a function so I hardcoded the intro script to be imported into the cutscene script and it defines a global function that I call, but that's just a workaround really. Ideally this functionality is generic and I could release it to others. For that to happen I need to be able to load a lua file dynamically inside a function. That's what I was doing with dofile(). The best part was my function in the cut scene was defined as local and I returned it so no messy global issues. The below is the ideal situation I think,just doesn't work when published.

 

--inside my generic CutScene.lua file that takes an editor parameter of what lua file holds the details to the cutscene

self.func = dofile(self.scriptFile)

[beo6]

Exactly the same issue I had here:

http://www.leadwerks.com/werkspace/topic/13175-lua-loadfile-not-working-with-zip-files/

 

I think you need to forget about trying to stay local with files that are loaded at runtime unfortunately.

[Rick]

I switched it to use the Interpreter:ExecuteFile() function and had my entity script accept both the lua file to load and a string which represents the function name in that file to run which I them get from with: _G[funcName]

 

This works but as beo6 pointed out in his thread it's not ideal as it clutters up the global space and has potential collisions with function names if not careful. Would love for dofile() to be rewritten like I assume import was to handle zip files and such?