turret behavior range

Problem Description

hi,

turret behavior range just compare the middle of an object and if middle (or x and y) is in the range then fire..

but in large objects this is a problem ... because maybe some of an object is in the range but still middle is not in range and in real life if some of the object is in range then turret can fire..

thanks

Attach a Capx

[attachment=0:2x08d82w][/attachment:2x08d82w]

Description of Capx

in my capx file you can see this problem .. the object is in range but the turrets not firing..

but if you move the object more near to the turrets .. when middle is in range then turret firing..

this is a big problem when we have large and small targets

Steps to Reproduce Bug

• make a sprite with a big size
• make that sprite to target of a turret
• you can see the bug

Observed Result

the turret range just use x and y position for checking the target is in range or not

Expected Result

turret must check all of an object for checking the target is in range or not

Affected Browsers

• Chrome: (YES)
• FireFox: (YES)
• Internet Explorer: (YES)

Operating System and Service Pack

windows 8.1 pro 64bit

Construct 2 Version ID

r173

This is not a bug. There are a number of way to deal with this. Off the top of my head, you could set an invisible target pinned to the corners of your big objects.

This is not a bug. There are a number of way to deal with this. Off the top of my head, you could set an invisible target pinned to the corners of your big objects.

this is a bug..

that is not the right way...

if i have 50 objects so i must pin 5-10 to each one ! .. so we lost performance and time... !

yes we can fix this but if we must "deal with this" so it is a bug !

we can make this behavior with construct 2 but with using the behavior we spend smaller time

construct 2 have the basics (we can do programming with construct 2) so we can tell we don't need the behaviors because we can make all of that behaviors with construct 2 ... but no .. this is about time and performance...

use a container. and/or an on created command that pins em there. 1 line of code would do it.

give the turrets greater range.

or, to differentiate between smaller and larger targets, use two turrets on top of each other, one with larger objects for targets and a bigger range to make up the difference.

there are a lot of not that difficult ways to fix this.

but maybe you're right. maybe there is a better way. but it seems, to me, at least, that checking for one point, on what would presumably be a good number of targets, is going to run a lot better than checking the whole collision box for all of them. That's just my best guess as to why it is that way.

Whether it's a bug or not, I'm just letting you know, it's not that difficult to deal with.

I don't think there's a good way to fix this in the behavior: doing a full circle/poly intersection would be a lot more CPU intensive than the current simple origin check, and there are reasonable workarounds (using pinned targets). Closing as won't fix.