How do I fix line of sigh to visible sprites

I'm using "Line of Sight" plugin but the problem is that i want to use it with "visible block sprites".

Using the Line Of Sight example on construct 2, you can see how the sprites that are not in sight are -50 opacity becase there is a black bar as obstacle.

Changing the pig sprite by boxes, i want use Line Of Sight so the box works as an obstacle and as an sprite that if is bloqued will get 50% of opacity.

So the problem is that how the same sprite works as obstacle as an sprite that have to set 50% of opacity if is not on line of sight all they are off because the line of sight also gets the first sprite off due is a block.

Here the .capx

https://drive.google.com/file/d/0B8vm3F ... sp=sharing

I want the box has an obstacle for line of sight to block sprites behing them but no hide the sprite itself that works as block.

matriax

I managed to get it working by giving the box the line of sight behaviour and adding box to it as an obstacle. I then reversed the condition so that the box checks line of sight to the player:

https://www.dropbox.com/s/4q7ie4zgr9l0o ... .capx?dl=0

In base you have 3 'things' to deal with.

1/ The behaviors are developed in times that devices could not run html 5 at a decent performance. And we are still locked up in that paradigm. I feel like it is time to move on, but i dont know that. As a result, .... all behaviors are optimized in an awesome way (i can only give compliments about that) ... but also to a point that any change will break compatibility with older versions of construct 2. That is why most behaviors are pretty basic.

Escape is possible, but you have to re-code it all yourself and accept a drop in performance in a lot of cases.

There are 3th party behaviors that are made outside of that paradigm. Like the one that i am using in my example.

plugin-jcw-trace-raycast_t172320

2/ The LOS behavior only checks if the origins are visible. This for obvious performance reasons. I wish Ashley would make that paradigm shift, but i guess either Ashley or our devices are not ready for that. So, even if you would manage to get it working with LOS, it will not solve your problem.

3/ Since the LOS behavior only checks for the visibility of the origins, but the obstacles act as volumes, adding an instance as obstacle .... will obscure its origin from the LOS. So, there is no solution for an instance to be an obstacle (an obstacle = its collision polygon shape) and at the same time to be a target (origin is inside the polygon shape).

x/

Taking in account all the above, i made you a working example using a 3th party plugin.

https://www.dropbox.com/s/trz1xmjq6wscv ... .capx?dl=0

Have fun.

Wow mekonbekon !! Very clever solution!

99Instances2Go Thanks for the info/example, i will download the trace plugin and test it too but i guess i will use the mekonbekon solution due no require more plugins ans seems to works easilly.

Also the Trace plugin with this solution maybe can i use it for other things, will see!

Thanks both of you guys!

Tested Both and the Line Of SIght works better, the trace one makes the sprites "flash" to fast some times like not works correctly or something i don't know. Also the player gets 10 opacity? I tried to change but seems then not works :S , make all slowly and all 10% opacity... 99Instances2Go what happens?

matriax Cheers, glad to be able to help out

99Instances2Go , mekonbekon Well, maybe i talked too fast XD , after some tests none works correctly an each solution have similar issues :S .

First image is using line of sight, the second image using raytracer.

I'm trying adding other events or edit some parameters but never get it working 100% correctly :S

Any idea? I'm, gonna try to do some double checking liek if both can see each other.

Also with RayTraces in theory have to work after see some examples but at least in the .capx as you can see boxes behinh others are visible ¿? :S .

matriax I've updated the capx:

https://www.dropbox.com/s/4q7ie4zgr9l0o ... .capx?dl=0

I've reduced the player's cone to 60 degrees and put in a check for his line of site so only stuff he's looking at is shown.

I also added solid to the block's behaviour and changed their LOS check to solid, in case the custom setting was causing any issues.

The reason for the odd block showing visible behind other blocks is because the LOS can peek through blocks that are adjacent to each other - if you overlap them the problem disappears.

Your cone was 360 degrees. There is/was no hint for another cone. You can easily change the loop to your liking for a cone to your liking.

The collision polygons for your blocks have gaps. Can not read your mind that you dont like your own collision polygons.

Of course the player goes transparent when it is set to transparent (traces of debugging).