yep, the sprite's size increases, but the collision polygon should still wrap the drawing, not the whole sprite. Also, the origin should be the same for the entire animation (I assume you have the origin on the floor)

You should try tweaking the friction of both objects. The higher the friction, the less they will slide.

That's what I was trying to tell you. You create an animation in which the player jumps. Each frame of the animation has the player a little higher than the last one, until he reaches the top, then it goes the other way around.

Something like this:

Each drawing is a different frame of the same animation. The origin (image point 0) stays in the same spot so you can know where in the floor the player is, and you don't need to manually change the sprite's coordinates. When you want to jump, you simply play the animation.

Hmm, what I'd do is create a jump animation. In each frame, the sprite is a little higher than the last one without you actually having to change it's coordinates manually in an event (of course, when it reaches the top, you make every frame a little lower than the last one). You can add a shadow to the 'floor' of your animation to tell the player at which point in the ground the player will land. Also, you will probably need to modify the bounding box of each frame to wrap around the actual body of the sprite (because if you use the same bounding box throughout the entire animation, enemies will still hit you as if you were on the ground and you won't be able to jump over obstacles either).

I hope I made myself clear

Aren't you missing a "&" in your URL string between both parameters?

The final string should be

facebook.com/sharer/sharer.php score=1000:0&level=3:1

for example. You need to put the "&" before level, like so:

"https://www.facebook.com/sharer/sharer.php?u=http://www.mysite.com/share.php?score=" & highscore & ":" & random(1,0) & "&level=" & levelsCompleted & ":" & random(1,0)

Also, you should use a larger random range (like 1 to 10). The whole point of using the random function there is to make sure that facebook gets a new URL every time and doesn't use the cache

Sure thing. I'll see if I can help you then

Tell me what you had trouble understanding and I'll try explaining it in more detail

you can get an approximate distance by picking all dashes associated with that plane (Dash Plane = Spitfire.UID) and multiplying the picked count by 20

the distance would then be Dash.PickedCount*20

Actually, there were several problems with your implementation.

The Wait action does not put the whole event sheet on standby for the supplied duration. It only queues the actions that come after it in that event block (and subevent blocks that branch from it) to be executed after the delay. The rest of the event sheet runs normally while you're waiting for the queued actions to execute.

You had events that queued the walking animations to start after 0.1 seconds, and your 'attack' event only started the attack animations when a 'on any animation finished' trigger was fired. This was wrong for two reasons:

1) Let's say that the enemy is already walking left and on a certain tick you enter the 'chase' event and the enemy is still to the right of the player. That would satisfy the criteria for the event that queues the walking animation (which was already playing) to start again after 0.1 seconds. Let's say that on the very next tick the enemy bounding box is overlapping the player bounding box. You stop the walking animation, but since ticks normally take between 0.02 and 0.016 seconds, you still have a 'start walking animation' action queued (several, actually), so when the 0.1 timer is reached, the animation starts again. Since your 'attack' event only starts playing the attack animations 'on any animation finished', it has to wait until the 'fresh out of the queue' walking animation ends before starting any attack animations, which caused your problem.

2) If you had started using Wait correctly to fix that, you would have still had problems because you stopped the walking animation within the 'chase' event, so the 'on any animation finished' trigger subevent on your 'attack' event would have never fired (triggers as subevents only fire if their condition is met while inside their parent event). In fact, if you disabled the Wait actions in your solution, the enemy got stuck at the end of a walking animation even if it was in attack mode.

Aside from that, you were using wait every tick, when what you intended (I assume) was for the enemy to wait only the first time he found himself out of the player's range (that's why I used Trigger Once in the attached solution). You were also restarting the walking animations every time you did that, which would have looked awkward when you started using real sprites. The sensible choice there is to have the walking animation loop and only stop on command.

The 'direction' variable was necessary in order to use the waiting animation* properly, because you only begin movement when the waiting animation is over, so you need some way of knowing the direction the character has to walk to when the 'on enemywait animation finished' trigger fires. The only alternative would have been to place the trigger inside each of the events which compared the positions of the bounding boxes, which is a bad practice because you have to duplicate actions and that is never a good idea.

The event you were using to change back to chase mode was also a bit flawed. It worked, mind you, but it was confusing since it bounced the enemy back to chase mode even if he was still in the player's range, which would bounce him right back to attack mode. This could have caused you problems in the long run if you ever wished to add more complexity to the enemy AI.

I don't know if I'm missing something, but I'm guessing you can understand now why your approach wasn't working as intended.

Cheers

*: you can replace it with a Wait action in the solution with very few modifications. I still don't recommend it, I find that using Wait is less clear, and you can use the wait animation to have the enemy look confused or whatever, so it's an added bonus

Joy

Don't give up. Even though Construct 2 is incredibly simple for a game engine, it's still hard to get accustomed to the event system. I had to almost scrap your event sheet and start over. It took me the better part of 3 hours to distance myself from the way you were approaching your problem, because I was stuck trying to fix your code rather than re-do it. I'd say you were suffering from tunnel vision. I have attached a working version of what you were trying to do.

I'm awfully sleepy so I won't explain what I did in detail (in any case, the capx is pretty much self-explanatory). If you have any doubts, just leave a reply here and I'll get back to you.

The only thing I think needs mentioning is that I removed the Wait actions you used and replaced them with a 'wait' animation that lasts 0.1 seconds. I'd advise you to steer away from the Wait action unless completely necessary (it is prone to cause unintended behavior unless you are really familiar with it and most of the time it can be sidestepped).

For more information about the Wait action, read this tutorial: scirra.com/tutorials/56/how-to-use-the-system-wait-action (as you can see, it isn't as intuitive as you might think).

I hope this helps you,

Happy Coding!

If I could somehow override the cursor position manually I could make it appear at the opposite edge of the window whenever it goes out of bounds, fixing the problem. Bur afaik there's no way to do that in Construct 2

Here's a capx of the rotation only.

If you move the mouse around you'll see that the layer rotates but the player doesn't. My intent is to later only move the player in the direction he's facing (like a first person shooter). The problem is that when the mouse reaches the limit of the screen, rotation stops. I want to allow the player to rotate the layer indefinitely in the same direction and don't know how to accomplish that.