Tic based?

[Nati46]

Hey,
I've been wondering this for a long time, but never actually bothered to get the answer for this.
As far as I know, the original Doom game updates every 1/35th of a second "tic", which is ~28 milliseconds.
I have been playing ZDaemon at some point and I did hear that it works this way aswell, which is also a reason as to why pings there tend to show up at tics (28, 56, 84, and so on) with the real ping showing up on occasion.
However, as you know, in Zandronum, your direct ping result to the server is shown, which implies that the ping shown is the actual time it takes to register all of the client's actions.
The uncapped FPS option further supports this premise, and that Zandronum may indeed be running on a faster update rate than 35hz.
And would this mean that pings which are on the same tick, i.e 87 and 110 would act exactly the same game-wise, since the are both on the 4th tick (112ms)? I've had many games where it feels similiar and a few where I had a noticable difference.
Could anybody familiar with the Zandronum mechanics clear this out?

[Llewellyn]

Well the client renders faster than once every 1/35, but I don't know if anything besides that is calculated outside once every one thirtyfith of a second. Client positions are probably interpolated inbetween frames though...

[Watermelon]

The main question is for a dev to drop by and say if packets that arrive with instructions in between two tics are held until the next tic.

As said previously, I'd assume client positions are interpolated based on velocity.

[Torr Samaho]

I freed the ping from the shackles of Doom's fixed ticrate years ago. The game logic still runs at 35 tics per second, but client and server try to receive packets whenever possible, not only once per tic, and process network commands immediately when receiving them. So pings of 87 and 110 may actually behave slightly differently.

[Llewellyn]

I freed the ping from the shackles of Doom's fixed ticrate years ago. The game logic still runs at 35 tics per second, but client and server try to receive packets whenever possible, not only once per tic, and process network commands immediately when receiving them. So pings of 87 and 110 may actually behave slightly differently.

Does this cause things like GePlayertInput to change during the current tic or the next one? I would assume the next one otherwise it could change states during tic.

[Spider]

I'm pretty sure when I used to code alot 35 or 33.33 Tics were 1 real second, I might be wrong but I think that it is like that...
I hope I helped you.

[Llewellyn]

I'm pretty sure when I used to code alot 35 or 33.33 Tics were 1 real second, I might be wrong but I think that it is like that...
I hope I helped you.

It's 35 and not common knowlege to everyone else in the discussion lol.

[Torr Samaho]

Does this cause things like GePlayertInput to change during the current tic or the next one? I would assume the next one otherwise it could change states during tic.

Since ACS scripts are only run at the tic rate, you won't see the effect of network commands the server processes between tics in ACS scripts before the next tic.