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()