ID:153680
 
Has anyone come up with a way to create line of sight systems in BYOND without creating a ton of lag, or dragging the processor down? I don't know whether its the way my game works or not, but the built in line of sight is just...wrong. It shows things that are obviously around a corner, and shows walls that are plainly out of sight but doesn't show the things that come before the walls which aren't opaque, just the opaque walls. Drives me nuts. Is there any way to create an alternative line of sight system with BYOND that anyone is aware of? (Or to modify the existing one if that's a posibility.)
Unfortunately, since LOS is independent for each client, it's extremely difficult to create a non-laggy LOS system in BYOND -- you have to resort to images, which essentially can demand a maximum number of images being changed every time the player (or a vision block!) moves equal to the number of tiles on the screen.

This is another of the situations where being able to override client-side procedures would be very useful.
To check if one atom can see another, I have a non-dense obj, using step_to, move from one atom to the other. if it ever moves over a dense tile then it returns 0, if it reaches the other atom then it returns 1. However, I don't use this to black out what you cannot see, that would probably be laggy.
In response to OneFishDown
step_to isn't reciprocal.

See this example:

. . . . . O . . .
. . . . . . . . .
. . . . . # . . .
. . . . . . . . .
. . . . X . . . .


Drawing a step_to path from X to O will bump into the #:

. . . . . O . . .
. . . . . . . . .
. . . . . # . . .
. . . . . = . . .
. . . . = . . . .


But drawing a step_to path from O to X:

. . . . . = . . .
. . . . = . . . .
. . . . = # . . .
. . . . = . . . .
. . . . X . . . .


...will succeed.
In response to Spuzzum
Spuzzum wrote:
step_to isn't reciprocal.

Well you're right that it's not (necessarily), but wrong about the reason why: It's not that it will bump into an obstacle, because step_to() is the proc that uses pathfinding. step_towards() is the dumb one.

Lummox JR
I actaully came across the same problem when trying to develop a table-top wargame engine. My solution was to trace four paths to the target. Each path would start on a tile one square away from the source, in a cardinal direction. If more than half the paths made it with out being blocked, then you had LOS. Otherwise, LOS was either partially or fully blocked. And, since doing partial LOS is just out of the question, they count as blocked LOS.

Unfortunately, I lost those and many other files when my comp decided to eat itself =(
In response to sapphiremagus
mob/var/sightDist = 3
mob
proc
getView()
var/list/turfs[] = new/list()
for(var/turf/T as turf in view(src.sightDist,src))
switch(src.dir)
if(NORTH)
if(abs(src.x-T.x) <= T.y - src.y)

turfs += T

if(SOUTH)
if(abs(src.x-T.x) <= src.y - T.y)

turfs += T

if(EAST)
if(abs(src.y-T.y) <= T.x - src.x)

turfs += T

if(WEST)
if(abs(src.y-T.y) <= src.x - T.x)

turfs += T


I dont know if thats what your looking for but onefishdown helped me on that proc.
What we need is one like Nox's. If you have never played nox, they have a very nice system. You cant see though windows unless your really close, walls have a more triangled shape block;not a line like byond, and much more. Like when people or items go off vision, you see them in the black at the exsact state they were in when they left your vision, so you can follow people and things better. Its hard to explain, but i have never seen anything better.
In response to Spuzzum
Oh well. I'll just have to start nagging Dantom to improve it then... (After 4.0 is released.)