how to make the LineOfSight condition trigger on a collision mask.

Good afternoon Ashley , I have a question about LineOfSight. why the behavior doesn't work on the collision mask, but only on ImagePint0. This is not logical since the object can climb out from behind an obstacle and ImagePoint0 does not. How to implement lineOfSight triggering on a collision mask.

Line of sight won't check every pixel within the collision box of every object that needs to be checked, that would be absurd. The origin point makes the most sense.

A solution would be for you to use a invisible helper sprite as a ray to check for overlap.

construct.net/en/tutorials/lightning-fast-raycasting-587

Line of sight won't check every pixel within the collision box of every object that needs to be checked, that would be absurd. The origin point makes the most sense.

A solution would be for you to use a invisible helper sprite as a ray to check for overlap.

https://www.construct.net/en/tutorials/lightning-fast-raycasting-587

Why check each pixel if you can check the points of the collision mask? Your implementation is crutches. I pay $ 100 a year for 3 beta, and would like to have some obvious things right out of the box.

The Documentation is free.

Might try reading about Cast ray.

construct.net/en/make-games/manuals/construct-3/behavior-reference/line-of-sight

> Line of sight won't check every pixel within the collision box of every object that needs to be checked, that would be absurd. The origin point makes the most sense.

>

> A solution would be for you to use a invisible helper sprite as a ray to check for overlap.

> construct.net/en/tutorials/lightning-fast-raycasting-587

Why check each pixel if you can check the points of the collision mask? Your implementation is crutches. I pay $ 100 a year for 3 beta, and would like to have some obvious things right out of the box.

Because if you checked the collision points only, you would have issues detecting any collision at all half the time even with nothing in the way due to rounding errors.

LOS has always worked that way. It's a quick and simple design and it seems to be fine for the majority of uses, since it's worked like that for years and most people seem fine with that.

Also, testing line of sight to any point on the collision mask isn't necessarily desirable. In many cases you don't want to count line of sight if only a tiny fraction of the collision mask is exposed. For example if only a tiny hair-width of the player is showing past a wall, should enemies count that as visible? If it works by any point on the collision polygon, the answer is yes, and then you get enemies that leap in to action chasing you down when the player is still basically hidden (and based on past experience people will probably file this as bugs thinking Construct is calculating this wrong). This then also breaks the symmetry of line-of-sight, meaning the enemies have line of sight to the player, but the player doesn't have line of sight to the enemies. You could also try to fix that by allowing any part of the player collision polygon to have line-of-sight to any part of the enemy collision polygon, but then you get even more absurd results, like a hairline edge of the player's shoulder being able to "see" a hairline edge of an enemy's shoulder counting as both objects having line-of-sight to each other. So then you could try to fix that by having some kind of way to configure the proportion of the area of the collision mask that counts as visible... and now you have a complicated feature that's hard to visualise, difficult for beginners to understand, and tricky to program.

As with most features if you run all the way down the rabbit hole of the various details and edge cases, you end up with lots of complications, which in turn makes Construct more complex and difficult to understand. The main point of the product is to be simple and intuitive for beginners, so we avoid doing this wherever possible. As it stands, you can test line-of-sight to any position, so you could set up a few key image points around the edges of the object, and count it as visible if you have line of sight to any of those points. That's pretty straightforward, doesn't require any new features, and still more or less solves the problem.

Ashley Can we have a setting on LOS behavior - "LOS to origin point" / "LOS to polygon"?

This will ensure compatibility with old projects, but will also allow to use LOS to collision masks to those who need it.

The symmetry is not an issue in my opinion, as in real life you may see someone's leg for example, but that person may not see you.

a hairline edge of the player's shoulder being able to "see" a hairline edge of an enemy's shoulder counting as both objects having line-of-sight to each other.

This is a valid point, but currently much more often we have a situation that objects are in clear view, but not in Line-of-Sight. Like here - two blue sprites have origin point at the bottom and therefore don't "see" each other:

