btw I do have more ideas for refreshing netcode though... but the one I write about here (Weird.jpg) could be implemented in no time at all (as it doesn't break anything from the q3 code and utilizes stuff which is already implemented in ql)

stop warping plz

pictures man pictures.

Good job, not getting it yet but maybe tomorrow and some coffee helps :)

well preferibly I would want to draw them without as many "preconditions" especially points 2, 4 and 11 are very fundamental to how large the problem is. But it's kinda un-drawable when you want to put all of that in as well...

you missed the all important Q43A

I covered all important Q43A stuff.....
wtf is Q43A? :)
----
ok ok I actually know what Q43A is but I only discuss OSP/CPMA/QL because I know how those work ;)

To be honest your pictures were too much of a mess for me to understand what's going on.

well I can imagine that... But that's also (mainly) due to how the problem works.
If you want the most simple way to look at it just look at 4 things.
1) the green dot on the p1 timeline (you press a button).

2) the yellow vertical line to see which time is shown on your screen (aka if the yellow line is further to the right than the green dot the enemy is, on your screen, "drawn to be there"*).

3) the blue vertical line compared to the yellow line: if the blue line is further to the right than the yellow line you are aiming ahaid of the opponent.

4) the possition of the blue line compared to the the notation where "the shot gets drawn" on the p2 timeline. The larger this difference is the more "behind the model" you will get hit. In QL this is almost double the size of OSP. And it is the main reason why I think this netcode is too horrible to play on.

I've added some ingame images which show the same concepts as the timeline stuff....
It might be easier to grasp that way.

Small note is that I don't explain why the phenomena occur in the ingame images while I do do that in the timelines.

all idtech games send and receive the same snapshot based netcode, with bools, lists, entitynumbers, physic vectors, etc written in

the async connections in the engine dont really do nothing much but open/close/send/receive,

the snapshots get read in the sdk and overwrite clientside bools, lists, entitynumbers, physic vectors, etc making them be in sync

most of the bugs come from other code and client prediction which you have to recode, cleanup or make server or clientside

Q43A does less processing for every entity spawned on server and client side and gives a little bit better performance, and a alot better when playing on dedicated servers and no projectiles will ever go through walls because they are 100% serverside physic synced, and 1000s of other changes that make q4 playable with all new features in Q43A active in gameplay

all idtech games send and receive the same snapshot based netcode, with bools, lists, entitynumbers, physic vectors, etc written in

the async connections in the engine dont really do nothing much but open/close/send/receive,

the snapshots get read in the sdk and overwrite clientside bools, lists, entitynumbers, physic vectors, etc making them be in sync

most of the bugs come from other code and client prediction which you have to recode, cleanup or make server or clientside

Q43A does less processing for every entity spawned on server and client side and gives a little bit better performance, and a alot better when playing on dedicated servers and no projectiles will ever go through walls because they are 100% serverside physic synced, and 1000s of other changes that make q4 playable with all new features in Q43A active in gameplay

double probation postage...

server doesnt need to update huds etc, so they are not update serverside on q43a servers, for all players being sent out to all clients, and gameplay huds being updated serverside when no1 can see them or they are not actually loaded but server side code -> still gets processed

server and clientside physics are not being both run fully on either side of the game which fixes clientside prediction

q43a doesnt need to use clientside heads, for "better" performance, models use full heads for the lipsync taunts to work

and 1000s of other changes, and performance is better still, in gameplay and on the ingame mp ESC menu

i'm looking forward to kdawgs commentary

lol

Holly fuck !

I see where you get your netcode "theory" from but i have to break it you. It's completely illogical. First off cpma is open source
and it clearly states that xerp has 50ms delay (the cpma.txt folder even says this when you install it). The 50ms delay is then further increased with the use of s_mixahead which gives the 20ms delay sound wise. So that proves your 20ms theory wrong. Considering cl_predicthitbeep it would be ineffective because cl_timenudge/cl_autotimenudge is only effective clientside and decreases the buffer load on the extrapolation of the model and therefore the interpolation is decreased as well. Also i have no idea what i'm talking about.

>First off cpma is open source
Give a link to sources then, I'm pretty interested to see this :)
Never saw them, and I think it's not going to happen ...

I have to break this to you tho: cpma isn't open source and there's absolutely no mention of any ping whatsoever in client.txt regarding xerpclients. Go read it again!

did you miss this? "Also i have no idea what i'm talking about."

play more promode

OSP.JPG
"you aim INFRONT of the opponent"

glory days...

started giggling when i read it was weird's research :'D sorry weird probably good job nonetheless!

Weird you need to work on how you present information to the reader in a logical progression and have an intro/middle/conclusion structure D:

Maybe hire an artist too xD

It's like the rantings of a mad scientist which noone will ever understand.

edit: But maybe secretly brilliant?

*comparisons
will read it later

MIND = BLOWN :O

The big news I take from this is that timenudge changes the timestamp in the snap that the client sends to the server. This is in total contrast of what I always have read about timenudge. If this observation is based on looking at q3 src code, then it's a welcome news, and I finally understand some controversial debates from the past.

My understanding is that the most fair solution would be:

- No backward reconciliation, anti-lag, whatever. When the server receives a snaps from the player, it gets processed at that time. This way, the only thing that counts is your ping to the server, which is something mostly consistent, so you can learn to deal with it.

- Timenudge only extrapolating positions of entities for visual purposes (no change to timestamps). A excellent job can be done with projectiles fired at you, as they can be extrapolated almost perfectly (excluding ping fluctuations), while for the players one would have the classic correction warp.

Players with a high ping would be disadvantaged, and this is the cost of playing online. But at least, the experience in game would be consistent, and you would only blame yourself and your connection, rather then the crappy netcode or the opponent's connection which changes every match.

I think anything going away from this introduces more unfairness. My understanding is that it has been done in the past as an attempt to make the game more pleasing for casual gamers (who pretend that the game considers what they see on the screen as true, despite that being either impossible in a fair setting).

In a perfect world, games would have a "casual netcode" for public play and newbies, and a "competitive net code" for people who actually care about competition and fairness.

- No backward reconciliation, anti-lag, whatever.

This. But it won't change because "every modern game has it". I stopped complaining about it some time ago. However, it's good that weird still holds the fort.

That would only be fair if in theory everyone has access to the same network connection (regarding latency and quality). And by fair I mean that skill is the deciding factor on match outcomes.

That level of fairness is impossible online. Given someone has to pay the price of latency, I think the constrained optimum is that those with a bad connection suffer more than those with a good one.

Quake Live netcode works quite well up to 55ms at least. What breaks it is when the ping starts fluctuating or there is packetloss and I'm sure that there is a better way to fix that (= make laggers feel their lag) than going back to Stone Age.

I guess it depends how deep you want to go in the discussion.

If you say QL is an acceptable compromise between something playable for more people and something competitive and fair, I agree.

Stone Age. I'd call it the good old days. Where a HPB was a HPB and a LPB a LPB (probably with shaft). The biggest plus this approach has tbh, is the fact that the ping is pretty consistent in this day and age. Back in the '90 ping spikes were very common but 2012? I would take a consistent ping of 50-60 over what the QL netcode offers me now. And I ping around ~20-30 now.

Let's imagine id offering servers with anti-lag turned off and hence running osp-like netcode. It's only hypothetical but imo only those players with ping 1-30 would use these servers. No one likes to get an obvious disadvantage if it can avoided in some way.

so true.

That can never happen in ql, unless id let us run lan servers and every country has its own servers, like it was in q3. Then again, I would never play outside my country, at least not with anyone decent (only vs noobs). I know some ppl can do it (cypher for example) and I have huge respect for them and they are like heroes with huge balls in my eyes. I and most ppl aren’t capable of such feats. Ppl like weird are delusional pussies, which is proven, even at the lan he went. pavel and evil pawned, they even almost won cypher. Weird sucked, as everyone was expecting.

If ql was using OSP’s netcode, I and probably everybody else from my country and many other countries that don’t have servers, would never had started playing. I am sure that is the case for me.

Having said that, I too h8 the randomness of the netcode and it gets much worse than weird thinks for high pingers. I had many games where not only my rails were going through the enemy body but even my rockets… try to win such games, pointless. I am also probably the first here who said that in ql we play vs the opponent’s connection and it’s always different, even if ur connection remains the same (at least I hadn’t seen anyone else mention it, until the time I did).

Nothing can compare though with the feeling of responsiveness and the illusion that u play in equal pings, which ql’s netcode gives u. In q3, if u entered a server with high ping, u could see it so badly after firing few rockets that ur reaction was like “omg get me out of here asap”. Would that be good for ql? Certainly not and for sure much less ppl would had been playing it.

ps: even though in the end I disagree with weird (I agree though in the netcode’s randomness), I like his consistency and passion for what he believes. I don’t think he can achieve what he wants, for which I am glad. If I thought he could, then I probably wouldn’t find his post entertaining, but dangerous.

Yes, I see your point and agree with your concerns. Having a broader audience is probably more beneficial to the game than make a more hardcore ping-dependent setting, especially when people have little chance to play on lan, and servers are limited.

I don't like the idea of ping-only-dependent netcode. Why? How are you supposed to organise FAIR online-tournaments? ATM it is possible. And if Wierd thinks he is in a disadvantage then he should prove first that he can beat those players, he loses online to, on LAN. And most of the time, I think the better player wins, independent from the netcode. If the netcode was so heavily depending on ping, then the server-discussions would be ENDLESS! ENDLESS!!!!!!!!!!!!!!!!

Nontheless i also recognized that I hit some players far better than others, depending on their connection, and not their dodging. But I managed to addapt my gamestyle. So if it is difficult to hit someone with rail/shaft, then i just spam more rockets and play more deffensive.

While it's a bitch to play with russians (80-90 ping) it eventually turns out that crappy highping netcode doesn't make that much difference in match outcomes - unless you're on the same skill level, but then winning with a few frags is nothing more then luck so whatever.

LANs prove that shitconnection russians are pretty much on the same level with lag or without.


Plus QL has REALLY good netcode compared to other nonquake games.

ah come on. PK-netcode is DA SHIAT! ... trololololol

