Why does "turn on/off Solid on collision" apply to more than one object? [Example provided]

When you stand next to any rock the overlap its always true, if you stand next to 3 rocks it will pick 3 of them this is without pushing and just standing next to them.

If you look at your gift, the first rock you push to the right then you go away to go around to the Second rock when you move away from the first rock you give space of one tile and that's enough to no overlap any rock so the "Event 26" can be true and make all the rocks solid.

But when you coming back of pushing the second rock you never stop overlapping the rocks you pass next of both of them making them None solid because "Event 9" is true for each of them because you oberlap one by one, that's why when you push the last rock to the right both of the rocks are no solid, if you want to make them no solid you need to go away at least one tile far like when you first push.

So the Logic is wrong plus you checking for collision constantly unnecessary when you are next to any rock even if you don't push, you could save collisions check for better performance.

Maybe by doing something like this:

Capx: dropbox.com/s/o2gq5furliw8hsp/pushblocktest2.c3p

Here is my version, I managed to make the rocks and the player move smoothly.

dropbox.com/s/kfvczdlqplt5hiu/PushBlockTest_dop2000.c3p

It's a useful demo, will it be ok with you if I upload it to my website?

steve1984

Ho sorry I though the player needed to push first the rock, I see what you need now, see if this is what you need, this Tile buy Tile

https://www.dropbox.com/s/rdkwpgcemiq40yv/pushblocktest3.c3p?dl=0

====================

mm not sure what's going on but If you try to do a continuous movement instead of Tile by Tile like my last Example :

It looks like there is a bug with the condition is not moving I think is triggering before the rock stops moving and sets the solid before time? this makes the player do small stuttering.

The only way I managed to fix it it's by setting the solids manually adding a boolean and few more variables but it shouldn't need to add those extra things.

https://www.dropbox.com/s/bxd4d7envpp5lu6/pushblocktest4.c3p?dl=0

So you have two now, one continuous Moving and the other Tile by Tile, Pick the one you like

Np steve1984 glad it's sorted out)

Ho yeah, I didn't even look on the Animation sorry, I thought you still have to work it out because it looked unfinished the events.

However, if you want to count for every possible situation to get the right animation and Direction + Smoothenes you are gonna need to rework a bit more the events for that.

I had to remove all the events because it didn't count for some situations

Example:

If you are in a corner-blocked by solids from the (Top & Right) and the player is looking up but you start pressing right it will not change the animation to "Idle_Right" it will just stay on "Idle_Up", this is just an example of many situations that you need to count for.

If you want to see what I mean check the last Example from dop2000 it has those problems swell

========================

Another Example:

Will be if you going Left and you stop in a Tile and below you have two rocks on the next two tiles down so you start pressing down you cannot move because the path is blocked by the rocks but the animation still keeps looking Left even you are pressing Down.

Basically, you want the player to look always on the direction it's pressing even if he cannot move to that Direction.

Here is the new one with the Animation fixed:

Check it properly because Not sure if it's 100% Bug-free:

Construct 3 Project:

https://www.dropbox.com/s/b9quj5d24613lnr/pushblocktest6.c3p?dl=0

tarek2, yeah, took me a while to figure out that after you do "Simulate control", condition "Is moving" will still be false until the end of the tick. Not sure if this is a bug, but other behaviors (8direction, platform) start moving in the same tick.

I see, it makes sense now why it doesn't work when is at the bottom but I still think is a bit unintuitive especially for new beginners but hey the behaviour its been around for some time now and no one reported it, so looks like no one has a problem with it lol )

I don't use it normally I use "MoveTo" behaviour most of the time so for me doesn't bother me much.

Also, another thing that I notice is that the Condition "is Not moving" is a bit misleading because it behaves more as "MoveTo >>>> on Hit Target"

Example:

Right Key its Down >>> MoveRight

If you keep moving right none stop then still the "is Not moving" condition it will fire up on each tile even if you didn't stop moving so its look more like on "Hit Target" condition

I will instead do it like MoveTo where it has the same thing but separated into two conditions:

1-Is Moving

2-Oh Hit Target

The "MoveTo" >>>>("is Moving" << Inverted) condition it will not run unless you stop moving

That's why the "TileMovement"-- "is Not Moving" it feels like they have both conditions in one

Anyway, it was a good thread to refresh everything about "TileMovement" as I didn't use it since it came out.