-
-
Notifications
You must be signed in to change notification settings - Fork 88
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add #hasEnded() #151
Add #hasEnded() #151
Conversation
…ckahn#135) * Add typescript definitions generation * `ts`: Fix lint errors * Fix doc:view script * Add type generation to ci script Co-authored-by: Jeremy Kahn <jeremyckahn@gmail.com>
This is an attempt to fix breaking CI jobs: https://stackoverflow.com/a/68464475
Thank you for the PR @arthuro555! I should have time to review in the next day or so. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Thanks for adding this new method @arthuro555. I'll merge and release this momentarily. Out of curiosity, what's your use case for this method?
This is has been released in |
It's for usage in GDevelop. The events loop is separate from the JavaScript one and shouldn't be deeply coupled to JavaScript features, as we have a modular architecture where we could technically swap out the runtime engine's language at any time, and the event loop should work exactly the same independently of the runtime implementation language. Therefore, our events loop cannot really use JavaScript async/await or callbacks directly - instead, we do what the JavaScript event loop would do, check at every update of the loop if the state of the events' target is in a state where the event should be triggered. Usually we just use an extra variable that we set to true when a callback is called, and use that variable to know whether to trigger events or not, but that is annoying, bloats our code, adds a variable & a callback that are redundant, is error prone... Therefore, it is more convenient and performant for us to have a way to check if the state of the object (in this case the tweenable) is in a state where it should trigger an event (in this case "the tween is complete" event), instead of having to set a callback on it (in this case via Tweenable#then). |
That makes a lot of sense. I think that's how a number of other engines such as RPG Maker MV work as well. It's exciting to see GDevelop mature as a game engine to this degree! 😁 |
Adds a way to check whether the tweenable has finished tweening or not.