<Set angle of motion> failed for spawned bullet

Problem Description

For a spawned bullet, it doesn't response to <Set angle of motion> action quickly. It will need a <Wait 0.02 second> to work properly. As a C2 tutor, we are asked to reply this kind of question about every 3 months.

Attach a Capx

https://dl.dropboxusercontent.com/u/209 ... ailed.capx

Description of Capx

Click mouse left button to <Spawn> + <Set angle of motion>. Click mouse right button to <Spawn> + <Set angle>. The <Bullet> behavior's <Set angle> is set to YES. You can observe the differences by clicking corresponding mouse button.

Steps to Reproduce Bug

• Preview the project and push mouse left/right button
• Enable the <Wait 0> action in event#1. Check the response.
• Disable <Wait 0>, enable <Wait 0.02> in event#1. Check the response.

Observed Result

When mouse left button is pressed, the bullet doesn't responds to <Set angle of motion> action. Unless you enable the <Wait 0.02> action.

Expected Result

<Set angle of motion> should take effect quickly after bullet is spawned.

Affected Browsers

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

Operating System and Service Pack

Win7 Sp1

Construct 2 Version ID

r201 64bit

Supplement: Bullet generated by <Create object> responds quickly to both <Set angle of motion> and <Set angle> actions.

Set angle of motion is used with Every tick..

Every thick : set angle of motion -45.

Create is used with the (object+behaviors) imediately;

Closing as not a bug: the bullet behavior's 'Set angle' property is set to 'Yes', which means it tries to sync up the object angle with the angle of motion, which contradicts what you are trying to do. Set it to 'No' and it works.

Thanks for the reply. And pardon me for one more question about the corresponding part in C2 manual, I copy the followings form <Bullet> chapter:

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.

So the above means it will using the value of the 'object's angle' to overwrite 'angle of motion'. Is my understanding correct?

jomo the opposite actually:

Set angle to No: the angle of motion will be independent to the display angle (self.angle) of the object (think of a ghost in a pacman, it does not rotate visually when the angle of motion changes, always the top of the head at the top, and the bottom at the bottom)

set angle to yes: the angle of motion will set the actual display angle (self.angle) to the angle of motion of the object (think of a pacman, it rotates with the direction it goes to to have his mouth going forward), the angle of motion is the one to overwrite the display angle.

jomo the opposite actually:

Set angle to No: the angle of motion will be independent to the display angle (self.angle) of the object (think of a ghost in a pacman, it does not rotate visually when the angle of motion changes, always the top of the head at the top, and the bottom at the bottom)

set angle to yes: the angle of motion will set the actual display angle (self.angle) to the angle of motion of the object (think of a pacman, it rotates with the direction it goes to to have his mouth going forward), the angle of motion is the one to overwrite the display angle.

Aphrodite Thanks for your comments. And what you've described is the same with my original understanding - before I made the capx which attached with this post. I have no idea how to explain what I see.

And if you rotate the [Sprite2]'s angle to 0 in <Layout 1>, you'll see some more interesting things.

After that, set [Sprite2]' angle to 0.5, you might start to feel what i'm feeling now.

Ashley

It might ignore "action:set angle of motion" while property "set angle" is "Yes" in bullet behavior. And put this info into manual.

In source code, "action:set angle of motion" would set this.dx, this.dy , which might not be allowed while "set angle" is "Yes", since this.dx, this.dy should be calculated by sprite.angle only.