How do I free a stuck sprite in a solid object

Hi! The help file says you should not teleport or move solids so nothing can get stuck but if you have to enable/disable the solid behavior the Player can get stuck inside an object if it becomes solid when the Player collision box is inside. Does anyone know a Workaround to fix this? I tried to add something like "Middleclick to set Y Position of Player to Player.Y-10" to bring him on top of the object but this could be a Problem if he is stuck in a wall and should not go up (may get out of the Level this way).

Best workaround would be preventing it from happening alltogether..

The other way would be to add conditions for each possible unwanted situation..

Comparing either player position on overlap or maybe the boundingbox and moving some px in the desired direction untill overlap isn't happening anymore (this could offcourse be done within the same tick if wanted)..

Right, but I don't think its possible to prevent it because its part of the gameplay and sometimes the Player sprite gets stuck. Maybe it works with last vector and moving the sprite in the opposite direction to free it? (never tried something like that)

Yeah, you could always use the OldX, OldY trick..

Should be something like this:

create three instance variables OldX, OldY and A

-sprite is overlapping

-- trigger once

set A to : angle(sprite.x,sprite.y,sprite.oldX,sprite.oldY)

-- system every tick

sprite move 5px at angle A

-else

sprite set oldx = sprite.x

sprite set oldy = sprite.y

• (event)

-- (sub-event)

Hi. Thank you for your example!

I added the code with a small modification (only if sprite is visible) and will test it. So far it seems to work fine.

Just a thing:

• The "Every tickt" from line 13 is not necesary. The upper condition is an "every tick" condition, so if you use the action "Move 5 pixels..." without the "Every tick" but in the same line 13 or 11, it should work the same way. It's weird to use "Every tick" inside an "every tick" condition, it can produce non expected results.

Just a thing:

- The "Every tickt" from line 13 is not necesary. The upper condition is an "every tick" condition, so if you use the action "Move 5 pixels..." without the "Every tick" but in the same line 13 or 11, it should work the same way. It's weird to use "Every tick" inside an "every tick" condition, it can produce non expected results.

Using an empty (sub)event is actually the same as every tick, so removing it would make no difference..

If you put the action in line 11 it will not work as expected the first tick, because the angle is not set yet..

> Just a thing:

> - The "Every tickt" from line 13 is not necesary. The upper condition is an "every tick" condition, so if you use the action "Move 5 pixels..." without the "Every tick" but in the same line 13 or 11, it should work the same way. It's weird to use "Every tick" inside an "every tick" condition, it can produce non expected results.

>

Using an empty (sub)event is actually the same as every tick, so removing it would make no difference..

If you put the action in line 11 it will not work as expected the first tick, because the angle is not set yet..

That is what I tried to say... the "Every tick" inside is worthless.

And you're right... only in the same line 13 without the "Every tick" should work the same way I added the 11 line without reading the action before line 13.

>

> > Just a thing:

> > - The "Every tickt" from line 13 is not necesary. The upper condition is an "every tick" condition, so if you use the action "Move 5 pixels..." without the "Every tick" but in the same line 13 or 11, it should work the same way. It's weird to use "Every tick" inside an "every tick" condition, it can produce non expected results.

> >

>

> Using an empty (sub)event is actually the same as every tick, so removing it would make no difference..

> If you put the action in line 11 it will not work as expected the first tick, because the angle is not set yet..

>

That is what I tried to say... the "Every tick" inside is worthless.

And you're right... only in the same line 13 without the "Every tick" should work the same way I added the 11 line without reading the action before line 13.

To you and me it's worthless, for beginners it shows what the condition is (an empty event/condition can confuse some)..

Removing it makes no difference whatsoever..

To you and me it's worthless, for beginners it shows what the condition is (an empty event/condition can confuse some)..

Removing it makes no difference whatsoever..

Agree, but it doesn't mean that they can't understand it

About the position of the action... now that I think about it a little more LittleStain, I'm pretty sure that lines 12 & 13 are not necessary executed secuencially because they don't belong to the same action and they are at the same place from the condition hierarchically speaking. Am I right Ashley?

If this is right... placing the "Move 5 pixels..." in line 11 or 13 should be the same so it can cause the angle isn't know at right moment.

> To you and me it's worthless, for beginners it shows what the condition is (an empty event/condition can confuse some)..

> Removing it makes no difference whatsoever..

>

Agree, but it doesn't mean that they can't understand it

About the position of the action... now that I think about it a little more LittleStain, I'm pretty sure that lines 12 & 13 are not necessary executed secuencially because they don't belong to the same action and they are at the same place from the condition hierarchically speaking. Am I right Ashley?

If this is right... placing the "Move 5 pixels..." in line 11 or 13 should be the same so it can cause the angle isn't know at right moment.

As I understand events are read and executed from top to bottom..

Because I'd like the angle to be known before setting it, placing the event setting the angle above the one moving at that angle seems like a logical choice..

If I put the action in event 11, the first tick the overlapping condition is true the action would take place using the old value of the instance variable..

Now at the first tick the overlapping condition is true, first the new value is set (triggered once) and after that it is used in the second action..

>

> > To you and me it's worthless, for beginners it shows what the condition is (an empty event/condition can confuse some)..

> > Removing it makes no difference whatsoever..

> >

>

> Agree, but it doesn't mean that they can't understand it

>

> About the position of the action... now that I think about it a little more LittleStain, I'm pretty sure that lines 12 & 13 are not necessary executed secuencially because they don't belong to the same action and they are at the same place from the condition hierarchically speaking. Am I right Ashley?

> If this is right... placing the "Move 5 pixels..." in line 11 or 13 should be the same so it can cause the angle isn't know at right moment.

>

As I understand events are read and executed from top to bottom..

Because I'd like the angle to be known before setting it, placing the event setting the angle above the one moving at that angle seems like a logical choice..

If I put the action in event 11, the first tick the overlapping condition is true the action would take place using the old value of the instance variable..

Now at the first tick the overlapping condition is true, first the new value is set (triggered once) and after that it is used in the second action..

LittleStain I do understand the logic of what Bl4ckSh33p is trying to do... He has to know the angle before the action "Move 5 pixels...", that isn't in discussion.

What I'm wondering if they are always executed secuentially by Construct 2.

I had this doubt on one of my projects when some things triggered in a bad way, so I did a proof of concept and it seems that two subconditions at the same position hierarchically speaking below another condition are not necessary evaluated secuentially.

Ashley please! any comments

... and if they are evaluated secuentially, it doesn't mean that the actions inside of those conditions will be executed secuentially from condition 1 to 2... actions from the first condition can be executed after actions from the second condition. For example, condition 1 can have 50 actions and condition 2 can have 1 action... that 1 action sure will be executed before all the 50 actions from the condition 1.

Events are always evaluated sequentially. The only way you can run an event outside of top-to-bottom order is with a trigger (such as a function call). Within each event, the conditions are tested from top to bottom. If they are all true, and only after all conditions have been tested, the actions are then run top to bottom. It's pretty simple, it all runs in order!