FlyCam motion restriction

Still in SimpleApplication, I am trying to restrict the camera to dive underground.
I found


and MotionAllowedListener (jMonkeyEngine3)
So I assume the checkMotionAllowed() function is called with the current position and curren velocity, and the code that I inject shall decide whether the motion is allowed and modify the values if it is not allowed. My first exercise was to just have code that gets called:

    new MotionAllowedListener() {
        public void checkMotionAllowed(Vector3f position, Vector3f velocity) {
            log.debug("checkMotionAllowed({}, {})", position, velocity);

So my code does not touch the values, it just prints them, which should not restrict any movement.
To my surprise the camera can rotate on mouse movement, but the WASD keys no longer show any effect.

Did I preempt some other MotionAllowedListener that was already there? Should I have added my listener into a chain and call the original implementation? Or do I simply have to calculate the new position myself and just the JavaDoc is wrong?

As with many of the more ancient JME classes like this, naming is very confusing.

It appears as if “MotionAllowedListener” should probably have been named “MotionHandler” and “checkMotionAllowed” should have been name “handleMotion”… if they were to do what they actually say. Alas, old JME developers (really really old) didn’t think that way.

…translate to reality accordingly.


Wow, that is some discrepancy. And from your response I read it did not happen for the first time, so I better watch.

Renaming the classes and functions would create a huge incompatibility, so that seems of little benefit either. Would it make sense to add such insight into the javadoc?

Probably. You may be the first person to try to use this feature in the last 10 years… so it may not have gotten any attention.

It’s worth keeping the source code open but I may have overstated things a little. There are certain classes in JME that I’ve never liked and FlyByCamera is one of them. To me it’s the product of a design mistake. It’s great that folks get some use out of it but invariably most games will replace it with something else.

(JME terrain is my other least-favorite code.)