LineOfSight issues

I'm using the LineOfSight behavior with a little top-down space adventure game. I want to use it along with a player-centered light and shadow-casting obstacle sprites to hide areas and objects that the player doesn't have a line-of-sight to.

It basically works, but I have two problems which I'd like to discuss:

1) Objects marked "Solid" never satisfy the "Has LOS to object" condition.

2) The "Has LOS to object" condition is only true when the player has direct line-of-sight to the center of the object.

Issue #1 can be worked around by using a secondary non-solid object at the same position as the solid object, which is then used to query visibility. Is there a better option, short of changing the behavior code?

Issue #2 seems to require a change to the behavior code to consider object width/height/radius. Or is there another option?

Thoughts?

I think question 2 answered number 1. However if you were using the attribute to group your obstacles you can add those objects to a family, and use the family instead.

Keep in mind los does not add objects it detects to the selected objects list.

On number two:

The behavior works off of points, basically its the same as distance(x1,y1,x2,y2), only it can detect if something is in between those two points.

There is a work around that does not use the behavior. That being a detector sprite that you have scaled to the to the range of sight.

However if you were using the attribute to group your obstacles you can add those objects to a family, and use the family instead.

I'm using the "solid" attribute to block movement, not for any kind of grouping.

Keep in mind los does not add objects it detects to the selected objects list.

What are the "objects it detects" and the "selected objects list"? Are you saying that solid/obstacle objects are not in the list of objects to check for LOS?

On number two:

The behavior works off of points, basically its the same as distance(x1,y1,x2,y2), only it can detect if something is in between those two points.

I checked out the code and confirmed this. Thinking about it more, LOS logic that accounts for the size of the object is non-trivial. Nevertheless, it would still be really nice to have.

There is a work around that does not use the behavior. That being a detector sprite that you have scaled to the to the range of sight.

That would give me an easy arc and distance check, but it doesn't account for obstacles. I'd need to manually check if LOS to an object is blocked by another object.

What are the "objects it detects" and the "selected objects list"? Are you saying that solid/obstacle objects are not in the list of objects to check for LOS?

It only checks for points so a large solid will do no good, since it only has 1 point...(Im guessing)

If it's not detecting solids you may have to add "obstacles" manually in your events.

That would give me an easy arc and distance check, but it doesn't account for obstacles. I'd need to manually check if LOS to an object is blocked by another object.

Well distance(x1,y1,x2,y2) will give you that, but to get a line of sight you can take a rectangular object that can do collision detection, scaled to the range, and always pointing the same angle as the sprite, then have a collision event if the detector is overlapping an obstacle.

Thanks, Newt. I implemented your proposed solution and it works great. It's a bit slow because I'm creating a new "vision checker" sprite each frame for each object, so I may need to optimize that a bit later.