How to animate on the server? GG guys?

#1 Setting that "animate on server" flag for the action should do it. One think to note... the server runs at 30 hz, and slightly ahead of the client, so there will always be small differences between the client and the server, even on the same machine. The difference should be very small though, so there's probably something else going on in your situtation.

#2 Thanks for the response!

Is there any reason WHY the server runs slightly differently?

You were right about the animateOnServer flag, it works. Dont know why it didnt seem that way before, oh well.

However, my problem still exists. If you want, I can send you some pics of what is going on(the hitbox for the real player lags behind, and chops, and also looks like it is rotated by about 5 to 10 degrees).

I dont think it is my drawing code, I just store the nodeTransform in a matrix in my hitbox structure, then take it out and apply it to some points when the player is rendered.

Perhaps something is wrong with where I am calling my hitbox collision function (thus where the matrices are updated). I call it from the player::ProcessTick function, at essentially the very end (the only stuff after mine has stuff to do with bubbles.. :)

Could you please help me? I will send you the screenshots, just in case you care... :)

#3 Which player render transform are you using? There are actually two... One is the current 30hz "tick" transform, the other is the "render" transform. The render transform is the inter-tick frame rate interpolation transform. When rendering on the client, you want to use the render transform, or you'll always be slightly ahead of the player.

The render/non-render transform stuff was added in near the end of the project to address some performance issues... anyway, there are two sets of the image and eye transform functions. getEyeTransform, getImageTransform, etc. and getRenderEyeTransform, getRenderImageTransform, etc. Make sure your using the render ones :)

#4 Thanks for the suggestion tim, but that isnt the problem (I already use getRenderTransform :) However, your suggestion made me think of something...

I just noticed something odd. The rotation only seems to happen when the player is in the idle animation... When I make him wave, the hitbox stays relatively close to the arm (only one or two degrees off, it seems to be about one frame behind...)
Any clue why this would be happening?
Any ideas on how to keep the hitbox even closer to the limb?

Note: I use getRenderTransform and getNodeTransform for all my tranformations, on both the client and the server players.

Thanks again for your help tim! This is the best support I have ever seen... :)

#5 You shouldn't be calling getRenderTransform on the server though, not sure what that would return.

The shape is only animated when the animation transforms are needed, usually to render it, or collide with it, etc. If you search for "animate" in shapeBase, you'll see where it's being called. Advancetime, or animating a thread sequence doesn't rebuild the transforms.

In general though, animation on the server takes place in ::processTick (where it does everything), where as the client manages animations from ::advanceTime. ProcessTick is the work horse method called every 30 ms, both on the client and the server, and ::advanceTime is called once per frame on the client only. AdvanceTime is used for the client side "frills" that need to run at frame-rate.

You may want to try a call to animate before your render, or just render your boxes from within the ::render method.

#6 Wow, thanks ALOT Tim!

It didnt completely fix the problem, but I have a much better understanding of everything now, and that is a very good thing. :)

I DID however, figure out what was causing the rotating of the hitbox. I was always viewing the hitboxes in third person, and somehow that is messing up the transforms. Can you think of why, or how to fix it? It seems to be just with the idle animation (looking around) in third person that is causing this. I need it to work in third person, because that is how most of my game will be played.

It works in first person nearly perfectly.

I say nearly perfect, because even though I animate the mShapeInstance right before I do my collision, the real player's boxes lag about a frame behind. Maybe render is just called before the server::ProcessTick is... thats probably it.

Thanks again for the help! :)

#7 Well, as I explained earlier, there will always be some minor differences between the server in the client. There are several reasons for this, and one of the obvious ones is that the client interpolates to the frame-rate where the server does not.

Not sure what the deal is with your rotation... though I suspect it may be the same thing that causes the weapons to "rotate" out of view when you stop (at least they used to before I put in the first-person view option for the images). This may have something to do with the idle animation itself.

Another note: the client and server don't always run exactly the same animation... this is a side effect of viewing your body first person, to make that work we had to "turn off" upper body spine transforms while first person (a long story having to do with using mocap for our animations). So first person your upper body is rigid, where as third person it animates.

#8 I think that your last note is what is causing it. Thanks alot for that, I probably never would have realized that on my own. :)

I just have one last question. I think the reason why the hitbox for the real player lags behind the ghost one is that processtick(and thus my collision routine) is not called nearly as often as teh player is rendered. Is there any way to call it more often just for the collision routine?

