input_redundancy rename and check

[TheYellowArchitect]

Batching inputs was implemented in https://github.com/foxssake/netfox/pull/221 input_redundancy is the variable used for batching the inputs of previous ticks. Given its unintuitive name, I suggest renaming it to input_batch_count or something similar.

Also, if its value becomes lesser than 1, netfox bugs heavily, so there should be a check in the project settings for it.

[elementbound]

The original idea was to send redundant inputs as well, to avoid having to send inputs as reliable. What's the issue with input_redundancy for redundant input count?

Good catch on the value check.

[TheYellowArchitect]

The original idea was to send redundant inputs as well, to avoid having to send inputs as reliable. What's the issue with input_redundancy for redundant input count?

It's that the inputs are not redundant. They are batched. It is unknown if inputs are redundant, maybe no inputs contained in the batch are redundant, maybe all except one. If the variable is set to 1, no input is redundant :P

The rename is good because I skimmed over the code and saw the variable name, and didn't know input batching was implemented until I started coding input serialization. As for the name, bonus argument is that this technique of sending inputs together (e.g. Doom/Quake) is called input batching, at least from what I recall

[elementbound]

It's that the inputs are not redundant. They are batched. It is unknown if inputs are redundant, maybe no inputs contained in the batch are redundant, maybe all except one. If the variable is set to 1, no input is redundant :P

They are certainly redundant from the sender's perspective. Either way, I'm not currently in the mood for smirks :slightly_smiling_face:

I did some googling on input batching, but didn't find much. Based on this thread, it's slightly different from what the netfox feature does. Could you please link to some reference material on what input batching refers to in other games?

If input batching is a widely used technique ( Quake certainly qualifies ) and refers to what netfox does, then I'm in for this change.

[TheYellowArchitect]

The above link you posted is not for input but for the states, it refers to diff states as done in #264 if I read it correctly.

All FPS&fighting games do this input batching technique. As for what they name it exactly, they aren't open-source so their variable names for this technique is unknown.

Lastly, I want to say input_redundancy sounds like a boolean at project settings. count helps to identify it as integer. What rename would you suggest if not input_batch_count

[albertok]

I originally went with input_redundancy as it conveys it's intent - keep the show going if a packet gets lost or arrives late.

I wanted to give the user control over how much fault tolerance they wanted to target as well.

[elementbound]

Merged the check PR, thanks @albertok!

As for the naming question, I suggest we continue it in a discussion if needed. I'm happy to consider input_batch_count if there's any doc that it indeed refers to what our current implementation does.

[TheYellowArchitect]

I'm happy to consider input_batch_count if there's any doc that it indeed refers to what our current implementation does.

Input redundancy This is the number of previous input ticks to send along with the current tick. We send data unreliably over UDP for speed. In the event a packet is lost or arrives out of order we add some redundancy. You can calculate your target reliability % packet success chance by using the formula 1 - (1 - packet_success_rate) ^ input_redundancy.

The above is in guides/network-rollback.md

You mean docs in other games?

[elementbound]

Yes I mean docs in other games :slightly_smiling_face: So that there's sources showing that input batching is a. used in other libs/games too and b. it means what netfox's input redundancy means. If those two points are fulfilled, that gives a good reason to discuss renaming.

[annamaria-szentpeteri]

This comment is not an argument for renaming or not renaming, I just got curious about input batching and started searching the web. These are some interesting things I found during that search. Give it a read if you will.

---

This article about Quake 3 Network Protokol. Bit relevant paragraph:

The above description applies to all game objects except the most important one: the player. This case is special, because the player’s eyes are the first person camera through which we are seeing the game world. Any latency or lack of smoothness here would be much more noticeable than with other game objects. Which is why sending user input to the server, waiting for the server to process it and respond with the current player position and only then rendering the world using that delayed information isn’t a good option. Instead the Quake 3 client works as follows. In each frame it samples user input (how much the mouse was moved in which direction, what keys are pressed), constructs a user command, which is that user input translated into a form independent of the actual input method used. It then either sends that user command to the server immediately or stores it to be sent in one batch with future user commands from subsequent frames. The server will use those commands to perform the player movement and calculate the authoritative world state. But instead of waiting for the server to do that and send back a snapshot containing that information, the client also immediately performs the same player movement locally. In this case there’s no interpolation - the move commands are applied onto the latest snapshot received from the server and the results can be seen on the screen immediately. In a way this means that each player lives in the future on their own machine, when compared to the rest of the world, which is behind because of the network latency and the delay needed for interpolation. Applying user inputs on the client without waiting for a response from the server is called prediction.

---

Mirror is a high-level networking library for Unity. Relevant section is in the Timestamp Batching document:

Batching

Every message that you send will be batched until the end of the frame in order to minimize bandwidth and transport calls. For example, if you send a lot of 10 byte messages then we can usually fit ~120 of them into one MTU sized batch of around 1200 bytes.

For the Transport, it's pretty convenient to send around messages in 1200 byte chunks (see MTU). Messages larger than MTU are sent as a single batch. To be exact, the Transport decides the batch size that Mirror aims for via Transport.GetBatchThreshold().

Mirror batching is bidirectional. Which means that both the client and the server batch their messages and flush them out at the end of the frame.

---

Command batching from Unity Gaming Services Use Cases:

Command batching is the concept where each game action is a Command which can be collected into a queue to be sent to the server in batches for processing. Command batching optimizes your game’s bandwidth to be as energy efficient as possible, and prevent poor performance due to frequent server calls or rate limiting. This provides a smoother game experience with less downtime.