Bullet spawning from non-existent offset due to speed

Bugs will be moved here once resolved.

Post » Mon May 04, 2015 11:16 pm

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.
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 » Tue May 05, 2015 12:14 am

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.
B
92
S
32
G
107
Posts: 5,274
Reputation: 69,959

Post » Tue May 05, 2015 11:05 am

@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?
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 » Tue May 05, 2015 5:38 pm

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"
B
92
S
32
G
107
Posts: 5,274
Reputation: 69,959

Post » Tue May 05, 2015 7:26 pm

Thanks a lot R0j0hound, this helps out a big lot!
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 » Thu May 14, 2015 2:10 pm

@R0J0hound is absolutely right, this is to do with the order of execution. The problem is the browser Gamepad API doesn't actually fire events. With keyboard input, pressing a key makes the browser fire a "keydown" event which fires Construct 2's 'On key pressed' trigger. On the other hand the Gamepad API just has an array of button states which you have to regularly check and see if something has changed. Construct 2 makes it look like gamepad input fires events by using an event that looks like a trigger, but is really evaluated every tick like normal events, and it internally uses logic like "is button down this tick but was up last tick", therefore practically firing like a trigger.

However I think the execution order for each frame is something like this:

1. Browser fires any pending events [possibly firing a keyboard input trigger]
2. Behaviors tick (the bullet behavior will advance speed * dt pixels here)
3. Events run [possibly firing a gamepad input trigger, since it checks it in the event]
4. Screen is redrawn

So the difference is whether or not the behavior is advanced the same tick as the input is triggered.

I don't know if this really counts as a bug; Construct 2 is working correctly, it just is a consequence of the order things are checked in. I guess it's an inconsistency though. I'm not sure there's anything obvious we can do about it. The Gamepad API is due to get real browser events in a future update, so I guess that would solve it. Moving the bullet behavior to tick after events would also work, but that would have surprisingly severe compatibility implications, since a lot of games probably rely on fairly subtle edge cases like this and changing that would break them. I'm also not convinced it's really an important bug - whether or not the bullet advances one extra tick before you see it is only really noticable at extremely high speeds and also when you compare keyboard and gamepad input at the same time, whereas I think most players would just stick to one kind of input for the whole game.

I'm not sure we'll do anything about this right now, but I'll leave this report open.
Scirra Founder
B
395
S
232
G
88
Posts: 24,371
Reputation: 193,762

Previous

Return to Closed bugs

Who is online

Users browsing this forum: Yahoo [Bot] and 3 guests