Game Development Community

Process Tick on server side - Time?

by elvince · in Torque 3D Professional · 12/18/2010 (4:59 pm) · 5 replies

Hi,

I have a doubt on how work process tick on server side. As the search function is down, I hope someone can help me.

I need to know whether the process tick will be called whenever it's possible or if it is called each xx millisecond?

My goal is to setup Hot (Heal over time) and I need to know if I can use the repair rate functionality to manage this or if I have to manage a scheduler on my side

Thanks
NextNext Thread
PrevPrevious Thread
More from Torque 3D Professional


Torque Owner Ivan Mandzhukov
Liman3D
#1
12/19/2010 (9:10 am)
server processticks are not guaranteed to happen for each 32ms,unlike the client ones.
This is the reason why when you're using processtick timers,you have to use corrections.For example the stock code : recover ticks and jump ticks in writePacketData.

Torque Owner elvince
Neo Studio
#2
12/19/2010 (1:40 pm)
Thanks for the clarification.

This was my understanding so I will implement another solution with a proper scheduler and avoid any issue with my healing over time function.

If I understand properly also, in the server ticks are >32ms we are lagging correct?

By the way, I'm not sure to understand your "corrections" example on recover ticks?
My understanding is that RecoverTicks are sent over the network, and each time you process a ticks you decrement it. I'm not sure to understand the purpose of this recover tick

Thanks,

Torque Owner Ivan Mandzhukov
Liman3D
#3
12/20/2010 (3:30 pm)
This is still not correct,I have seen server ticks to happen after 300ms
The problem with the timers comes from the states - ticks are used for transitions between states.For example the recover state will stay 2-10 or more ticks before being reset with MoveState.If timers differ,the whole state system will differ.The client ticks will process in MoveState,the server ones in another one state.And this is something bad.
That's why mState is also used in writePacketData.
For example if you have to use different input control logic for each state (like I do) - you'll see at least 10 correction writepackets.

Torque Owner elvince
Neo Studio
#4
12/20/2010 (7:05 pm)
Ok I think I understand the concept.

In fact, as process tick is running both on client & on server, you need to send "corrections" packets to be sure that the client is always in sync with the server.

By doing that, if the server ticks > 32 ms the client will go back to the Server state once it will receive the network packet.
I bet it's the same principle used in Image state machine. I mean to keep the machines in the same state.

If you have server ticks > 32Ms, for me that means the server is spending too much time in other process and didn't reach to keep 32ms between two ticks. If it's not correct, what would that mean?
isn't it a target to keep all the tick in the 32ms area as much as possible?

last question may be odd, but does the network update rate is somehow link to this 32ms value?

Thanks for your time, this is clearly useful to learn how things are working internally.

Torque Owner Ivan Mandzhukov
Liman3D
#5
12/20/2010 (7:55 pm)
Yes,the simulation runs at 32Hz afaik.