Hello mates, I am getting an odd bug where the collision shape of my Oto model is above where it should be, causing the poor guy to fall halfway through the floor. Here is an image of my little problem:
I am sure that the model is fine, considering it is just the standard Oto model, so I honestly have no idea what could of caused it, or how to fix it. Any help would be appreciated!
In the constructor you set the height and radius of the control. Increase those.
Attach the model to a node, move the model up and attach the character control to the node. And when you start creating your own models, just make sure the center is at its feet in the 3d editor.
Its kinda a defacto standart to have for player models the feet at the center.
(Quake,UT,Source engine) do this.
Note that for other objects it should be (usually) where the mass center is.
So I tried to move the character model, but to no affect. Here is my method for creating the model:
[java] private Node createUserNode() {
Node otherNode = (Node) assetManager.loadModel(“Models/Oto/Oto.mesh.xml”);
Node userNode = new Node();
userNode.attachChild(otherNode);
otherNode.move(0f, 3.5f, 0f);
return userNode;
} [/java]
Have I done something wrong? For some reason, no matter what the parameters, the model never moves.
Hi
Try something along these lines:
final Spatial model = assetManager.loadModel("character/character.mesh.xml");
//model.scale(1f);
//model.setLocalRotation(new Quaternion().fromAngleAxis(FastMath.PI / 2, new Vector3f(1, 0, 0)));
//model.setLocalTranslation(0, 1, 0);
Br,
Tommi
@IdreesInc said: So I tried to move the character model, but to no affect. Here is my method for creating the model: [java] private Node createUserNode() { Node otherNode = (Node) assetManager.loadModel("Models/Oto/Oto.mesh.xml"); Node userNode = new Node(); userNode.attachChild(otherNode); otherNode.move(0f, 3.5f, 0f); return userNode; } [/java] Have I done something wrong? For some reason, no matter what the parameters, the model never moves.
Yeah, that should basically work, you attach the character control to the userNode then, right? No idea whats going wrong there but thats exactly what I did a lot of times already.
I have noticed that if I comment out the “move” part, I just get these errors:
04:58.143 SEVERE com.jme3.app.AppT Exception
in class com.jme3.app.AppTask:invoke()-com.jme3.app.AppTask
04:58.144 SEVERE com.jme3.app.AppT Exception
in class com.jme3.app.AppTask:invoke()-com.jme3.app.AppTask
04:58.397 SEVERE com.jme3.app.Appl Uncaught exception thrown in Thread[LWJGL Renderer Thread,5,main]
in com.jme3.app.Application:handleError-com.jme3.app.Application
Repeated a dozen times before the application closes. Is there a reason for this? I am using a class that extends BetterCharacterControl and is initialized like so, if that’s any help…
[java] public PlayerControl(String username) {
super(1.5f, 6f, 1);
name = username;
this.setJumpForce(new Vector3f(0, 5f, 0));
this.setGravity(new Vector3f(0, gravity / 100, 0));
}[/java]
EDIT:
And today is the day, my good people, that I truly realized I am dumber than a rock. Note to self (and anybody who ever has the unfortunate status of sharing the same brain capacity as me): Don’t translate things not attached to a rootNode yet (Or something of the sort). Removing “playerNode.setLocalTranslation…” seemed to do the trick. Thanks for all your help and time guys!
Heh, yeah, when an exception occurs the code after that isn’t executed 
I guess your playerNode was simply null, causing a NPE when you tried to call a method (setLocalTranslation) on it in this case. Setting the translation of a spatial should work, even when its not attached to anything.
@IdreesInc said: I have noticed that if I comment out the "move" part, I just get these errors: 04:58.143 SEVERE com.jme3.app.AppT Exception in class com.jme3.app.AppTask:invoke()-com.jme3.app.AppTask 04:58.144 SEVERE com.jme3.app.AppT Exception in class com.jme3.app.AppTask:invoke()-com.jme3.app.AppTask 04:58.397 SEVERE com.jme3.app.Appl Uncaught exception thrown in Thread[LWJGL Renderer Thread,5,main] in com.jme3.app.Application:handleError-com.jme3.app.Application Repeated a dozen times before the application closes. Is there a reason for this? I am using a class that extends BetterCharacterControl and is initialized like so, if that's any help... [java] public PlayerControl(String username) { super(1.5f, 6f, 1); name = username; this.setJumpForce(new Vector3f(0, 5f, 0)); this.setGravity(new Vector3f(0, gravity / 100, 0)); }[/java]EDIT:
And today is the day, my good people, that I truly realized I am dumber than a rock. Note to self (and anybody who ever has the unfortunate status of sharing the same brain capacity as me): Don’t translate things not attached to a rootNode yet (Or something of the sort). Removing “playerNode.setLocalTranslation…” seemed to do the trick. Thanks for all your help and time guys!
I’m glad you got it figured out… but note that next time you should actually include the exception… not just the line telling you that there is going to be an exception.
I do stand corrected, though. I’m CONSTANTLY telling people that exceptions are as useless without the stack trace as they are just not included at all. Here is a case proving me wrong… some exception information is better than none. 
Always include the exception and always include the stack trace… it will keep us from wanting to crawl through the screen and shake you. 
Oh don’t worry pspeed, you were most definitely right! The whole reason that I was fighting this stupid battle with my code was because the only error it would give me was the one I posted. There WAS NO stack trace, so I couldn’t figure out for the life of me what to do. I had assumed that this was intended, or at least that it was of no fault of my own, because I had found errors before that provided unhelpful stack traces (like the Concurrent Mod. Exception). My previous post was actually incorrect, because the second I posted it, I realized I had just accidentally commented out the whole point of the post, the moving of the shape! So I tried again for a few hours, even just using breakpoints to see how far my code had gotten so I could find the offending line, when I commented out a little line of code that activated the login screen I had implemented earlier this week, because I was tired of typing it in all the time. Well, as it turns out, that login screen had been preventing any stack traces from appearing!!! (God knows why…). So from there, it was on, I found out the errors were caused by animation listeners being added wrongly, and the userNode and control being called before they were fully created. So, you are most definitely right, “exceptions are … useless without the stack trace”. I just wish my code would’ve handed them over, instead of just barking an exception a few dozen times! :facepalm:
@IdreesInc said: Oh don't worry pspeed, you were most definitely right! The whole reason that I was fighting this stupid battle with my code was because the only error it would give me was the one I posted. There WAS NO stack trace, so I couldn't figure out for the life of me what to do. I had assumed that this was intended, or at least that it was of no fault of my own, because I had found errors before that provided unhelpful stack traces (like the Concurrent Mod. Exception). My previous post was actually incorrect, because the second I posted it, I realized I had just accidentally commented out the whole point of the post, the moving of the shape! So I tried again for a few hours, even just using breakpoints to see how far my code had gotten so I could find the offending line, when I commented out a little line of code that activated the login screen I had implemented earlier this week, because I was tired of typing it in all the time. Well, as it turns out, that login screen had been preventing any stack traces from appearing!!! (God knows why...). So from there, it was on, I found out the errors were caused by animation listeners being added wrongly, and the userNode and control being called before they were fully created. So, you are most definitely right, "exceptions are ... useless without the stack trace". I just wish my code would've handed them over, instead of just barking an exception a few dozen times! :facepalm:
Heheh. Well, the logs you included were missing the next line that even showed what the exception was… for whatever reason.