that still sounds like you are in world space with that solution, not in the local coordinate space of the box, like the question wanted.
you used 2 positions as inputs, without using the rotation of the box at all. so you didn’t use enough information to transform into the box’s local coordinate space. before you can subtract those vectors, you need to rotate the players position around the box, with an equal and opposite, “inverse rotation” of the box.
im sure there is a way to do it from scratch, using nothing more than a mess of "sin(yaw) * cos(roll) " nodes, but without blueprints supporting matrices, you might want to do this in c++.
another way to state the problem from the box’s view, is:
you want to rotate the players position around the box, with an opposite rotation than the box, then subtract the vectors to find the distance and take its Y component as your answer.
to do that rotation, usually you multiply by the inverse of a rotation matrix for each axis of rotation, in the same order the engine uses to rotate the cube. if you don’t use the same order, gimbal lock can throw the cube’s rotation and the resulting data out of sync.
a hacky solution might be to have an invisible actor that you move to your player and parent to your cube, then you find its relative location to its parent, and take the Y component as your answer. to constantly update this, you would have to (unparent, move, parent, test) for every update, but if you only need this info rarely, than this hack might work.
imagine trying to do this kind of math in blueprint, with nothing but basic trigonometry nodes: