Player walk animation not played when moving while thread is running

[Rebusmind]

Describe the bug
When the player is moved via an actor move event while also a thread is moving another actor, the movement animation is not played.

To Reproduce
See this script:

When I disable the thread, the player walks normally.

Expected behavior
The walking animation should be played even if a thread is running.

Screenshots
With the thread running in parallel:

Without thread:

Platform (please complete the following information):

• OS: Windows 11
• App version 4.1.3

Additional context
This only seems to affect the player, other actors can walk at the samt time with no issue.

[chrismaltby]

Hi @Rebusmind just spent a little time investigating this, I believe it's caused by the exact same issue as #1644 that you raised earlier. As soon as you start a thread it's causing the script to become unlocked, which is currently needed to allow multiple threads to run at once but has the side effect of causing topdown_update() to run at the same time too. topdown_update() is responsible for moving the player when your press input (what you saw in 1644) and also for stopping the player animation when no input is pressed (the issue you're seeing here)

To me it seems like there needs to be a way for switching between

• Only one script runs at once
• Multiple scripts can run but the game update function doesn't run (<-- this isn't possible now)
• Multiple scripts and game update function can run simultaneously

Or something that ends up with a similar result. I'll need to have a think how best to achieve this and how to not break any existing projects in the process.

[Rebusmind]

That makes sense.
Maybe threads could have a checkbox for this titled "Disable player input"? Might be too abstract, though. And it would have to work with every scene type.

[chrismaltby]

After giving it some thought I've finally come back to this and think I have a solution.

In the latest develop branch:

gb-studio/CHANGELOG.md

Line 32 in 5b2d054

- Add events "Pause Logic For Scene Type" and "Resume Logic For Scene Type" allowing manual control of if the scene's update function should be running or not. You can use this when running multi-threaded scripts (such as a cutscene with multiple actors moving at once) to prevent player input while the script is running.

I've added two new events "Pause Logic For Scene Type" and a resume equivalent. If you want to have a script that uses threading but prevents the scene logic from running (so the player can't move from joypad input etc) you just need to put a Pause just before you start the threads and resume when your script is finished. Changing the current scene will resume automatically when the new scene loads.

There's an example project in the GBVM repo at:
https://github.com/chrismaltby/gbvm/tree/main/examples/thread-cutscene/project

Which can be tested with the latest develop build (assuming the build succeeds)
https://github.com/chrismaltby/gb-studio/actions/runs/13202450418

[Rebusmind]

This sounds great! I wonder if there are other use cases for these events. Otherwise they could be added as a checkbox inside both thread events, couldn't they?
(either way, I'm looking forward to trying them out. I can't get GB Studio to build the dev version anymore, so I'll have to wait for the next release)

[chrismaltby]

They could be added as a checkbox inside both thread events, couldn't they?

Unfortunately I think it's not quite that simple, say if you had the checkbox on the thread events and that would make it so that if checked at the beginning of the threads it would "pause scene updates" and at the end it would "resume scene updates". Well what if you ran multiple threads at the same time and one took less time to run than the other

• Thread A would pause the scene update function
• Thread B would pause the scene update function
• Thread A would finish resuming the scene update
• Here the player can now move
• Thread B would finish also resuming but it was already resumed

I'm just using a simple boolean value to store if the scene is currently paused so multiple threads could cause race conditions like this. You could potentially keep a running counter of how many threads are currently causing scene pausing but I think there's a few too many ways this could go wrong (Stopping a thread from another one preventing the counter from being updated) causing a game to lock up.

I can't get GB Studio to build the dev version anymore, so I'll have to wait for the next release)

by any chance have you tried using the latest instructions from the README

> cd gb-studio
> corepack enable
> yarn
> npm run fetch-deps
> npm start

I recently made a few changes that these commands handle

• Updated to using a new version of yarn that requires corepack
• I moved the game engine to use a Git submodule rather than having a second copy of the engine codebase. npm run fetch-deps handles retrieving this
• I moved the GBDK binaries out of the repo and they now need to be fetched from the GBDK releases archive. npm run fetch-deps should also fetch the right version for your platform and put it where it needs to be.
• I also updated to using Node 21.7.1 at some point so this could be the problem too.

[Rebusmind]

Ah, yeah, I didn't think that through. I think the way it is handled now is great.

About building GB Studio, I'm getting errors when updating npm or yarn. I'd probably have to start fresh with everything (last time I used it was for the GB Studio 3 alpha). But I want to stick to full releases anyway.