Updates to the Scene Interpreter
Two bug fixes have been implemented for the Scene Interpreter. One has been an outstanding issue for a long time, and the other was recently reported to me.
Windows are still selectable
This problem has been around for months. Basically, suppose you chose an item that runs a common event and then gave it to an actor. The common event would run and say displayed a message. While this message is up, the player can still move around the item list and select another item. If the player is fast enough, they could use multiple instances of the item as well.
Today I thought of a solution and provided an implementation. This is how it works:
- Keep track of all of the windows in the scene
- Store all of the active windows temporarily before a common event is about to run
- Re-activate all of those windows after the common event has finished running
Event stops running on scene change
A bug report was sent to me recently indicating that when the scene changes (for example, if they explicitly call SceneManager.call or SceneManager.goto), the event just stops running.
Turns out, there was a bug in my design. The scene interpreter makes it so that every scene had its own interpreter. Naturally, this means that if you created a new scene, a new interpreter is created, and the old one is lost.
We don’t really have some sort of “global” scene interpreter that would exist regardless of which scene you’re in. I’ve decided to make it so that the scene interpreter is global by default, and is held by the SceneManager
Scene interpreter stack
Now, thinking about it, there could be use cases where you actually want to have separate interpreters for each scene. This is a simple use case:
- A common event runs in one scene
- This event leads you to another scene
- A new common event begins in the new scene
- When the new common event is finished, it returns you to the previous scene
- The common event from the first scene continues to run and finishes
Now, this is not possible with a single, global interpreter. This is possible, however, if each scene held its own interpreter.
So perhaps the next feature that should be implemented is a way to allow users to choose whether a common event should be run globally (regardless of scene), or locally (they will only execute within the context of a scene, but they will exist as long as the scene exists).
There is a problem, however, and that is how you determine which interpreter to update. The scene doesn’t know which interpreter to use! There needs to be a way to determine whether we are running a local common event or a global common event, and there also needs to be a way to properly set this flag somewhere before and after the event has finished running.
It seems like there’s more work to be done, but currently you should be able to use the scene interpreter to handle a lot of things.
Spread the Word
If you liked the post and feel that others could benefit from it, consider tweeting it or sharing it on whichever social media channels that you use. You can also follow@HimeWorks on Twitter or like my Facebook page to get the latest updates or suggest topics that you would like to read about.
