turret behavior range

Bugs will be moved here once resolved.

Post » Sat Oct 11, 2014 9:51 am

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
TurretBug.capx

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
You do not have the required permissions to view the files attached to this post.
B
16
S
6
Posts: 243
Reputation: 1,755

Post » Sun Oct 12, 2014 10:01 pm

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.
B
88
S
43
G
71
Posts: 601
Reputation: 43,669

Post » Mon Oct 13, 2014 10:43 am

spacedoubt wrote: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...
B
16
S
6
Posts: 243
Reputation: 1,755

Post » Mon Oct 13, 2014 4:53 pm

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.
B
88
S
43
G
71
Posts: 601
Reputation: 43,669

Post » Mon Oct 20, 2014 4:31 pm

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.
Scirra Founder
B
399
S
236
G
89
Posts: 24,528
Reputation: 195,388


Return to Closed bugs

Who is online

Users browsing this forum: No registered users and 4 guests