Skip to content
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

Capability to set the current state without doing transitions #15

Closed
JimWuerch opened this issue Aug 2, 2023 · 4 comments
Closed

Capability to set the current state without doing transitions #15

JimWuerch opened this issue Aug 2, 2023 · 4 comments

Comments

@JimWuerch
Copy link

I'd like the ability to set current without firing off any transitions or checking any conditions.

The reason is for setting the machine state when handling an undo, or loading from a save. Since the state of the world gets reverted during an undo, I'd like to be able to just set the state machine to be in the same state as it was also. Similarly, when loading state from disk, being able to set things as they were would be useful too.

Being able to specify the start state (instead of having to create a new one with how set start works now) would also work, as I could just set the start state to the previous state and start the machine.

renggli added a commit that referenced this issue Aug 2, 2023
@renggli
Copy link
Owner

renggli commented Aug 2, 2023

Added the possibility to call machine.setState(state, skipBeforeEvent: true, skipAfterEvent: true). Let me know if that solves your issue?

@JimWuerch
Copy link
Author

Looks like transition.activate and transition.deactivate still gets called. I think what I'd like is just something like _current = state, as anything a state transition would've caused will already be restored, so I'm looking to just restore _current. For undo, _current is all that matters, and for a restore situation, the rest of the machine data can be restored with the existing members.

renggli added a commit that referenced this issue Aug 2, 2023
@renggli
Copy link
Owner

renggli commented Aug 2, 2023

Hmm, but that is strange to not call activate() and deactivate(). Some transition types have assertions and break if the two methods are not called in the right order. Maybe you could wrap your handlers with some predicate that checks if they are called from within an undo operation?

@JimWuerch
Copy link
Author

Looking at the transitions, I'd guess I'd have to not add callbacks, and just use the before and after events. Given the stream and time based transitions, I can see that it makes sense not to allow setting _current directly. I think I can work with just disabling the events. Thanks for the quick update!

I think I'd only allow states with the simplest transitions inside areas that can be undo'd, which should be good enough, and I can work around the states firing off callbacks during undo.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants