[BUG] Reaching max speed just by running, doesnt seem to be consistent for lineups? Maybe sm1 can explain to me whats the problem for the inconsitent falls in this clip: https://youtu.be/aytJg0T9dQY
[BUG] Reaching max speed just by running, doesnt seem to be consistent for lineups? Maybe sm1 can explain to me whats the problem for the inconsitent falls in this clip: https://youtu.be/aytJg0T9dQY
np, but I'd also like to know the technical reason why you get different results when using the same speed but from different starting points(edited)
Gumba
[BUG] Reaching max speed just by running, doesnt seem to be consistent for lineups? Maybe sm1 can explain to me whats the problem for the inconsitent falls in this clip: https://youtu.be/aytJg0T9dQY
the problem is that the physics are calculated only 50 times per second. this makes them less accurate
only 50 times per second does the server check if you should start getting freezed, so how far you get depends on how far you can walk into the freeze until the server detects that you should be frozen
Patiga
the problem is that the physics are calculated only 50 times per second. this makes them less accurate
only 50 times per second does the server check if you should start getting freezed, so how far you get depends on how far you can walk into the freeze until the server detects that you should be frozen
ohh so getting into the freeze and walking as soon as you're unfreezed, puts you into the same server tick timeline everytime?
Gumba
[BUG] Reaching max speed just by running, doesnt seem to be consistent for lineups? Maybe sm1 can explain to me whats the problem for the inconsitent falls in this clip: https://youtu.be/aytJg0T9dQY
yes (although I'm not sure if we talk about the same thing)
if you start at the same position, and press d, you will start walking at the start of a tick.
then each tick you accelerate, experience friction and gravity, might get frozen.
this is deterministic, other tees starting at the same position will have the exact same values each tick as you had
I think I understand now, altho I'm trying hard to visualise it in my head tbh xD
1
00:55
ye I think I understood, and I think it doesn't even matter if you start at the exact same position, it only matter if you both start at the exact same fraction of a tile
00:55
what I mean is that you have to start at the same decimal coordinates, but the tile itself doesn't matter
sadly it is not that easy, at max speed, you won't be on the same decimals each tile, you will skip some and for each tile you will probably be on different decimals
lets say that your speed is 0.3 tiles per tick, constant
you start at x = 0. on tick 34, you will be at x = 1.02
if another tee starts at x = 1, both you of will never ever be on the same x position
Patiga
lets say that your speed is 0.3 tiles per tick, constant
you start at x = 0. on tick 34, you will be at x = 1.02
if another tee starts at x = 1, both you of will never ever be on the same x position
There are numerous graphics (gfx) related bugs users encountered. Not all are fixable, but might have workarounds.
This site is there to collect these to help those encountering the same issues.
ok, great. Let's hope there are not too many people who run into these issues. I wish we could detect them automatically instead of players having to do manual steps
Because they are now simply allocated on vram. Also not lazy allocated or similar. But he was out of vram before. It's simply that u can swap out the vram with system memory at the cost of the bandwidth speed
There are numerous graphics (gfx) related bugs users encountered. Not all are fixable, but might have workarounds.
This site is there to collect these to help those encountering the same issues.
after updating ddnet client to 16.7, spectating players lags and console gets spammed with this, normal playing seems lag free on the same server, just spectating players lags very hard