Time Manager V2 - Breaking the time barrier! - Advanced User Individual Packet Type Timings! #546
Replies: 3 comments
-
Then there is a discussion of what "Default" behavior should be, we know everyone will have a different opinion but it may be argued that most people may be in favor of having RPC like data that is not related to physics, or CSP be sent by servers frame, and physics related data be sent by Tick by default. |
Beta Was this translation helpful? Give feedback.
-
If I understand, this is already a thing. You can set timing to variable and send RPCs and what not immediately. If you run CSP code using tick events (which you should be doing) then they will only send on tick. |
Beta Was this translation helpful? Give feedback.
-
With V5 in development I am reading this again and am understanding you want each packet to have it's own timing, for example: RPCs send every 3 ticks, spawns every 2 ticks, so on. If true, this isn't possible. Doing this would essentially break the order of reliable packets. Imagine if RPCs were every 5 ticks and spawns/despawns every 2. A spawn and despawn could go through, then a RPC would send for the missing object. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
As developers get to a stage where they are releasing their games, editing performance depending on their code will be very important to them!
Tweaking the timing of packet type would give developers full control on what type of packets they want to be sent based on the servers frame rate, or based on the tick interval they decided. They can then also limit the servers frame rate if they like. Heck, adding multiple tick rates could be a thing as well.
A key example is allowing users to have physics based data, and physics be tick based, but all other data be sent frame based.
But why stop there? Allow the user to choose timing of each packet type would give them full control!
On top of that you could have a setting on each instance of a packet type sent to override the time manager settings.
The goal of this request is just to add more flexibility for production ready advanced users. If some types require order of operation. Like ObserverRPCs,TargetRPCs must be sent with SyncVars so that the relied order is kept, then just bundling those together as a option would still be a better situation. Though allowing them to tweak it individually as long as they know it can break the default behavior may not be the worst idea!
These packet types below would each have their own setting, as well as physics simulation being a separate setting to be tied to tick or frame.

Beta Was this translation helpful? Give feedback.
All reactions