Bug Input cached when not immediately consumed by a State

https://open.codecks.io/unity-open-...ched-when-not-immediately-consumed-by-a-state

Hey all, just wanted to start the conversation about this bug since it seems important and I'm curious about what might be causing it. Not exactly sure what I'm looking for, but I'll post anything I notice/suspect here. Help would be greatly appreciated!

And please feel free to add to/correct any of the information below.

---

Short description
Player input is cached while performing another action. The cached action is performed once the existing action finishes.

Expected behaviour
Some existing actions should be cancelled when the new action is initiated (e.g. if the player attempts to talk to an NPC while walking, the player should stop walking and enter dialogue), whereas some should ignore the new input (e.g. a player that is jumping should not be able to enter dialogue)

To Reproduce

1. Open a testing scene, press Play
2. While walking or jumping, press the ExtraActionButton ("L" on keyboard, "Button North" on gamepad)

Notes
Interacting with the pot to begin "cooking" does seem to cancel both walking and jumping, but not the ExtraAction. I assume the input is still being cached though because "cooking" begins as soon as ExtraAction completes.

 

Are we storing input somewhere?

 

My rough, high-level understanding is that the Protagonist class stores input from the InputReader and relays it to the State Machine which decides what to do with the data. The way it is currently set up it looks like each input is read and acted upon totally independent of the others -- which seems very good for some things, but makes it hard for me to see an obvious solution to this bug. Maybe the TransitionTable or Conditions could be modified to add more constraints on when to change states? (I see a field called "Cache Result" on each Condition but I'm unclear on what it does, and setting it to false does not seem to solve the issue... might be unrelated.)

I'm kinda shooting in the dark here. Perhaps someone more familiar with the State Machine could shed some light on this?

EDIT: Just though of this so I thought I'd add it. It might be helpful for designers to have a visual way to modify the transition table -- similar to ShaderGraph or the Animator -- but then again that is probably more trouble than it is worth.

 

We should have a look at Protagonist.cs and that Cache result script.

Maybe some light is there.

 

Got it, thanks for the clarification. That's what thought was happening, but I was stuck thinking about more generic/infeasible solutions. I'll experiment with the Protagonist and InputReader scripts, and avoid messing with the StateMachine!

Using Interactions sounds promising. I'll check it out and try some stuff!

The only problem that I anticipate with that is that we might need to experiment a lot to get the Interaction type/timings correct for each action, since actions might be linked in quick succession, like during combat for example. And this could lead to some interdependencies between those Interaction types/timings.

So funny! Future-proofing for a future that never came...

 

I agree, it seems when a state checks the value of extraActionInput, what they really want to know is whether or not the extraActionInput was performed during the same frame. A quick and dirty solution is to just set

extraActionInput = false;

in LateUpdate(), but that will get messy as more inputs are added.

Maybe we can introduce new classes for modeling common input types. In this situation, the input should only be true if it was performed during the same frame. For example:

class TriggerInput
// triggers only on the same frame when the input was performed, ex. Attack, extraActionInput (for now, until it is handled via an Interaction)
- bool IsTriggered: returns true if the input was performed this frame, false otherwise
- OnLateUpdate(): resets the triggered status to false at the end of the current frame

The Protagonist class will hook it up with the InputReader, and call its respective update method every frame. These input types can be expanded later if needed (ex. ChargeInput, ToggleInput, etc.)

We also encountered a similar challenge in handling chained attack animation combos for an action brawler project. Our approach was to have AnimationEvents in mecanim to signal the start/end frames where an input could transition into the next attack animation. The mecanim UI was a pain to work with for that purpose though. I wonder what Chop Chop's combat system will be like?

 

Hi for all.

I made two little changes on State Machine.

1st change - Walking State:
I added a transition to Talk State when player will talk to someone and not in proccess of jump.


2nd change - Talking State:
I added more one action to disable player walking.


I think that is expected behaviour that was reported by drbir.

In my tests this two changes has been put the train on the track.


Please feel free to add or remove any change that I maded.

 

Hi.

Yes.

The previous action is canceled immedially in only the case action "Walking".

I wait the finish of the action "Jump" and when thats action was finish the action "Talk" is started.

As I understand it in the previous messages is that the action "Talk" would high priority related to action "Walk".

Was my understanding correct?

If my understanding is correct read the message #1 or just read the message #2 otherwise:

#1
This change was only priorize to cancel action "Walk" when the character start action "Talk".

#2
Perhaps the excitement of helping and getting involved in the project may have gone much further and I missed a few points.

If my excitement overrode reason, I apologize.

 

Hi again.

I wait that character finishes jump and after that I start to action "Talk".
I never interrupt the jump.

I'll looking for something here too.

Would be interesting the use of an attribute in class StateConditionSO to indicate the behavior that this action could make?

Something like an attribute boolean "isToStartImmediately" that could be interpreted to cancel some action.

 

I understand your point.

 

Hi.

I don't know if this solve the problem, but works here.

I just made one change on Condition isMoving settings Cache Result to FALSE, but I think that this maybe have some other problem.

 

My solution https://github.com/UnityTechnologies/open-project-1/pull/338

 

maybe we can create a scriptableObject that acts as my filter state. This object would be responsible for informing the current state or Condition about the activity of the Inputs. Or create a Condition Inputs active. Or look at the previous state in a condition.

 

I've made a very simple fix using coroutines based on the earlier discussions in the issue.

I don't remember exactly what Condition was our concern at the time, I think IsSliding because we have to calculate the angle so we wanted to avoid doing that several times per frame... But it doesn't have to be some oddly structured set of Conditions, as several Transitions can share the same Conditions, eg: from JumpDescending to both Walking and Idle have IsGrounded and IsMoving . Perhaps I'd leave the feature on but remove the option from the SO, as I think it's caused more confusion than anything and it's not disabled in any Condition.

 

Yeah, and I think if there's ever any conflict it's probably because the Condition is already hacky, like changing the input of the Condition from within the Condition itself so subsequent calls in the same frame get a different result??

 

Hmm, this might not fix the issue for Talking, I think (is there any scene to test talking interactions?). The Condition to go to the Talk state checks Protagonist.extraActionInput, but I can't seem to find where it's being set to true ? Does anyone know?

 

Oh okay, then my fix should do. Attacking works as intended, no Attack-chaining and no immediate Jump->Attack, you have to press the Attack button after (or, at most, one frame before) you're in a State that can transition to Attacking (ie: Idle, Walking).

One question would be whether we want that for jumping as well. Currently, you can start holding jump while mid-air or mid-attack and you'll start jumping once you go back to Idle/Walking. Do we want to change that?

 

Okay, I fixed queueing jump.

The easiest way to fix it was by using an Action to set jumpInput to false when entering Idle or Walking. Then after doing that I thought it'd be best to have all the input clearing stuff together, instead of scattered around across multiple scripts, so I did that and reverted the changes I made to Protagonist.cs and InteractionManager.cs. I think it's all working properly now.