Yes, 1.4.9999 and 2.x both have rrggbb instead of bbggrr color codes. 1.4.9999 is extra fun to deal with, because the color CONSTANTS weren't updated to match the new format, so c_red is actually blue and so on. I'm sticking with 1.4.1773 for stability reasons :P
Well I'm so used to 2.0 and like it so it's fine. But sorry to bother you. I have 2 weird issues that are happening. First, is the player can't finish climbing the ladder and gets stuck at the top in climbing state. I noticed I can make it happen when the player is on the left or right and not in the middle of the ladder. Second, is sometimes for a reason I don't get the player gets stuck in falling state on jump thru platforms and can't jump since they are stuck. No idea why.
I did some digging into why climbing occasionally doesn't work, and I think I found the cause. Change player_controls_ud so its contents look like this:
/// @description player_controls_ud()
//Crouch
if(onground){
if(k_d){
crouching = true
}
else{
crouching = false
}
} //Climb
if(k_u){
if(place_meeting(x,y,parent_climbable)){
state = playerstate_climb
yspeed = 0
}
}
The cause is that vertical speed isn't reset to zero when you start climbing (which is a bug), so jumpthrough platforms will act solid if you were falling down when you grabbed the ladder, which is why you get stuck.
I don't have any ideas for what causes the jumpthrough-platform bug, though. Are you using different sprites / collision masks than the demo version? player_free has the collision mask for the player-character more or less hardcoded, so you need to keep it updated to match. Coordinates in the function are rounded, so I don't think it's different subpixel precision causing it.
My recommendation would be to run the game in debug mode, and when the player gets stuck, pause the game and investigate local variables.
I'm also thinking the failsafe in player_inertia_x might be a potential cause, try putting a breakpoint inside that and see if it gets triggered.
Another potential cause is how player_step_start rounds player coordinates when checking if you're on the ground or not, while player_free also rounds coordinates - maybe rounding twice leads to some cases of these coordinates being inconsistent with the ones used for other collision checking. Try removing the rounds() in player_step_start so the variable is set like this instead:
onground = !player_free(round(x),round(y) + 1)
One final potential cause is that the player is stuck in an infinite loop of stopping and being moved back, but new input builds up speed. Try switching the two "inertia" and the two "control" in playerstate_normal like this and see if it stops it:
player_inertia_x()
player_inertia_y() player_controls_x()
player_controls_y()
Thank you very much for your reply. The ladder fix worked great. After lots of testing the Jump thru platform seems good now too. For the Jump thru platform it was putting inertia before the controls that did it. The variable jump when done small at a specific amount would make the player stuck a little in the bottom of it. And switching these two seems to prevent that. I appreciate your reply and time more than you know. #BestExtensionEVER!
Sorry to bother you again. The ladder thing is good. But now for the jumping when I am on a Jump Thru platform I can jump low and high, but on other ground it only jumps high. There is no variable jump and I can't figure out why. So the fix is kinda not good as I really want the variable jump. If you have any time or ideas I would appreciate it. There is no other issues and I am using the same sprite sizes and everything. I changed the art, but same sizes and origins.
Variable jump is handled in player_controls_y, lines 16-18. Normally looks like this:
if(jumped && !canjump && yspeed < 0){
yspeed *= 0.5
}
Not sure what could be wrong, but there's a lot of variables involved, so it's possible one of them gets changed behind your back with the new ordering of things. I think this would work just fine and with less potential for interference:
if(p_a && yspeed < 0){
yspeed *= 0.5
}
(since we know that k_a is false going into this check, we have k_a && !p_a, i.e., the jump button is currently not pressed, but it was the previous step - i.e, it was released this step. We still want to check that the player is moving upwards so that check should be left in)