Dan,
I’m been working with Googles V8 engine for Javascript. But I’ve been following Robert’s work and am excited by what the potential is.
The instructions I gave you just builds basic Lua. You would need to add a an extension like this but once that’s done, it should be pretty easy.
Jerry
And it’s in! Enjoy!
Looks interesting. I’ve not really used lua before, but i know that it’s used for game modding (including RTS games), though the only games i ever really modded used .xml for storing all the important things like unit data and such, though there was one game i used to mod that used lua scripts for the AI and mission scripts.
I’ve seen several people a while ago inquiring about the mod-ability of games made with this engine, and they said that lua scripting integration would go along way to making that possible, and as someone who would like to support modding for any games i create, this addition will certainly make that easier, provided the lua scrips can be compiled outside the editor at runtime when the games are launched.
Guess i need to start brushing up on my lua, but my c++ is terrible, any estimate on when this will make it into the main launcher-based version of the engine? 4.6 maybe?
Cool stuff Robert. I’m going to try and use this for an experimental MS CLR binding so I can get C# working in Windows builds. Do you have any further features planned for this functionality?
This is doable but not currently supported. In general it usually is up to the game if it provides hooks for mods. In some cases you may not want them.
I do hope so, yes 
Sure! I want to improve the workflow when editing scripts and updating the compiled classes in the editor (or editor game) so it’s more automatic. I also want to add support for exposing functions with arbitrary number of arguments.
I’ve started implementing a CLR binding and have run into an issue with FScriptContextBase::CreateContext(), it can only create a Lua context, and there’s no way to override that behavior. Perhaps some sort of registry of FScriptContext factories is in order, the various ScriptPlugin(s) could then register their factories, and FScriptContextBase::CreateContext() could pick the relevant factory at runtime based on some sort of identifier passed in by the caller.
The idea behind the plugin is that you only have one script integration active (otherwise supporting multiple integrations can get tricky). I’d suggest changing ScriptPlugin.build.cs and ScriptGeneratorPlugin.build.cs to support different script integration (essentially defining WITH_SOMEOTHERSCRIPTINGLANGUAGE in case Lua is missing and there’s another one present).
The approach you’ve suggested probably would’ve worked just fine in the pre-subscription days when only the big boys could afford source access and maintained their own forks of the engine, but it’s not very practical now that every man and his dog can be a UE4 developer. First of all, it’s a PITA for me as the language integration developer because I have to hack engine source to enable the new integration. I don’t have the rights to distribute engine source publicly, so I can’t put my code into a standalone public repository on GitHub. I’d have to maintain my own engine fork just for this, or publicly distribute just my code and a series of convoluted instructions that should be followed in order to enable my language integration, but both of those options are a PITA for me and the end user.
Remember that the end user may not be a programmer, and even if they are they may have little desire to maintain their own fork of the engine source just to enable my language integration. As it stands you can’t add a new language integration via the ScriptPlugin to the launcher build of the engine. IMHO language integrations should be standalone plugins, download one from the Marketplace, enable it on the Plugins window in UnrealEd, and you’re good to go, no stuffing around with preprocessor definitions, or replacing this or that source file and rebuilding the entire engine.
I agree that having more than one active script integration could be tricky, and it’s not a huge issue yet. However, I foresee a time when the Marketplace will contain useful assets that are written in Lua, Python, C#, etc., and I think all those assets should be interoperable… it’s not going to be terribly efficient in terms of performance but if you’re an Indie you can probably sacrifice some performance for all the time saved not rewriting these assets from scratch.
That makes sense, sure. I originally thought that there’s going to be multiple plugins that support a specific language and this one could be used as a template once it matures (because I imagine that each integration would like to add specific functionality to it). However, I guess it could be possible to dynamically support different language contexts and have the engine -> script glue (class compiler etc) be only one. I’ll look into it.
Hi Robert,
I’m not clear yet, but are there Lua bindings to all of the objects in UE4? Is it possible to compose UIs with Lua, etc?
I think it’s just limited to the objects Blueprint has access to. You do have access to the Hud class, so you can do some UI stuff.
jCoder, does that mean anything Blueprint has, Lua can use too? Does Hud let you have access to the typical sets of controls (text input, numeric, drop down, button, scrollable area, etc.)?
Also, for most up to date Lua support is it best to get from Git? Final question, is UE4 using Lua 5.2?
ATM you have access to ANY DLL-exported class from the engine that has any UPROPERTIES or UFUNCTIONS (otherwise there’s not point in having it exported). This is not limited to Blueprint types.
Yes, it’s built against Lua 5.2.3
Thanks Robert. Does this mean it’s possible to control Slate using Lua? It would be really nice to be able to compose UIs (in-game tools for custom A.I. and testing) using Lua, to avoid re-builds. I know UMG is on the way, but that could be months before it’s stable. Is it possible to do this now with Lua? Also are there any Lua examples? Oddly I didn’t see Lua mentioned once in the entire 4.3 release notes.
No, it is not possible, because Slate widgets don’t have UPROPERTIES or UFUNCTIONS. UMG widgets do have UPROPERTIES and UFUNCTIONS so you’ll be able to manipulate them via Lua, but obviously that’s not going to solve your immediate problem.
So is it as easy as wrapping Slate widgets with the U* binding macros and rebuilding UE4 so those classes are Lua visible?
Nope, you would need to create UMG GUI objects instead. They handle the heavy lifting of wrapping the slate widgets we provide in the UMG designer.
Ok got it. So basically to do any UI stuff with lua, sit tight and wait for 4.4+ when UMG has evolved and can be accessed with Lua?
Also, is there a doc somewhere that shows a quick start to doing Hello World with Lua in UE4? I may have missed it, but I can’t find anything showing how to get this working. Also, is there a list of all Lua exposed classes/functions? Would be handy to have this rather than digging around source for those exports.