setting the friction of the ball while it is on sand (or speed/acceleration, increasing de-acceleration), or setting the friction of the sand object itself if the ball passes over it.

revolute joints tend to act funny, i was trying to make an example but found that the snake body pieces would turn and get the whole snake to turn with it, thus creating a vortex of spinning snake.

my other thought was a system to simulate the "snake" game. set the controls to only be able to turn 90 degrees at a time and every time it turns create a waypoint for the body pieces to follow, would that work?

Whiteclaws - what specifically is the behaviour you'd like to create?

i made a debugger for the D action:

dropbox.com/s/4xjyfypx7qlnwtv/TestDebug.capx

if you want the one you are standing on to move you would need to change your condition to check for X instead of Y and then add in a condition (if you want) to pick the nearest to the player for stacked blocks.

hi there!

i would like to solve dt and floor() gaps using built-in behaviours and plug-ins (so i could eventually still upload to the arcade).

i have been recreating the example tutorial from another program for an endless runner for construct. when i tried to make it framerate independant gaps began to appear in the object spawning so i left it out to complete the tutorial.

another problem appeared - when the run speed is not a factor of 32 (the ground size) it creates gaps in the floor because floor() is used to get rid of the remainder in the ground spawning code, so it doesn't randomly stop spawning the ground because the runspeed isn't a factor of 32.

https://www.dropbox.com/s/bvupkq6urq9qxnr/endlessrunner.capx

if any one has some ideas to help fix the floor() rounding gaps i would very much appreciate it. is framerate independance important in an endless runner type game?

do you mean idle animations or waiting for a period of time after space is pressed and then the character jumping?

the first one could be done with variables and adding/subtracting to them when no keys are being pushed

the second one could be done with an animation or a wait event (on space is down/or is pressed, wait X seconds the simulate platform jump)

have you tried using physics revolute joints?

Rhindon - do you have another event to reset the animation to a default pose that conflicts with it?

ie. in pseudo code:

when not pressing the key (or key is not down) - set animation to default

raddevon

its because "start" starts outside the layout (event four) so it sets finished to true.

edit event four to add another condition:

start - compare x - x is less than -50 (or more if your text is bigger but it works for start)

rfisher - in your game you spawn falling down the first gap (firefox)

procrastinator - are there any drawbacks to using user made plugins? (like do they not work in certain places, on mobile phones or web publishing for example)

Rory - someone left a link to an endless runner tutorial on a different program. i've been trying to recreate it in construct to use in my own game with different mechanics and also leave as an example file for anyone who wanted to learn from it - however i am suffering from the same problem.

if made with dt it leaves tiny (dt spaced i assume) gaps in the floor tiles, i couldn't for the life of me figure out how to account for dt in all the equations

Rhindon - i'm not sure about other game types, the tutorials advise in platformer's for your player at least to have an invisible player box with the platform behaviour, and working as your collision mask, and then sticking your animation on top of that box with either pin or set position (i'm not sure which is better, if either is even).

the reason i mention this is it follows the same principle, you can change your animations but your actual player (invisible under box) remains unchanged and therefore always interacts with the environment in a consistant manner.

you could use image points to attach other invisible hitsensors and use that instead of the x and the y of the sprite's to weed out even further changes.

(again i'm not sure which is the "better" approach pinning or setting a position), you could just make sure that it's there - by pin or set position - and then on collision or on overlapping the to-be invisible hit sensor take damage. if you change the sprites size later on you'll just have to change the image points and the hit sensor sizes instead of the code.

it's not that big of a deal either way, just something to think about   <img src="smileys/smiley1.gif" border="0" align="middle" />