Please address CurTime's lack of precision

[xaviergmail]

Player movement (among other things, but is the most noticealbe) is heavily affected by CurTime. It's a float, so precision isn't that great.

After just 9 hours of uptime, we already lose half of our precision:

Compared to 194 days if it were a double

It is not uncommon to have a server stay up for longer than 9/18 hours without a map change, depending on the gamemode.

I know I'm not only speaking for myself when I say this, but scheduling server restarts / map changes just hurts the flow of my gamemode as well as its player count (loading a large map / navmesh can take sometimes up to 8 minutes and people give up trying to reconnect)

07:51:23 - [RCON Response] <Xavier> : > print(CurTime())...
524243.21875

07:51:38 - [RCON Response] <Xavier> : > print(CurTime() / 60 / 60 / 24)  -- Days...
6.0678052662037

[aStonedPenguin]

It's extremely annoying and harmful to player counts having to do server restarts every few days due to this. +1

[Kefta]

I agree, however, CurTime is used by A LOT of stuff in the engine so adjusting for the extra precision might take time.

[ghost]

Would be a necessary change. However, it would take quite a while to go through the source code and change all instances of math done with curtime to involve doubles.

[KingofBeast]

Can I :+1: more than once pls

[deinemudda32]

+1

[TeddiO]

It's extremely annoying and harmful to player counts having to do server restarts every few days due to this. +1

While not a fix as such, you can just reload the map to continue business as usual. I have something which does this automatically every day during low-pop hours.

[xaviergmail]

Of course, like every request on here, it'll take time to implement / fix.

However, Willox mentioned something about only having to change the implementation of a few things as well as how it is networked. Most compilers can handle mixes of doubles/floats pretty well so I doubt he'd have to change everything. I don't remember exactly what he said, so take my input with a grain of salt.

While not a fix as such, you can just reload the map to continue business as usual.

Some servers don't drop below 50 players. A map reload / server restart is extremely difficult for continuous gamemodes , as I said at the bottom of my post.

[TeddiO]

It's not ideal but unfortunately it's the only way to deal with the situation until a fix is implemented.

[DrVrej]

seems ok +1

[G-Force007]

Bumping this up. This seems to still be a huge problem for servers running for multiple hours on end. Causes vehicles/props/players to become jittery too, seems like a physics problem but it always comes back to CurTime()

[Kefta]

Change the map every few hours

[Kefta]

Never said it was

[xaviergmail]

Any update on this? Seems like it should be a pretty simple refactor these days..

[Kefta]

A lot more than a simple refactor since all places it's used, including in networking, will have to update the precision. For future updating though, perhaps a Time typedef should be added and change all references to that.

[xaviergmail]

Has any consideration been given to this?

[thegrb93]

Reload the map each day. I actually do it 2x/day to clear out caches and such.

[WinterPhoenix]

RealTime apparently runs into the same issue if you run a server for more than like 30 days, only change-leveling: https://wiki.garrysmod.com/page/Global/RealTime

[WinterPhoenix]

Surprisingly not. CurTime resets, but RealTime doesn't: https://winteris.moe/share/2019-08-29_22-23-53.mp4

[mrwallace888]

Bumping this. Double precision would make this significantly better across the board. It'll be a pain in the ass to go through the code, but it's what matters in the long run that counts.

[NathanX-S]

Bump.