Hm, most of your concerns could be solved by rules for online tournaments. One thing QL does right is offer one big website to find servers. With pro accounts we can create servers pretty much everywhere. Yes some countries do not have servers I know that.

But killing all the anti-lag-hax stuff does not mean russians would have to play in the UK when facing UK players. There are servers closer to russia, further away from the UK too.

If all else fails a best of three can be played on 2 servers. Back in Q3 switching servers between maps (or just the initial server search) was terrible. In QL its damn easy.

TL;DR:

Don't make "fair" netcode. Select fair servers.

In ut04 years ago there was a setting with some pro-mode (don't ask me the name) where you could implement reconciliation or not.

well you're partially right.
If you look at the OSP-code the time at which you fire is basicly ignored everywhere in the server code (it's not completely ignored btw but it's mainly used for checks as to if the commands are legit).
That changed with CPMA and QL though. Who both use the time of actions to perform some 'tricks'.

So in OSP, the fact that timenudge changes the timestamp of the snapshot the client sends to the server is irrelevant, ultimately making TN a client-side-only feature? (besides of course influencing how the player plays)

Yes in OSP that is a fairly correct way to look at it.

In OSP the most important thing that it does is that (because the snapshot is shifted and therefor you skip a lot of interpolation of the opponents) you aim ahaid of where you would aim when tn = 0.

Let's take a ping 40 example with tn 0 in osp note that all 25's in the story are due to snapshot interpolation:

at time(X) you will see time(X-25) in order to hit the opponent you need to aim 1/2*your ping + 25ms infront of him = 45ms.

Then same situation on tn-20 would be:
at time(X) you will see time(X-25+20) in order to hit the opponent you need to aim 1/2*your ping + (25-20)ms infront of him = 25ms.

note that X-25+20 is the time that your packet will be marked with.

----
Both CPMA and QL use this value in order to do some sort of server side correction (at least QL does for sure and CPMA very probably also does something similar).

I remember discussion where people would testify about experiments where player A would turn tn on (-20) and as a consequence player B would see on his screen player A warping. At the time my reaction was "makes no sense, you are doing something wrong". Comment on that?

Well in OSP if you're on really low ping this could happen.
Because packets that have an illogical timestamp (read future) upon recieving by the server can end up being ignored.

Also packets which are less recent than the packet last recieved are ignored. (aka switching between multiple timenudges can make you warp).

Also note that all times in ql are resembled by integers (which repressent milliseconds). So time doesn't have to go in steps of 1 but rather it goes in "thinking steps" so time on your computer goes in steps of 8ms (on 120fps).

if you dont know for sure what cpma does, i seriously suggest you dont make unqualified assumptions about it. it will just take away from any point youre making. :)

"- No backward reconciliation, anti-lag, whatever. When the server receives a snaps from the player, it gets processed at that time. This way, the only thing that counts is your ping to the server, which is something mostly consistent, so you can learn to deal with it."

= You all know I love Q2, but this is one of the main reasons :D You basically predict based on your ping and you will learn it depending on your ping. All the 'anti-lag' crap ruins the feeling in general.

:)

but isn't in that regard q2's netcode similar to q3’s netcode? And if yes, then why u prefer ql over q3, since the later has the netcode u enjoy? :P

I mean q2 is very different to ql and is logical to prefer the one over the other, just based on that (they are different games). On the other hand, ql is essentially q3 with different netcode and as far as I know, u have pld much more ql than q3.

to conclude, I will skip what u say :P and only check the facts:

q2 != ql => not good for comparison
q3 = ql => good for comparison
ql > q3 (at least for u)

therefore, u like ql's netcode ;-DDDD

ps: I know u don't like it, but I also know that u love q2, because it is q2 and not particularly it's netcode... just messing with u.

ps2: honestly, what is ur usual ping when u play q2? Bacause if I had less than about 40, then I would probably prefer it too. After 40, no antilag becomes worse and worse.

I'm not comparing the games. I'm just giving the Q2's netcode as a example and also that this netcode is something I prefer after playing all quakes online for years. I'm not hating the QL netcode, but if there was a perfect world and I could chose 1x over the other? Then I prefer that the client and server behaves just like in Q2.

You can learn your ping and prediction and it does not really matter if you have 20 or 100 in ping. I've played a lot on American servers (in Q2 back in the day) with 120-150 ping and after a few games you will get used to it even without anti-lag, but you are not affected by other clients good or bad ping as you will always 'see' what is happening in 'real time' :)

On a side note as well, I don't necessary dislike the QL's netcode either, but I don't think it's as good as the old ones that don't predict lag. This is just personal preference and to be honest you can get used to all of them even if they are quite different.

I guess that q2 is great that way if you don't have a problem playing it with 120-150 ping.
I want to ask you this not to troll but because I want to know. I remember playing q3 with high ping and remember having issues with plasma as a very ping dependant weapon, even spiking my ping at times when for instance in a plasma/plasma fight. Is there a ping dependant weapon in Q2 that would guarantee a lost fight in a HPB vs LPB situation. Chaingun comes to mind, but I didn't play Q2 that much so I don't know.

I do agree that every system of ping I've played on requires some getting used to and that QL's netcode isn't perfect for getting consistent results. Sometimes the same ping feels quite differently in terms of latency and reaction time.

You will be at disadvantage with all weapons if you have a higher ping than your opponent. With this said, if you learn how to time the ping + weapon you can still aim very good. You can also with higher ping 'predict' that someone is coming out from a door or from a hiding place -> and before you see him, you can fire a rail, turn around and walk away and then the rail will come out after :)

However, you will have the same behavior on all clients no matter what ping they have. What you see is what you see and you basically need to predict the shots and the higher ping you have the more you need to predict.

Yeah in all cases it boils down to a guessing game, but guessing in situation described by you has more consistency. Unlike QL which plays a guessing game around every corner.
Thanks for clarifying the weapon question.

"This way, the only thing that counts is your ping to the server, which is something mostly consistent, so you can learn to deal with it".

That is so true that you deserve a +.

He was quoting me :<

the %^$^&*^#$*$.
Then I'll be forced to also + you ;)

Its easy to deal with it, when you have ping <20. Its difficult to deal with it when you have 80 against such a player. 60ms is a lot when e.g. it comes to reaction, like peaking around a corner n stuff

imo it's pretty easy at all pings as long as it's consistent.
I have np aiming 60ms infront of an opponent, sure it gets a bit harder but you get used to it and then it's fine.

I remeber days in OSP, I have played guys on swe server with 60 ms vs 20 ms, I lost like 20:5 all 10 maps. When we changed server to estonian, I had 35 ms and he had 30 ms, I won all 10 maps to 20:0.
This shows, how 30 ms ping different. In swe server I looked like a noob and with equal pings he looked like a noob. I am from 3rd wolrd country and I was used to high ping, but it didn't helped me, like purri said, to predict and shot. And I am not alone, I saw same storys like 10000 times...
With OSP netcode I would never won zotacs and never reached online finals. I remeber then we got swap btw OSP and CPMA , I started to own my idols/gods in Q3, and most of them were SWE guys with 20 ms....
F*CK THAT!

Was the osp netcode, in any way, inconsistent?

ur making assumptions about "fairness" and "competitiveness" as well as what realistic goals should be about these things when you play online.

seriously what's at stake online these days? nothing other than your ego for the most part. having gone to qcon and played on lan for the first time, i feel like closeness to lan feeling should be as big a goal as anything else. (in other words i think going back to an osp-ish netcode would be fucking crazy as "fair" as that could be in online competitions).

ps: didnt really read weirds post so my reply might be out of context. will update after reading.

This whole discussion is quite nerdy, so I understand my post look silly. Let me try to exemplify.

Your are battling an opponent whose rail is reloading. If he hits you you die, and potentially lose the match. I guess it's fair to say this is a common scenario.

Now the question is when you should stop dealing damage and take cover.

In what I called a fair system, this choice is purely dominated by your ping. Once you are used to the ping, you just know how much time it takes to take cover effectively (in the sense of really being behind the pillar according to the server). If your ping is high, you need to take cover early, dealing less damage. If it is low, you can stay a little more. That is your advantage in this context. In both cases though, things are consistent and one can perfect its timing.

With anti-lag systems, there is just no way to do things right. Against a high ping player, you need to take cover earlier, against low ping later is fine. every match is a different story.

Makes sense?

i understand your point. mine was simply that the problem with ql netcode is that some times the player with the higher ping has an advantage. this doesnt mean we have to go back to the situation where the player with the higher ping gets severly punished for it.

look at cpma. atleast with cpm gameplay u barely notice a difference between say 30 ping and 60 ping, something that makes a huge difference in ql. more importantly the minor advantage in that case goes to the 30 pinger instead of the 60 pinger.

im perfectly fine with the cpma netcode. im also kinda fine with the ql netcode although i think it could do with improvements. my response to all this rant is simple. if weird thinks he has a system thats MUCH better than any (ql, osp or cpma) he should write a q3 mod to do it, instead of keeping on trying to convince people by theoretical arguments. at some point you have to step up and actually do it. i seriously doubt he'd do better than cpma but hey its not impossible either. if he does it ill be the first to congratulate him.

ps: i STILL feel that its misleading to say that the high pinger has an advantage in ql netcode. yes u have to adjust your dodging if youre playing with someone with high ping. but overall the advantage imo still goes to the player with the lower ping.

pps: given above, an alternate and equally viable defintion of fairness would be to tell the lpb - hey u still have the advantage, yes the system is not perfect but u should be able to adapt to it fairly easy. its not perfect but its still better than going back to fucking osp with or without timenudge however u implement it.

The complete opposit is the case if the scenario switches from hiding behind a corner to peaking from a corner. The guy with a lower ping, sees you earlier and can hit you before you can even see him... seems fair.

A consistent and skill rewarding experience is at stake of course.

If you played tennis semi-professionally and a referee would count every match, but make false decisions all the time based on pure chance, you would most likely lose all interest to compete.
Now, make this referee a master at cheating the players, so that viewers will not spot his misjudging while experienced players will.

That is the QL experience for me in a nutshell. The better my internet connection got (in tennis terms, the better my hitting precision got) the more often and consistent I would see and feel the game cheating me, of the result, the fun, my competitiveness and ultimately my interest to invest time in something I have no control over and won't ever have unless I spend serious amounts of time to get so much better I would overpower any enemy no matter what. But then, all close games are still a gamble, like poker, the best player will win more, but will never be guranteed the win, which he'd rightfully deserve.

Timenudge simply 'releases' a packet sooner.

In quake3 (and ql) the latest snap is held until a new one comes along so it can extrapolate an intermediate position and smooth things out. This causes a delay.

With timenudge, you basically decrease the time a snap is held, to shorten/remove the delay from keeping the snap until the next one comes along, but in return, the interpolation will be off causing the well known stutter.

you should see that differently though.
You could imagine a "snapshot" as being "the last 3 frames" (on 120fps) "that the server saw" (which for the server = 1 frame... sv_fps 40 that 1 frame is 'build' over time though aka each command adds stuff to the frame).
Interpolating this would mean "rerunning what happened on the server"
TN-20 basically skips 2 frames from those 3 and then draws the next 2 frames extrapolating (guessing what will happen).
In osp there was no guessing for players -> players would warp.

So the difference between timenudge as I explained it (and how it works in at least baseq3 as far as I know) and ql timenudge is the extrapolation?

I don't see how timenudge would affect the server though, it's a client side thing to basically trick the renderer?

p.s.

Love this new esreality feature where the comment box appears under the post you are commenting on. :)

theres no difference between q3 and ql implementation of timenudge.
timenudge does however affect lookback in ql (which isn't in q3).

tn 'physically' puts you ahaid of (your local) time. Everything has to change according to this. So if you're 15 seconds into the game, with tn-20 you'll be 15.020 seconds into the game. So every action you do at this time should be handled by the server as if it is done on 15.02 rather than at 15.00.

You are arguing to use q3 netcode then :)
I also find it "consistant" and "fair" (only factor being ping, which can be constant when playing to servers in the same geographic area, so that you get used to it).

in a perfect world, everyone would have fiber to the home AND proper worked out (competitive) netcode.

laggers should be at a disadvantage, like they got glued to the floor if they lagged too much in quake 4 (yes, fuck u warpers)

tl;dr

You're just supplying us with a reason why almost everyone is a lagger in your eyes?

It's an interesting read, despite his motives or your assumptions.

Can you expand your proposal? I'm not sure I understand the server lookback.

well basicly the idea is that if you use autotimenudge the data on your own screen becomes less reliable (aka your pc does predicting for you at which it might pwn but it might be wrong).

The higher your ping the more problematic this will become. So people on ping 50-60 and higher will be less and less inclined to put autotimenudge to 1 (unless you bind a max to it which I wouldn't do).

Imo it would be a fair idea to then let the server allow a bit of backwards reconsilliation in order for the really high pings to 'not have to aim too far' off of the model.

Basically it's my intention to rather than having to aim 1/2*your ping infront of the enemy (OSP), to make it gradually fall off where the speed of decline is up to how high your autotimenudge is set to.

Example you have ping 60, autotimenudge 0.666 (so it tries to correct for 40ms) then the server calculates a value based upon the autotimenudge as to how far it would look back in time for the remaining 20ms which are not predicted. Perferibly (because this is a reasonable autotimenudge... which is semi difficult to play on) I'd say that he should only need to aim 8-10ms infront of the opponent.
So 60ping - 40ms autoTn -10ms lookback -> manually aim 10ms infront. Aka for the remaining 20ms the server solves 50%.

But on 60ping -20ms autotimenudge (so 0.3333) I would not set the server to solve 50% of the remaining 40ms, but much rather have it only solve 35%. So you'll be encouraging the use of fairly high autotimenudge.

Ofcourse the higher the ping goes the 'earlier' the server should help. (let's say that ping 100 and tn 0.5 -> 50% server side lag correction -> feels like OSP ping 25 (to fire).

So you could say that it's a way for the server to perform lookback based on how far your own client is guessing.

Oops sorry I messed up the above post what I mean is:

On ping 60 the delay to the server is only 30ms. so to 'solve' for 40ms delay you do tn -20, not tn-40.
so for ping 60 it would be:
30ms delay -20ms tn -0.5*10 = 5ms that you manually aim infront.
30ms delay -10ms tn -0.35*10 = 16.5ms manually aim infront.

ping 100 ->
50ms delay -25ms tn -0.5*25 = 12.5ms manually aim ahaid.

do note that this is only on agressive stuff right... the high ping guy's dodging is still a lot harder than that of the guy on ping 50.

It's too early for this, I'll try again later

it will always be too early for this

i knew who wrote the post before i read it
:edit: also dafuq did i just watch that shits deep

I'm too dumb to understand all this but is weird's post showing what can be easily improved upon the current netcode or highlighting the drawbacks that come with anti-lag? Because if it is the latter than weird has no chance considering most of ql population prefer with anti-lag than without.

both.
In order to show how it should be improved I first go through how the different netcodes work (which I do neutral but you can see what imo the drawbacks are on anti-lag).

"neutral" ... hah nice try

I don't give any opinions in the main post m8. Just show how the implementation work.
You can't be more neutral than that.

TBH, your graphics make no sense to me.

The main difficulty probably is that time and space are being bundled together. That's ok though because he's assuming that players are moving at constant speed along parallel lines.

So those player lines represent both, points in time and points in space. While the server line obviously just designates time.

I think the only solution for a proper visualization is to create small animations, which is far more of an effort than simply using paint/photoshop.

Not sure. As I keep looking at it it's starting to make sense. Just needs a little additional thinking, about what's wall clock time (e.g. packet travel times according to ping) and what's client/server game times.

I'm getting this much right now:
- OSP: aim ahead according to ping
- OSP + TN: aim ahead according to ping minus tn (possibly leads to buffering of hits, freezes)
- QL: aim at model up to those pings, because server's checking back according to ping (what's tn then doing QL?)

Still looking at the other scenarios, and if these comparisons are actually proving a point at all. I mean, with QL and high pings the statement is that "reconciliation" stops working at some point, but what then? Is QL falling back to OSP model?

Also, the description of yellow bar is odd. Being the same, what I'm seeing on screen and time stamp set on outgoing packet? I thought in OSP+TN, yellow bar is what I'm seeing and yellow bar minus tn is the time stamp set on the (action) packet. I mean, I have to "see ahead" for tn to have any effect, don't I ...

I think one can decipher the images, but it requires some effort, so many readers may not get the meaning. I did a very similar post many years ago in a different forum and I dealt with the same frustration of people thinking I was quite a weirdo.

_Weird_ does not share these frustrations.

to answer some points

In QL timenudge reduces the need for the 'checking back' and *should* be advantageous for your opponent. The reason why many pro's use it is because of one of 2 reasons.
1) they are stupid. ( I won't point out names ;P)
2) they they to get the opponent to completely missjudge time because the lg is hitting closer than rails are.

Reconciliation has a max everything above that max *should* be handled like osp. Aka if it works up till ping 65 ping 80 will feel like 80 - 65 = osp ping 15.

Yellow bar is both what you see and the timestamp on the packet. The main advantage of tn (why it has effect) is because you don't have to wait as long for the events contained within the snapshot to de drawn. Aka in my examples you can see that the hitbeep will suddenly play upon recieving the packet while without tn you still have to wait for it.
Also the rail gets drawn immediately (at the nmy) rather than after xx ms.

Thanks for the clarification. Still not quite getting OSP timenudge though.

You're saying above in your post that the outgoing packet timestamps are skewed by tn. The only way that'd make sense to me is if tn affected snapshot interpolation. Because else the client would be sending "fake" times.

So lets say client's interpolating two snapshots from time t and t+x. Linear interpolation would normally give me a world view at t+x/2. The interpolation could be shifted though by some amount tn to t+x/2+tn, up to the point where interpolation stops (tn=x/2) and only the latest snapshot is taken.

Is that how you're suggesting it works?

hmmm, I'm not entirely following your calculation there.
What happens is that your computer interpolates between the before last and last recieved snapshot.
Which depend on the sv_fps command so in ql it's 25ms.
Within 25ms your pc should draw 3 interpolated images (on 120fps).

These 3 images are all linearly interpolated. Aka you linearly interpolate at time T1+8, T1+16 and T1+24 (although it shifts a bit etc. as 25 isn't divisable by 8).
To further this example say that played 2 is at possition X in the before last snapshot and at X+9 in the latest. You'll see him near possitions X+3, X+6 and X+9 without tn.

your idea about what tn does is pretty accurate as it will skew time forward so that at tn-20 you'll linearly interpolate 1 image which is at T1+20 and the following images will be, extrapolated images, at time T1+28 and T1+36.
So again in our example you'd see him get drawn near X+8, X+11 and X+14 (with extrapolation). (without extrapolation (osp) you'll see him at X+8, X+9, X+9).

I hope that clears stuff up for you.

It should be noted that there's absolutely no 120 fps in QL.

Can use 100, 111, 125.

The cg_drawFPS display is obfuscated due to being capped at the value of com_maxFPS.

Can be verified with Fraps.

I was thinking that at 125 fps there's 3.125 frames being drawn in that 25 ms time frame between snap shots at sv_fps 40. So perhaps a timenudge of -1, -9, and -17 might be more consistent as it deals with whole frames. Probably this is just naive.

every time I think I learned something about quake it just gets refuted by the next poster

I'll ask you the same thing I asked weird a week ago. In LAN servers will using sv_fps 120 make the game ...better? Another value that's not 40 (125, 60, etc.) or other server commands?

Increasing sv_fps will make the game feel more responsive, although on LAN the effect will be much more subtle than online. Personally I'd hate for there to be a difference between sv_fps for online servers and on lan servers, something about that bothers me greatly.

Online the increase in responsiveness would be very noticeable, but it would tax the server's bandwidth much more.

What you'd see on lan is that the average accuracies would increase.

If you're asking about the desync'ing between sv_fps and com_maxfps/maxpackets I think it would be better if they were sync'd up yes. It is bound to reduce latency and improve the feel of the game. Whether this improvement is substantial or negligible, I have no way of testing.

So hmm, if there is 25 ms between snapshots due to sv_fps 40, and the game is running at 125 frames/sec, that's 3.125 frames shown between snaps, so there is a short delay and small desynchronization happening.

We don't the 3 frames being shown at the very beginning of the snapshot again for 7 iterations (1st and the 8th).

I have to entertain the distinct possibility that the effect is negligible though, even though I would really like it to all sync up.

I cba if it runs on 120fps or 125....

Your last part doesn't make any sense though that -1, -9 and -17 would make more sense....
Snapshots are sequential and time is linear so your idea would maybe make sense on the 1st 2 snapshots but as soon as you go further you're off by a few ms again. 3rd snap you're off by 1ms, 4th by 2ms etc.

Indeed, it would be off.

That sucks! I wish it were all sync'd up.

well q3 actually has code in place such that it stays close... but it's like "if I'm not on there now do value+=2" ;)
I shouldn't give details about this drunk though so if you want to know more just msg me and I'll prolly answer within the next 2 days ;)

Then resend that to me :D

why not read the code?
cl.serverTimeDelta -= 2.... it's around there ;)

okay :D
I'll be sure to pester about it if I don't understand something.

Why is this necessary though? Why not just snaps/fps/packets/nudge all divide evenly and live together as one big happy family of integers? :-)

because you're dealing with asynchronous systems which you try to synchronize but due to the nature of the problem... you can't ;)

Elaborate :-)

you want to have 3 instances of the game running simultaneously but due to connection, hardware and settings differences you can't.
Where tn is an attempt to somewhat reduce the connection factor, the time delta is more an attempt to reduce hardware and setting differences.

Seems like there's a simple problem with integers.

Like, 1000/x {x set Z}.

x = {1, 2, 4, 5, 8, 10, 20, 25, 40, 50, 100, 125, 200, 250, 500, 1000}

At the range of values desired for server fps, and the range of values desired for client framerate there are very few cases where both numbers are integers and divide evenly with each other.

We'd hate to go back down to sv_fps 25, but it would line up with 125 fps/maxpackets.

We might be able to swing sv_fps 50, and 100 or 200 fps.

How about sv_fps 40 and 200 fps, that could work.

Yeah, that's what my line of thinking was, without ever having looked too closely at those details.

In the meantime, I've glanced over Fabien's q3 source code review http://fabiensanglard.net/quake3/index.php and the "Unlagged" docs http://www.ra.is/unlagged/ which clarify quite a bit, even if we don't really know what of this is still applying to ql in the exact same way.

The one point I was still wondering about is what entities are subject to extrapolation, under which circumstances and to which amount. Rockets, plasma balls etc is ok obviously, since the trajectory is known. But player movement extrapolation of course introduces prediction errors.

You're saying that tn 20 just replaces the interpolated screens at T1+8/T1+16/T1+24 with one interpolated screen at T1+20 and two extrapolated screens at T1+28/T1+36. Where I was thinking that one could just shorten the interpolation interval towards the late end, but that would of course lead to jumpiness. So for the sake of fluidity, and given that prediction/extrapolation would be right in most cases, extrapolation apparently is the right thing to do.

Messy stuff. I'm amazed it's working at all ... :)


Edit: while at it, another question is if server side backward reconciliation is taking account of client side tn, to the extent of applying the same extrapolation (i.e. "forward reconciliation"). If so, tn should definitely be considered a cheaty thing imo.

as for which entities get extrapolated. In Q3-osp just projectile weapons (not players). In cpma everything. In ql also everything but they also added different types of extrapolation (I think) aka projectileNudge. So I'm not entirely sure how which variable alters the extrapolation but it is possible to extrapolate everything.


On your edit, that's why they removed positive timenudge after me whining how stupid it was. Negative timenudge only reduces the backward reconciliation.

You still failed hard at lan lolol your point is invalid. Cypher plays with 100+ ping and still rapes online and you play with like 20 and lose.

So because hes not as good as one of the best players in the world, he has no possibility of helping ql netcode?

u dumb

There's nothing to help it's obviously fine when players with both less and more ping beat him not to mention his dire performance @ lan where he claimed he could beat cooller etc.

So no you're the dumb one.

http://www.youtube.com/watch?v=1KwlRKg-WgU

Me trying to understand *if* netcode can be improved is dumb, but you surrending to conformism must be rulez, yea right.

Yeah, memento mori isn't a good dueler so why the fuck is he making spawn visualization?
Let cypher do it, he's so much better at predicting spawns.

dur hur dur derp that's all I got Anhedonique, God your name is as ridiculous as your comments.

Says the guys named nicholas

Sorry Anhedonique rofl

The internet needs troll kids like you so other points seem more valid, keep up the good work!

Dutch

I think I already win this argument.

What exactly does this have to do with "netcode" ?

The problem is the antilag(PREDICTION) that the server is doing.
Your anomolys come from the client doing its prediction aswell.
Making things look wonky and feel bad.


Now your suggesting adding more prediction into the mix by pretty much making it "dynamic"?.


What exactly would change?
The shots will still be hitting exactly the same, the only difference is the sound timing.

So what exactly would change?

How does this make "netcode" better?

And why would people waste their time implementing this when it makes no sense?

if you can explain to me what the server PREDICTS in antilag I'll go and leave the thread all up to you.

doing lookbacks to where shot was fired and where the receiving client was standing is prediction ffs.
That is why its called SERVER SIDE PREDICTION.

netcode handles packets and how they are sent/recieved. Prediction has nothing to do with handling said packets.

Thus you calling it netcode to begin with and complaining about people being oblivious is just stupid.


The fact that you recently have even been saying that vq3/osp prediction is better then what ql has right now is laughable considering you where whining just as much back then as you are now.

In my opinion your grasping at straws trying to justify yourself.
In truth i cant even blame you for that, but too say with 100% certainty you have solved the "puzzle" is shallow and egotistical to say the least. Your not even taking bugs and drawbacks into consideration and just presenting what it would possibly fix.


Like i said before, if it is that simple as you say it is present your proof of concept and stop pestering people with your self biased opinions.

Need I remind you that:
"A prediction or forecast is a statement about the way things will happen in the future"

So what you're saying is that: Both players keep me updated on where they are. Whenever I recieve an update of where they are I put it in my memory...
Whenever you fire. Upon recieving that information I look BACK to where he WAS in my memory 1/2 of YOUR ping ago. ==> PREDICTION!

In essence yes, why are you taking the word prediction literally?
It has been called prediction since several years back, why are you all of a sudden opting to change that now for the word netcode, which is allready used in other terms of the engine?

Why arent you even factoring client side movement into the equation?
You do realise that most of the bugs are caused by the conflicting nature of server side prediction and the client predicting movement?

Adding in the possibility to change variables on how this is handled makes things worse. Your solution of having the client/server handle the tn issue wont fix anything as said bugs still happen even if most of the conditions are "right".

And dont you blame things on other factors all the time?
Am i wrong?
Arent you very self biased in terms of this?


Dont take it the wrong way, its nothing personal against you.
Im just trying to get people to realise that you constantly skew information when it suits you. Filtering out factors and have a habit of blaming others.

Should i keep repeating myself?

For the sake of argument, lets call the prediction
"server side hit detecton"(which its also known as..)

What exactly would your change fix and how would it effect negatively.
Cause negative effects will allways be there when handling things between clients with different latencies.


The way i see its just a superficial addition and doesnt fix anything.

Troll: Not sure you understand how the engine work.

And as said there is nothing like prediction or whatever.
For vq3: client issue a request (fire) and the server executes it when he receives the packet against its view of the game world at this moment. No miss or prediction or whatever (client and server) possible.

Now when making INTERPOLATIONS of the PAST between two saved snapshots, it is called backward (re)conciliation. No sign of prediction from the server.

And when talking about netcode it obviously is not about the "socket" and packet handling but about how to handle the game informations they contain.

Just so that every one talks the same language...

Sounds like a oversimplification though. Client and server state might briefly diverge, for example. Which I'm guessing would be called client side movement or hit prediction, depending on which kind of state is (visibly and/or audibly) affected.

And the server game world backlog might contain more than just two snapshots, to any of which at least instant hit weapon shots like rail could be applied. Isn't that after all what timenudge is about?

Which model are you referring to ?
For vq3, the rule is quite simple, what you see is what the server calculated and sent to you, EXCEPT your own movements (otherwise the feeling is horrible as every move you perform is lagged) and the time at which you want to display (dynamic) entities on the map via timenudge which is a client side only parameter, the server has absolutely no informations this value.

For backward recon, the server has a stack of "old" snapshots (something like 64). The client sends a request, "I fired *here* at a given *time*". The server will then look in its stack for the 2 closest snapshots to *time* and then (linearly) interpolate them to obtain precise player positions at *time*. Then it starts to check if the client could have hit something when firing from *here* at *time* in the world reconstituted from its archives.

None in particular. Any half way recent quake client will normally render stuff faster than it's receiving world updates from the server (just calculate the ping you need for 60Hz screen updates, packet loss not included). And I'd be surprised if that "predictive" rendering consistently just included pov player movement. Sound cues understood to be part of "rendering" in this context.

And if timenudge was client side only, opponents would not notice the effect. Is that what you're saying?

I don't know precisely about QL netcode (no sources available)

From q3 sources, you can see that timenudge is purely clientside and other players shouldn't notice any effects from other players value.

For the client rendering part, your engine will take the two latest snapshots from the server and interpolate positions between them so that you can have fluid animations on your screen but keep in mind that these are informations from the past. It is not predicting anything but your pov against this interpolated past.

Might timenudge be too low, you won't have enough snapshots to interpolate between them (the 2nd one being too old for treatment), but just the last one that is just displayed "as is" (giving the ugly lagging sensation).

What the engine could actually do then is to extrapolate other players positions from this last snapshot to make it more fluid. But then you can have mismatches between what is displayed client side and what the server calculated.

That's an excellent observation to make. That, where sources are closed (OSP,CPM,QL), actual facts are hard to come by with. Indeed, when hearing people talk about "netcode" I'm almost constantly under the impression that what they're talking is a mixture of hearsay and speculation.

Moreover, even where sources are open, I'm pretty confident that only the very fewest people would actually look at it thoroughly. And of those only a few understand what's really going on.

That said, much of the prediction we've talked about relates to user input processing I'd say, cause the game needs to feel responsive. And I'm doubting that pov model movement would be all that's affected. Without having much cared about this stuff recently myself, I'd very strongly suspect that you're seeing a rail beam before the action has traveled through the server. Item pickups and corresponding sound cues might quite likely be affected too.

In fact, I seem to recall some discussions back from Q4 times about the actual rail hit beep being predicted client side, possibly giving false positives. That's apparently how far as it can go.

Regarding timenudge, I'm quite regularly hearing ppl complain how their game was negatively affected when opponents are using it. strenx/cypher would be a typical coupling. So if there's anything to those complaints, i.e. if they're not just "whine", it can't be just client side, can it ...

I'm confident for what I said when talking about vq3 (and OSP as the author stated he didn't touch the "netcode" parts) for the rest of course as there are no sources available it might all be psychological :)

to be fair i was trolling a bit while still getting my points across.

There is prediction in Q3. It happens in the client.

semi related ramblings :)

This is kind of a tricky subject/thought experiment because most games obviously have speed, accelerate and decelerate values as well. But hypothetically if clientside was taken out of the equation would that lead to a mooshy/uncontrolled feeling? And aim would just feel like shit -- im guessing you would need aim ahead?. Unless you did have crazy low ping, but even then blehhh.

eg. You would stop moving on your client but the server hasn't decided yet that you've stopped moving, so on your client your still moving. Just to note I don't think any games with decent netcode* do this lol, it's just a fun thought experiment and probably an obstacle engineers/programmers have thought about .



So like most people say, LAN isn't online so the only practical real fixes that I can see are with client and server based feedback. So I like weirds sound idea in one of his many threads about this topic, it was like cg_predictHitbeeps or something I could be remembering wrong though :)

Netcode will never be perfect in any game and quake's netcode for the most part is probably one of the best out there so I don't really have any problems with it(as long as I visually shoot their model and I hit them most of the time im happy). But if I were to complain my issues with the netcode would be through-rails and how people can manipulate how they appear on peoples screen. eg skipping. So limiting silly and broad settings would be my hopes. But I guess this can't be truly fixed completely because people can just manipulate their own connections with programs but limiting the effects is ideal. :)

I would make each client choose if
1) they want to aim ahaid of an interpolated / slightly extrapolated (=predicted) opponent.
2) they want to have their pc predict where the opponent will be such that they can point and click.
3) set the variable for any mode in between 1 and 2.

Negative aspects are obviously that
1) you aim infront of the nmy = less awesome aim.
2) the model will appear to warp whenever prediction fails.
3) any mode in between (but you can decide on the tradeoff which you like)

lot of points lemme do them 1 by 1.

1) antilag / backwards reconsilliation / lookback / unlagged has, as far as I know, never been called prediction. (There are a few types of 'unlagged' that have had some form of prediction in them though).

2) I do factor this in myself but I couldn't figure out a way to put it in the image. As I note within remark nr2.
Also this does not lead to any bugs which you could otherwise avoid (without at using cg_nopredict 1 (which is too horrible to play with)). The only thing this really leads to is that when you get hit by a rocket your model (on your screen) will be warped towards the correct location.
If you want any type of responsive game you are forced to let the local client be the leading factor in registering your own movements.
Next to that the images are already quite hard to understand at the moment... if I keep adding everything in it'll be really messed up :).

3) No because the variables I propose cannot affect how the opponent sees your shots. Aka you control your yellow line (and therefor what you locally see) using the commands but you always have to aim at a forced blue line (which is 'more or less controlled by the server').

4) What am I blaming?
5) yes.
6) no.

7) good to know.
8) what is skewed about my images which I don't mention in the post?

i still dont see how your solutiong would fix anything.
From what ive gathered your biggest gripe is warps,lags, shots not hitting etc.
How would this fix any of that?
How would this even work when it comes to packetloss, corrupted packets and generally bad internet connections/conditions.

3) "1) they want to aim ahaid of an interpolated / slightly extrapolated (=predicted) opponent." why even have antilag for this just to have it at a fixed point isnt that a bit overkill?

"3) set the variable for any mode in between 1 and 2."
Wouldnt this open up for shooting people behind walls btw, for you to have to aim ahead of an opponent wouldnt that factor in that your firing at something that isnt even visible on your "screen"(model behind wall)? this is an extreme example ofc as the "delay" would most of the time be miniscule, unless your aiming for the osp/vq3 self latency compensation style (truelightning esque).

Now thinking of it, would this even be feasible without client side hit detection? I mean i get your point with having the client predict the hits and providing feedback. but im pretty sure this would produce false hits as its pretty much guessing and cant take things like packetloss and "jitter" into consideraton.

Also wouldnt the antilag code need a complete rewrite to handle several different states for each client to allow the different styles?
i mean, adding your thing only with aiming ahead wouldnt be that hard. but having several different versions for each client is a bit tricky as the client just doesnt handle that at all atm and the server doesnt support it.

All in all, this just seems to be about preference and not really a solution to anything, things would still be the same.

if you want me to try and clarify anything just ask, its late and im sleep deprived as f**k.


4 & 5) so your basically saying im wrong that you whine alot
when you loose, blame the netcode for alot of your losses and quite honestly have a "i know more then you do" attitude?
Youve been doing this for years so its kinda hard to deny dont you think. Also my reasoning for saying that your opinions on this are skewed are because of the above things. If your thing would be implemented and your still effected by whatever effects you ingame and you still whine,complain,blame other factors... What would the next avenue be for you?
Im honestly curious about this, as you have been putting down alot of thought into this, this is your "holy grail" of netcode and a hopeful view of you continuing playing quake in a more "fair" way.

all im saying is, what if your wrong?..

from what you've gathered my biggest gripe is warps, lags, shots not hitting.... no it's not.
One of the points does touch upon what I really hate though. I hate it that in QL if you warp you have an advantage because netcode will correct for your warp but it will show the warp to the opponent np.

I would like antilag to gradually come in and ease the negative effects that very high ping players will experience. Obviously this will somewhat negatively effect the opponent of a high ping player (aka QL style). It is basically there make the game playable for people on ping 50 - 80 and make the experience of responsiveness gradually build off.
For instance atm in QL I can't do shit on ping 75 - 90 but I play fine on 110+. This is imo because the falloff in how it feels is too strange. Ping 75 feels like a world of difference to ping 55.

Changing the settings I proposed won't open up being hit behind walls. You will get pre-fire where you think the nmy will go if you choose to go for that.

No you ALWAYS want to have a "real game" happening somewhere which is consistent in how time flows. This job is up to the server. And QL doesn't work like this = why the netcode (imo) fails.
If you don't want false hits then turn off the predicted hitbeep.


4&5 first line first part: Hmmmm... I get somewhat annoyed when I feel like I have to change how I play due to the ping my opponent is on. This just rubs me the wrong way, so badly, that I refuse to change my game according to that. When I loose as a result of that or am heavily punished for having that attitute I feel like it's unfair to me. And my nmy should know about it ;)
2nd part of the 1st line: But I do know more than you. At least on this subject.
Why would I whine if the game was fair? I am advocating this stuff because imo it is unfair that I get, in any way, punished for my opponent having a crappy connection. At least he should be much more affected by his ping than me.

I put some thought in this because I want it changed, so at least I should know what I'm talking about as just saying "It feels like crap" isn't any good fundation to change it.

And I could come up with much more elegant ways to solve the netcoding problems. Like if you'd change movement and make it more similar to car racing (aka you accelerate rather slow at the start and decelerate fairly slow as well) you can make stuff always look fluent and have a much more elegant solution.

To answer your last question: I'm not.

Im reading thru your post and answering them one by one

till i come to

"To answer your last question: I'm not."
And i proceed to delete everything.

You have allready proven your theory?
Great, ill get an ftp up for you so you can upload a build so esreality can try it out and judge by themselves.

I mean why write answers when you have allready proven your not wrong. All you need to do is show us the results and let the work do the talking for you........

if you pay me enough I'll build it.
We're not all 15 year old kids who can do whatever they want whenever they want.

and yet you wrote some stupid netcode comparison

writing this didn't take me more than an hour... fixing / testing would take a week up till a month or so. Kinda semi difficult to say because testing stuff could show that the code breaks something which 'I would assume to be' unrelated to the problem. (computer programming works like that ;p)

800€ for a months work to get the product working.
This means, your netcode/ beep prediction fuctioning as intended.
Payment will be transfered when the product is finished.

1) my engine of choosing
2) code must be well commented.
3) Everything will be released within GPL license.

"We're not all 15 year old kids who can do whatever they want whenever they want."
This line makes no sense whatsoever, so post 15years your freewill and overall freedom magically dissapears?

I mean i work a fulltime job aswell as taking extra hours whenever i can.
Still doesnt stop me from having various projects aswell as a social life.
Just drink more coffee and stop whining allready.

Sorry, but no. Prediction is a client side thing. What you are refering to is called backwards reconciliation.

A bit late to the party jalisko.

fail.

just gimme the essence of all this crazy shit in one simple sentence which states a is better than b and c and would be even better if..

the essence of it is that his subjective preference with regards to net code is the correct one and he's actually way better than people who beat him, its just the net code messing him up. this can be proven using confirmation bias by looking through demos of LAN versus online play.

haha nice one but I don't actually give my opinion anywhere in the post and I try to show how it works as objective as possible.

Also whoever beats me is better than me at the game they beat me in. Just that often in QL it's not quake they beat me in.

Yeah I'm just fuckin with ya. I think any set up is going to be a compromise between aiming/dodging and where to draw the line is a matter of preference.

btw how possible would it be to mod your proposal into q3? why dont you try it and see how it feels

osp is best for dodging.
ql is best for aiming.

If the compromise has to be in the middle... then maybe you know why I dislike the ql netcode.

Weird, what's your opinion of CPMA's netcode compared to QL's?

I have personally always preferred CPMA's netcode as it's far more high-ping friendly (especially with hit-scan weapons) yet still feels much more consistent. It also doesn't give warper's an advantage like it does in QL...

Obviously VQ3 game play in CPMA was far too hit-scan heavy but I always thought that could have been fixed relatively easily by adjusting the hitbox sizes/weapon damage.

Personally, I still prefer VQ3's gameplay over QL's because in QL the weapons are nerfed far too much and as a result the gameplay has become so painfully slow and favoring passive,safe play with not enough risk taking reward, but that's a whole different subject.

Exactly, CPMA/vq3 netcode had a great feeling and overall pace of the game was higher compared to QL in my eyes. The biggest problem was overpowered LG, but that could be easily fixed by changing from 8-8-8 to 7-7-7 for example (personaly I liked 8-unit). There are a lot more things a liked more compared tu QL, but yeah this is for another thread.

well I like the xerp.

But hmmm theres something which feels somewhat off in CPMA but since they haven't released their code I dunno exactly what it is.

I've discussed it with some other people who told me that there are 2 forces in CPMA which both do somewhat opposite things. But they also didn't know stuff in full detail etc. Or they didn't want to tell me about it ;)

Also there was really too large of a difference between playing people on laghax + xerp than playing those who didn't (kinda like how QL feels different vs different opponents.)

you are essentially saying you have no clue about cpma netcode. thx for clarifying.

afaik the only problem people have had with cpma netcode is xerp 1 (which afaik isnt even a cpma feature). im sure someone like reptile would give more info but the summary as i understand it is that with xerp 1 lg feels like it hits way too much as opposed to lan. as ive never played cpma on lan i cant comment either way. i can only GUESS that this is something similar to ql timenudge online and ql on lan, although i would guess the difference is not nearly as bad in cpma as it is in ql.

btw just to clarify, you're totally wrong in assuming that theres a huge difference between people using xerp and those who dont. i know top cpm players who dont use xerp. and their aim is just fine. pls dont pull shit out of ur ass.

Well wonko I didn't say that it's extremely hard to aim with xerp off... just saying that the difference between on and off is really large.
It's like you have to have a different style of aim or smth... at least I somewhat struggled in cpma with this untill I got my settings right (for me).


Another thing is that there are combinations of settings in cpma which fail.... which is smth I don't want to glorify.
if you put laghax off and xerp on stuff really doesn't make sense (it could be laghax on and xerp off, it's been a while since I played it :p) hitboxes will start to feel like they are floating around in paths behind the opponent.

Also I wouldn't say that I have no clue about cpma netcode... just not as much as I'd like. All knowledge from cpma netcode comes from how it played + comments made by arQon about it.

its not hard to figure out what settings work for you in cpma. and out of all the forms of quake ive played, cpma comes closest to emulating lan without introducing bs like unlagged does. its as simple as that. how many times have u heard people saying high ping gives u an advantage in cpma? pretty much the only complaint you hear is that xerp 1 doesnt feel as sharp as lan and it gives you higher accuracies than lan. it still doesnt aim for you so a better aimer will hit more than you. thats about as good as it gets imo.

half of the combinations of settings don't work well in cpma man. Like add tn to xerp and the shit hits the fan. Put laghax off and xerp on and it's completely random.
On some settings you even have to aim behind the enemy model... I'm have pretty solid ideas as to why this occurs but again due to lack of source code I can't be sure ;) (I assume it's that cpma smooths out the difference in prediction over 25ms rather than 0ms in osp (0ms is actually somewhere around 8 due to rendering and 25ms is more around 30)

But you're doing something really strange here. You are arguing with points I make without actually disagreeing. You seem to think that I hate cpma netcode or smth. I really don't and I would prefer cpma netcode over ql's netcode any time.
I just propose something which is slightly different (at least as far as I know it is different).

When you say put laghax off and xerp on do you mean with timenudge enabled? Cause I've played with laghax0 xerp1 nudge0 and there's absolutely nothing random about that combination.

hmmm I don't remember my exact settings but I'm pretty confident I had tn off. As back then I thought like most others (tn is banned on lan let's not use it online).

Well cl_timenudge wasn't designed to work smoothly in CPMA, thats why they added cg_nudge to CPMA, which was designed to aid people with over 100 ping. In fact I remember playing some 4v4 TDM in CPMA on an israeli server with a some NA players and even one dude Japan(forgot his nick, was a well known cpmpickup player). They all had way over 300 ping but it was still playable and we all had a lot of fun, one of the NA players actually had the highest NET.

Some info I found online about CPMA's netcode in case you're intrested:

1: g_lagHax is now the core variable for controlling netcode timeframe adjustments, and it's pretty much a souped up, modern interpretation of arQ's old 50ms code that made cpm so famous from a technical view point ages ago. It provides the functionality most of you will have sort after with cl_timenudge; that is, it adjusts the display of entities within the gameworld in a manner that attempts to make it appear as tho you were playing in a 0 latency environment. It doesn't 'remove' ping, it doesn't allow you to shoot round corners if you're hpb, (like certain other games Tongue) or use the client to predict player's future movements beyond your ping, (like cl_timenudge with slpb's) but it does make for a much more responsive, enjoyable gaming experience. It functions normally up to a limit of 100ms, and adjusts automatically to ping spikes and fluctuations in latency.

2:cg_nudge. This variable is used to 'pad out' cg_lagHax when you need to play on servers that you ping higher than 100ms to. It is not adaptive in the way that cg_lagHax is, and isn't as accurate. However, it is still better in a lot of cases than trying to guess your lead time yourself. On a server you ping lower than 100ms to, cg_nudge should be set to 0 (default) and for those over 100ms, it should be set to -(your stable ping to server - 100ms). Note the negative sign.

3:cg_xerpclients. With the use of cg_nudge comes some difficulties with 'filling in' the gaps between the information your client receives about the gameworld in packets of network information, and as a result things don't update in the smooth way you will be used to. cg_xerpclients is provided to allow you to manually choose a method that best suits you when playing. On a server you ping lower than 100ms to, where you do not need to use cg_nudge, cg_xerpclients should be set to 0 (default) On servers over 100ms, there is functionality you can try by setting cg_xerpclients to -1 or 1. -1 is more appropriate, but both settings produce noticeable errors, and can result in players briefly sinking into walls and such. It should be used as a trade off between ease of viewing enemy players, (-1) and accuracy of position, (0).

Link: http://forum.drc.su/cpma-net-settings-explained-vt3719.html

osp has client side movement and no client nor server side hit prediction.

Making it easier to dodge things as there is a clear delay on shots.
ql has both movement and hit prediction that suits best for both high ping and low ping gameplay as the low ping conditions make the prediction void.


There is no middle ground as you would have to sacrifice one or the other to get your desired effect.


If you want too feel something completely undiluted by prediction code, take a whack at playing original netquake, its painful even on "good" conditions (20-30ms)

Im seriously curious over how a ggpo solution would work. upping pings till they are even and then taking care of the prediction from there.

Why don't you just give us the math? I mean, apparently you've looked at the code, so you're likely knowing what time attributes are involved and just need to give us the equations relating them together. Would likely be much easier to comprehend ...

I drew this stuff to make the concept clear of what is happening because people don't understand the math.

@weltschmerz do you found it on site 2? sry but to do a second site was the best solution.

I have no problem aiming be it in q3osp/cpma or ql.

Never understood the constant whining of some people about that. Agreed netcode issues have to be adressed and discussed but blaming the game for your inability to properly aim is just wrong.

where in this post do I do that?

do what ?

Blaming the netcode for his accuracy (or lack thereof). I can't find it too.

in this post... Fair enough :)

And I aint even naming him specifically

no but "your" in a reply to a post of mine would give a hint. ;)

"your" ? :xxxx

blaming the game for your inability to properly aim

way to take it out of context. perhaps you should read that again and put your megalomania aside while u do it.

With all of my knowledge of the english language (which I confess is far from perfect) I am unable to find anyone "your" would refer to except for myself. (seeing as it is a reply to me)
The only other notice of human beings in his post is "some people" which has to be referred to with "their inabilties" not "your inability".

Correct me if I'm wrong :)

in the previous sentence he refers to people who whine about netcode. the "your" refers to those people.

its quite possible that the "some people" is his way of talking about you but the sentences themselves don't necessarily have to mean that way.

you didn't actually read my post did you?
Your: "(a form of the possessive case of you used as an attributive adjective): Your jacket is in that closet. I like your idea. Compare yours."

Their: "a form of the possessive case of they used as an attributive adjective, before a noun: their home; their rights as citizens; their departure for Rome."

I still don't see how you would refer to "some people" using "your".

trust me people do it all the time. those definitions dont say anything btw. it only means that hes using the word to refer to people that are reading the thread.

right the definitions of a dictionairy should not be used to convey information... gotcha. Epic educational flaw on my side....

You're argueing about someone who has english for his first language that he's wrong about english also that you took it personal doesn't mean it was directed at you, I don't even know if I'd want a better netcode I'm an aim player and every update quake made to make aiming easier for everyone the game has gotten harder for me because everyone who used to aim poorly became around my level of aim just because of bigger hitboxes and other doings, so EVEN better netcode won't that just make it even easier? Wouldn't people like silencep be hitting 70% rail and won't people like strenx be hitting 50% LG?

Overall aiming will should harder. Although the cg_predictHitbeep would be really usefull for LG heavy players.
Also (imo) the overall game experience should become better which *might* then increase stats on a wide scale.

"The Americans are identical to the British in all respects except, of course, language."
- Oscar Wilde

"We (the British and Americans) are two countries separated by a common language."
- George Bernard Shaw

im not american. or british. :)

altho for all practical purposes english is my first language. i know english better than my mother tongue. which is quite sad.

actually no. the definitions just state that your is the possessive form of you and their is the possessive form of them. the context determines which one is "right".

you assumed that hes speaking directly to you in which case the "your" would refer to you. im just saying that the second person term simply refers to the "some people" he mentioned in the previous sentence.

so let's just agree that he should've used 'their' and it's np ;)

But using "your" in this context is common in everyday speech D:

theres english and australian... you don't want to go into this discussion ;)

When you're Australian your english is very similar to English.

apparently not

He's right and you're wrong. w0nk0's comment above couldn't have explained it much clearer.

rofl. Even w0nk0's explaination (which I don't fully agree with) has in it that I assume that he's talking to me personally. If dem0n used "their" I could not make that (correct) assumption.

I would seriously consider buying or at least reading a dictionairy for a change. The use of "your" as described, by others above, is actually in there... it's right behind "their:". It's similar in this situation to the use of "one's" like kg said.

http://en.wikipedia.org/wiki/Anaphoric_refere..._reference

obviously here "knowledge of its context." is a double edged sword. Because it implies the context... which is: He REPLY's to my main post refering to "your" while there are only "some people" in the line before that. Obviously anyone with a logical brain would assume that your then refers to the writer of the origional post.

It's called an anaphoric reference. Now stfu.

omfg I know a term! And even though it shows that you are right... I will use it in a situation such that it seems like you are wrong... but, as a backup plan, I will tell him to stfu when he tells me this!

100% succes.

you're a smart man teioh... I can see why you took such a hard subject to study as the english language.

I'm proud that you admitted you were wrong.

The only time I have a problem admitting I'm wrong is when I know I'm right.

By the way have you ever seen this?

zzzz

I'm an English student from England btw. Telling me to read a dictionary when you have no knowledge of linguistics whatsoever. What a laugh.

if you can't comprehend why his line is flawed then you slept through most classes and probably will have to drop out somewhere along the line.
Next to that... to say I am less of an expert than you are because I do not study the subject is a solid proof of your own incompetence. Especially because everyone can tell you that when you phrase something ambiguous it is your own fault when it is misunderstood.

Tbh your comment of "what a laugh" is just sickening. You insinuate so much bullshit in just 1 post that you lost my respect.

p.s. read a dictionary and tell me where the above definition of "your" is at.... and then look behind "their" and say that I'm wrong.

The wording was ambiguous, I can see how Weird could understand it that way. It would have been better to say blaming the game for one's inability.

tl/dr
current ql "netcode" favors your aim assistance at the cost of your enemie's dodging. this effect increases proportionatly with your own increasing ping.
this means the higher the ping of your enemy, the harder you can dodge his shots (hitscan only if i am not mistaken?)
weird would favour a more balanced way of "netcode" that assists your enemie's dodging more at the cost of assisting your aim.

*netcode = the way the game is handling the obligatory and varying travel times of information inbetween player-server-player

am i getting this right?

pretty much yes

I'm not going to read it but I hope you had fun writing it.

I looked at this post when I was thoroughly shitfaced last night and needless to say I couldn't understand a god damned thing :P Now I'm looking at them thoroughly hungover, and it's still hard to decipher your visuals...but I'm starting to understand after looking at them for a couple min

at least your are honest and called yourself a weird´o

Thanks for sharing this, starting to grasp how complex this netcode issues are. Dont mind the majority here that are posting while not understanding or trolling you because their fear change. That said some proof of concept in q3 or one of the other q3 open source improved versions would be very nice.

well I thought about that but the one very time consuming part would be writing a function that extrapolates player movement. This is already implemented in both CPMA and QL

I personally don't feel much for having to re-invent something that is highly complex ..... well the complexity of the function itself shouldn't be *that* hard but you need to have such a badass overview of the whole q3 code before you can write it that it would be very time consuming.
I wouldn't even be amazed if the extrapolation of players could just be done with the function used to extrapolate grenades and you could actually solve it with just 3 lines of code.

Bleh... Think I accidentally deleted my previous post while trying to edit it

Anyway, I believe that the extrapolation is just the interpolation code but with a small fix to make it cope with players properly. See this link (technical answer): http://www.ra.is/unlagged/faq.html#IHAMCEAWTNDWIIR

Idtech 4 takes extrapolation to a whole oother level with everything being run in a fully extrapolated state of ping/2 ms with the aim of having things nicely in sync with the server (including all physics/world interactions). It fails badly when there are prediction errors though. Q4 (without q4max cg_unsmoothclients 1) also had an attempt at smoothing out the player positions to counter the prediction failures that dodging etc causes, but it actually just has the effect of screwing the prediction badly such that they are neither in an"unpredicted" position and nor the "right" position.

Note that I've not actually studied your images to figure out what you're saying

can you please look at them. youre known and i think you can give something to the discussion.

Pretty much yes (I implemented it in Warsow), but it takes more than just exploiting the interpolation code to make it work right. The biggest benefit of extrapolation is that you can start drawing before receiving the next snapshot, so you are actually reducing ping for real.

In Q3 negative timenudges + cg_smoothclients "hack" the game to produce a pseudo-extrapolation effect. It's not half of the real thing, tho.

so honestly what u think about what weird says?

I don't have an opinion, sorry. I don't have the patience to try to guess those graphics :)

What I do have an opinion is about some comment I've read discarding backwards reconciliation as bad. It is very good as long as it's not abused.

The netcode is way better than what it was in q3 and it's improved a lot since when quakelive first was released. Any average player can hit solid 30+% lg in a duel you probably just can't aim you troll from youaregay x

I also consider ql netcode pretty good and i dont have issues with my aiming, but if someone is trying to help, i will listen to him prior to conformist xenophobics.

The reason I don't listen to him is because he's a dellusional wannabe pro who actually believes he's 20 times better than he actually is and anytime he loses to ANYONE he always blames it on netcode in some way. Heck he even did it on lan and said the shots felt "Weird" (No pun intended)

me?
dude wtf are you on about?
only thing I said on lan that my decisions were way too agressive because shots made sense to me.
I fixed that for the 2nd day (mostly) where I barely lost to spar1e.

I can make a netcode where every player has a solid 90+% lg and rail.
Doesn't mean the whole is good...

Many players in QL don't hit 30+% lg on average.

Rails going through are due to the netcode, but people don't really care cause for 1 rail going through you have like 10 false hits, so it's kinda good.

But what about the stairs bug and the invisible wall bug? Are they also due to Unlagged™?

Pretty sure those "bugs" have also been around in quake3 vanilla and q3:cpma.

None of these bugs exist in Q3 (baseq3/OSP/RA3/etc., not sure about CPMA - rails going through happens IIRC but I've never seen the two others)

Explosions not climbing stairs up isn't a bug. Deal with it.

Alright, the stairs bug is in fact a feature. Is it caused by the netcode?

no it has nothing to do with netcode. It's got something to go with how explosions are being influenced by the geometry.

Splash damage isn't volumetric. It is calculated by line of site checks from the point of impact, or a point offset from the point/surface of impact. Offsets being traced back from the vector of impact, opposed to using the normal of the surface.

maybe not a bug, but its stupid anyway :D

The flipside is taking splash damage on a ledge from rockets from below. Which one do you prefer?

depends on whether i recieve the dmg or give the dgm.

But e.g. on T7 at RA, those little things in the water have fucked me many times. They should at least change that mapwise.

Rails going through have proven to be due to the cylinder hitbox code, not anything having to do with netcode.

and is that issue (bug or whatever) going to be fixed?

It's already been fixed. I don't know how anyone could complain about rails missing anymore, the hitbox is so big you can just aim in their general direction and hit them.

ok then. I have never found that one though, but it annoys me that all I can hear is impressive.

Rails going through and false hits aren't mutually exclusive.

i like the netcode of ql alot. :)

c-u on lan warpin nudger

Weird presents: "cl_timenudge and me: a story of love, lust and betrayal"

I like kenshin better.

From my understanding the cpma netcode was too good (ruined the weapon balance of the game) which is why we choose to play wtihout xerp. Also anything that uses client side hit detection will affect dodging but it's better than going back to a game that is heavily dependent on ping. The community wants a netcode that makes the game between 2 players as even as possible regardless of ping. While i understand your concerns such as high pingers hitting bs shots that arn't there, the lower ping player will always have the advantage, unless the high ping playing is warping horribly (forcibly or not) but you can just choose not to play with them. While i still think lg is a bit overpowered online (comparing strenx's winning online compared to lan) The only way we could fix this is by forcibly setting truelightning to .05 or w/e but that would kill the whole emulating lan experience and regarding this i think people would care more about the emulating lan experience then fair weapon balance.

Who choose to play without xerp in cpma?!?
Who's talking about client side hit detection?
What would changig the truelightning value have to do with where you have to aim? If anything it will just make what's drawn on your screen even more retarded than it is atm.

I think I remember vampire saying he didn't use xerp, and he was the hell of a player (any1 correct me if im wrong)

Yep, there were always quite a few CPM players who preferred playing with xerp off since projectiles felt more accurate that way and in CPM RL was always the main weapon. On the other-hand, in VQ3 pretty much every player had xerp on as not using it was too big of a handicap considering how dominate LG was.

a bluga bluga bluga bloo!

Incredible work!

thx :)

incredible useless work...

still trying to justify you lack of skills in QL by blaming netcode? Guess what, everyone got same problem, but instead of bullshit statements [top4@ lan] they got used to the game as it is...



ps. thx weird for being such a dumbass, you make me lol with 90% of ur posts

I always like your post as well because they make me feel so superior. Not only intellectual but in every positive aspect of being human.

T O P 4 @ L A N

you'll be top4 at lan? damn man that's a good ambition to have. Good luck with that.

who's this hitsu guy?

I don't know but he seems very bittered. I think he's going through a though time irl and can't really express it anywhere except here.

In the end if we don't know his QL account then it's safe to say he's a random noob making up shit.

ozymandias or something like that was his account iirc.

It's probably this 1392 elo noob
http://www.quakelive.com/#!profile/statistics/Ozymandiass
http://qlranks.com/duel/player/Ozymandiass

all the other "ozymandias" are even worse

it's esr.... it's safe to assume he's a random noob making up shit as a baseline. After a while of replying you could slowly scale that up to someone being fairly reasonable etc.

i never said im uber pro player in quake, but i got enough experiance in multiple fps games to lol in faces of ppl like you or weird...



and now to the funny part: noone knows your ql account either

yet you said that the rail was a projectile ray that was so fast it counted as an aim weapon and denounced rockets as an aim weapon?

1. yes, i read it on esr, i accepted my mistake
2. yes again, they got fucking splash dmg dude...

I was just pointing towards what your "experience" has urged you to spit out.

so what's your account?

I posted mine like 5 times this month rofl

sorry, im not stalking ppl on internet forums, dunno if u did

i belive my last account was hitsuj1

http://www.esreality.com/post/2313076/netcode...pid2316655

http://www.quakelive.com/#!profile/statistics/hitsuj1
http://www.qlranks.com/duel/player/hitsuj1

