Double Tap System

it's may not be much but it will help those who don't know how to achieve this.

http://www.mediafire.com/?51jzgemxm8t

It's also documented and all that jazz.

edit:

Vrav's version using sub events as well as eliminating the use of detectors for collision detection. it may seem trivial but when games become larger eliminating certain things can provide you with the virtual resources you require!

http://www.mediafire.com/?6lgnlltt21j

The tap is a little too fast (hitting the keys) but good of you to help people out

oh, that can be changed by altering the value used for the "runTimer" from 10 to a larger number for a longer input period

This is awesome, every bit of it. Thank you, Vinny.

For custom movement, Ashley mentions a 'time delta' routine. I am blind to programming techniques; is there any demonstration of that method here?

heh, no problem. i want to know if there is anything i could improve on though, like putting in more or less detail in the explanations, what i should focus on more, etc.

I think it's very well-documented. I'm curious about the detectors, though. Is it possible to forgo them entirely by using "Sprite.Left" and "Sprite.Right" positions instead, algorithmically?

to be honest, i don't know all of the functions available in construct so just play around with the events, conditions, and actions and if you find that something could be accomplished more efficiently, please, let everyone know!

Yeah, I have it working that way, but the collision only recognizes the first wall object. Free of detectors, with leftmovement, checking that Sprite.Left is 'different to' Wall.Right correctly stops movement when hitting the left wall. The right wall however is simply passed through, because it's checking on the Wall.Left of the wrong wall object. Unless one wished to have distinct left and right wall objects, is there any way to solve this?

Something that references all instances involved...

i can't seem find the Sprite.Left, Sprite.Right, etc functions? where are they?

You can just type them, but if you're going through the bottom object thingy in your event window, they're called "Get X position of * edge"... I'm thinking that if you nest some loops into movement to test overlap of objects, then individually test the edge positions, it could work? Will try it, but really don't know if it's any more efficient to introduce new queries.

Edit: Okay, I figured out a way to do it without either system. Dunno if it's accurate, but the result looks fine to me.

http://www.mediafire.com/?6lgnlltt21j

that's awesome! i don't know if there's anything that will break the loop but the logic is definitely correct and we now know of another way to accomplish the same thing! great job Vrav!

Not bad, guys. Could use a little polishing, but it's a pretty solid system. With a little dash of momentum thrown in you could get rid of the jerky start.

Yeah, I had a bit more polished system working with only one movement loop. What it did was keep track of direction, 1 being right, -1 being left, and add that to the x position when the movement loop was run. Construct ate the cap, though.

Keeping track of direction facing is useful for the sprite's animation, I would think. It had two animations worked out which were switched between when the direction variable changed. I'd also modulated player.xSpeed, so it would add smoothly. Could have different animations phase out when the speed exceeds a certain point, etc.

In my feeble fiddling however, before the cap combusted, the double-tap system was removed, and replaced with a 'run button' style a la Super Metroid, just for fun. It would gradually speed the player up.