Instant teleportation to the top bug fix

ABC124816

Project concerning help: https://scratch.mit.edu/projects/991251842/
So I have been working on a basic platformer (my first one) but with a twist: The force of gravity changes its direction every time you collide with a wall in that direction. Here are the implemented features apart from that:
Black: Ground
Grayish Black: Text (so that the player goes right through it.)
Gray: Spikes
Red: Lava
Yellow: Bouncy spring
Blue: Slippery ice
The problem I have is in level 8. You are supposed to jump from the bouncy spring to the ice and change gravity towards down. Instead of that, it instantly teleports to the top without registering the gravity change (which is controlled by the ‘direction’ variable.). After a few experiments, I concluded that the most likely culprit was the hitbox costume (labeled ‘1’) in the player sprite. However, no matter how hard I tried, I couldn't get the hitbox working right, modifying its shape ten times. Can someone help with this?

ABC124816 NEWS: We've crossed the 100 posts mark!
Developer of the lagless theory!
Love these blocks!

(timer)
(days since 2000)

Block of the time (I might suggest adding it if it is sensible):

pause all scripts in project for (3) seconds::control

kingKASEtheGREATalt

You only change gravity when its touching the ground, you would need to change every instance of

<touching color [#000000] ?>

to

<<touching color [#000000] ?> or <touching color [#80ffff] ?>>

also, you don't reset velocity when the player dies, this can make a softlock of the player clipping through the ground and dying

BigNate469

You should also change the script that spawns the player when they hit a spike, lava or the edge to use the coordinates of the edge, rather than

<touching [edge v] ?>

I'm noticing that when you come down too hard on a spring or the ground that this script tends to be triggered before the ones that would push you out of the ground.

Highlight any part of this signature and press ctrl+shift+down arrow to see the rest of it

forever
if <person asks [what's a signature] :: sensing> then
Redirect to [https://en.scratch-wiki.info/wiki/Signature] :: motion
end
end

Please read the list of Officially Rejected Suggestions before posting a suggestion for Scratch! 100th post
This signature is designed to be as helpful as possible.
View all of the topics you've posted in:
https://scratch.mit.edu/discuss/search/?action=show_user&show_as=topics
View all of your posts:
https://scratch.mit.edu/discuss/search/?action=show_user&show_as=posts
Forum tips:
Don't post in topics where the latest post is over ~2 months old, unless you have something critical to add. Especially in topics that are several years old- it isn't helpful, and is known as necroposting.
Don't post unrelated things in topics, including questions of your own. Make a new topic for your questions.
You can use the

 [color=color name or hexadecimal value here] and [/color]

tags to color text.
Lesser-known Scratch URLs:
scratch.pizza (redirects to main page)
https://scratch.mit.edu/projects/PROJECT ID HERE/remixtree (replace “PROJECT ID HERE” with project id number. Shows all the remixes of the project, and the remixes of those projects, and the remixes of those projects, and so on, as a chart. Link currently redirects to one of my projects)
View a larger list at: https://scratch.mit.edu/discuss/topic/542480/
Why @Paddle2See's responses are so often identical: https://scratch.mit.edu/discuss/topic/762351/

ABC124816

kingKASEtheGREATalt wrote:
You only change gravity when its touching the ground, you would need to change every instance of
<touching color [#000000] ?>
to
<<touching color [#000000] ?> or <touching color [#80ffff] ?>>
also, you don't reset velocity when the player dies, this can make a softlock of the player clipping through the ground and dying

Thanks for the tip! I should have realized that. However it is still teleporting. Do I need to change my hitbox scripts? Also the velocities aren't reset when the player respawns so I am not sure if you meant that.

ABC124816 NEWS: We've crossed the 100 posts mark!
Developer of the lagless theory!
Love these blocks!

(timer)
(days since 2000)

Block of the time (I might suggest adding it if it is sensible):

pause all scripts in project for (3) seconds::control

ABC124816

BigNate469 wrote:
You should also change the script that spawns the player when they hit a spike, lava or the edge to use the coordinates of the edge, rather than
<touching [edge v] ?>
I'm noticing that when you come down too hard on a spring or the ground that this script tends to be triggered before the ones that would push you out of the ground.

Ah, I think it must be because the velocity is so great that between frames it just goes right through without touching the color in question! Strange though, I only encountered it once and put a limit on the falling velocity and x velocity to prevent it, and I never saw it happen again. Are you positive it is there? I can't reduce the limit too much otherwise the falling will become unrealistic.

Anybody else who has read this please give your own feedback!

Last edited by ABC124816 (March 28, 2024 19:27:38)

ABC124816 NEWS: We've crossed the 100 posts mark!
Developer of the lagless theory!
Love these blocks!

(timer)
(days since 2000)

Block of the time (I might suggest adding it if it is sensible):

pause all scripts in project for (3) seconds::control

BigNate469

ABC124816 wrote:
BigNate469 wrote:
You should also change the script that spawns the player when they hit a spike, lava or the edge to use the coordinates of the edge, rather than
<touching [edge v] ?>
I'm noticing that when you come down too hard on a spring or the ground that this script tends to be triggered before the ones that would push you out of the ground.
Ah, I think it must be because the velocity is so great that between frames it just goes right through without touching the color in question! Strange though, I only encountered it once and put a limit on the falling velocity and x velocity to prevent it, and I never saw it happen again. Are you positive it is there? I can't reduce the limit too much otherwise the falling will become unrealistic.

Actually, probably the best thing you can do is merge the two forever loops into one- just put the scripts that respawn the player at the bottom. That way, you know what happens first

.

Highlight any part of this signature and press ctrl+shift+down arrow to see the rest of it

forever
if <person asks [what's a signature] :: sensing> then
Redirect to [https://en.scratch-wiki.info/wiki/Signature] :: motion
end
end

Please read the list of Officially Rejected Suggestions before posting a suggestion for Scratch! 100th post
This signature is designed to be as helpful as possible.
View all of the topics you've posted in:
https://scratch.mit.edu/discuss/search/?action=show_user&show_as=topics
View all of your posts:
https://scratch.mit.edu/discuss/search/?action=show_user&show_as=posts
Forum tips:
Don't post in topics where the latest post is over ~2 months old, unless you have something critical to add. Especially in topics that are several years old- it isn't helpful, and is known as necroposting.
Don't post unrelated things in topics, including questions of your own. Make a new topic for your questions.
You can use the

 [color=color name or hexadecimal value here] and [/color]

tags to color text.
Lesser-known Scratch URLs:
scratch.pizza (redirects to main page)
https://scratch.mit.edu/projects/PROJECT ID HERE/remixtree (replace “PROJECT ID HERE” with project id number. Shows all the remixes of the project, and the remixes of those projects, and the remixes of those projects, and so on, as a chart. Link currently redirects to one of my projects)
View a larger list at: https://scratch.mit.edu/discuss/topic/542480/
Why @Paddle2See's responses are so often identical: https://scratch.mit.edu/discuss/topic/762351/

ABC124816

BigNate469 wrote:
…
Actually, probably the best thing you can do is merge the two forever loops into one- just put the scripts that respawn the player at the bottom. That way, you know what happens first .

Thanks! Although it didn't fix the bug, it simplified my code! I was actually hesitant to combine them as I thought I wouldn't be able to jump and move at the same time, but it didn't happen! The order is now:
Velocity physics
Ground/Ice detection
Checking for change of gravity
Up arrow detection
Left/Right arrow detection
Respawning detection
Bouncing detection
Level completed detection
I am listing this order so that it may be helpful for debugging.

ABC124816 NEWS: We've crossed the 100 posts mark!
Developer of the lagless theory!
Love these blocks!

(timer)
(days since 2000)

Block of the time (I might suggest adding it if it is sensible):

pause all scripts in project for (3) seconds::control

kingKASEtheGREATalt

ABC124816 wrote:
kingKASEtheGREATalt wrote:
You only change gravity when its touching the ground, you would need to change every instance of
<touching color [#000000] ?>
to
<<touching color [#000000] ?> or <touching color [#80ffff] ?>>
also, you don't reset velocity when the player dies, this can make a softlock of the player clipping through the ground and dying
Thanks for the tip! I should have realized that. However it is still teleporting. Do I need to change my hitbox scripts? Also the velocities aren't reset when the player respawns so I am not sure if you meant that.

I can't tell why it's not working anymore

ABC124816

Guys, I drastically modified my code, keeping the old script on the right. And it works on constant gravity, and switching gravity works… sometimes and only when you go slowly. In fact, it looks more buggy than my previous code. Can someone tell why my code isn't working? The detection is not by hitbox now, but through the following logical deductions:

Moving out of a hit bottom or top platform takes less than the absolute size of the v2 value, if it takes more than that to move out, then it must be a wall. Then, if v1 is positive (meaning the player moved to the right.) then it was a right wall. Else, it was a left wall.

Is my code not implementing this logic correctly, or is there something wrong with the logic itself? Or it is hitting the walls in too many directions? Or something else?

ABC124816 NEWS: We've crossed the 100 posts mark!
Developer of the lagless theory!
Love these blocks!

(timer)
(days since 2000)

Block of the time (I might suggest adding it if it is sensible):

pause all scripts in project for (3) seconds::control

ABC124816

ABC124816 wrote:
Guys, I drastically modified my code, keeping the old script on the right. And it works on constant gravity, and switching gravity works… sometimes and only when you go slowly. In fact, it looks more buggy than my previous code. Can someone tell why my code isn't working? The detection is not by hitbox now, but through the following logical deductions:

Moving out of a hit bottom or top platform takes less than the absolute size of the v2 value, if it takes more than that to move out, then it must be a wall. Then, if v1 is positive (meaning the player moved to the right.) then it was a right wall. Else, it was a left wall.

Is my code not implementing this logic correctly, or is there something wrong with the logic itself? Or it is hitting the walls in too many directions? Or something else?

I need feedback please!

ABC124816 NEWS: We've crossed the 100 posts mark!
Developer of the lagless theory!
Love these blocks!

(timer)
(days since 2000)

Block of the time (I might suggest adding it if it is sensible):

pause all scripts in project for (3) seconds::control

kingKASEtheGREATalt

ABC124816 wrote:
ABC124816 wrote:
Guys, I drastically modified my code, keeping the old script on the right. And it works on constant gravity, and switching gravity works… sometimes and only when you go slowly. In fact, it looks more buggy than my previous code. Can someone tell why my code isn't working? The detection is not by hitbox now, but through the following logical deductions:

Moving out of a hit bottom or top platform takes less than the absolute size of the v2 value, if it takes more than that to move out, then it must be a wall. Then, if v1 is positive (meaning the player moved to the right.) then it was a right wall. Else, it was a left wall.

Is my code not implementing this logic correctly, or is there something wrong with the logic itself? Or it is hitting the walls in too many directions? Or something else?
I need feedback please!

see if adding a delay between changes (through a variable, not through wait) can make it not switch to upside-down

ABC124816

kingKASEtheGREATalt wrote:
ABC124816 wrote:
ABC124816 wrote:
Guys, I drastically modified my code, keeping the old script on the right. And it works on constant gravity, and switching gravity works… sometimes and only when you go slowly. In fact, it looks more buggy than my previous code. Can someone tell why my code isn't working? The detection is not by hitbox now, but through the following logical deductions:

Moving out of a hit bottom or top platform takes less than the absolute size of the v2 value, if it takes more than that to move out, then it must be a wall. Then, if v1 is positive (meaning the player moved to the right.) then it was a right wall. Else, it was a left wall.

Is my code not implementing this logic correctly, or is there something wrong with the logic itself? Or it is hitting the walls in too many directions? Or something else?
I need feedback please!
see if adding a delay between changes (through a variable, not through wait) can make it not switch to upside-down

I reverted back to the old script as it was better, and now I am modifying it with more hitboxes.

ABC124816 NEWS: We've crossed the 100 posts mark!
Developer of the lagless theory!
Love these blocks!

(timer)
(days since 2000)

Block of the time (I might suggest adding it if it is sensible):

pause all scripts in project for (3) seconds::control

Discuss Scratch