ChaseCamera canRotate not set to true when re-enabled after being disabled

Whenever I’ve paused my scene, I’ve noticed that unpausing removes the mouse control of my ChaseCam. After using some *~*~*Black Subclass Magicks*~*~* (read: me not realizing until after the fact that I can just lookup the code on Github, because I’m a massive airhead) to display some internal variables of the ChaseCam, I’ve discovered that there’s no way to re-enable rotation if you have click-to-rotate disabled. Would it be possible to expose a method that can manually set the canRotate flag in code in a future version of the ChaseCam?

Sorry, I guess I am not entirely following, have you tried calling setDragToRotate(true) on the chase cam? Or are you talking about a different function of the camera?

Edit: or of you want canRotate to be true call setDragToRotate(false)
canRotate is set to the opposite of dragToRotate.

The point is to not do that. The point is that my camera movement is done with drag to rotate turned off intentionally, and turning it on is the thing I don’t want to do. Unless your suggestion is to enable, then immediately disable drag to rotate in order to get canRotate into the correct state - which would probably work, but is a fairly non-obvious solution.

See my edit, but you can just call it with a false even if it is already disabled.

To be honest, I’m not sure how you could get canRotate out of sync from where it should be. It is an internal var used to control if the camera should rotate based on the input state, and is not something that should be set externally from what I can see. Can you please provide the code which is causing it to become out of sync?

Alright, yeah. That’d probably be the canonical solution, though I stand by it being a largely non-obvious one based on the docs and the naming.

The code is fairly simple, contained within the relevant appstate:

protected void onDisable(){
  ...
  chaseCam.setEnabled(false); // the only line that references the chaseCam in this method, even indirectly
}

Followed by:

protected void onEnable(){
  ...
  chaseCam.setEnabled(true); //likewise, the only line to reference the ChaseCam in this method
}

This is enough to desynchronize it if the chaseCam already has dragToRotate set to false, which I do in the appstate’s initializer.

Interesting, when I’m at a computer I can take a better look at the source to see why disabling and reenabling would cause that.

An easy solution is to create a subclass that provides setters and getters for canRotate since it is a protected variable and can be accessed by any subclass.

Edit: im on my phone, but I think I may see the issue in the code. Does this issue occur only if the appstate is disabled while dragging?

I mean, you gave the solution earlier - I just set DragToRotate before disabling, and unset it after enabling, and it works just fine. My point at this point is that that’s a little unintuitive - but I’ll take unintuitive over not working (which it was for several hours before now - though it wasn’t the only issue I’ve been hacking on today).

I pulled up the ChaseCam source on Github and, best as I can tell, this would be the cause:

    public void setEnabled(boolean enabled) {
        this.enabled = enabled;
        if (!enabled) {
            canRotate = false; // reset this flag in-case it was on before
        }
    }

There’s just no corresponding check for if it should be able to rotate when it’s re-enabled, best as I can tell.

Nope, again dragging is not turned on. canRotate is just always true if dragToRotate is disabled, so it gets disabled when the camera is disabled and never gets reenabled when the camera is reenabled.

Ah, that was the function I was looking for, for some reason I’m not seeing the onEnable/onDisable on my phone. But perhaps there are two different issues in the code then…

Are you looking at this file?

I’m not finding the setEnable

No, I’m looking at this one:

… Hmm, i did not realize there was a different chase cam implementation, or perhaps I’m not seeing the full picture.

The one I’ve been using is the one that’s described in the wiki (specifically in this page) - if I’ve been using the wrong camera system for the entire last month I might actually cry.

Lol, you probably have the correct one. I probably should not be trying to traverse the github repo on my phone :rofl:.

When I get back to a computer in the morning I can take a better look. I’m thinking there is a bug that we can get fixed for 3.5.0, or possibly for a 3.4.x release.

3 Likes

@clericbob I have created a PR for the fix, can you test it?
Chase cam can rotate fix on re-enable by tlf30 · Pull Request #1692 · jMonkeyEngine/jmonkeyengine (github.com)

1 Like

I just pulled and tried this, but I was not only unable to get the fix to work, it also introduced a new issue where the mouse cursor no longer disappears/locks to the window bounds when drag to rotate is disabled. This makes mouse navigation difficult, as it is ignored once it crosses off the edge of the window. I’ll put more details in the git issue after I test it a bit more.

Edit: based on the code changes, this really makes no sense. It might just be an issue with me not knowing how to use the engine by itself, but I’ve been prodding at testChaseCamera with no new results.
Edit 2: I am are dumb. Forgot to checkout the correct branch after cloning the repo. After getting the right branch, the fix worked, but the mouse was still visible and not restricted to the window. This might just be an issue with me having set something up wrong in my environment, given that it was also happening with the version in master.

2 Likes

When I get some free time, I will build a test case to add to the PR. Perhaps this will help narrow down any lingering (or new) issues.

2 Likes