Make auto-advance flag a requirement for conditional/expression evaluation #65312
Conversation
SaracenOne
force-pushed
the
auto_advance_behaviour
branch
from
7901c1c to
249df04
Compare
|
One question I would ask from a usability standpoint though is if it's nessecary to show these options all time. They're highly context-sensitive, so maybe it would make their use clearer if this option was only displayed during 'new transitions mode'. |
SaracenOne
force-pushed
the
auto_advance_behaviour
branch
from
249df04 to
2ccb412
Compare
|
I went and added the context-sensitive behaviour anyway. I couldn't really see a reason not to do it given the way the state machine editor currently work, and feel like it will make it easier for people to understand it. |
|
@TokageItLab what do you think? |
|
Does this PR solve this issue? |
|
@TokageItLab It doesn't, but I've started experimenting with transition interrupts as part of major evaluation of state machine usability. I'm hoping I can add that as a new feature soon, along with more granular support of the exact timing of when transitions should occur. |
|
I think I recall we discussed using an enum for this, what happened in the end? |
|
Animation meeting: change to use an enum, maybe add |
SaracenOne
force-pushed
the
auto_advance_behaviour
branch
from
2ccb412 to
c3d5e18
Compare
|
This has been updated with the change to a single enum. I sincerely apologize for not following up on this sooner. |
… flag. Expressions and conditions now require auto mode to be set to auto. Adds a toggle button to the state machine editor for whether new transitions advance settings should default to auto mode or not.
SaracenOne
force-pushed
the
auto_advance_behaviour
branch
from
c3d5e18 to
092dbe5
Compare
|
Thanks! |
This is a PR to address a potential major design discontinuity with Godot's StateMachine system. This has been bothering me for a while, and I believe I understand why certain aspects of AnimationStateMachine's feel so counter-inuitive. I feel it is a consequence of two distinct ways of traversing them: via travel or via auto-advance/conditions. With travel, conditions are actually ignored, and it is a regular A* traversal to simply get to a desired node, whereas auto-advance can use conditional branch to have a state machine essentially drive itself.
The problem I feel with the current implementation is that you have mainly three types of transitions:
My problem is that auto-advance more or less overwrites the behaviour conditions, and this feels very strange from a usability standpoint. It essentially makes the it an either/or scenario, and the relationship between these two elements is not obvious. My proposal therefore is to make it so that for any automatic traversal, auto-advance must always be on, and conditional evaluation is only done if auto-advance is set. While this PR only changes the actual behaviour and documentation to provide better explanation, I think more could be done on the editor side to make the relationship between the two more obvious. I could also supplement this with features such as allowing you to set the default state of auto-advance on new transitions in the same way you can for switch mode.
I feel strongly on the whole that short of removing auto-advance entirely (which doesn't feel fair given not having auto-advance active can make it useful for the 'travel' method), this is the best way to address a pretty glaring design issue, and it feels relevant to address this given the potential that a lot of game logic can be implemented purely via state machines.