A few more questions

[TennoAntenno]

(Continuation of this discussion)

Hi again!
School kept me busy, so I had to take a break from working on this.
Thanks again for your help, awaiting is working great now! I do have a few more questions though:

1. Is it possible to pause a coroutine? I'd like to be able to pause (or end) the currently running code, for example by pressing a button.

2. How can I prevent infinite loops? Running something like while true do end freezes the entire game. Is there a way to guard against this?

3. How should I sandbox the code when using GODOT_UTILITY_FUNCTIONS? Now that I’ve opened the utility functions library for awaiting, I’m not sure how to properly sandbox the user code. You mentioned using an environment table, but I’m not quite sure what that means in practice.

4. I'm sometimes getting a Lua Error: nil message. This usually happens when trying to call a non-existent function. Syntax errors show up correctly, though. Here's how I'm handling errors, maybe something’s off?

   coroutine = LuaCoroutine.create(main_function)
   result = coroutine.resume()
   if result is LuaError:
       print_console("Lua Error: " + str(result.message))
   coroutine.failed.connect(func(err): print_console("Lua Error: " + str(err.message)))

5. Error line numbers are incorrect due to prepended code. I prepend a string of custom await enabled functions to the user script, so users can just call move("forward") without manually wrapping it in await(). However, this shifts the line numbers (i.e. an error on line 1 will show as line 15). I tried appending the functions to the end instead, but then Lua doesn’t recognize them.

Thanks again for your time and for building this extension. It’s been incredibly helpful!

[gilzoide]

Hey @TennoAntenno , welcome back!

1. Is it possible to pause a coroutine? I'd like to be able to pause (or end) the currently running code, for example by pressing a button.
2. How can I prevent infinite loops? Running something like while true do end freezes the entire game. Is there a way to guard against this?

You can use a count hook to yield coroutines whenever they execute count instructions (added in Lua GDExtension 0.4.0). This fixes the infinite loops, as well as make it possible for you to just discard the coroutine without ever resuming it, for example with the press of a button.

You can setup count hooks in GDScript like so:

const COUNT = 1000

func _coroutine_hook_func(debug_info: LuaDebug):
    prints("The coroutine ran", COUNT, "instructions, yielding...")
    # Returning HOOK_YIELD here makes the coroutine yield
    return LuaThread.HOOK_YIELD

var my_coroutine: LuaCoroutine = ...
my_coroutine.set_hook(_coroutine_hook_func, LuaThread.HOOK_MASK_COUNT, COUNT)
my_coroutine.resume()

# After the first resume, if the coroutine isn't finished, it will yield automatically after COUNT instructions.
# You can then re-resume it or cancel / just discard it as necessary

3. How should I sandbox the code when using GODOT_UTILITY_FUNCTIONS? Now that I’ve opened the utility functions library for awaiting, I’m not sure how to properly sandbox the user code. You mentioned using an environment table, but I’m not quite sure what that means in practice.

The environment table is the "global" table used by the loaded script. If you get/set "global" values from Lua code, they will actually access the environment table, which by default is _G, Lua's global table.
For example, even if you open all libraries, but pass an empty environment table to LuaState.load_string / LuaState.do_string, the script won't be able to access any of the global values in _G, because its env table is empty.

Here's an example GDScript that passes an env table that contains only print:

var lua = LuaState.new()
lua.open_libraries()
var script_env: LuaTable = lua.do_string("""
  -- script env contains only the "print" global function, so scripts will only be able to access it
  return { print = print }
""")
var script = lua.do_string("""
  -- by passing "script_env" as this script's env, it is used instead of _G for global access (both set/get)
  print(_G == nil)  -- true, since "_G" is not present/accessible in script_env
  print(print ~= nil)  -- true, "print" is the only thing in the env
  some_global = 5  -- sets script_env["some_global"] to 5
""", "", script_env)
print(script_env.some_global)  # 5

Now you can cherry pick the exact functions you want to the script by only providing them in the environment. Even if the global Lua table contains all utility functions, the script won't be able to access them.

4. I'm sometimes getting a Lua Error: nil message.

Hmm, that may be a bug, I'll check it out later.

5. Error line numbers are incorrect due to prepended code.

Well, if you prepended some lines to the script, then the line numbers are technically correct.
What I suggest is ditch this prepended code and define such functions as globals (or define them in the environment table) so that the script don't have to be edited and line numbers stay the same.

