LOS not working with Solids

Post reply
0 favourites
  • 10 posts
From the Asset Store
Fighting Template: A (Not So) Basic One
$31.99 USD
2D fighting template based in the game that defined the fighting games genre.
danuyos's avatar
danuyos

  • I tried Line of sight behavior today, turned out it doesn't detect sprites having Solid Behavior or Physics Behavior,

    is this a bug? or is it by default and why?

  • Solids block the line of sight by default so you cannot see through walls for example. You can change this though by changing obstacles from Solid to Custom, where you can set your own.

  • It is not working with custom object either...

    Here you can see for yourself...https://drive.google.com/open?id=1kZndM5TLmVoH4rOIIjWn4MhlyV3BkQ_9

  • "doesn't detect sprites having Solid Behavior" - the sprite you want to detect should not be solid, ie obstacle. Obstacles block LOS.

    If you want to have solid on sprites that you want to detect, then use custom on Los and define obstacles separately

  • If you want to have solid on sprites that you want to detect, then use custom on Los and define obstacles seperatly

    SnipG I did the same in my previous post, you should see the .c3p file . It isn't working that way either.

  • You added the pig object as an obstacle, an obstacle is used for blocking line of sight, not to be used for an object you want to see.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • — is right, the pig instance is self obstructing.

    The behaviour casts a ray from it's instance to the instance your checking for. If there is any obstruction between those positions then the condition is false. As the destination position is inside an obstruction it says it can't see it. Which is kinda wrong.

    I'm not sure if this was a regression when I changed the behaviour to use ray tracing or if it's always been a limitation of the behaviour. Most of the code related to the conditions didn't actually change so I expect the latter. We already had a special rule in place to prevent the casting object from being considered an obstacle, and I think it makes sense that if you are explicitly trying to check LOS to an obstacle that it should not block itself in this scenario. So I've made a small change to allow this situation. Fun side effect is that if your checking LOS to an obstacle now you get collision information ( surface normal, reflection, etc. ).

    Now it's probably worth noting that if you didn't actually care if the piggy obstructs other piggy instances then I wouldn't recommend doing this. In the worst case situation for this game you would go from 155 collision checks per tick to ~24000 ( 155 * 155 ).

    This is a slight change to how LOS works, but I think this is the expected behaviour so hopefully won't cause any issues for people.

  • Would'nt it break something or add regression as extra line of code?, ie if someone used disable/enable solid to check LOS. But now LOS is enabled by default against solids.

    (some monster - a fictional rock by day and monster at night, had solid. You disable solid and you could LOS it etc). Now you can ALWAYS see it :o

  • Mmm yes if you were using the behaviour like that then it's a breaking change. That feels like a bit of a hack to me, it's taking advantage of an edge case not using intended behaviour.

    There's a load of ways that come to mind that are based on expected behaviour would still work.

    - Change the collision tags so that LOS ignores the monster when it's "invisible".

    - Remove the monster class from the custom obstacle list ( custom mode only, and doesn't work for a single instance ).

    - Add an instance variable to the monster to say if it's invisible, and filter the results of LOS to Monster against this.

    - Pin a "invisibility cloak" ( a solid that's larger than the monster ) to the monster, so that the ray hits that instead ( might interfere with movement behaviours, but collision tags can probably solve this ).

    Just tried the 3rd one in the example project and it's super easy. Are many people relying on "Has LOS to ObjectClass" returned false if ObjectClass was an obstacle?

  • Thanks everyone for helping!

    I got it working by choosing Custom on LOS.

Post reply
  • 10 posts
Return to board index
Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)