[Post-r90] Bullet Behavior "Set Angle" broken

I really wish the other problems I run into when working on stuff were as easy to demonstrate in a simple cap like this. :p

Say I want a spinning boomerang thing that spins independently of the Bullet behaviour's angle of motion, and the behavior has an option to allow stuff like this - except it doesn't work, because the object's angle is always affected even if the option is switched to "no". I imagine nobody's noticed this because, quite frankly, you don't often want to make bullets not point wherever they're moving.

Example capx.

I don't think the bullet behavior is making your sprite rotate so turning off rotation in the bullet behavior shouldn't do anything in this case. I think it is just the rotate behavior that is causing the sprite to rotate. To test that out I set rotation speed to 0 on the sprite on the top left, but made the bullet angle of motion change every tick. The sprite does not rotate at all. The top right sprite has the same change to bullet angle plus the rotate speed set to 180. The one in the top center is your origninal.

BulletAngleOfMotionAnim.capx

(I misunderstood what your problem was at first--didn't see it was a bug report and thought you were asking for help-- and created an indendent rotation through animation and just left it there. You can see it on the bottom three sprites. (The one on the right has rotation of the bullet, rotation from the rotate behavior and rotation through animation.)

My point still stands regardless - "Set Angle" is supposed to allow the object to rotate WITHOUT affecting the Bullet behaviour's angle of motion. In this case, the Rotate behaviour should make the cross spin while the cross moves in a straight line. It's not that complex.

It's a bug, plain and simple.

I agree with you that there is a bug--more specifically, some sort of unexpected interaction between two behaviors--but I don't agree it has to do with the bullet's set angle action. According to the manual:

Set angle

If set to No, the behavior will never change the object's angle. If set to Yes, the behavior always sets the object angle to the angle of motion.

This is not what you seem to expect. You seem to expect the opposite--that if set to No, the bullet's angle of motion will never be affected by the object's angle. That is, for the bullet to ignore the sprite's angle when determining motion.

Meanwhile, using an animation instead of rotate to make the boomerang might be a reasonable workaround.

Or even using a "base" invisble object with the bullet behavior on top of which the actual boomerang is pinned and rotates.

I still think the opposite should be true as well, that rotation should not affect angle of motion if the developer wants it that way.

Kyatric: I'd use that, but it's rather difficult without Containers, unfortunately.

Have the boomerang sprite have an instance variable "Parent" in which, on creation, you store the Base.UID

Ex:

=> On start of layout

--> System: create Base somewhere on layout

--> System: create Boomerang on Base.x, Base.Y

--> Boomerang: Pin to Base

--> Boomerang: Set Parent to Base.UID

With a Boomerang pinned to the base you only need to bother about Base's trajectory, the Boomerang with a rotate behavior will rotate on itself directly.

And you can have a

Base: On destroyed

Boomerang: Parent = Base.UID

--> Boomerang: destroy

Picking the Boomerang instance that has the same UID as the currently picked Base does the job.

Same goes to pick Base by UID => Boomerang.Parent (if you want to pick the Base related to an already picked Boomerang)

Example commented capx

Hmm, this is a slightly tricky one. There are two angles: the angle of motion of the Bullet behavior, and the object angle (the visible angle). The 'Rotate' behavior doesn't have any awareness of other behaviors - it only sets the object angle.

What you want is for the rotate behavior to set the angle of motion, but not the object angle. This isn't easy to support because it means the rotate behavior has to gain awareness of other behaviors and modify them, and this isn't really in line with how C2 behaviors tend to work.

What really is the bug report is setting the object angle shouldn't affect the angle of motion when bullet's 'Set angle' is set to 'No'. In this case the object angle and angle of motion should work independently. Previously, if you ever set the object angle, C2 would also update the angle of motion. This has been fixed for the next build so setting the bullet's angle only affects the object angle and not the angle of motion. However, the result is still not what you wanted: the object moves continually to the right, since the angle of motion is always 0, while the object appears to rotate.

There is also one exception: the angle of motion is still set to the object angle on the first tick of the behavior. This is to preserve compatibility with existing projects like Space Blaster, where many objects are spawned then 'set angle' used to modify the bullet angle. The bullets would fly off at the wrong angle unless they initially take the object angle as their first angle of motion.

Hopefully that's clear... however, even with the fix, you'll still need to use a second hidden object or manually set the angle of motion with events to get the effect you want.

This might be fixed by the changes in the next build but I noticed if you set the 'angle' and then the 'angle of motion' in the same event, the 'angle of motion' doesn't change (or it does change but then changes back to the angle).

angle_angleofmotion.capx (r93)

Whoa, whoa, back up, Ash, I think you accidentally misinterpreted what I actually want, because, well, the bug fix you've made is exactly what I want.

hat you want is for the rotate behavior to set the angle of motion, but not the object angle.

Actually, the opposite is what I want - for the rotate behaviour to only affect the object angle, not the angle of motion. <img src="smileys/smiley36.gif" border="0" align="middle" />

hat really is the bug report is setting the object angle shouldn't affect the angle of motion when bullet's 'Set angle' is set to 'No'. In this case the object angle and angle of motion should work independently. Previously, if you ever set the object angle, C2 would also update the angle of motion. This has been fixed for the next build so setting the bullet's angle only affects the object angle and not the angle of motion. However, the result is still not what you wanted: the object moves continually to the right, since the angle of motion is always 0, while the object appears to rotate.

You're mistaken, actually. I WANT the object to keep moving to the right (or up, or down, or wherever) in a straight line. (And then flip around and come back like a boomerang, but that's a different story.)

here is also one exception: the angle of motion is still set to the object angle on the first tick of the behavior. This is to preserve compatibility with existing projects like Space Blaster, where many objects are spawned then 'set angle' used to modify the bullet angle. The bullets would fly off at the wrong angle unless they initially take the object angle as their first angle of motion.

Eh, not a problem, I usually define the angle of projectiles on creation anyway.

opefully that's clear... however, even with the fix, you'll still need to use a second hidden object or manually set the angle of motion with events to get the effect you want.

Also not an issue, since I plan to do the latter anyway.

Oops, sorry for misunderstanding what you wanted. Anyway, I've made some tweaks for the next build, hopefully that will solve the problem.

Ah, it's alright, it worked out in the end anyway. Thanks, mate!