fix blink locomotion when changing player scale - #323
Conversation
|
I think the 'proper' solution to this is instead of returning when a locomotion method is used, recording that fact and passing it down to each function in the line, so that they can handle the situation themselves. In that scenario, activating two-handed scale could just cancel the blink out. I'll make an issue for this. But, in terms of a fix for this release I'm fine with this solution |
AndrewTHEManeri
left a comment
There was a problem hiding this comment.
I think we should cancel a blink if active here, rather than just performing it. Right now you can't do a locomotion reset (scale+translation) without immediately blinking afterwards
|
ok, changing it to cancel blink |
|
blink cancels now ! |
|
Yeah... the if (didlocomote) return pattern was a little more sensible when there wasn't anything that needed to happen when transitioning between states. Blink visuals and feedback really complicated things. I'm open to restructuring this tool, but I'm not sure of the best solution. Maybe something more like a state machine? |
|
@mtschoen-unity something like that is probably sensible, but that's a bigger discussion. for the purposes of this release i think just fixing this one bug instance is what we want |
|
Excellent |
fixes #300
tested that everything else in locomotion still works as expected.
now, if you release the blink button while in the middle of changing player scale, the blink is cancelled.
I'm not wild about having to do it like this - with the
if(DoThing) return;pattern, but as far as the scope of this bugfix goes, i think it's the right solution.Perhaps there is a better way ? it seems like this pattern in general will lead to more instances of control being consumed in a way that prevents another system from working.