And FTR, I need to use this method of movement/collision detection as the rest of my game requires it this way. So I can’t/won’t use the normal force/collision events.
I think that might be because when check the boolean value of the square, you are immediately filtering the solids group down to that one object. So the solids group you are checking with is just that moving square. And so the point is inside condition will never be true.
You could create objects that act as collision boxes for the moving sprites - so these will be hidden sprites the same shape as the object that can move. You move and do all the collision checks with the hit box, and position the visible moving sprite when all checks are done.
That happens because you never stop doing “Square force add 50”, let me explain:
When the Boolean value “Moving” is false, that need stop moving the square, if you don’t stop the Collision this Square continue and the “Moving” is more powerfull that the “Static Square” and “solid”, that broken the collision and trespassing this.
Maybe, you seyed me "When the boolean value is “false” the position X add 50 is stopped!! (Can you confirm me this happens or no, please?)
But, one condition never stop… The “delay” timer!!! (chan chan chaaan) and that makes the force continue!
I looked and copy/pasted your events, and i recommend you use forces to move and stop, don’t need the behaviour physics 2.0
Oh… please return my happiness…,ejem, Can you explain a little more about that “filter”?
Because that i don’t understood.
Only circle solid!
Square + Square = wrong Stop
Square + Circle = OK
Square (oh… ok, i think because never is false)
Square are solid “all squares in the screen, literally, all”, and when he touch one square, this gonna pass to “true moving” right? ( Strange because the square is solid, so why the square move?)
The guilty is Square.X()+square.Width() that condition never complete, so never change to “false moving”.
I Put in my copy/paste Square.X() and Square.Y() That only move the Square one time to the right (because the Position X add 50). And Stop immediately because all Squares are “solid”.
To solve this problem you need to do one object called Solid and apply. I tried to find another method to solve it, but just changing events, the results at the moment still… nothing (the Condition: Square are collision with other Square, you don’t wanna solve with that form, right @anon14980890 ?)
Sorry about my bad english,and if I burned your eyes, all the blame is because @MrMen took away my happiness
Square are solid “all squares in the screen, literally, all”, and when he touch one square, this gonna pass to “true moving” right? ( Strange because the square is solid, so why the square move?)
‘Solid’ doesn’t mean the object can’t move, it just means these types of objects don’t allow others to pass through them. In my game (the above is just a proof-of-concept to highlight the issue I was having), the ‘squares’ can move around, but when they stop moving they block other squares from moving through that position. Like pieces on a chess board - you can move one of your pieces to, say, C5, but that’ll then prevent your other pieces from moving to C5, since that square is now occupied. Hope that makes sense.
(the Condition: Square are collision with other Square, you don’t wanna solve with that form, right @anon14980890 ?)
You could create objects that act as collision boxes for the moving sprites
While not ideal, that worked, thanks @MrMen. I created a new object (‘hiddenSquare’, which I coloured grey to differentiate) then added in to the game on top of the square in the top-right. I added a new action on game start to hide this object, then added it to my ‘solids’ group (instead of ‘squares’). It works now. I still hope to find a better solution (one that doesn’t require adding a bunch of hidden objects on top of all existing objects once they stop moving), but at least now I have a backup failing that.
However, given how GDevelop treats objects, I think it may be the best, if not only, way to get around it. The earlier GDevelop example platform game used this method. And although not ideal, it does have it’s uses in same object type collision detection.
Sure, note though that this is my rough understanding of how it works :
In a GDevelop game you may have a number of instances of an object in the scene. With OP’s example, the game has multiple Square objects. When you refer to a Square in an action of an unconditional event, all Square objects in the scene are affected. GDevelop works with a list of all the Square objects.
When you use a condition on an object, it narrows down that list of object instances. For example, checking the boolean variable Moving of the object Square. With the condition Square objects with Moving = true, the list of Squares for GDevelop to work with is reduced (or filtered). GDevelop filters (or reduces) the list to a subset of object instances that it then works with in that event and it’s sub-events.