Thanks again for your time and for building this extension. It’s been incredibly helpful!

No problem, thank you for using it!
Keep them Discussions coming \o/

[TennoAntenno]

Thanks for the response, @gilzoide!

I didn't have time to look at all of the answers, but regrading the infinite loops, the solution you provided is kind of problematic. Say for example a player wants to make a car. The code for it would have a while loop that checks inputs and adjusts throttle & steering accordingly. If we would limit the number of instructions, the car would stop running after a few seconds. Another example could be a turret that is constantly waiting to detect enemies and then shoot. I should've reworded my question as sometimes infinite loops are necessary. I just want to prevent the game from freezing.

Right now, the throttle and steering functions have a cooldown so they wouldn't freeze the game when executed in a loop. I guess what I want is that every instruction (function execution, variable declaration, value assignment, statements, etc.) would have a small cooldown, like 0.01 seconds. This would allow for an infinite loop if necessary for the player's contraption, while not completely freezing the game.
I've looked at the HookEvent documentation, and maybe HOOK_EVENT_LINE could be the solution? I basically want to halt the code for a short moment every time an instruction occurs.

I'm stoked to finally get over these hurdles and start working on the gameplay!

[gilzoide]

If we would limit the number of instructions, the car would stop running after a few seconds

Well, yeah, but then you manually resume the coroutine in the next frame or something like that. In this case, you have control of how the script runs.

I've looked at the HookEvent documentation, and maybe HOOK_EVENT_LINE could be the solution?

Count hooks are more reliable than Line hooks. I remember reading somewhere that line hooks is much more costly to detect in the runtime than count hooks (can't confirm where, sorry). It wouldn't make much of a difference now, would it? With line hooks, you still have to manually resume the coroutine, so it doesn't matter much if the stop is in lines or Lua VM instructions count.

I basically want to halt the code for a short moment every time an instruction occurs.

That's exactly what count hooks do (thinking of "instructions" as Lua VM instructions though) =]

[TennoAntenno]

then you manually resume the coroutine in the next frame or something like that

That makes a lot of sense... 😅 I'll look into it tomorrow.

[TennoAntenno]

Hey,
After implementing the COUNT hook that stops the code, I noticed that functions that have an await cooldown no longer await, and just execute at the same rate as any other function without pausing the code.
When running the following:

i = 0
while true do
	i = i + 1
	print(i)
end

everything works fine, but when I run:

i = 0
while true do
	sleep() -- supposed to pause for 1 second
	i = i + 1
	print(i)
end

then it will run the same as the previous snippet, without waiting for the sleep() function. However, after a few seconds the game will grind to a halt. I assume there are a bunch of sleep() timers simultaneously running in the background.

Here is the relevant code, in case I did something wrong:

func _physics_process(_delta: float) -> void:
	if running: coroutine.resume()

func _coroutine_hook_func(debug_info: LuaDebug):
	# Returning HOOK_YIELD here makes the coroutine yield
	return LuaThread.HOOK_YIELD

var main_function = lua.load_string(text, "user_code", script_env)
coroutine = LuaCoroutine.create(main_function)
coroutine.set_hook(_coroutine_hook_func, LuaThread.HOOK_MASK_COUNT, COUNT)
result = coroutine.resume()

function sleep()
	await(_sleep())
end

lua.globals["_sleep"] = func():
	await get_tree().create_timer(1).timeout

Thanks!

[gilzoide]

Oh, I know your problem. So the thing is: Lua's await actually works by yielding the current coroutine and connecting the coroutine's resume to the signal. So you should avoid resuming the coroutine manually if it was yielded by await vs by the hook.

A simple boolean value should be enough in your case. You can name it something like "yielded_in_hook", set it to true on _coroutine_hook_func and only resume the coroutine in _physics_process based on that:

var yielded_in_hook: bool = false

func _physics_process(_delta: float) -> void:
	if running and yielded_in_hook:
		# don't forget to reset yielded_in_hook to avoid false positives!
		yielded_in_hook = false
		coroutine.resume()

func _coroutine_hook_func(debug_info: LuaDebug):
	# yielding coroutine from hook, mark yielded_in_hook as such
	yielded_in_hook = true
	return LuaThread.HOOK_YIELD

(disclaimer, not tested)