Tested and couldn’t get goto to work with HTML5 builds either.
2 Likes
Ah, you’ve stumbled across one of a few discrepancies between the different platforms Defold supports. On HTML5 and iOS 64 bit platforms we use plain old Lua 5.1 and on all other platforms we use LuaJIT.
goto is a part of Lua 5.2 and upwards but LuaJIT which is based on Lua 5.1 has a couple of added extensions, one being the support for goto.
To ensure that your game will run on all platforms it is not recommended to use any language features other than the ones provided by Lua 5.1.
We have three separate tickets in our backlog to make the platforms using Lua 5.1 more in line with LuaJIT:
DEF-1742 - Add support for the bitop module in Lua 5.1
DEF-1439 - Add support for pcall and xpcall inside coroutines in Lua 5.1 (using the Coco extension)
DEF-1284 - Upgrade LuaJIT to a version which supports 64 bit ARM
6 Likes
It explains everything. Thank you!
1 Like
Fixed in Defold 1.2.115
Well, we updated to v2.0.5, and added support to 64bit OSX. The 64 bit arm will have to wait until we update to version 2.1.0 (which is in beta right now)
1 Like
Ah, yes, my bad. Thank you for clarifying!
HTML5 still doesn’t work with goto and labels
goto and labels would be really very convenient with dialog based scripting to jump around to different paths within the same script file!
It probably never will. There’s no LuaJIT version (that I know of) that runs in a browser.
The other option would be that we run Lua 5.2 instead of 5.1 on platforms that doesn’t support LuaJIT and on LuaJIT build with DLUAJIT_ENABLE_LUA52COMPAT (http://luajit.org/extensions.html).
1 Like
I think then my options are to use while loops for sections within dialog based scripts for repeatable sections, or to parse scripts before running and break them down into labeled chunks before running.
I have a chunk parser/loader working now and now am trying to improve it. I’ll only activate it for HTML5 builds and otherwise use goto/label features.
Is
_,label,_ = string.match(file, "^(::)(.*)(::)$")
an acceptable way to check if a line matches a label or is there a better way?
That looks about right. How are you using labels by the way? I’ve never really considered them that useful.
The VN dialog scripts are generally executed linearly via a coroutine. Usually line by line one at a time with some commands having a wait period or waiting on user input. Labels can be used to make sections which should be on a loop a little cleaner in this style of scripting. While loops would also be possible but it’s less ideal for this style I think. And at some point I’d like to make a visual editor for dialog scripts and labels would be better for that. Labels can also be used to skip sections within a linear dialog script without wrapping everything in if statements.
2 Likes
Is this ever a possibility?
Right now no. We have no plans at all for this. It was way too time consuming to update to latest LuaJIT but in that case there was a direct need and an improvement to be had. For this upgrade to 5.2 the benefit is much smaller and not something we would like to spend time on doing.
3 Likes
Is it possible to add build warnings when using an unsupported Lua fature by the selected platform?
Or even betterva generic build warning when using a feature that is not 100% cross platform?
1 Like
Sure, we could spend time to implement something like that, but I’m not sure it is worth it. I’m also thinking that an editor script and the use of the luac command from Lua 5.1.x could catch the use of unsupported features.
Have you guys experimented with https://github.com/openresty/luajit2 or is the LuaJIT implementation in the engine isolated so I could experiment with this? Do you know the reason for LuaJIT not supporting HTML? The engine uses emscripten for HTML5 but I’m guessing that LuaJIT isn’t fully LLVM compatible. Honestly no idea, but it sounds like an interesting side project to try to add HTML support to LuaJIT for anyone brave enough 
EDIT: I’m seeing the project Fengari: https://fengari.io/ which supports is a Lua VM rewriten in JS. Wondering if you guys have had a chance to look into this?
It’s isolated and built per platform. See the packages folder of the repo. LuaJIT is widely accepted as the Lua version to use in games. We use Lua JIT 2.10-beta with support for arm 64.
The openresty version has diverged even more from Lua 5.1 so I don’t really see it as a viable option for Defold.
Fengari is a reimplementation of Lua 5.3 in JavaScript. It’s not really an option and I don’t see how it could work with native extensions for instance.
2 Likes
Linux editor 1.9.6 (2024/12/19)
External text editor: neovim with Lua LSP.
Run with F5 (local build for Linux).
I’ve had a goto in my script for exiting an inner loop (removed since, managed now with break).
That was working for a few days, until this morning when i had an error message in the build windows of the editor telling me that i couldn’t use goto with Lua 5.1 (when pressing F5, so LuaJIT should have been used).
I’ve tried to remove goto, but even after, i was still getting the error message.
Modifications in the source file wasn’t “seen” by Defold editor.
I’m using an external text editor, but even by opening the source file in the Defold editor, i still had the same issue.
I’ve tried then differents things, Shift+Control+B for forcing a complete rebuild. I was still getting this error message. Anyway, i think build has nothing to do with debug run.
I’ve exited Defold, killed my LSP (just in case), then run again the Defold editor. Then the modifications in source file were at last taken into account. I could even put a goto again without the Lua version error.
I know you probably don’t have answer for this, but i leave this message in case or someone else would encounter this issue. Then, we could narrow what has triggered it.