Thanks for solving my problem! :)

#9 All game logic, including movement, collision etc. happens in processTick, having your box match the frame-rate is going to make any difference to the core logic. Process tick is not bound to the framerate (a Good Thing) and you can't run it any faster without changing the overal time progression and network synchronization for the sim engine, which is possible, but not recommended.

Are you making a multi-player game? if so, what's running on the server will never match what's on the client, so your wasting your time :) (besides fixing the any obvious problems).

Hit boxes are great for single player games, but multi-player, what your seeing on the client is most likely 40-200 ms out of date, by the time the server get's your fire instructions, it's even later. If the object is moving or animating, the odds of you hitting what your aiming at are very low, if not 0.

The main way to avoid this type of latency issue is to put some trust into the client, but that's a risky business, and totally a game design issue.

#10 Rune did it.....

I remember playing Rune (a 3d melee fighting game) over the net, and there were lots of weapon collisions. I had a ping of probably 100 or so. Rune had hitboxes too.

CounterStrike has hitboxes, and those work fine. If you shoot at someone's head, it hits them in the head. So the problem must be integral to the Torque engine?

If it IS a problem with the engine, what is actually preventing the hitboxes from being accurate enough? You said that there were lots of reasons why the client and server were different. What are those reasons?

Thanks again.

#11 It's not a problem integral to Torque, it's integral to any networked game. T1 had special damage for head shots, someone also added a weapon hit box so you could shoot weapons out of people's hands, both features worked fine. I'm not really saying you can't do it, just that the latency is an issue, as it is with any networked game. You can either say "good enough", you can design around it, or you can put in some form of client side "prediction" for hitboxes.

I just wouldn't design a network game where pin-point accuracy is a major feature of the game. Torque has probably the best networking code out there right now, it doesn't get any better.

Rune and CounterStrike could be doing client side prediction, but they're probably in the good enough category :)

#12 I am glad to hear that it isnt a problem with Torque. I doubted that it would be... :)

Designing around it isnt really an option.

What would be the negative side-effects of client side prediction? (besides cheating, and weird stuff like a sword both hitting the enemy, and being blocked(opposing outcomes on two clients)...)

I will probably have to settle for "good enough". :) Pinpoint accuracy isnt important, as long as it is as good as Rune's, I will be fine. So now the question is, how do I make it "good enough"? Is there any way to make the server more accurate? (So it doesnt chop around like it does now) What are the reasons for the differences between clients and the server?

(My game has people swordfighting alot, so I need hitboxes, and I need to be able to let people block blows. The fights are going to be a little slower than in real life so that people can react, and so the battles are more about skill and thinking than rapidly clicking)

#13 There are lot's of issues with client side damage. One is clients won't all match, so the bullet looks like it misses on one, but hits on another and applies damage. It can actually benefit laggy players since they get to hit players that would normally be dancing around. There's the potential for client side cheating, etc.

Without seeing the behavior of your boxes, it's hard for me to tell what's going on, but some mismatch is normal. This is not a question of accuracy, the server is 100 percent accurate. It faithfully reproduces 100% of every single player move for all players, something that not all networked games do. Assuming there are no problems with your implementation, what you are seeing is a frame interpolation difference between the client and the server. This is a normal side effect of the way the client and server timing is run. The server does not interpolate to the frame-rate, the server must maintain a constant rate of simulation so that it can be deterministic, an important requirement for client side synchronization and prediction.

#14 I just realized something. About 4 or 5 posts back, you said, "(a long story about using mocap)". Does mocap==motion capture? If so, I would be interested in hearing about that long story, or at least the moral, since we plan on using motion capture to do the animations (we already have a suit reserved... :)

I guess the real question then is: Can I speed up the server? What are the downsides to this? Is there a way to only calculate the collision more often? Or somehow interpolate the position of a hitbox and the sword that it might collide against, and check it that way?

Thanks again! :)

#15 Ok, I still need to know if mocap==motion capture.

I did however, think of a system to interpolate the location of the hitboxes.

Thank you so much for your help! It's this kind of service that makes me tell everyone in the IRC channel to buy Torque... :)

#16 Yes I was refering to the mocap. The issues mainly had to do with cleaning it up, having the mocap look good first/person and third person was a real problem, having the eye point based off the mocap also didn't work, it would jump around all over, etc.

#17 Glad to hear that it was just problems caused bly the first and third person perspective of T2. My game will be locked in third person, so that wont be a problem. Thanks again!