[b34] new LOS does not always perform properly

[Marbat]

While happily shooting mobs with lightning bolts in the forest, I noticed that the new LOS algorithm might behave strangely on some occasions:

tome-3.9.34-1316504434.png (109.73 KiB) Viewed 4031 times

Depending on where I aim, I may get a correct display of what is reachable and what is not:

tome-3.9.34-1316504723.png (99.65 KiB) Viewed 4031 times

[tiger_eye]

ah, thanks for posting, Marbat, because I am interested if the new LoS doesn't perform properly for a particular configuration.

It is, however, working correctly for the above situations. In the first configuration, the path is blocked by the trees two tiles right and one tile upward (even though that tile isn't actually highlighted). Hmm, I guess this could actually be made more clear. Would it be better if that tile were highlighted red, orange, brown, or with an X or something? This would be pretty easy to do. Thoughts?

[Marbat]

It is, however, working correctly for the above situations. In the first configuration, the path is blocked by the trees two tiles right and one tile upward (even though that tile isn't actually highlighted).

I see. So, the LOS is blocked by a tile that is not actually on the highlighted path? Now, THAT was unexpected!

I do not have the slightest idea about how the new LOS implementation works, and I can understand it performs as expected algorithm-wise, but from an end-user point of view, I would have expected that the highlighted tiles would be 1/ those actually affected by the bolt or 2/ those which would block line of sight or 3/ those which would have been affected by the bolt if LOS was not occluded.

So, if I would have cast that spell in the first example, the 2nd mob would not have been hit? Kinda weird. Before I took these shots, I am pretty sure that I did cast spells that hit mobs in situations very similar to the 1st example. In fact, I was trying to reproduce that situation when I made that post.

[Aquillion]

ah, thanks for posting, Marbat, because I am interested if the new LoS doesn't perform properly for a particular configuration.

It is, however, working correctly for the above situations. In the first configuration, the path is blocked by the trees two tiles right and one tile upward (even though that tile isn't actually highlighted). Hmm, I guess this could actually be made more clear. Would it be better if that tile were highlighted red, orange, brown, or with an X or something? This would be pretty easy to do. Thoughts?

It'd probably be good. THOUGH. I'm a bit bothered by the fact that the player, in that situation, can move the cursor to get the targeting line to where they want without actually changing anything mechanically -- that is, the bottom picture and the top picture clearly show the player "trying" to produce the same thing, so I'm bothered by the fact that the game tells the player that they lack LOS in the first one even though all they had to do was move their cursor around to find a point where it worked.

This is unintuitive. It would be better if the game could detect that there was a point that the player could aim to to produce a longer line of effect along the red-highlighted path in the first, and calculated using that automatically... though, hrm, the player might not always want that... hrm.

[tiger_eye]

I'm very open to suggestions for how to make this more intuitive, so let me try to explain what's going on.

The first image is blocked, because an obstructed terrain blocks the entire tile:

los1.png (106.08 KiB) Viewed 3987 times

Here is one way to show in-game that the path is blocked by this tile (feel free to suggest other ways):

los2.png (104.85 KiB) Viewed 3987 times

The second path is not blocked:

los3.png (96.66 KiB) Viewed 3987 times

It is possible to set the permissiveness, so obstructed terrain won't block the entire tile. This is currently only set-able on a per-level basis, however, and not a per-terrain basis.

[Marbat]

This is what I would expect:

expected.png (89.93 KiB) Viewed 3973 times

This path looks perfectly natural and explains why the 2nd mob is behind an obstacle. Tile a is not on the path, while tile b is. easier said than done
The fact that the slope is 0.25 is this example makes things even more tricky. 0.25 gives a symmetrical role to both tiles a and b. The straight line path does pass through tile a more than it passes through tile b, yet the display has to highlight only on tile.

[tiger_eye]

This path looks perfectly natural and explains why the 2nd mob is behind an obstacle. Tile a is not on the path, while tile b is. easier said than done

Hmm, I'll think about that, Marbat. The initial concern I have about that is if b wasn't blocked, then the targeting path would go through a, not b.

Anyway, here is another example of why corner-blocking is necessary:

los4.png (160.42 KiB) Viewed 3968 times

los5.png (185.07 KiB) Viewed 3968 times

[Marbat]

Hmm, I'll think about that, Marbat. The initial concern I have about that is if b wasn't blocked, then the targeting path would go through a, not b.

Feels like a clunky solution, indeed.

Your previous los2.png solution is interesting. I am not sure I am real fan of partly highlighted tiles, but it sure explains what happens most of the time.

If a ghost was standing on the blocking tile, things would still be confusing, as it would not be hit by the spell, right?

[Hedrachi]

You could just draw a line representing the path of the beam or projectile like you did in the example, but if it's needed, with a less basic-looking line. Would probably be more intuitive for projectiles, that the projectile is following the line and not occupying the entirety of every tile on its flight path. Just my opinion, though.

[tiger_eye]

If a ghost was standing on the blocking tile, things would still be confusing, as it would not be hit by the spell, right?

Correct. This is why the half-highlight is red, not blue. You would need to aim more directly at the blocked tile with a ghost in it to hit the ghost. (just don't ask me how exactly the player is able to hit things in walls ).

You could just draw a line representing the path of the beam or projectile like you did in the example, but if it's needed, with a less basic-looking line. Would probably be more intuitive for projectiles, that the projectile is following the line and not occupying the entirety of every tile on its flight path. Just my opinion, though.

Could you make a mock-up of what you're thinking, Hedrachi? An example would be wonderful.

[Hedrachi]

The second path is not blocked:It is possible to set the permissiveness, so obstructed terrain won't block the entire tile. This is currently only set-able on a per-level basis, however, and not a per-terrain basis.

When I get home I'll try to give you an example, but basically it's the attachment you had at that point in your quote, replacing the thin black lines with a colour passed from a variable stated in the power (or alternatively, just up the alpha channel for the power's effects /show a translucent projectile going along the path you specified, like how trade goods moved along trade lines in Activision's Call to Power 2). For tiles blocking the beam/projectile, just a glaring red outline would suffice I think.

[tiger_eye]

This is unintuitive. It would be better if the game could detect that there was a point that the player could aim to to produce a longer line of effect along the red-highlighted path in the first, and calculated using that automatically... though, hrm, the player might not always want that... hrm.

Just to clarify, if the path in the first example hadn't been blocked by the trees in the middle:

los7.png (108.15 KiB) Viewed 3921 times

Then the line would have been "smart" targeted through every tile, as I crudely tried to draw here:

los6.png (100.73 KiB) Viewed 3921 times

Currently, if the path is obstructed, then it reverts to a center-to-center line. Aquillion, I think you were perhaps suggesting to use a semi-smart line that goes the furthest without being blocked, so the targeting in the first example would be:

los8.png (82.34 KiB) Viewed 3921 times

This could work for situations like the above where there are multiple obstructed tiles, and may be more user-friendly. What does everyone think?

If it is blocked by a single tile like the Lake of Nur entrance example I posted above, then there is nothing we can do. There is no quasi-smart line that would do a better job.

[Marbat]

This could work for situations like the above where there are multiple obstructed tiles, and may be more user-friendly. What does everyone think?

This is one perfectly intuitive.

The Lake of Nur example feels unintuitive, though. Here is what I would have expected:

nur2.png (172.65 KiB) Viewed 3914 times

Don't know if it's feasible.

[Grey]

With the "smart line" idea, maybe just stop the line entirely after it meets the obstacle? Then you won't see any weird looking end to the line.

[Hedrachi]

With the "smart line" idea, maybe just stop the line entirely after it meets the obstacle? Then you won't see any weird looking end to the line.

Yeah, that's probably better with my idea. Still should probably highlight the blocking tile(s) though.