Would moving then code into the custom control have any performance/other benifits, because I’m just trying to get all the functionality of the program working at the moment.
If so, I’ll add it to my TODO: list
It would be cleaner and works if you need “n” characters, instead of patching the app state every time.
So yeah that’s the real aspect, it’s cleaner, also if you re-use the control in another game
Oh, yes I didn’t think about that, I would be adding new player n’s which would be needing this method, so I will do just that!
Thank you very much for your help, much appreciated. 
1 Like
Several known issues with CharacterControl are specific to jme3-bullet. Switching to jme3-jbullet may help, particularly with “travels along the z axis”. That one sounds familiar to me.
Is jme3-jbullet a similar setup to jme3-bullet, but with slightly different internals, i.e has all the same methods and properties but just does some calculations slightly differently?
Because I could switch to it if I run into other physics-related issues down the line, but also I wouldn’t want to re-write existing code.
1 Like
jme3-bullet and jme3-jbullet are meant to conform to the same interfaces. So switching back and forth should be easy.
jBullet is a not maintained anymore complete java implementation of Bullet, where jme3-bullet (or bullet-native) is using the original bullet physics engine source code (ín cpp) and bundles it as dll/so/dylib, so the performance should be better for bullet-native and it should also be more future proof, but you know, sometimes one or the other has a specific bug the other doesn’t have
1 Like
I think I shall stick with native bullet, unless any servere issues arise, if that’s the case.