I totally agree it should be included the option of "LOS to polygon" for the people that need to use instead of Line Os Sight to the Origin Point, as many Games needed LOS to polygon not Los to Origen, Example many years ago I was making a game like Agario and the biggest problem I had is how to detect the Enemies with LOS as each enemy can have different sizes and you cannot use one LOS Range size for all, example one object can have 3000 px sizes while other can have 100px size, so if you have some Ai logic that has to trigger only when you have an enemy at 100 Range then is impossible but if we had the LOS to polygon then doesn't matter how many different sizes the object will have then you can always detect them at the same range 100px for example, I had to drop the project on that Time as it was quite complicated to make it without this feature.

Here is more visual using the same example as above:

Player 200px

Enemy 3000px

Enemy 1500

Enemy 100px

So if I want to have AI to do attack the Player when an enemy is on Range 100px of the Player, then first the player has to have a LOS Range minimum of 1600 so it can detect at least the enemy that is size 3000px

SO I have to set Player LOS Range =1600

but here is the problem:

Enemy 100px Size >>>>It ill be detected at player distance 1550px away not 100px Range as we wanna

Enemy 1500px Size >>> It ill be detected at player distance 850px away not 100 as we wanna

Etc......

This was making any AI impossible to make because you had to create hundreds of extra filtering events due to this problem because this Agario type Game the Enemies are constantly (Growing & Shrinking).

So if instead, we had "LOS to polygon" then I could have only one Event

Start of layout >>>> Set Player LOS Range = 100 & "LOS to polygon"

Then:

Player has "LOS to polygon" To Enemies >>>>> Actions

It should be included as is essential for many Games, it can not hurt to add the extra option so people can choose which they need most why it should be limited, maybe its been working for people because they didn't have the option but not everyone had the same luck as I remember I had a lot of problem because of this specific problem and I requested many years ago as you can see here

https://www.construct.net/en/forum/construct-2/general-discussion-17/plans-upgrade-line-sight-c3-129012

I am one of those people who believe that you can create amazing and great games on Construct 3. But the lack of some things in construct 3 makes me feel discouraged.

I think that you know and understand what genres of games are most developed on construct. It seems to me that the guide to Construct 3 should be oriented in the world of game development, and support the easy creation of basic game mechanics in the platformer and TDS genres.

I like TDS games, I always keep an eye on the latest in this genre.

Let's look at the example of the TDS genre, here I am downloading a game called Bullet Echo from PlayMarket. Bullet Echo is a classic TDS. This screenshot shows that the item becomes visible as soon as its edge falls into LineOfSight. And this happens in all games of the TDS genre that I know, but in Construct 3 I can't implement this mechanics without crutches.

Let's look at another Popular TDS mechanic-line-of-sight visualization. It is present in many top games of this genre. I tried to implement the mechanics using your lessons using layers and mixing modes. I got 20-30 frames per second and 90%CPU on mobile devices.

I used to think that this is a very complex mechanics for CPU and GPU on mobile devices, but how disappointed I was to see 20 players with LineOfSight visualization on a single mobile screen. And it still worked fast and smooth with 60 FPS and 40% of CPU. Here are examples of games.

These questions I meet on the forums starting with Construct 2. And for so many years, there were no solutions to these questions. I want to create big and interesting games on Construct 3. and the position of orienting the engine only for beginners is fundamentally wrong. Or at least indicate in the description of Construct 3 that it is intended for children under 12 years of age, and not for serious game development.

You can create amazing and great games if you put in the effort.

Your belief that the engine is only for children under 12 years old is fundamentally wrong.

dropbox.com/s/m6x32uzqcjlf8sk/VisualLOS.c3p

I already gave you the solution for how to achieve the effect you want but didn't want to do it. The definition of a crutch is having someone else make something for you so you don't have to do it for yourself.

The engine does already provide an efficient line-of-sight capability. So it should be possible to customise it to your needs already.

The engine does already provide an efficient line-of-sight capability. So it should be possible to customise it to your needs already.

mm No without hurting Performance huge time, I tried it already before but you have to remove completely the LOS Behaviour and do all the LOS checking by Events, the problem is when you have 50 to 100 Objects that need to use LOS with Events it hurt so much the performance, it will be better to be integrated on C3.

This is just semantics. Line of sight denotes point to point.

I can see you, and you can see me.

Point to polygon does not fit that, raycasting does.