Player position haywire

#1 If it is always just the first shot (and subsequent ones are firing properly), then it would seem to me that the act of firing the first shot is "correcting" the orientation somehow. Is there something in your firing function that could be changing/reseting a variable somewhere?

#2 I suggest using the debugger to find out why the rotation is not what you think it should be on the first shot. I also suggest using the debugger to find out when the rotation changes and what it is that changes it. It will be tedious, but it will be a great exercise which will help you learn your way around the engine. Whatever the cause, it is likely going to be specific to your own code. That means no one else is going to be able to troubleshoot it as they don't have the code. If you want to learn to make TorqueX sit up and beg, this is going to be one of the things that helps you get there!

#3 @Chris - I stepped through the code and nowhere does it reset anything related to rotation. I stepped through leading up to it as well to see if some offset was getting tossed in there to no avail as well.

@Ben - Eh? Those values are from the debugger, not ones I just made up or want them to be. Both I posted are the actual rotations that the debugger showed without me touching anything other than firing the weapon (which doesn't rotate it). I realize others wont have this exact issue, but others might have run into something similar to say 'hey, did you check this?'. That's what the forums are for right?

You seem aggrivated with me Ben, something I did?

#4 Any chance that you are spawning the first shot before the rotation is queried/set properly and that the rotation for subsequent shots is actually the value of the last one? In other words, the first shot is "undefined" or otherwise wrong, the second shot uses the rotation the first shot should have, the third uses the second's rotation, etc.

#5 Couldn't be that because then we'd notice the bullet being off on every shot, not just the first as we rotated the weapon. I checked for initialization stuff but the thing is, I move the weapon, so it's rotation changes and is set based on the movement, and no matter where I move it, it has a screwy rotation for the first shot.

I'm going to delve more into this later in the week and focus on wrapping up the gameplay.

#6 Yeah, those numbers are from the debugger but something is changing them somewhere and you can find that through the debugger. The number is not changing itself outisde of TorqueX, deep in the bowels of the cpu registers. Something in your code (or possibly the TorqueX code) is changing the number. Use the debugger to find out what piece of code is changing the number. Find all the access points to rotation on that object and after you see the initial rotation in the debugger put breakpoints on them all and watch for what changes it. When you see the call changing the value, trace back up the call stack and find the root cause of the change. If you're unfamiliar with how to use the debugger in this way, just post and I or someone can give you some pointers on how to do it.

#7 I actually ran into something weird as well, not quite like this but similar. I was modifying the space shooter game to support multiple bullets in a spread and I ran into a weird problem where I would fire the bullets and some of them would just not have a velocity. They would sit where the ship was at the instant I fired, sorta like a mine instead of a bullet.

The fix for it was a bit strange as well... The code originally was just a cut and paste of the stuff to fire a bullet with a new set of variable names. I could get it to fire the first two of my three projectiles (Each projectile had a different material). I tried swapping the order but that made no difference, only the first two fired. Then I tried moving all the code that was similar next to each other and ended up registering all three objects right next to each other in time. That's when I got third bullet on screen, but it didn't move.

Things didn't work right till I put all the bullets in an array and walked the array with a for statement. Was really weird, but maybe there is some underlying bug that's related to this bit of weirdness and the problem Jonathon is having, because I saw some strange things in the debugger myself at the time.

#8 @Ben - The only problem with what you're proposing is that TXE is tick based and so it would stop continually over and over again before I'd even get to a point where I could find anything useful. If I need any input whatsoever from the player, then it's unrealistic to step through every line of code. You can't set conditional breakpoints (that I could find) in vc# express like you can in the full version.

I've already attempted to step through in this way. If you know of something I don't as far as conditional breaking, please divulge it so I can actually do what you propose without a 50 hour commitment.

What I am testing out now is what the rotation is once the object is deserialzed from xml and what it is when the component in question actually loads to see if something strange is going on there.

#9 I recommend finding all the places that CHANGE the rotation and breakpointing those just before you fire the second shot. TX doesn't tick when the window loses focus and I'm assuming you aren't actually changing the rotation yourself otherwise the problem doesn't make sense (because we would expect the rotation of 1st and 2nd shots to be different). Another technique you could use if you don't want to do the breakpointing is journaling object state, specifically rotation. Write out rotation values to the console or a text file. Write out some good state information too so you can see the cause. You should be able to pinpoint the code with the stray rotation change in less than 20 minutes of debugging. The lack of conditional breakpoints in GSE is a bummer but it doesn't make it impossible. If you have to, put some conditionals around all the code that changes the object's rotation and only breakpoint inside the conditional when you have detected a stray change in rotation. I've used this technique to great effect with Asserts. When an assert is thrown you don't get control into the debugger. So I place a conditional around the assert with the opposite of the assert condition. Then I can breakpoint the assert statement and have access into memory before the assert is thrown. You should be able to play some little games like that around places that change the rotation of your object. When one of those is hit, you know something is changing rotation unexpectedly.

#10 That's the thing, I am changing the rotation. The shotgun rotates (you can get an idea of what I'm doing by looking at my latest blog). If I didn't move it and it had that problem I'd understand, but I actually move it around and it always has a rotation about 90 degrees (not programatically, but visually it looks like a 90 degree addition) higher than it should for the first bullet.

I'm going to hack into it more later tonight. I implemented tracing and am seeing how that's gonna go.

#11 Checked out your blog. Advice still stands. Just don't rotate the gun between the first and second shot. If it is too sensitive, just disable the movement binding until you're done troubleshooting. Your initial post said that you didn't move it and you had the problem. Are those numbers you posted in radians instead of degrees? You mention the "visually about 90 degrees" thing and your numbers look like they're 1.something apart (around 90 degrees in radians). Could that account for some math error?

#12 I found the issue. It wasn't the player's position, it was the offset and it wasn't getting set until AFTER the first shot was fired (stupid mistake). I was too busy looking at the damn player's rotation that I didn't bother looking at the offset.

Thanks to all who took a shot! It's always something small.

#13 Yep, I've been slowed down by the small things a few times. That's why the debugger is so valuable. It can help you find those things within 10-20 minutes.

Glad you found it and got it working!