BulletAppState stateDetached implementation

BulletAppState.stateDetached method’s body is empty. I think this method should detach debugAppState if it is not null. See follow patch:

[java]
Index: src/bullet-common/com/jme3/bullet/BulletAppState.java

— src/bullet-common/com/jme3/bullet/BulletAppState.java (revision 10477)
+++ src/bullet-common/com/jme3/bullet/BulletAppState.java (working copy)
@@ -220,6 +220,10 @@
}

 public void stateDetached(AppStateManager stateManager) {
  •    if (debugEnabled && debugAppState != null) {
    
  •        stateManager.detach(debugAppState);
    
  •        debugAppState = null;
    
  •    }
    

    }

    public void update(float tpf) {
    [/java]

What do you think?

stateDetached should never be overridden. stateAttached should also never be overridden. These are mostly provided for debugging and because if I remove them I’m sure it will break someone.

initialize() and cleanup() are the methods you override instead.

1 Like
@pspeed said: stateDetached should never be overridden. stateAttached should also never be overridden. These are mostly provided for debugging and because if I remove them I'm sure it will break someone.

initialize() and cleanup() are the methods you override instead.


Ok, got it!

So, in this case, having an appState (let’s call it “AppStateB”) depending on other appState (“AppStateA”). Then when AppStateA is disabled, it should disable AppStateB. Right?
i.e: BulletDebugAppState depend on BulletAppState. If user disable BulletAppState, BulletDebugAppState need to be disabled too. make sense?

So, I think this best place to handle this functionality is on setEnabled method. is that ok?

@H said: Ok, got it!

So, in this case, having an appState (let’s call it “AppStateB”) depending on other appState (“AppStateA”). Then when AppStateA is disabled, it should disable AppStateB. Right?
i.e: BulletDebugAppState depend on BulletAppState. If user disable BulletAppState, BulletDebugAppState need to be disabled too. make sense?

So, I think this best place to handle this functionality is on setEnabled method. is that ok?

Yeah, I guess so. Or the place where you disable one then you also disable the other.

I am not sure if theres necessarily such a rigid connection. You might want to see the physics locations even if you’re not updating the physics space, no?

@normen said: I am not sure if theres necessarily such a rigid connection. You might want to see the physics locations even if you're not updating the physics space, no?

I think yes, it may be helpful. Thanks!