Why does E2 works 66 times per second while game itself runs 60 fps #3166
|
I dont know if I am writing this quiestion in correct place, but why does expression2 chips execute code 66 times per second? When making some control stuff it makes control unreliable and weird. And also how does it work 66 times. Like why does it need to run 1 additional tick after 10 ticks |
Replies: 1 comment 6 replies
|
(Moved for not being a bug report) Tickrate is unrelated to framerate and is based on the server settings. By default, a Gmod server runs at 66 ticks per second. That's why E2 also runs at 66 ticks, because it's matching the tickrate of the server you're playing on (in singleplayer this is also 66). |
|
Ok. But is that consistent with game frame rate? Like would it always 10 frames synchronous with a game and then 1 extra frame or is the server ticks completely not synchronous to the game. Also why is implemented like that? Because it was impossible to implement otherwise, or there are some advantages to this? Also that should probably be documented if possible on E2 page |
|
Server tickrate and framerate are completely unrelated, but hosting a server/playing singleplayer and doing something that reduces your tickrate can reduce your framerate. Think of it like this: you have a part of the game that handles physics, and a part of the game that handles rendering the game. The part that renders doesn't need to be directly communicating to the part that handles physics, it just need to read the information it produces about the current physical state of the world so it can render that information to the player. This practice is used in all sorts of games. Minecraft is a popular example. |
|
While your response makes sense to me, I should mention that I use E2 chips to make some control systems. So I guess my question is how E2 handles game physics. Are forces at each E2 cycle gets accumulated, so 1 in 10 cycles you apply double the force? And if physics and E2 are desynchonised what would :pos() function return? Would it change? I am sorry but I cant fully wrap my head around this topic |
|
Everything (besides graphical elements) in the game gets computed every tick, and every tick happens at roughly the same time. During a game tick, basically everything gets recalculated and updated, so physics and E2 would update on the same tick. There would be no desynchronization. If you're doing something like PID, you don't need to worry about the specifics of tickrate. All you need to know is that your force needs to be multiplied by the tick duration (e.g., 1/66 seconds) so everything is in the same units. |
|
Alright |
|
Oh, also, you can get the tick duration/interval using |
Server tickrate and framerate are completely unrelated, but hosting a server/playing singleplayer and doing something that reduces your tickrate can reduce your framerate.
Think of it like this: you have a part of the game that handles physics, and a part of the game that handles rendering the game. The part that renders doesn't need to be directly communicating to the part that handles physics, it just need to read the information it produces about the current physical state of the world so it can render that information to the player.
This practice is used in all sorts of games. Minecraft is a popular example.