In any case all those accounts are 1300-1400 elo and only you manage to win against players sub 1200 (then that's your true elo, which equals 0), so you have no moral authority whatsoever to discuss with weird, who even when having grey hair has 2k, with 1845 QL duels, or even with me or any user of this site really. We all can beat you playing with our feet.

I do like interwebz anonymity, so people can talk about ideas instead of persons (and trolling is funnier), but from reading your comments it was obvious you had no clue about the game. Stop embarrasing yourself and wasting ESR users their precious time.

the only one embarrasing himself is you atm.

any person with iq over 60 would know ELO statistic is useless in QL, as you rarely play series of matches against same opponent... my only duel mates were indepther and ffx, both above 1600... and i got rather equal win/lose ratio agains them...


also, even if i actually understand how the game should be played, i never spend enought time to pracc it... and im not playing quake for 10 years like weird...


now, tell me your nick, so i can talk bullcrap about you

why are you posting about something you don't a clue of

nice engrish, try again

He is only missing one word, where as your mistakes are more prominent.

missing a verb in a sentence us rather prominent

I missed a

to be fair anyone is free to discuss netcode with me, regardless of their ability to play the game.
Take the developers at ID for instance... I doubt anyone of them has an elo > 1600.

The problem isn't that he is shit at quake... it's that he doesn't bring in valid points and only whines about how I whine :)

nice try :-)

but pretending you didnt say you would be top4@lan, but u cant go through online quali because of highpingers wont work for me... kinda eidetic memory to all kind of internet bullshit :-)

ow, and i did place 4th on a lan with my ET team... it was polish only, but still :D

omfg you got top4 in a local lan in a game nobody plays.... that's fucking awesome man... that's so much better than me

yes its not much... but i never said it is...

you on the other hand cant backup your big mouth with skilled enough play... instead of praccing to get better, you blame netcode for not being ospish enough...

omfg I barely lost to spart1e and now I'm worlds biggest noob... I get it.
That I played crap on the 1st day of DH is without questioning but hey you try to play after a 16hour bus ride and having only slept for like 5 hours. I don't want to use it as an excuse as imo it's "me being unprofessional" (although it's a mixture of not wanting to spend lots of money on a hobby just to perform well).

I know cypher was shocked as hell when he saw me play vs spart1e after seeing my games on the 1st day and comparing it to the 2nd....

just shaddap at some point huh :D

I get sick from people who think they know everything about everyone while they know nothing... So my hope is that if I show them just how fucked up they are they might one day realize that they could also start to improve themselves rather than whine at others.
The only way to truely feel superior is to be superior :)

yeah, u truly superior schooling people who dont give a fuck on an online forum :D wake the fuck up :D

more excuses? why im not suprised?

awesome that you can't even read... it's amazing.

ye ye whatevah...

Weird hope you dreamhack again. Was fvery fun to see your style imlemented on lan. I still remember a commentator bragging about how he'd thought he had seen evrything on ztn, untill he saw some of your traps!

I would like to show you more insanely strange traps / sneaky moves / etc. (and I know so many more moves :p)

But I would doubt that is going to happen though :(

I haven't been active at all in cups since DH and I haven't really played much practise games either.

Darn oh well :p. You cant help that you have a life. Maybe next year!

who knows if one of my projects turns out better than expected (which could happen :p). I might have so much spare money/time that I can do whatever I please.

That would be nice :D

:) :) well if things go good for you and you still have need help. I know its not much., but, ill throw ten to fifteen usa dollars your way, maybe others would as well! War Weird!

haha thx!

I really appreciate the gesture :)

Is it true that once was possible to play Q3a with a 56 k modem?

you can play ql with 56k, it will just suck

no, it's totally impossible, i've tried it around a years ago, the ping shows 999 but you are simply blocked, you hear something happening around you, and once every some seconds the visual random turns around for like 1/10 of a second, and then returned stucked; it is totally impossible, not just a bad experience: simply impossible even to move around;
Then i wonder if it was really possible to play with 56 k in the 2000s, but theorically adsl weren't in the houses of many players, so it must be possible....

The following question, then, is why the connection resources demand have improved so giantly, how is it possible that a game played in 1999-2000 runs actually worst than the latest Call of Duty, on the same connection, with more peoples and way more shit flying around.

Your config was probably tweaked to have best performance rather than lowest bandwidth - and the same goes for the server config too. Maxpackets, rate etc

Also, playing q3 on a cheap software modem was always pretty bad (fine with a real hardware modem) so maybe you had one of those? Dunno if modern CPUs would counteract the issue of contention between the game and the modem both wanting resources but maybe not of you are running a q3 build that doesn't relinquish CPU after completing the frame)

i've never played q3a with a modem, so i dunno how it worked back in the days....
I still doesn't think it's possible to play quake live with a modem, someone should try and youtube the videos, just think, it's already difficult with the latest adsl, imagine with a crappy thing like a modem

I expect it works absolutely fine if you configure it right. I see no reason why anyone would make a youtube video just to prove you wrong. Two key cvars seem relevant to me:

cl_maxPackets used to default to 30, which is appropriate for a 56k modem. You could play on a 33k6 modem by lowering this value. The QL default is 63 I believe.

"rate" used to default to 3000 IIRC, which is about what it should be for a 56k modem. The QL default is 25000 I think.

If either of these cvars is set too high, you'll flood your connection and get the behaviour you described. By lowering these cvars, you should be able cap both your upstream and downstream bandwidth to acceptable levels. There may be other cvars that I'm forgetting.

i used both these cvars at the lowest possible level, at an intermediate, and at the maximum; i also tried to disable the packet duplication, there is no way to be able to play or just to move properly with a 56 k, and it is already difficult to play good with a medium adsl that works fine with all the others online games, so or the netcode is crap or it is heavy;
Ah, anyway, actually the minimum level settable is higher than the ones you mentioned i'm not sure of what is it and i cba to control just to prove you are wrong, but i'm sure one of two cannot be setted so low anymore, not that that could do any difference, but still.

The visuals are a bit confusing (lines here and there crossing).. and I do not get it (yet!).

But I hope that perhaps the interested community members can work out some improved diagrams based on your sketches, as some have seem to have understood this already.

Thanks for sharing your thoughts!

the concept itself is pretty difficult to grasp tbh.
It's not natural to think of several timelines running somewhat synchronised.

Once you get the basic idea however (of what the timelines represent and why they are there) it's not that complex to see where the differences between the netcodes are.

I feel like the given visuals (although confusing) are still the best way to represent what is actually happening though. At least I myself can't really come up with a more intuitive / clear way of showing what happens. Even in my drawings I've ommited a few minor details such that it doesn't get too complex.

Where edawn? ;)

I am gonna save you all a lot of time and summarize the point weird is trying to make:


1- I have low ping and this is a disadvantage
2- high ping noobs who normally wouldnt hit 10% lg can hit 50% because they abuse their ping
3- high ping noobs can spam rockets to the ceiling and hit full damage to a poor low ping skilled player on the otherside of the map, this is unfair.
4- ql netcode sucks. for me. for everyone else its good because it was made for them so they can beat me
5- fuck you I am weird.

spot on..
what a selfish ...
If you cant appreciate that ppl with 1000's of km between them, can have an enjoyable game of quake. You are a tard.
In the old days you could barely play against a neighbouring country, without a huge disadvantage.

it's nowhere near spot on....
In the post I just explain what happens ingame, netcode wise, focussing on the differences between osp, cpma and ql.

you're pathetic.
Fuck you I am Weird!

What an absolutely waste of time that was for you, I feel sorry for all the effort you put in because it doesn't mean jack shit.

I feel sorry for you too that you cannot comprehend it.

Promode all the way

I can't believe this guy went this far just to put some theoretical excuses behind his low-ping-whine.

For anyone who might run into this post in the future looking for reference or learning material:

The explanation herein must be taken with a grain of salt, due to the author of the post neglecting to account for prediction. Prediction is done client side and was developed (if I recall correctly) by idSoftware for the first Quake game (or maybe it was Quake 2), which basically did what OP describes in the fifth image, within the block starting with "THEORY".

The mechanism has not only been employed since the first Quake game (or second, as I might be remembering incorrectly), but has been adapted in virtually every game since then. The client receives a packet and based on the difference of SENT and RECV times, accounts for the it. This is also the reason why sometimes, when losing connectivity during game, you may see opponent players, or your own POV, keep moving, in the last registered direction, through game world solids (like walls, for example). This is because prediction is sometimes implemented differently.
Sometimes, it repeats a cycle of receiving a packet and based on the data, predicts the location contents of the next X packets, X being dependent on the heroes communication delay with the server, and that is it. Other times, to further reduce 'warping' and account for even more lossy connectivity, in the absence of follow-up packets, the prediction is done by using the data of the previous prediction calculation, until a new world snapshot is received from the server. In the first case, the opponents simply stop dead in their tracks. In the second case, they keep moving solid structures in the game world. This is because collision detection is also done on the server side of the communications model.

As for the 'timenudge' concept - this works on the packet data level. You're basically instructing the client to lie to the server about the time when the packet was sent, but even with this lie in place, the following procedures remain the same. You're just adjusting the data.

The things I have described here are very specific to animation and movement of objects within the game world. This does not apply to event driven action, such as firing weapons, simply because the opponents client has no way of predicting them, as opposed to movement of objects, such as player models and projectiles, which is done based on the simple concept of velocity.

You seem to understand the images and have a fair amount of knowledge on the topic. (Shame that you're posting anonymously though :( )

However smoothclients, as far as I know, doesn't actually affect the time (aka it doesn't "move your opponent ahaid of it's last known possition"). It just sais that when you don't have any new snapshot (even though 'you should have recieved one') you can assume that the player continues his path linearly.
Which is a type of prediction.... and combined with TN (which makes quake think that you 'should recieve a new snapshot') it actually does lead to a fair kind of prediction. But I cover that in my image(s).
Perhaps my note that "players stop moving" when you use TN should be changed into a more detailed text.... but smoothclients + tn would still lead to considerable amount of warping.

If you know of any other type of 'prediction' then do tell me ;)

so what are the best settings for 100mbps 10-20ms connection?
packetdup
timenudge
smoothclients