Clientside prediciton

[Hypersonic]

Lag due to distance along the Earth surface should never account for more than 67 ms. The rest would be caused by relay delays such as routers.

Speed of light - Wikipedia, the free encyclopedia
about 300 Mega-Meters per second

Equator - Wikipedia, the free encyclopedia
about 40 Mega-Meters, so half-way around the world is no more than 20 Mega-Meters.

speed = dist/time
300 Mega-Meters/sec = 20 Mega-Meters / time -> time = 67 milli-seconds

Although the original NetQuake plays crappy on a poor connection, it has a very pure networking model. Everything on the player's screen is the same as on everyone else's screen for each time/position frame. Although each player might receive the frames at slightly different times. Also the time the server receives input might vary a bit as well.

I believe you can play QuakeWorld the same way as NetQuake if you turn off prediction. Self prediction is basically letting a client see the result of their input immediately, but the displayed position of their player is incorrect relative to the time/position frame of other players and projectiles, time-wise. The correct position of your player would be slightly behind you as you move forward. Small price to pay though for the illusion of immediate reaction to your input.

[Cobalt]

In theory its CLOSE to the speed of light , always approaching it but never fully reaching it.

[R00k]

My ping at 72fps at the lowest is 20ms. when connected to texas, 600 miles away.

at 20 ms netQuake feels just as good as QW or lan.

qw just has diff mods, rules, physics. netQuake doesnt have bunny hopping but it can be added via quakec, (ive done this).

quakeworld/FTE have Multiview demos, and QTV.

but then we also have twitch.tv

[Spike]

