Bedrock Edition?

[LayZeeDK]

With the Bedrock mod APIs, would it be possible to start working on something similar to ComputerCraft?

Minecraft Bedrock Edition now supports 2 languages:

• JavaScript: Bedrock Edition scripting documentation
• MoLang: Bedrock Edition MoLang documentation

More Bedrock Edition mod documentation:

• Bedrock Edition Add-on documentation

[vico93]

If i'm not mistaken @SquidDev did a very experimental "port" of CC:Tweaked for Bedrock.

[SquidDev]

As vico mentioned, there's a very proof-of-concept port at SquidDev-CC/bedrock. While it technically works, there's several deficiencies in the current scripting API which make it pretty unusable:

• Mojang/MS's scripting work has been largely focussed on entities up until now, meaning there's still a lot of functionality we need which is missing (whatever Bedrock's equivalent of tile entities are, persistence, etc...). I'd expect this functionality to be introduced in the future, but no clue what the time span for this is.

• CC runs computer code on a separate thread in order to not block the main server. However, Bedrock edition doesn't support that (it's JS so single-threaded, and there's no web workers as far as I can tell), so we have to do some weird time-slicing stuff. That, along the fact that we're running a Lua interpreter within JS, means everything ends up being super slow.

[LayZeeDK]

Wow, that's an awesome first step, @SquidDev!

Regarding singlethreading, if we don't have dedicated web workers, is there anyway we can hook into the Lua scheduler and make it run for example 3 ms at a time, then unblock the main JavaScript thread, schedule the next Lua execution, and so on?

Regarding persistence, if we have HTTP and in particular web sockets, I guess we could add a web server to run alongside Minecraft to handle persistence.

[SquidDev]

Is there anyway we can hook into the Lua scheduler and make it run for example 3 ms at a time, then unblock the main JavaScript thread, schedule the next Lua execution, and so on?

That's exactly what we do right now! Well, it runs for 30ms, as each server tick should be 50ms.

I'm honestly not sure why the performance ends up being as bad as it does - copy-cat uses a similar pre-emption technique to not block the browser thread, and the lag isn't anywhere near as bad. I'm fairly sure the JS is being JITted - it's using Chakra after all - goodness knows.

Regarding persistence, if we have HTTP and in particular web sockets, I guess we could add a web server to run alongside Minecraft to handle persistence.

I'm not what APIs are exposed to the JS side. I'd be surprised if we had access to AJAX/Websockets/fetch, but honestly can't remember.

[LayZeeDK]

If it's anything like a regular browser, each VM turn has 16.67 milliseconds to run business logic and rendering. Realistically, that means something like 8-9 ms tops to run business logic if we expect 60 frames per second.

30 milliseconds definitely sounds like too much blocking at a time.

Do we have requestAnimationFrame?

Some resources on this subject

• Optimising for 60fps everywhere
• In the loop

[SquidDev]

If we expect 60 frames per second.

I think this is the kicker - we don't have to. The Minecraft server (which is where the computer actually runs) only runs at 20tps (ticks per second), which gives us a much larger timespan to work with.

Do we have requestAnimationFrame?

We do on within the GUI code, but IIRC none of the standard "run immediate" functions (setTimeout, requestAnimationFrame, Promise.resolve) are available on the server. It kinda makes sense: the sever isn't async in the same way the browser is, it needs to have finished all work by the end of the tick. Just ends up being a pain for us :).

[LayZeeDK]

Interesting. Did you try lowering the scheduler execution time to 15ms? 5ms?

[hooded-person]

I'm not what APIs are exposed to the JS side. I'd be surprised if we had access to AJAX/Websockets/fetch, but honestly can't remember.

For so far I understand it you are able to use a api for bedrock dedicated servers that allows https connections and therefor websites and other things to communicate with the server.