Line of Sight Workaround?

karlkerschl@gmail.com

Hi all! I'm trying to figure out a way to confirm whether or not a character can 'see' an enemy. For example, he'll aim at the enemy if there's a clear line of sight but not if there's an object (like a platform or wall) in between them. To do that, I thought the easiest way would be to draw a line actor between the player and enemy using magnitude as the width, but when I do this, the line fails to register collisions or overlaps with any object. Is there a way to make this work?
I've attached a screenshot showing the formula I'm using for magnitude (which might be totally wrong).
If I can't get this working, I guess my next strategy will be to fire a fast, invisible bullet from the player to the enemy to determine line of sight, but that seems clunky.

tatiang

draw a line actor between the player and enemy using magnitude as the width, but when I do this, the line fails to register collisions or overlaps with any object

If you use the same line actor but manually place it on the scene with a non-constrained width (e.g. 20), does it register collisions?

karlkerschl@gmail.com

Yes! I should have mentioned that. Unconstrained width works fine, but when I define it by the magnitude it no longer works.

tatiang

And what types of widths are you seeing when the width is constrained to the magnitude? For example, if you use a Timer and Log Debugging Statement to watch that value change (or just a Display Text behavior perhaps)?

tatiang

I just made an actor constrain its width to a variable function and collide with another actor and you're right... it's not detecting the collision. I suppose this is similar to the fact that Interpolating an actor's position will prevent collision detection.

Demo attached.

tatiang

What about firing a very fast bullet in the direction you want to check? That can have issues too since it skips pixels, but just a thought.

karlkerschl@gmail.com

With a Display Text behaviour, the width reads as a variable real number of between 20 and 400 (depending on where I touch the screen in relation to the player). So it seems pretty normal and it looks like the formula works, at least. But no dice on the collision.
I set up the invisible bullet workaround and that seems to be doing the trick - it's just that the magnitude constraint would have been such a tidy solution.

karlkerschl@gmail.com

Thanks, @tatiang! I suspected it was akin to that interpolation problem - maybe the coordinates are just changing too quickly for it to properly detect the collision?
I've set the invisible bullet to a speed of ~900 and the detection works. Have to test it in different scenarios but hopefully it'll hold up.
At least now I know I'm not crazy and I can stop staring at this magnitude formula.

tatiang

Glad at least one solution is working.

Armelline

Here's a rather convoluted but pretty accurate way of achieving line of sight. It's... not the easiest method and if I'm honest I'm not sure it's the method I'd use if I was making a game, but putting it together was an interesting little experiment.

It uses actors constrained between the player and the enemies, and only fires bullets if there's a clear line of sight. It gets around the problem of the line not detecting the collisions but looking for the collisions using the walls, not the lines.

tatiang

Very nice demo, @Armelline! What I don't get though is that you did use lines and the collide rule in the Wall actor works even though the width of the lines is being constrained.

Armelline

@tatiang said:
Very nice demo, Armelline! What I don't get though is that you did use lines and the collide rule in the Wall actor works even though the width of the lines is being constrained.

The collide is being checked in the walls. Each wall has a self attribute identifying it specifically. When it overlaps with the line of sight detector, it puts a 1 in a table cell. If it doesn't, it puts a 0. Enable the display texts in the enemies to see this happening. When the player detects that there are no 1s in the table column, it fires at the actor. Otherwise, it doesn't (as at least one wall is being collided with). This is why it's a bit convoluted

tatiang

Right, I did turn on the Display Texts and I get how it's supposed to work -- I'm just surprised that it does. Did you try the demo I posted above? I would think an actor with a constrained width would still trigger a collision but in my example it didn't and in yours it did.

pHghost

Is this a bug?

I think I remember seeing a tutorial on this method some time back, and as far as I remember, it used to work.

Armelline

Huh that is weird! I'll look at it more after supper, interesting conundrum!

karlkerschl@gmail.com

Yeah, this demo is great, @Armeline! I just tried detecting the collision using my platforms rather than the line (as in your model, but with a simple boolean rule rather than tables) and it still didn't work for me.
I'm using the 0.13.7 beta of the Mac Creator, for what it's worth.

AlchimiaStudios

The walls in @Armelline 's demo are doing the collision detection, and are not dynamically scaling width.

So it is a "static" hit box.

When the collision detection is on the dynamically scaling object, it's hitbox can no longer can detect properly.

So it is a "dynamic" hitbox. I've never seen GS properly detect collisions on a dynamic hitbox.

That's why @Armelline 's demo works.

Armelline

Hah, I think I worked it out and yeah, I think it's safe to say this not working is a bug.

Will post a demo in a second.

Edit: Well I can't replicate it using @tatiang's demo. Will keep working on it!

Armelline

@AlchimiaStudios said:
The walls in Armelline 's demo are doing the collision detection, and are not dynamically scaling width.

So it is a "static" hit box.

When the collision detection is on the dynamically scaling object, it's hitbox can no longer can detect properly.

So it is a "dynamic" hitbox. I've never seen GS properly detect collisions on a dynamic hitbox.

That's why Armelline 's demo works.

That was my assumption making the demo. But try taking @tatiang's, and removing the constrain from the red actor. Then move it manually into the path of the white actor. Collision fails to take place

AlchimiaStudios

@Armelline said:
That was my assumption making the demo. But try taking tatiang's, and removing the constrain from the red actor. Then move it manually into the path of the white actor. Collision fails to take place

You're right. Hmm, very strange...

AlchimiaStudios

@Armelline when you change the layer order in @tatiang 's demo... it starts working

Armelline

@AlchimiaStudios said:
Armelline when you change the layer order in tatiang 's demo... it starts working

Right you are! This definitely looks like a bug then.

Gets even weirder. It'll work even though both actors are constrained. This would imply that if you don't swap the layers, it would work with the other actor triggering the debugging statement, but it doesn't.

AlchimiaStudios

@Armelline said:
Gets even weirder. It'll work even though both actors are constrained. This would imply that if you don't swap the layers, it would work with the other actor triggering the debugging statement, but it doesn't.

Yeah def a weird bug. Somethings not right.

Armelline

@BlackCloakGS Any of you guys able to shed any light on this?

tatiang

I'll submit it as a bug with this file.

http://bugs.gamesalad.com/show_bug.cgi?id=926

AlchimiaStudios

@tatiang said:
I'll submit it as a bug with this file.

http://bugs.gamesalad.com/show_bug.cgi?id=926

Nice!

Wonder if these are related (one is listed as ARC, so obv can't confirm):

http://bugs.gamesalad.com/show_bug.cgi?id=869
http://bugs.gamesalad.com/show_bug.cgi?id=219

@BBEnk Came to a similar conclusion on the second bug listing.

Seems to be an old bug too. Although It can sorta be worked around, it certainly isn't consistent.

Huh, well maybe @BlackCloakGS will take a look when he gets a chance.

tatiang

Ah, didn't see that second one. Thanks.

BBEnk

@AlchimiaStudios said:
Huh, well maybe BlackCloakGS will take a look when he gets a chance.

I tested this awhile back and it was working fine but I guess it's back again.