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.
@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?
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?