Bullet spawning from non-existent offset due to speed

Bugs will be moved here once resolved.

Post » Sun May 03, 2015 8:03 pm

Problem Description
Using a keyboard press as a trigger to spawn a bullet going a high speed makes the bullet spawn at an offset from the spawn point.
(Important note that confirms this as a bug: Using a gamepad does not reproduce this problem.)

Attach a Capx
https://drive.google.com/file/d/0B0gW1A ... sp=sharing

Description of Capx
"Spawner" sprite object spawns a "bullet" sprite object at image point 1 and 2 when arrow keys left or right are pressed.
When the "bullet" collides with "wall" sprite object, or overlaps it, "bullet" is destroyed.
Steps to Reproduce Bug
  • Press Left or Right

Observed Result
Bullet object is spawned at a huge offset from the image point and is not destroyed by the wall object because it doesn't overlap or collide with the object.

Expected Result
Bullet object spawns at image point X, overlaps/collides with Wall object and is destroyed.

Affected Browsers
  • Chrome: (YES)
  • FireFox: (YES)
  • Internet Explorer: (YES)
  • NW.js (YES)

Operating System and Service Pack
Windows 7 SP1

Construct 2 Version ID
Beta r203


@Ashley
This is one of the major bugs I mentioned in the email, hopefully this will help you debug C2.
Also I noticed that the offset from which the object spawns is related to both the object's speed, and the size of the original window.
Last edited by Nesteris on Mon May 04, 2015 11:51 am, edited 2 times in total.
The moderators are corrupt and ban for no reason, especially that condescending neckbeard asshole Kyatric. The forums are filled with fanboys.
Banned User
B
22
S
7
G
1
Posts: 558
Reputation: 2,925

Post » Mon May 04, 2015 7:42 am

Hey Nesteris.

The bullet is appearing to be spawned outside of the wall because it is simply moving so fast, that by the next tick of the engine it is already outside the collision range. I don't think this is a bug, it's just what can happen when you use bullet behaviour to move objects.

If you want high speed accuracy, try to use custom movement instead.

Here is a nice example from Ramones that was posted a while back : https://db.tt/15CfaNkS
ImageImage
B
130
S
23
G
7
Posts: 1,078
Reputation: 13,280

Post » Mon May 04, 2015 11:40 am

@GenkiGenga

If that was the case of it simply moving too fast, then the problem would be present when you used a controller.
If you use a controller, it actually spawns at the proper image point with no offset. And thus, bug confirmed.

@Ashley I believe you take over now.
The moderators are corrupt and ban for no reason, especially that condescending neckbeard asshole Kyatric. The forums are filled with fanboys.
Banned User
B
22
S
7
G
1
Posts: 558
Reputation: 2,925

Post » Mon May 04, 2015 12:51 pm

Hmm that is weird. It's not so simple though.

There must be a difference with the way the "on press" works between keyboard and controller because If you add a 1 second wait before the bullet is fired, you see the controller now behaves the same way as the keyboard.

https://db.tt/1ctTYhCJ

There is a bug somewhere :) But if I was you I would just switch to custom movement. From the example above you can see how much more accurate it is.
ImageImage
B
130
S
23
G
7
Posts: 1,078
Reputation: 13,280

Post » Mon May 04, 2015 2:09 pm

@GenkiGenga

I tried setting the Custom Movement speed to 3000 instead of 5, it becomes inaccurate as well (but not as much as bullet behaviour) so the .capx is set up in a slightly unfair way.

So it turns out the bug affects all speed, not just bullet behaviour. But it seems to be only present when using keyboard triggers.

There must be a difference with the way the "on press" works between keyboard and controller because If you add a 1 second wait before the bullet is fired


If you add a 1 second wait, there is absolutely real world application value if there's going to be a one second delay between pressing and spawning. Triggering using a keyboard spawns immediately and with an offset.

If you want to see exactly where it spawns, make the bullet spawn a marker object when and where it's destroyed, then make the wall object the size of the room.
The moderators are corrupt and ban for no reason, especially that condescending neckbeard asshole Kyatric. The forums are filled with fanboys.
Banned User
B
22
S
7
G
1
Posts: 558
Reputation: 2,925

Post » Mon May 04, 2015 2:24 pm

Can you post a cap.x? Ramones example I posted is 100 percent accurate for me, even when I set the speed to 100 thousand.
ImageImage
B
130
S
23
G
7
Posts: 1,078
Reputation: 13,280

Post » Mon May 04, 2015 4:33 pm

Here.

If it really was the bullet being too fast for the eye or something, this wouldn't be happening. It's stupidly obvious that it's spawning at an offset, otherwise the marker would get set at the imagepoint and not a huge distance away.
The moderators are corrupt and ban for no reason, especially that condescending neckbeard asshole Kyatric. The forums are filled with fanboys.
Banned User
B
22
S
7
G
1
Posts: 558
Reputation: 2,925

Post » Mon May 04, 2015 5:14 pm

Sorry, I meant can you post an example of the custom movement not being accurate (you said the cap.x was unfair).

I get what your saying and I know you are frustrated, but the thing is, you can see from the example I posted that using bullet behaviour at high speeds is not accurate. So if you want to use bullets that fire that fast, you really need to use custom movement anyway.

It doesn't make sense to me that it is different using the game pad as input, that's what I think it is though. A game pad bug.
ImageImage
B
130
S
23
G
7
Posts: 1,078
Reputation: 13,280

Post » Mon May 04, 2015 9:52 pm

Here, should be it.

This is a very, very weird bug for C2 to have.
Also as for the .capx, the accuracy for custom movement is still a lot higher, but it's never 100 out of 100. The lowest I got was I think 60 and the highest around 80.
The moderators are corrupt and ban for no reason, especially that condescending neckbeard asshole Kyatric. The forums are filled with fanboys.
Banned User
B
22
S
7
G
1
Posts: 558
Reputation: 2,925

Post » Mon May 04, 2015 10:39 pm

The problem with your example is that you have mistakenly tried to set the speed of the object in the 'pixels per step' property (which is actually used to check how often we look for collisions). Set that back to 5 for this example.

Go back to the original example I posted, your new one is also missing an important action in event 4.

You set the speed of the custom bullet in event 2, Should be 100 percent accurate now.
ImageImage
B
130
S
23
G
7
Posts: 1,078
Reputation: 13,280

Next

Return to Closed bugs

Who is online

Users browsing this forum: No registered users and 6 guests