[r243] Line of sight with multiple instances

Problem Description

Line of Sight doesn't seem to activate if there are multiple instances of the same object close of one another.

Attach a Capx

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

Description of Capx

A single event checks if the enemy has LoS on the player. If it does, then triggers its animation to change once.

Steps to Reproduce Bug

• Create an object with the LoS behavior
• Add multiple instances of it
• Check if it has LoS on the player and trigger something to happen

Observed Result

If enemies are far apart it seems to work, but if 2 enemies are close by only one of the enemies change animation.

Expected Result

Each enemy should change animation if the player is close to them.

Affected Browsers

All of them.

Operating System and Service Pack

Windows 10

Construct 2 Version ID

r243

Is not the LOS. To illustrate this i added a 'is overlapping' and a 'once while true' to your capx. In the same way as the LOS is done. As you can see, it seems to show the same problem.

Yet does what exactly what it is designed for. I agree that it looks weird. But lets think it trough.

The ''once while true' allows that event to run its actions the first time that it is true. To have it running again, it got to be 'untrue' first.

So you approach those 2 monster plants, and at the moment 1 is in sight, the event is true. When the other one comes in sight, that event is still true. As long it is true, it will just not run due the ''once while true'.

You can test this, i made playerbase drag&drop to test it faster. Approach those 2, it will not work. Make the LOS condition untrue by getting to a distance, try again, it will work.

Side tips. I know why you want that 'once while true'. I used to do that myself. But it is not needed for animations. Because, see ....

The animation will ONLY change to the 'new animation' (and therefor start from beginning) when ...

1/ the current animation is different then the new animation

2/ the current animation is in the state of 'stopped playing'.

You got them looping, so not point 1, not point 2 will happen.

So dont worry to much about re-starting an animation that is already playing. It has no effect.

Better even, you can use this to loop animations like 'walk'. Those usually need a continuous press of a key. Meaning, when the 'walk' is at the end of the animation (point 2) it will auto restart again, due holding the key.

hey 99Instances2Go , first of all, thanks for the help!

I noticed that this problem is also happening with "if player is overlapping" like you said, and I understand what you mean.. since that certain event is already true, it can't be true again, so this happens.

But why doesnt it work if I do this:

This should make these events work for each instance of that object, right? But the same thing happens.. to be honest I've been using C2 for quite a while and have never had a problem like this, maybe I really am approaching this in a wrong way?

What I'm trying to accomplish is simple - if the enemy has the player in its LoS, the enemy should change animation. When it does that, if the animation frame is = 1, it should shoot a sprite at the enemy. If the player is no longer in the enemy's LoS, the animation should change back to default.

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

First things first. Although they have nothing to do with your question.

To make a flawless example i had to decide if they can rotate towards the player or not.

Since they are dumb plants, i decided not to. But then they have 2 states, mirror or not.

And as a consequence, they need a LOS cone. And as a consequence of that, the default state must be aligned with the default zero angle in C2. Since i dont know how to (temp) mirror in the layout editor, i added a 3th animation to be able to design in the layout editor as i want to. That is why the animations now align with the default zero angle in C2. So you know where halve of the code comes from.

Back 2 your question.

As you can see i will try to avoid a 'for each' at all costs. A 'for each' (depending on how many sprites in the loop) will always weight on performance. In this case that is perfectly possible because ALL sprites that meet the LOS condition will 'attack' and ALL sprites that dont meet the condition will be 'idle'. So there is no 'personal' thing going on. It is a 'all or nothing' case.

I have never seen a 'Once while true' work as intended in a loop. So i will avoid that to.

Usually you can not bring a 'shoot situation', a 'move situation' and a 'change animation situation' under the same condition. Because they often have different 'sample rates'. Gosh, how to explain that. Say, it runs at certain ticks / second. Each tick we can measure something, in other words : take a sample. The LOS needs a sample every tick. The animation change needs a sample only when something happens.

Starting from those 'base rules', (my personal rules) the way to go is already paved.

Has LOS, change to attack, else change to idle. I always bring conditions that are paired with an 'else' under an empty (every tick) condition. That way they stay together when i drag them around with my dumb brain.

For the animation. Done in a different event for reasons explained above.

Now, if i use a 'for each' then i am stuck with a 'Once while true' in a loop. So i look for something to avoid this. At the same time i prefer a picklist that contains only one plant, just as in the 'for each'.

Usually there is a trigger for that, and luckily there is a trigger in this case.

Just have to add a little logic to the trigger.

Notice also how nice the 'attack' loops, yet not a loop in the properties.

Hope this helped you some, despite my bad english, despite (maybe weird) personal rules.

Thanks for your help!

I noticed that your example has the same bug - if you move the player in front of 2 enemies, and move him just a little out of the LoS of the enemy in the back, this enemy's animation will get stuck (same problem as mentioned before).

I ended up finding an easy fix though, just had to add "On animation finished" to the enemy.

Thanks again!