Mesh position not in sync with "actual" position
by Noah Dyer · in Torque Game Engine · 12/20/2005 (12:22 pm) · 9 replies
I wrote a function to steer a projectile (which I'll happilly post if anyone is interested). I bound the function to the left and right arrow keys. I'm testing the functions with starter.fps. When I press the arrow keys, nothing appears to happen, the crossbow bolt just continues to render in a straight line. But when I open up the editor, the red "node" that represents the bolt is in fact being steered by the left and right arrow keys. And if the node collides with another object, the explosion is rendered at the correct location.
So the question is, what do I have to do to make sure the mesh is being updated correctly?
So the question is, what do I have to do to make sure the mesh is being updated correctly?
#2
My first thought would be, are you making sure that your controlled movements are being updated across the network?
12/20/2005 (1:15 pm)
Without seeing the specifics of your fucntion, we can only really offer troubleshooting ideas.My first thought would be, are you making sure that your controlled movements are being updated across the network?
#3
12/20/2005 (1:19 pm)
Kirby is definitely right on here, the changes you're making to the projectile are not being ghosted down to the client. The node is the server's copy of the object and the model is the clients version.
#4
12/20/2005 (1:36 pm)
That's right, I remember that now from going through the resource on changing player speed. Thanks for pointing that out. I'll make the changes, and post the fully functional code for those interested.
#5
12/28/2005 (3:16 pm)
I've submitted the resource, but it's still going through peer review :D Look for it over the next couple days (since its my first resource, I don't know how long this usually takes). 
#6
12/28/2005 (3:22 pm)
Oh boy, Redeemer-Like-Weapons here we come!
#7
As the second poster mentions, what you describe as your problem indicates that the user's steering is not being propagated to the clients (which handle rendering), which means that you didn't use setMaskBits() somewhere along the line in your change so the networking code would pickup the change and pack up the update. Without further information as to how you did your implementation we can't get much more specific than that.
12/29/2005 (9:26 am)
Well, it will take longer--it's the holidays, and most of GG is on vacation, or at least working lightly, so it will be a bit longer than normal!As the second poster mentions, what you describe as your problem indicates that the user's steering is not being propagated to the clients (which handle rendering), which means that you didn't use setMaskBits() somewhere along the line in your change so the networking code would pickup the change and pack up the update. Without further information as to how you did your implementation we can't get much more specific than that.
#8
But there are other issues. For example, I stored the "steerability" variable (the strength of the steering) in the projectile itself. So if you get a steering powerup, it would only make it easier to steer an existing projectile (not very useful). So steerability needs to be moved from the projectile to the player or the firearm itself, or at the very least one of those needs to have a hook into the projectile's steerability. Also, as it stands, I think in a multiplayer game, everyone would be controlling the same projectile. I mention some of these concerns in the resource itself, but others have arisen since I submitted it. Anyway, if its deemed worthy enough to at least show to the public, I'm sure the community can help me sort through these issues. Hopefully the bulk of the work is done: the code and keybinds to steer the projectile and properly let clients know the attributes of the projectile were changed.
12/29/2005 (11:16 am)
No rush on my part, especially since after I submitted the resource I realized a couple more design flaws. Before I submitted the resource I was able to fix the problem I mentioned in this thread by doing what you mention: adding a couple of maskbits and adding a little code to packUpdate() and unpackUpdate().But there are other issues. For example, I stored the "steerability" variable (the strength of the steering) in the projectile itself. So if you get a steering powerup, it would only make it easier to steer an existing projectile (not very useful). So steerability needs to be moved from the projectile to the player or the firearm itself, or at the very least one of those needs to have a hook into the projectile's steerability. Also, as it stands, I think in a multiplayer game, everyone would be controlling the same projectile. I mention some of these concerns in the resource itself, but others have arisen since I submitted it. Anyway, if its deemed worthy enough to at least show to the public, I'm sure the community can help me sort through these issues. Hopefully the bulk of the work is done: the code and keybinds to steer the projectile and properly let clients know the attributes of the projectile were changed.
#9
i cant seem to find the resource that you have posted, i looked in resources by you, and only one appeared (making games twice as fast with ubersleep).
09/04/2006 (8:04 am)
Noah Dyer, i would be really interested in your controllable projectile, do you think you could send me the modifications?i cant seem to find the resource that you have posted, i looked in resources by you, and only one appeared (making games twice as fast with ubersleep).
Torque Owner Andrew Hull