Help with collision detectors in ISO environment

[chrilley]

this method is cool, but you can't go diagonally

The diagonal movement should work fine in the .mfa I attached. Could you elaborate what doesn't work?

[fredetmumu]

sorry it was because my poor french keypad don't work perfectly, your MFA is very fine and better than mine because very simple

do you accept to share it on the french forum "le comptoir du clickeur"?


https://lecomptoirduclickeur.fr/newsfeed

if you are ok, i can post it and credit you

[chrilley]

Of course you can share it anywhere @fredetmumu

[fredetmumu]

thank you!

[Outcast]

Fastloops are great for this stuff. I've put in a basic movement for you. It moves the player by the X/Y Adjust values, you've setup, at a one-by-one pixel rate(within a fastloop so it's just as fast for us, mere mortals!). When the player hits an obstacle it will be pushed back out in the opposite X/Y value and stop the loop.

Thank you this is just perfect! I am trying to understand the logic though for my own understanding. Why do the loop need to run the same amount of times as the X and Y Adjust? Also with this event "X( "Player1" ) + ( XAdjust( "Player1" ) / Abs(XAdjust( "Player1" )) )" Why is the XAdjust divided by itself? And also why do the X and Y adjust need to be reverted to 0 if detecting an overlap? (I actually tried to remove these reverting to 0 and it seemed to work as well without these events?)

[chrilley]

Sure!

The fastloops run the amount of times equal to the pixels that you'd like to move. In this case it's 5 times and by putting abs() around it will ensure negative numbers like -5 turns into 5 instead, else walking left or up won't work since running fastloop -5 times means to run it 0 times.

On each fastloop step we only want to move 1 pixel at a time per axis so if we divide the x/y adjust values by themselves you get either 1 or -1. Basically the x/y adjust values only serves to tell us what direction on the axis to move in. So for x adjust: 5/5 = 1(right) and -5/5 = -1(left). We use abs() again to make sure you don't divide a double negative and end up with a positive value by accident(-5/-5 = 1, so you'll end up going to the right even when you want to go left).

And setting x/y adjust back to 0 just makes sure the fastloops doesn't needlessly re-trigger again until next key press. It's handy when you have acceleration/deceleration and such where if you let go of a key and the object keeps sliding forward and hits a wall or if you apply this movement to multiple objects and number of fastloops start adding up. It might not be that much applicable in this example like you point out though.

[Outcast]

Sure!

The fastloops run the amount of times equal to the pixels that you'd like to move. In this case it's 5 times and by putting abs() around it will ensure negative numbers like -5 turns into 5 instead, else walking left or up won't work since running fastloop -5 times means to run it 0 times.

On each fastloop step we only want to move 1 pixel at a time per axis so if we divide the x/y adjust values by themselves you get either 1 or -1. Basically the x/y adjust values only serves to tell us what direction on the axis to move in. So for x adjust: 5/5 = 1(right) and -5/5 = -1(left). We use abs() again to make sure you don't divide a double negative and end up with a positive value by accident(-5/-5 = 1, so you'll end up going to the right even when you want to go left).

And setting x/y adjust back to 0 just makes sure the fastloops doesn't needlessly re-trigger again until next key press. It's handy when you have acceleration/deceleration and such where if you let go of a key and the object keeps sliding forward and hits a wall or if you apply this movement to multiple objects and number of fastloops start adding up. It might not be that much applicable in this example like you point out though.

Thank you for explaining, makes more sense now! However with the last thing with setting the x and y adjust back to 0 would that not cause bugs if indeed the character would slide forward and hit a wall? To me logically that would be the opposite of what should happen in that case and the engine will think that the character is standing still (x and y adjust at 0) while it might be sliding and need to still check collision? I might have missunderstood this though..

[chrilley]

I don't quite follow but there shouldn't be any buggy behavior afaik. Sliding next to a wall pretty much just means that the player is being moved on only one axis while the other is getting repeatedly cancelled every time it tries to start up; fastloop is called, player immediately moves into a wall, gets pushed back out, rinse and repeat.