Setting bullet speed to 0 affects angle of motion

Problem Description

The angle of motion of the bullet behavior is affected by setting its speed to 0.

Attach a Capx

http://www.amirai.net/bugs/bulletdirectionbug.zip

Description of Capx

It has three events. Preview three times with only one of the events enabled at a time.

Event 1 works properly. The white sprites move in the opposite direction of the grey one.

In event 2, by setting the bullet speed to 0 before setting the angle, the white sprites move either left or right.

In event 3, moving the angle action after the second action to set the speed overrides the bug and it works properly.

Steps to Reproduce Bug

Open the capx, it should have events 1 and 3 disabled, and 2 enabled. Preview.

Observed Result

The white sprites move either left or right.

Expected Result

The white sprites should move in the opposite direction of the grey sprite.

Affected Browsers

I know the list of browsers I can test is sub-optimal, but it's the best my computer can manage and I'm confident it's not a browser bug.

• Chrome (out of date, the newest versions don't support my computer anymore): (YES)
• FireFox: (Can't test it, Firefox doesn't work on my computer for reasons I don't understand)
• Internet Explorer 8: (YES)
• Nw.js v0.15.0 (v0.16.0 doesn't work on my computer): (YES)

Operating System and Service Pack

Vista SP2

Construct 2 Version ID

231

It was reported before a few times. The crux of the issue is speed is stored as X and y components, and the speed and angle of motion are calculated from that. So when the speed is zero both components are zero and the angle of motion is calculated as zero.

Hmm... if that's the case it's not obvious. I suspected something like that might be happening, but I didn't think it was by design.

Ashley if you're not going to change the way it's coded, perhaps a note should be put on the set speed action of the bullet behavior's manual page? If this has been posted about multiple times before that would make it clearer.

Well it's about momentum, there is none so there is no angle to change. If you move "set speed to 100" before setting it to move at angle it works.

Also there's a difference between angle of motion, and angle.

If you set it to use the object's angle it will work as is.

Which may be why you feel that it should behave that way.

It's not that it can't be changed. It can be changed to store speed and angle of motion instead of xvelocity and yvelocity. The only other tweak would be when gravity is applied it would have to switch to x and y velocity for the calculation since it changes both speed and angle of motion.

The real issue is this is a breaking change, the affects the behavior's behavior and can change how existing projects work. Personally i'd like it changed but then again I don't have commercial projects relying on the previous behavior.

A new behavior sounds better. Vector behavior maybe?

Then again we have the generic "move at angle", and the custom movement behavior.

Edit:

I just noticed we do not have an expression to get current angle of motion for "move at angle".

I added a note to the AngleOfMotion expression in the manual. Closing.