Bullet spawning from non-existent offset due to speed

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.

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

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.

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 <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile"> 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.

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.

[quote:3jyi959y]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.

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.

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.

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.

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 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.

Yeah, it looks like how I thought custom movement worked was wrong. My bad.

Getting back to the topic, objects spawning at offsets from where they're supposed to spawn is a huge bug. Should be fixed.

Hello,

What's happening is the "on key pressed" condition is a trigger which is called before the behaviors and normal events are run. So before the new bullet is drawn or your events get a chance to check for a collision, the bullet behavior runs and the bullet is moved. At 60fps and with a speed of 4000pixels/sec it will travel about 66 pixels which appears to be the offset. If the fps drops the distance will increase as expected.

The reason it doesn't happen with a gamepad is it's triggers are fake triggers, much like "on collision", which is a check in place in the event sheet. For examples:

"on collision" is the same as "is overlapping" and "trigger once".

"On gamepad button" is the same as "gamepad button is down" and "trigger once".

"key is down" and "trigger once" could be used instead of "on key pressed" if the check needs to be in place.

R0J0hound

You're a complete genius, thank you so much!! I'm screen-capturing that for future use.

Are there any other events that do something like this?

There aren't too many, but here's all the fake triggers I could find. Just to clarify again they're like a normal condition but have an implied "trigger once". The "on timer" was a new one for me.

System-> "every x seconds"

Sprite-> "on collision"

Gamepad-> All "On..." conditions

Timer Behavior-> "on timer"

Thanks a lot R0j0hound, this helps out a big lot!