Here is the logic chain here
1) locate a vector that points from the player to 0-Y'
2) move along the vector till the player is as close as possible to 0-Y
3) snap the player to 0-Y

secondary logic
1) do not move along the vector unless landing
2) stop the move if landed

logic of the code
1) define vectors
VECTOR vec_temp
Vector vec_temp2

2) set vector to my location
vec_set(vec_temp,my.x)

3) get a abs vector to 0-Y
vec_diff(vec_temp2,nullvector,vec_temp);

4) change the vector length without changing it's direction to get a speed along the direction vec
vec_normilize(vec_temp2,5*time_step);

5) set a lock
if(vec_dist(my.y,vec_temp2.y)>5)

6)move along the direction at speed 5*time_step, along the abs vec
c_move(my,nullvector,vector(0,vec_temp2.y,0),GLIDE);

7) snap to the 0-Y ( step-5 if is now false)
vec_set(vector(0,my.y,0),nullvector);

Malice, your code is good, but for 3 dimensions.

Just for one (y) , y * 0.9 is easier and simple, and doesnt need a lock.
Simply scaling down the y pos until it becomes as close as 0, every frame.

Sure I get it.
muling the my.y by that factor will reduce it towards 0 every frame regardless of the sign of my.y pos.
it is not regulated by time_step.

The basic logic is a mul by .9 reduces the my value by 10% and to increase the shift rate you decrease the decimal value.
So then a mul by .75 will decrease the my.y pos by 25% per loop.

I understand, but does the OP understand. We both present a logic design to achieve the same effect. But if the OP doesn't see the logic then they can never use that logic to create variation for similar effects.

You are right.

I started with 3dgs so i never learned to design programs. I recently picked up that skill from a Java tut and now I know what I've been missing for the past 15 years