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

ActionDiffs are not being networking correctly when an action is consumed #443

Closed
cBournhonesque opened this issue Jan 17, 2024 · 4 comments · Fixed by #582
Closed

ActionDiffs are not being networking correctly when an action is consumed #443

cBournhonesque opened this issue Jan 17, 2024 · 4 comments · Fixed by #582
Labels
bug Something isn't working

Comments

@cBournhonesque
Copy link
Contributor

cBournhonesque commented Jan 17, 2024

Version

The release number or commit hash of the version you're using.

What you did

In my Update schedule, I have something like:

if action.pressed(PlayerActions::Shoot) {
   action.consume();
}

and in PreUpdate, I generate ActionDiffs using the diff-generation system after InputSystemSet::Update.

However I don't get any diffs for the action that was consumed.

My understanding is that the flow is this:

  • Frame 1: user presses button
    • PreUpdate: PressButton, Shoot is pressed
    • Update: Shoot is consumed (consumed=true and state=JustReleased)
  • Frame 2
    • PreUpdate: Tick, so we go from JustReleased to Released
    • PreUpdate: in generate-diffs, we only network JustReleases, so this is not networked
      ...
  • Frame X: user releases button
    • PreUpdate: consumed=false. state=Released and not JustReleased because the button was already marked as Released. The diff-generation system only networks JustReleased events, so I never get the information that the key was released.

What you expected to happen

The release of the button is networked, either when the button is consumed, or when I actually released the key.

What actually happened

Nothing is networked.

Potential solutions:

  • I could try to be more clever in where I use the diff-generation system (maybe run it once before InputSystem::Tick as well so that the consumed action is still JustReleased

  • Maybe when a key was consumed, we still trigger a JustReleased when the actual key is Released.
    (so release() would be something like:

if *self != ButtonState::Released || self.consumed {
            *self = ButtonState::JustReleased;
}
  • maybe in the diff generation system, we send a release diff for every action that is consumed, even if it's not a JustRelease. We could get potentially a lot of duplicate Release ActionDiffs, but it's a good short-term solution
@Shute052
Copy link
Collaborator

Shute052 commented Feb 23, 2024

have this fixed by #480?

@cBournhonesque
Copy link
Contributor Author

Nope; the problem is not with the consume function, it's more about how ActionDiffs are generated.

the problem is that consumed actions are immediately marked as JustReleased, and then become Released in the next frame (because we tick them once).
The generate_action_diffs runs after that and doesn't generate diff for them, since it only generates diffs for JustReleased and JustPressed actions.

Personally I have a solution that creates action diffs for JustRelease OR (Released && Consumed) actions, but I don't like it that much because it generates an Released ActionDiff every frame until the key is actually released.

Maybe another solution would be to have a generate_action_diff_for_consumed system that runs before InputManagerSystem::Tick and a generate_action_diff system that runs after InputManagerSystem::Tick

@Shute052
Copy link
Collaborator

Shute052 commented Feb 23, 2024

yeah, I'll also take a look when I have some time, mostly because my holiday is ending soon (Chinese New Year and Lantern Festival).

I'd like to get some work done on #483 first.

@cBournhonesque
Copy link
Contributor Author

Yes I don't think it's a priority, especially because the system is not added in the plugin itself so users can just use it for reference but roll out their own implementation

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants