rot can be replaced with the spatial equivalent, but position canât without some extra changes.
public void moveFwd() {
this.position = getNextLoc(1);
}
public Vector3f getNextLoc(int steps) {
this.innerNode.setLocalTranslation(0.3F * steps, 0, 0);
Vector3f newPosition = this.innerNode.getWorldTranslation();
if (newPosition.x > GameLogic.boardSize) newPosition.x = GameLogic.boardSize;
if (newPosition.x < -GameLogic.boardSize) newPosition.x = -GameLogic.boardSize;
if (newPosition.z > GameLogic.boardSize) newPosition.z = GameLogic.boardSize;
if (newPosition.z < -GameLogic.boardSize) newPosition.z = -GameLogic.boardSize;
for (Crusher c : logic.crushers) {
if (c.position.y < 1) {
if (Main.colliding(body, c.shape)) return steps > 0 ? getNextLoc(steps - 1) : position;
}
}
this.innerNode.setLocalTranslation(0, 0, 0);
return newPosition;
}
A breakdown of my confusing spatials and nodes:
nonRotNode - Top level, dosen't rotate
|- node - This one does rotate
|- innerNode (I probably obsoleted this one, I haven't gone through everything yet, but it looks like i could just move this stuff to node.)
|- body - varies by skin, the "ball"
|- spear - varies by skin - the "pointy" thing
|- name - Bitmap text of the username, I don't want this rotating
Whoah⌠you do some seriously odd things that make this harder. It looks like you rotate a parent and move a child? There is no good reason to do that and lots of bad ones.
Itâs going to be impossible to factor tpf into your steps approach, also⌠so your game will speed up and slow down with frame rate.
You are better off just calculating a new position using forward direction and then clamping that to the board. You could do all of your positioning with speed and the orientation of the spatial.
Your ânodeâ structure should be:
node - rotates and moves
|- body
|- spear
|- text with a BillboardControl
Move node, rotate node, find direction for node, etc⌠Your life will be 10000x simpler.
Edit:
And to clamp position instead of move() you could do something like:
Vector3f pos = node.getLocalTranslation();
pos = pos.add(node.getLocalRotation().mult(Vector3f.UNIT_Z);
pos.x = FastMath.clamp(pos.x, -GameLogic.boardSize, GameLogic.boardSize);
pos.z = FastMath.clamp(pos.z, -GameLogic.boardSize, GameLogic.boardSize);
node.setLocalTranslation(pos);
@pspeed (I keep forgetting to do thisâŚ(not hitting reply))
Remember that thread I used earlier? The update counter? It shouldnât take me long to convert that to some subtraction and a variableâŚ
Also, other aspects of the game call getNextLoc with values other than one, so itâs kinda vital.
I had the NPC place a box where it thought its target was, now I know it knows exactly where the target is. It appears to be having problems with the rotate code.
Well, you are moving a different node than you are rotating (by your description and code) so things are always going to be all kinds of bonkers.
getNextLoc(some random integer) is a super strange way to do things. You should be using tpf. Everything you do will be harder and unsupportable by this community with your current approach.
Thatâs the down side to doing everything in a totally unique and ultimately unnecessary way⌠we wonât be able to help you sort out your mess. There is no good reason to do this and certainly you havenât provided one.
So at this point, Iâm going to have to bow out until you explain why this is ârequiredâ (so I can convince you otherwise) or you rethink your approach. You have like 400 lines of code to do the job of 10.
Edit: just in case this is me bowing out⌠good luck with your game.
The reason for getNextLoc(updates) is because the other aspect of my game, the crushers, use it to calculate the position the player WILL be, that way they donât just keep falling behind the player.
Iâm going to go start working on tpf(Done) and those nodes nowâŚ
What is a BillboardControl though?
I Fixed it to work with tpf:
public float time = 0;
public static final float speed = 1f/30f;
public int updateCounter(float tpf) {
time += tpf;
int updates = (int) Math.floor(time / speed);
time -= speed * updates;
return updates;
}
Pretty standard steering primitive type thing. In the roughly a dozen articles Iâve read on the subject, not a single one of them used an âintâ steps⌠instead, they use the speed of the target so that it scales properly with time.