Blocker Behavior

[Forestidia86]

This is probably well known, maybe even used somewhere but since I've encountered it:

Passing through blockers in two different variants (attached replays for both):

1st Is more of an oddity that works in L1 Winlemm as well I think. The lix can walk through two blockers under following circumstances:
- You position a blocker at a very specific place close to the hatch.
- You position then a blocker directly under the hatch.
=> The lix will "dance" through the two blockers.

2nd Is about changing directions through blockers:
- You place a blocker under the hatch. (=> Lix can still pass through in their spawning direction)
- You place another blocker one frame to the side of the first blocker. (=> Spawning lix will be turned around and pass through the first blocker to the other side.)
- You place then another blocker one frame to the other side of the first blocker.
=> Lix will be turned around again and walk through the first and second blocker (in their original spawning direction).

[Simon]

Fun corner cases, thanks!

The dancing (1) looks like a bug. I can't guess where it comes from. I should understand (1) before I even comment on (2).

A blocker at coordinate (xb, yb) turns a lix at (x, y) to the left if, measured in lo-res pixels, xb - 6 ≤ x ≤ xb - 1, which is a 6-lo-res-pixel-thick field. The blocker turns the lix to the right if xb + 1 ≤ x ≤ xb + 6. The center xb = x is neutral, it behaves like air. There are status fields per turned lix to avoid turning several times per frame, I don't remember the implementation perfectly.

I haven't ever specified properly what should happen when lixes overlap several blockers. In C++ Lix, I've always hoped it would be fine no matter what happens. In D Lix, I've never given it proper thought.

-- Simon

[Forestidia86]

The first case is actually what I encountered occasionally in usual play. The second is more result of testing around after getting notice that you can pass through two blockers.

The first case happens in usual play when you want to compress or fast catch the crowd and therefore assign blockers close to each other. But if you (accidentally) do it in such a manner as described above then you have the dancing and therefore don't catch the crowd at all, which can get annoying.

[Simon]

Pushed a fix to the unstable repository in branch phys. This fixes both (1) and (2). In both cases, the walkers will be trapped after the final blocker assignments.

Source of bug: Your horizontal movement was correctly blocked when you're both in a blocker's left-hand field and in a blocker's right-hand field. The bug was that the lix didn't get her (we're in a blocker's left-hand)-field set when she was already facing left. Now, the flag is properly set even if the blocker need not turn her.

-- Simon

[Forestidia86]

The current physics have a mechanics that can get nasty in multiplayer:
The other player places a blocker so that your lix turn before they have already landed. Therefore you can't bat the blocker away.
In current physics in singleplayer there would be another way to counter that, which is a subcase of the originallly reported behaviors in this thread:
You can place a blocker that way that it turns around again your lix and is close enough to the first blocker so that your lix walk through the first blocker. This quasi neutalizes the first blocker.
Simon said for multiplayer this is not safe to work since blocker behavior depends on the order of players (?) if I understood correctly.

I've attached a replay to show off what I mean.

[Simon]

Correct; I believe that in 0.9, overlapping blockers depend on order of evaluation. I haven't conducted detailed tests whether it really depends on order of evaluation, I can test that at home again.

In a physics update, all blockers of all players are calculated, then all other skills happen. The blocker calculation should be independent of the blocker order. I took great care that order of evaluation is irrelevant for terrain adders or removers, but it's still important for exiters in race maps (bug, I have a physics change ready for 0.10) and, as I believe here, for blockers (again bug, I have a physics change ready for 0.10).

Whenever some physics depend on order of the lix (usually because of such subtle bugs), it will also depend on player order. All red blockers are computed first, then all orange blockers, then all yellow blockers, etc, then all red flingers etc. I'd like the colors to be completely equal (they're largely equal, but not totally in 0.9) and, as a side effect, will make everything independent of lix order within a player.

Most important for multiplayer is the ability to bat blockers no matter where you have landed next to a blocker. This is a property of the batter, not of the blocker, and is orthogonal to these subtle ordering bugs. This extra range should go into 0.10, too.

-- Simon

[Forestidia86]

Another thing that is peculiar:

If you assign walker to a blocker, you have at first an animation that dissolves the blocker state and only when that has finished the blocker counts as walker and doesn't block anymore. That means that although you've assigned walker to a blocker you still have the blocking effect for a couple of frames and can't assign skills that you couldn't assign to a blocker.

[Simon]

Yeah. Existing beahvior:

* Dissolving blockers still block.
* Dissolving blockers may be assigned walker, this will turn them, but not speed up the animation.
* Dissolving blockers may not receive builder/basher/...

I would like instead:

* Dissolving blockers behave exactly like landers.
* As a corollary, dissolving blockers don't block anymore.
* As a corollary, you can still assign walker to turn without speedup.
* As a corollary, you can but also many other skills.

Landers have a peculiar behavior where, on a walker assignment, they turn, but their frame remains the same. Not sure if this is good or whether I want to advance frame; at least its downside is minimal.

-- Simon