GOTO not working on html5 (SOLVED)

The game object is no longer working on HTML5, if I try to add the following code in the object’s script:

goto point ::point::
While it works fine on Windows and Android.

What is wrong can not be found, because the browser console not written any errors. It looks like HTML5 build only supports Lua 5.1, while other platforms work with version 5.2 or later. Is it true? Or is it a bug?

2 Likes

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

5 Likes

It explains everything. Thank you!

1 Like

Fixed in Defold 1.2.87 has been released

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?

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 :stuck_out_tongue:

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