[bug] [player] LMB advances physics before cancelling replay

Started by Simon, February 14, 2016, 02:32:21 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Simon

BitBucket: https://bitbucket.org/namida42/neolemmixplayer/issues/40/left-click-advances-frame-before-updating

Status: This appears to be two different things being reported together:

1. Left-click cancels replay *and* advances a frame. This is very unlikely to be changed; as there are keys for both functions alone (C to cancel replay without frame advance; N to advance frame without replay cancel; assuming the user hasn't re-customized them).

2. When using said left-click, a skill assignment in the replay is prioritized over one the user tried to assign with the given left-click. This is more likely to be changed.




Steps to reproduce:

  • Have assignment to lemming Y coming up in the replay that are assigned at the beginning of update n+1.
  • Be in update n.
  • Hover over a lemming X different from Y.
  • Click to assign to X.
Computer does:

  • Physics advance from n to n+1.
  • Queued assignment to Y is replayed.
  • Queued actions in n+2, n+3, ..., are deleted from the replay.
  • No assignment to X.
Expected instead:

  • Queued actions in n+1, n+2, ..., are deleted from the replay.
  • Physics advance from n to n+1.
  • Assignment to X takes place.
  • No assignment to Y.
Reason: When I click a lemming, it should receive an assignment. This should not depend on whether there's an assignment queued for the very next update. During frame n, I don't see yet whether anything is queued for n+1.

-- Simon

namida

Left-click essentially has the function of "advance physics one frame" and "cancel replay" at the same time. There are keys for both of these functions alone (by default, N and C respectively).

Chances are this change is not going to happen, but if enough people are in support of it I'll consider it.

The whole "next frame assignment in replay takes priority over the manual one" is perhaps more justifiable in changing, but I'm not sure how major the changes needed to implement this may be. I'll take a look at it at some point.
My projects
2D Lemmings: NeoLemmix (engine) | Lemmings Plus Series (level packs) | Doomsday Lemmings (level pack)
3D Lemmings: Loap (engine) | L3DEdit (level / graphics editor) | L3DUtils (replay / etc utility) | Lemmings Plus 3D (level pack)
Non-Lemmings: Commander Keen: Galaxy Reimagined (a Commander Keen fangame)

IchoTolot

I often want to "one-frame-advance" the replay to precisely get to a certain frame, so it's a clear no to a change for me here (as I naturally use the mouse-button rather than n). For canceling I mostly just change the skill on the skillbar, or click when the game isn't paused.

Simon

Quote1. Left-click cancels replay *and* advances a frame. This is very unlikely to be changed; as there are keys for both functions alone

I agree with this design. Indeed, in my "expected instead" section, the replay is both cancelled, and physics advance.

I am suggesting that LMB does exactly what you have written in the quote -- cancel the replay, then advance a frame. :lix-evil:

Quote2. When using said left-click, a skill assignment in the replay is prioritized over one the user tried to assign with the given left-click. This is more likely to be changed.

Yes, this is the issue.

-- Simon

namida

Okay, by looking at the code, cancelling the replay is done first, but this doesn't allow overriding the assignment in the current frame (which is put into effect in the next frame, thus causing the appearance of it updating physics first).

    if (Button = mbLeft) and (not Game.CtrlButtonHeldDown)
    and not (Game.Replaying and GameParams.ExplicitCancel) then
    begin
      Game.RegainControl;
      HandleClick := true; //{not Game.Paused and} not Game.FastForward{ or UseClicksWhenPaused};
      if HandleClick then
      begin
        if Game.fAssignEnabled then
        Game.ProcessSkillAssignment;
        if Game.Paused then
            ForceUpdateOneFrame := True;
      end;
    end;


So, I'll have to look into TLemmingGame.ProcessSkillAssignment. I have a feeling the current behaviour was implemented as a fix to something else, so I can't promise anything - if something bigger would break by fixing this, then (at least for now) I'll probably leave it the way it currently is.
My projects
2D Lemmings: NeoLemmix (engine) | Lemmings Plus Series (level packs) | Doomsday Lemmings (level pack)
3D Lemmings: Loap (engine) | L3DEdit (level / graphics editor) | L3DUtils (replay / etc utility) | Lemmings Plus 3D (level pack)
Non-Lemmings: Commander Keen: Galaxy Reimagined (a Commander Keen fangame)

namida

Yeah, it would look like more significant changes are needed to implement this. So for now, this will have to remain as it is. I'll leave this open though so that at some point I can come back to it.
My projects
2D Lemmings: NeoLemmix (engine) | Lemmings Plus Series (level packs) | Doomsday Lemmings (level pack)
3D Lemmings: Loap (engine) | L3DEdit (level / graphics editor) | L3DUtils (replay / etc utility) | Lemmings Plus 3D (level pack)
Non-Lemmings: Commander Keen: Galaxy Reimagined (a Commander Keen fangame)

Simon

My understanding from observing the game alone:

  • The game has physics updates, I number them with 0, 1, 2, 3, ... The game allows player input between any two sequential physics updates. Assume that physics update n has passed, and we're between n and n+1.
  • We assign a skill X to a lemming between between these updates n and n+1.
  • Game takes the assignment, performs the physics update n+1, and shows the assigned worker in the worker's first animation frame. We're now between n+1 and n+2.
  • We press exactly once the key to go back 1 frame. We're back between n and n+1.
  • It is impossible to assign something else now: This is the bug described in the first post.
  • Look at the skillbar. The skill X that we assigned is deducted from the skillbar. Go back and forth in time to observe how the skill is consistently deducted after update n, even though it comes into effect only in update n+1.
  • I conclude that there is replay magic. When we assign after update n, this assignment affects update n, even though that update has already passed. This is counterintuitive.
  • The game obscures this magic even further: During replay, the game draws a white rectangle around the assigned lemming between updates n+1 and n+2. But the assignment seems to be recorded for update n, which isn't even adjacent in time to the white rectangle.
Assignments are super important, they're the most important thing in the entire game. Yet they irritate and obscure what's happening.

Sure, the entire physics depend on the bug. Doesn't matter: The bug seems 100 % predictable. In old replays, you can move on-the-fly the assignment from n to n+1. This can't be the showstopper.

Why does NL write to the ostensibly-wrong physics update in the first place?

-- Simon

namida

Off the top of my head, I recall it being something to do with when skill assignments are processed vs when release rate changes need to be processed (remember that bug where every so often, an RR change would lead to a replay desync?). I forget the exact details.
My projects
2D Lemmings: NeoLemmix (engine) | Lemmings Plus Series (level packs) | Doomsday Lemmings (level pack)
3D Lemmings: Loap (engine) | L3DEdit (level / graphics editor) | L3DUtils (replay / etc utility) | Lemmings Plus 3D (level pack)
Non-Lemmings: Commander Keen: Galaxy Reimagined (a Commander Keen fangame)

Simon

LMB-advances-before-cancelling does not manifest in 1.44-no-fading with highlight-assignments. A highlight-assignment is when you highlight a lemming (arrow over its head), then hold the highlight key, and while you hold that key, click the skill in the panel.

In detail:
1. Highlight lemming.
2. Highlight-assign exploder. Observe how the game shows the explosion picture.
3. Go back exactly 1 frame.
4. Regular-assign floater. (Click floater in the panel, click the lemming.)

Observe how the lemming won't explode, as I would expect.

-- Simon