How do you get the turrets to chase you? When I run the .capx they just all spin in place.

I was going to see if maybe something was making them fail their pathfinding query.

I have narrowed it down to the Bounce event. If I manually bounce something off an object while it is decelerating, when the speed reaches 0 it will sometimes get NaN as its position (but not always).

Ashley - I'll continue to try and isolate the issue and see if I can get a repro-able .capx, but does anything jump to mind knowing this?

What would be the most likely input culprits for divide-by-0 calculation with the bullet behavior? Speed? Acceleration? Position? Angle?

Hey all, I have some objects in my game with the bullet behavior that I'm doing a lot of stuff to (disabling and enabling bullet, bouncing off of certain objects, adjusting positions and angles, pinning, unpinning, changing speeds and accelerations, etc.)

I'm running into an issue where every now and then a bullet object's position will be set to NaN by something (both x and y values). I haven't been able to repro it reliably, but I do notice it often happens when a bullet decelerates to 0. When it gets to the point where I expect it to stop, it will vanish, and checking the debugger reveals that the object still exists but has NaN as the position.

The project is kind of large and sprawling so I can't easily link it, but was just wondering if anyone has run into this issue or had suggestions for debugging to try and figure out why the position is getting set to NaN, or if there's a way the bullet behavior can end up dividing by 0 or whatever.

Thanks!

This is a little clunky, but when you touch the sprite, you could save its UID, then use that to pick all objects NOT with that UID to set their variable to inactive.

<img src="http://storage.wertle.com/construct2/TogglePick.PNG" border="0" />

I solved the "toggle active" issue in a way similar to this, only I used another instance variable to do the check for the not-being-touched objects in the family.

To illustrate the thing about the pivot point, make sure the origin point on your arm is opposite its default 0 angle, so that it will "point" properly. If the origin is at the center point it will just pivot like a windmill.

Here's a quick example

Could you post a .capx or a screenshot of how you were trying to pick?

That is strange, I just straight up had it print out 416%6.4 and its output is 6.4 instead of 0. Maybe there's a bug when using modulo with decimal numbers?

Or you can make an invisible sprite called "Camera" and put the scroll-to behavior on that. Then you can manipulate it separately, perhaps keeping it just in front of the player when he's moving, etc.

I've had good success using an invisible camera sprite with scrollto and the LiteTween plugin for camera work.

In case you have a situation where you can't use containers: If the objects pinned to the thing are all of the same type or are in one family, you could do as a subevent to your collision event:

System -> Pick by evaluate -> Object: Object that is pinned to spritePlane -> Expression: Object.Pin.PinnedUID = spriteShot.UID

That should pick all the things of that Object type that are pinned to the sprite you collided with. If you have multiple object types pinned, then it gets a bit messy, as you'd have to do a different pick for each Object type or stick them in a family.

Just make sure to Destroy spriteShot on a subevent after you do all the picking.

EDIT: Here's a .capx illustrating this idea

I have a similar setup and did more or less the same thing (door has SwitchID variable that will hold switch's UID and vice versa), but I did an extra step to skip the tedium and error-proneness of entering all the IDs by hand.

I made an invisible sprite called "linker" and placed it in my layouts connecting the switches to the doors. Then on layout start, I loop through all the linkers, pick the door and switch that it overlaps, and set the ID variables there.

Then I delete the linker sprite since it's unused except at initialization. This was handy for me since I'm a more visual person, so being able to see in the editor which doors were linked to which switches was helpful.

In this particular case, the point at which I'd like to check is after a relatively complex pick of the same instance type, so it would be convenient to be able to do so.