So I'm STILL having troubles with my Fresh Platformer Engine (a scrolling non-tile platformer engine similar to MEEK: DEMO), which I've made a topic about already. But now, I just got a thought: All my problems would probably be solved if I knew how to get variables to work with custom blocks. When I tried to use the repeat until block for my wall detection:

define wall detect
set [slope v] to [0]
set [old x v] to (player x)
repeat until <<not <touching [ground v] ?>> or <(slope)= [8]>>
change [player y v] by (1)
change [slope v] by (1)
end
if <touching [ground v] ?> then
change [ player y v] by ((0) - (slope))
set [player y v] to (old x)
end

But as soon as the player touches the ground, the game freezes for a second, then the character is instantaneously shot into the air, changing the y var by a TON. Is there any workaround for this?

Yes, loops do not work in custom blocks which do not have screen refresh, as without screen refresh, the custom block would continue functioning until the next frame, thus, rather then bumping the player up by as much as you need so it doesn't touch the ground, it instead increases the player's supposed y position, but not the actual, leading to the player shooting up in the next frame.

Instead, just use a load of nested if statements, something like

if <not <<touching [ground v] ?> or <(slope) = [8]>>> then
change [y v] by (1)
change [slope v] by (1)
if <not <<touching [ground v] ?> or <(slope) = [8]>>> then
change [y v] by (1)
change [slope v] by (1)
if <not <<touching [ground v] ?> or <(slope) = [8]>>> then
change [y v] by (1)
change [slope v] by (1)
if <not <<touching [ground v] ?> or <(slope) = [8]>>> then
change [y v] by (1)
change [slope v] by (1)
if <not <<touching [ground v] ?> or <(slope) = [8]>>> then
change [y v] by (1)
change [slope v] by (1)
end
end
end
end
end

It looks like as the player falls, it will change slope and player y by one. It will bounce the player up by slope(the number of times the script repeats. Try changing it by a smaller amount.

Koamodo975 wrote:

So I'm STILL having troubles with my Fresh Platformer Engine (a scrolling non-tile platformer engine similar to MEEK: DEMO), which I've made a topic about already. But now, I just got a thought: All my problems would probably be solved if I knew how to get variables to work with custom blocks. When I tried to use the repeat until block for my wall detection:

define wall detect
set [slope v] to [0]
set [old x v] to (player x)
repeat until <<not <touching [ground v] ?>> or <(slope)= [8]>>
change [player y v] by (1)
change [slope v] by (1)
end
if <touching [ground v] ?> then
change [ player y v] by ((0) - (slope))
set [player y v] to (old x)
end

But as soon as the player touches the ground, the game freezes for a second, then the character is instantaneously shot into the air, changing the y var by a TON. Is there any workaround for this?

)

yadayadayadagoodbye wrote:

Yes, loops do not work in custom blocks which do not have screen refresh, as without screen refresh, the custom block would continue functioning until the next frame, thus, rather then bumping the player up by as much as you need so it doesn't touch the ground, it instead increases the player's supposed y position, but not the actual, leading to the player shooting up in the next frame.

Instead, just use a load of nested if statements, something like

if <not <<touching [ground v] ?> or <(slope) = [8]>>> then
change [y v] by (1)
change [slope v] by (1)
if <not <<touching [ground v] ?> or <(slope) = [8]>>> then
change [y v] by (1)
change [slope v] by (1)
if <not <<touching [ground v] ?> or <(slope) = [8]>>> then
change [y v] by (1)
change [slope v] by (1)
if <not <<touching [ground v] ?> or <(slope) = [8]>>> then
change [y v] by (1)
change [slope v] by (1)
if <not <<touching [ground v] ?> or <(slope) = [8]>>> then
change [y v] by (1)
change [slope v] by (1)
end
end
end
end
end

OH that's why all those other games did that. I'ma try it.

Koamodo975 wrote:

yadayadayadagoodbye wrote:

~snap snap~ le crab

OH that's why all those other games did that. I'ma try it.

It's kinda working? Now the character can still walk through walls tho.

yadayadayadagoodbye wrote:

Yes, loops do not work in custom blocks which do not have screen refresh

loops very much do work in custom blocks with or without run without screen refresh. If you need it to happen in 1 frame (instantly) then it will need run without screen refresh.

Koamodo975 wrote:

Koamodo975 wrote:

yadayadayadagoodbye wrote:

~snap snap~ le crab

OH that's why all those other games did that. I'ma try it.

It's kinda working? Now the character can still walk through walls tho.

You're kinda changing the Y value, not the X, you'd have to change the X value to prevent it from walking through walls…
Also, you need to make sure you actually change the location of the sprite before you check again, don't rely on your other script that sets the character to “player y” as your custom block is run without screen refresh, which, well, runs without it refreshing the screen

Malicondi wrote:

yadayadayadagoodbye wrote:

Yes, loops do not work in custom blocks which do not have screen refresh

loops very much do work in custom blocks with or without run without screen refresh. If you need it to happen in 1 frame (instantly) then it will need run without screen refresh.

I swear there was a reason people didn't use that

yadayadayadagoodbye wrote:

I swear there was a reason people didn't use that

some people aren't careful and use repeat until <> loops, but break them and they never become untrue so it lags you heavily, which might be why loops are avoided but i use them alot (when necessary)
those 6 long stacked if statements hurt me internally

Malicondi wrote:

yadayadayadagoodbye wrote:

I swear there was a reason people didn't use that

some people aren't careful and use repeat until <> loops, but break them and they never become untrue so it lags you heavily, which might be why loops are avoided but i use them alot (when necessary)
those 6 long stacked if statements hurt me internally

goofy

anyways uhhh scrap what I said in the original reply ill see how I can help with ur thing with a remix, the code seems a bit messy and I feel like it might benefit from certain parts being reorganized

I have created a remix of the project with what I assume you needed. I havn't got all the collision done yet but you could take a look to take inspiration

Malicondi wrote:

yadayadayadagoodbye wrote:

I swear there was a reason people didn't use that

some people aren't careful and use repeat until <> loops, but break them and they never become untrue so it lags you heavily, which might be why loops are avoided but i use them alot (when necessary)
those 6 long stacked if statements hurt me internally

now I remember, people use the nested ifs because for whatever reason its faster. When I use the loop, it somehow takes multiple frames to happen even though its only supposed to take one. It causes no problems but looks kinda weird.

Idk why this happens it just does

Malicondi wrote:

yadayadayadagoodbye wrote:

I swear there was a reason people didn't use that

some people aren't careful and use repeat until <> loops, but break them and they never become untrue so it lags you heavily, which might be why loops are avoided but i use them alot (when necessary)
those 6 long stacked if statements hurt me internally

That's what happened. It broke from the repeat until <> loops mixed with variables.

yadayadayadagoodbye wrote:

(#10)
now I remember, people use the nested ifs because for whatever reason its faster. When I use the loop, it somehow takes multiple frames to happen even though its only supposed to take one. It causes no problems but looks kinda weird.

Idk why this happens it just does

run without screen refresh loops work as fast as nested if non-run without screen refresh
variables do too…?
the custom block probably isn't set to run without screen refresh.

pythonicKI wrote:

run without screen refresh loops work as fast as nested if non-run without screen refresh
variables do too…?
the custom block probably isn't set to run without screen refresh.

in most cases, run without screen refresh is faster than nested ifs btw