Setting bullet speed to 0 affects angle of motion

Bugs will be moved here once resolved.

Post » Sat Jul 23, 2016 12:16 am

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
Moderator
B
94
S
33
G
33
Posts: 3,006
Reputation: 27,744

Post » Sat Jul 23, 2016 2:46 am

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.
B
91
S
31
G
103
Posts: 5,234
Reputation: 67,754

Post » Sat Jul 23, 2016 6:37 am

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.
Moderator
B
94
S
33
G
33
Posts: 3,006
Reputation: 27,744

Post » Sat Jul 23, 2016 3:01 pm

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.
Image ImageImage
B
168
S
50
G
163
Posts: 8,221
Reputation: 105,061

Post » Sat Jul 23, 2016 4:11 pm

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.
B
91
S
31
G
103
Posts: 5,234
Reputation: 67,754

Post » Sat Jul 23, 2016 4:29 pm

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".
Image ImageImage
B
168
S
50
G
163
Posts: 8,221
Reputation: 105,061

Post » Mon Aug 01, 2016 10:35 am

I added a note to the AngleOfMotion expression in the manual. Closing.
Scirra Founder
B
387
S
230
G
87
Posts: 24,249
Reputation: 192,240


Return to Closed bugs

Who is online

Users browsing this forum: No registered users and 8 guests