@Hypersonic
electrical signals travel significantly slower than the speed of light, varying by medium.
'light' signals down fibre does not take a direct route along that fibre, and thus travels noticably slower (fibre depends upon light bouncing around the inside of the cable).
fibre cables are also not laid along direct routes.
fibre (and copper even more so) requires repeaters that retransmit the signal (so that any individual hop doesn't devolve into randomness). these will delay it even more.
determining the direction packets must travel in requires lots of lookups and other things that will queue+stall packets.
international links still often travel via satalite. you're no longer talking about the equatorial distance, but instead you're sending signals part of the way to the moon. and then back again.
packets arriving from multiple sources for a single destination need to be interleaved somewhat.
while the backbone might be somewhat direct, its the last-mile on both ends that'll add a whole boatload of lag that can prevent two people in the same town from getting a good game. datacenters have less of an issue, and the lag between there and your home can be less despite being a further distance geographically. its not just due to conjestion, but also that copper sucks.

@Hypersonic
QuakeWorld servers use different player physics that can be reliably predicted by clients, even if you switch off prediction in the client.
Hence why you can still bunnyhop so easily.
FTE is able to enforce NQ physics upon QW clients, but this isn't QuakeWorld in general, doing so will disable/break prediction (depending on the client).

@Ebisu
CRT screens fire photons at a load of phospher, causing it to glow. the individual pixels are updated no more often than the refresh rate (meaning an average latency of the refresh rate). while not instant, the delay between the signal reaching the electron gun at the back of the crt and the phospher glowing is really quite small. the phospher quickly stops glowing once there's no longer photons hitting it, and its this which results in flickering when run at a low refresh rate or when filmed.
LCD screens on the other hand depend upon using an electrical charge to change the alignment crystals in order to rotate light passing between two polarising filters. the charge applied to each cell needs to be correct in order to rotate enough light to get the correct intensity on the screen and this can take time, more so if its now going in the other direction from the previous frame. thus not only do they have a response time, it can take even longer to actually fully display the final colour value hence why how they can have such high lag. its fun stuff...
So yeah, if you're a serious gamer, get a CRT.

@Ebisu
the mouse rate depends upon the poll frequency. the device hardware specifies a poll interval to the usb host that is typically some value like 60hz. however, its possible for the host to ignore this completely and poll as frequently as 1000hz (which can start to become a drain on the cpu or result in glitches in mice/keyboards). some gamers swear by these hacks - the sort of gamers who already have CRTs.
I have no idea about audio latencies...

[Hypersonic]

OK, perhaps 2/3 the speed of light then.

Optical fiber - Wikipedia, the free encyclopedia
"...a simple rule of thumb is that a signal using optical fiber for communication will travel at around 200,000 kilometers per second." So 200 Mega-Meters per second for fiber optics

Velocity factor - Wikipedia, the free encyclopedia
Also around 200 Mega-Meters per second for electric network cabling.

Since network cabling doesn't travel in a straight line the entire distance lets say the most distance a signal will travel along Earth surface is 25 Mega-Meters.

New max lag time due to travel distance along Earth surface:
200 Mega-Meters / sec = 25 Mega-Meters / time -> 125ms (one way)
250ms (round trip)

Great site to determine straight line distances along Earth surface
Calculate distance and bearing between two Latitude/Longitude points using haversine formula in JavaScript
(note that straight lines can look curved on a Mercator projection.)

Any idea how high the internet communication satellites are?

I wonder if there's a traceroute program that also displays distance between hops along Earth's surface. Then you can get a rough idea how much of the lag is due to distance and how much is due to processing. (ya the cords don't go in perfectly straight lines, perhaps 25% more than straight line due to zig zagging about.)

What specifically is the difference in physics between NQ and QW? Can you still bunnyhop easily in QW with self prediction turned off?

It would be neat if clients could download different physics systems from the server they can use to predict just like they can download different maps and models and sounds.

[Adam]

As a point of reference for you.

I'm located in Albany, at the southern tip of Western Australia.
We have ADSL2 with a max download of 600kb a second.
That's the best you can get down here without using a satellite.

I was running around on dmtx.quakeone.com with a ping of 343.

[Spike]

Any idea how high the internet communication satellites are?

Geosynchronous satelites have a fixed speed+altitude. They orbit the equator. You should be able to google the altitude.

I wonder if there's a traceroute program that also displays distance between hops along Earth's surface. Then you can get a rough idea how much of the lag is due to distance and how much is due to processing. (ya the cords don't go in perfectly straight lines, perhaps 25% more than straight line due to zig zagging about.)

To route an IP packet, you need to know where to send it. This necessarily means that the approximate location can be determined from global routing tables. Its typically only accurate to the town (and apparently absolutely unreliable in the UK - address exhaustion is probably guilty). Of course, decent databases should contain more reliable location info for the various backbone routers.
Also, don't underestimate reverse dns lookups in traceroutes that name citys.

What specifically is the difference in physics between NQ and QW? Can you still bunnyhop easily in QW with self prediction turned off?

Most obvious is that QW physics allows you to jump as soon as you're onground. the result being that you're never onground when friction is applied, thus you're never slowed down and can accelerate almost indefinitely.
that's the biggest difference.

It would be neat if clients could download different physics systems from the server they can use to predict just like they can download different maps and models and sounds.

CSQC.

[Hypersonic]

Satellite Internet access - Wikipedia, the free encyclopedia
Wow, 36 Mega-Meters over the Equator! Moon is 384 Mega-Meters away so forget low latency Moon to Earth games!

300 Mega-Meters / sec = 36 Mega-Meters / time -> time = 120ms (one way) 240ms (round trip)
And that's the best case scenario if both points on Earth are close to the satellite! If the satellite is not in view of both points on Earth and has to relay to another satellite just forget it! The added relay distance would be astronomical! I doubt satellite companies advertise the minimum 240ms ping times, just the bitrates.

Does NetQuake physics have a limit on how often you can jump?

So you got Client Side Quake C going?
Quake Expo 2008 - Hosted by Tastyspleen.net
Client-Side QuakeC | QuakeWiki

Looks like it can do alot of stuff. Are there limitations on the client frame by frame player physics? Such as can you program 6DOF movement, walk on walls, change max speed/acceleration/gravity vector on the fly all with just Server and Client side QuakeC? If not it would be a great addition making the Quake engine much more versatile.

@Adam
dmtx.quakeone.com with a ping of 343? I wonder what city/country quakeone.com is located.

[Cobalt]

NQ lets you do that too, its been nicknamed 'bunnyhop. The trick there is that the bunnyhop seems only possible - or should I say an advantage at very low ping times (IE: single player)....so in my findings with NQ, your speed DOES change to a rate thats quite faster than what appears to be the 'maxspeed' the cvar sets if you watch other players connected at higher pings trying to move like that. Seems to me the factor activates somewhwhere like <40 ping or so but thats just my observation. After all, that guys info is arriving ALOT faster to the server than others , if indeed the others have significantly higher pings, and he will have the illusion of incredible speed.

Most obvious is that QW physics allows you to jump as soon as you're onground. the result being that you're never onground when friction is applied, thus you're never slowed down and can accelerate almost indefinitely.
that's the biggest difference.

[Adam]

@Adam
dmtx.quakeone.com with a ping of 343? I wonder what city/country quakeone.com is located.

I believe it is based in Texas.
Distance between the two points is (roughly) 10600 miles or 17000 kilometres.

[Hypersonic]

Cables from Australia to the United States are fairly straight, so that is probably fairly close to 20 Mega-Meters or so of cabling.
The secret world of submarine cables | ExtremeTech

200 MM/s = 20 MM / time -> 100ms one way, 200ms round trip due to distance alone. The rest is processing delays.

No matter how high bit rate gets, even a billion billion billion gigabits per second will still be limited to travel speeds of 200 to 300 Mega-Meters / second. So prediction is always going to be important.

[Hypersonic]

I wonder if bunny hopping is simply easier to do in QW due to the fact that your jump input coincides with your character striking the ground thanks to being able to basically see into the future as far as your own character is concerned.

In Prediction-less NetQuake you have to press jump slightly before your character 'on the server' strikes the ground, and way before your character 'on your client screen' strikes the ground on your screen.

NetQuake jumping
time: 0ms you press jump
time: 50ms you jump on the server
time 100ms your jump is finally shown on your client screen

QW jumping
time: 0ms you press jump. Since you can see 100ms into the future your phantom character immediately jumps.
time: 50ms you jump on the server
time: 100ms (nothing, it only displays your phantom character in the future)

[Ebisu]

I wonder if bunny hopping is simply easier to do in QW due to the fact that your jump input coincides with your character striking the ground thanks to being able to basically see into the future as far as your own character is concerned.

To what I understand, in NQ there is more friction when you hit the ground, thus making speed buildup take more time.

[Mindf!3ldzX]

To what I understand, in NQ there is more friction when you hit the ground, thus making speed buildup take more time.

I have never seen anyone even remotely come close to qw bunny hopping in a stock nq server. there is a large circle map in qw, that was (I assume) designed for speed bunny hopping over n over in a circle.

Anyone know that map I speak of?

[Hypersonic]

Comparing NQ with QW it seems that the physics is the same

Air accelerate
NQ https://github.com/id-Software/Quake...sv_user.c#L207
QW https://github.com/id-Software/Quake...t/pmove.c#L412

Friction
NQ https://github.com/id-Software/Quake...sv_user.c#L122
QW https://github.com/id-Software/Quake...t/pmove.c#L324

VectorNormalize (returns length, unitizes the parameter)
NQ https://github.com/id-Software/Quake...mathlib.c#L385
QW https://github.com/id-Software/Quake...mathlib.c#L383

I'm thinking that the reason stated on my 02-12-2015 post is the reason bunnyhopping is difficult on NQ, not the physics. Anyone try bunnyhopping on NQ with <10ms ping, 0% packet loss? Maybe if you also decrease the sys_ticrate
https://github.com/id-Software/Quake...ake/host.c#L60