update bot mbe?9((

welcome to quakelive my friend

It's replayed demo, right? It might look differently there than what you saw, and server saw.

Yeah but i looked the demo up because i was positive those shots were a hit when i played that match

Hey baksteen, im sorry for asking it here but it was the only option to reach u.

My question is: is it possible for you to post ur config+hud ? i would also like to know dpi and pollingrate if possible<3

Again sorry for disturbing

Didn't he just do that here: http://www.esreality.com/post/2602851/re-baks...pid2602851

..and it says mouse and dpi in the config.

Cheers Thank You Lorfa!

I don't think so, from pov. It looks a bit different in third person, that's all.

l2aim Kappa

I have noticed the same thing but in the US. cg_predictlocalrailshots 0 seems to help. But for some reason it will not save in my config so I need to put it in an autoexec.cfg .

it's an amusing placebo, because that literally just alters the timing that the rail beam image is drawn, it has no bearing on where you aim on your opponent or when you click fire.

it just *feels* better to people one way or the other.

You misunderstood me I am aware of what it does. It may be something sever side. Sometimes is takes more than the 32ms of ping I have for my gun to fire. It just helps me gauge how much lag there actually is. I just keep my crosshair on them until the gun fires and it seems to be pretty accurate. It is not a placebo. I think you need a dictionary.

What it does is
1: display the rail beam locally immediately.
0: display the rail beam when the server has confirmed it's received it.

A common sense postulation: setting it to 0 could help the player discern the amount of active rail lag and thus indicate the amount of correction needed, thereby increasing the player's chances of increasing rail accuracy.

Please critique.

Except you are NOT supposed to correct anything, even on higher pings (you're supposed to get perfect hit detection up to ping 55 with timenudge off, higher with it on).

Localrailshots 0 will display WRONG information on those pings in all situations except shooting AFK enemies ;)

By wrong information I mean: it will show misses when hitbeep confirms a hit and it will show hits when you've pre-aimed too much.

It's just like when spectating, just like watching demos, just like in the demo in the OP. It's a pre-shot and a clear miss that was later drawn as landing on enemy model.

I never get wrong information on localrailshots 0. I think you mean localrailshots 1 will show the false hits and misses. Because its the rail shot that is drawn client side.

0 shows what the server actually sees and where it went.

0 shows what server sees, but not what is used for hit detection. So it's consistently wrong by design.

1 is much closer to the correct view. It's not 100% accurate [1] but there's nothing better.

[1] Your own position is mispredicted by knockback all the time, lower cg_errordecay can lessen the effects a bit but nothing short of improved unlag can remove the cause.

ok thx. I have tried both extensively, and can't aim on 1.

Toxjq/Stermy predictlocalrailshots 1
strenx/k1llsen predictlocalrailshots 0

to each their own

Toxjq/Stermy are mostly LAN heros, while Strenx/K1llsen are were known by their OnLine skills.

I had to wait so long for a proper critique, thank you.

it gives you the correct timing of when to press your mouse1 vs where your crosshair is. If you have predictlocalrailshots 1 you will always press right when your crosshair is on the enemy.

sometimes you will miss because you aren't adjusting to your ping.

thats why I use predictlocalrailshots 0 so I can adjust to my ping, 20/40/60 etc, all have a different timing

.

It has a effect when you press fire/how you aim.

You'd use warmup to fire some rails and discern when and where they go depending on your clicking time and flicking time vs your ping.

How is this hard to understand?

Players like toxjq/stermy can't adjust to their pings so they always need to use predictlocalrailshots 1. Stermy puts -20nudge to help avoid through rails. Toxjq simply doesn't play anyone that warps. Which is why he likes playing kaide because his connection is amazing. And why he doesn't play on higher ping.

.

This is correct, the only exception is the lagged hitbox effect. But that's shooting behind the player based on the speed they're moving, not taking ping into account to aim ahead.

interesting question is why theyr lagged behind the player? is this a part of the netcode or local engine flaw?

It's the speed of player motions vs. ping/prediction/backwards reconciliation/sv_fps+snaps+maxpackets.

There's a tipping point where it's all just not fast enough to keep up.

Also you have issues like input lag on displays, and human reaction time. Vsauce did a video that stated that human conscious awareness is about 80 ms behind. Even if you take half of this for the sake of argument, that's still 40 ms.

In 40 ms, at 500 units/sec (initial strafe jumps can go higher, default running speed in-game is 320 units/sec), the player can move 20 units. The hit cylinder is 33 units, so that's ~60 % of a player length, certainly enough for a shot to miss. So, the laggy hit cylinder should be helping, but it goes too far when the player moves speedily.

.de servers only?

If yes then I'm surprised you didn't discover this a few years ago.

Yes the reg is horrible in this game. No id won't raise the tickrate above 40 because they're id.

cl_timenudge 0 is their hitbox always behind, cl_timenudge -10 makes it a bit more on them but it's unreliable.

horrible? You did not play modern AAA FPS. THAT is horrible. This game is perfect compared to them.

CSGO mm servers have higher tickrates, unless you don't count that as a modern AAA fps.

no, I do not count it as modern AAA cus it is not shit :D

Yet somehow on that game the hit reg is even worse.

If it wasn't the way it is, they wouldn't say it requires skill hehe.

hits does not register?

I haven't played in well over a year, but before I left the hit reg. was shockingly bad on mm servers.

exactly the same for me too. either that or recoil being completely potat.

Yes but even at point blank range with crosshair centre model; nothing. :(

hehe. not enough skill.

:D

hm that is bad. Did not play that much Ql yet, but in ~100hrs i did not see any shots to the center of model go thourgh.

Talking about CS:GO.

Where can you see that the tickrate is 40? I read a review on games quality network and they measured QL, they found it was higher than 40, I will edit with the links.

it is 40 server side and 125 client side (if you have consistent 125 or 250 fps)

ty

sv_fps on ql servers is set to 40.
It doesn't show on /serverinfo and if there is a way for a client to see the servers setting for this I can't remember it atm, but 40 is default, and the developers have stated a bunch of times that that is what the servers are all set to.

ty

I post another reply, I was wrong, I had bad memories from this feedback they wrote, they made the difference between client and server side, which is why I sitll had in mind that QL had higher tickrates, so yeah as randomguy and Yakumo said (and you too) it's 40 server side and more client side.

If you still want to know where I read about that even though you are right:

http://www.gamekult.com/actu/titanfall-de-lim...30413.html

Some people translated the page in English, it was understandable.

IT'S SAD BECAUSE CS GO FFA SERVERS HAVE STILL HIGHER TICKRATES THAN QL T__T

edit: what would happen if they rise QL tickrate to 60 for instance? (improved experience I guess? and then?)

edit 2: Oooh nevermind, size of the packets and bandwidth are very important.

We understand better why Titanfall's tickrate is so low compared to CS: GO. The bandwidth used is extremely high and if Titanfall proposed a 128 tickrate server, the bandwidth would increase to ... 124928 bytes/s! Almost 125 kb/s, it would be 1.5 MB/s for a full server of 12 players. Per day, we would reach 130 GB server side and it would multiply by 6 the costs, both financial and in data processing.

Meeeh, ok, but QL on the graph shows a bandwidth of 4520 bytes/s so if we rise the tickrate up to 128 like CSGO (Kappa) does it mean we have to multiply the bandwidth too by 3,2? 14464 bytes/s so like 14 or 15 kb/s so 1.269 GB /day /client then? So 15.228 GB server side each day for a server of 12 players? Am I right or wrong? If wrong why.

edit: what would happen if they rise QL tickrate to 60 for instance? (improved experience I guess? and then?)

I honestly haven't felt a difference when playing with higher sv_fps. That said, I was at around 80 ping so it was shit already and idk if the experience is that relevant.

Is it the so- called "netcode" then?

I'm afraid I don't understand your question.

It's normal. What is the "thing" that should improve the quality of the game experience online in QL then? If higher tickrate can't make it better, what would make it better? D:

There are things that just can't be improved. Not that it's QL netcode's case, heh. But shots going through really isn't a problem I get often. The most important improvement for me would be to stop warping (or warpers). I think the tickrate is fine as it is.

If they don't want to warp have them try cg_packetdups 3 to 5.

if they stop warping (which is possible) you wouldn't want to play QL with such netcode since it will cause whole bunch of other issues. Better kick the lagger.

Does this mean we can safely say CS:GO is way more uber esports stuff than cake and that we were lied to all these years about awesomesauce sv_fps netcode packets stuff in cake compared to others?

let's not even mention the LG sway even at 0 ping when doing anything but strafe aim. Load up practice, change cg_truelightning to 0 (which, disturbingly, makes it accurate) and move the mouse while firing the lg. There's about a 10° difference to where your crosshair is and where the weapon is actually firing.

If I walk from MH to LG-jumppad in ZTN while aiming constantly at the corner and firing LG on a 50 ping server with cg_truelightning 0, I get a 20-30° difference. edit: correction: It's easily >40 degrees

You need to read http://www.esreality.com/post/2475195/cg-true...pid2475231

So what he basically says is that, even though lower values of the cvar are more accurate, you shouldn't use them because it's not practical to aim with? What?

cg_truelightning <1 is all visual aswell under 80ms, you still hit where the crosshair is.

you still hit where the crosshair is.

No.
What happens to me on 50 ping servers: If I circle around a still-standing opponent while firing and keeping my crosshair (or shaft, when TL=1) more or less on him, hardly any hits will register (assuming hit sounds are accurate). If I orient myself with truelightning<1 shaft (=aim around the model, so that the shaft is on him, but not the x-hair), the beeps start coming in.

I experience the same.

I believe that TL1 is supposed to do what sync says, but in practice for some reason it doesn't.

It's close but not quite there. There are still plenty of cases where the beam is on the player and yet you get no hits. This is sometimes reduced with ever so slightly lower values of TL.

thats weird, cus if i go circles around my enemy who is standing still I get 100% acc as long as my crosshair stands on target no matter what ping am I on (highest i play is 60ms).

could you also check your actual accuracy when this happens?
Because it has happened to me that while useing some strange sound variables, with certain hardware setups consecutive hits don't play right....
Could be that over the years some hardware has been made where the default settings also cause this...

truelightning 1 should be accurate up to ping 65 or so.

other question which could be relevant is do you use something silly like nopredict? (I guess nobody would do that but hey it's worth a question :D)

other question which could be relevant is do you use something silly like nopredict? (I guess nobody would do that but hey it's worth a question :D)

Omg, i feel like such a retard now. :-/

Yeah, just checked my config, and it was on 1. Interesting that it has that effect, but the problem disappeared immediately when I changed it to zero. Thanks, man.

well.... Even I don't know exactly what the effect of nopredict is in QL....
It shouldn't be a possible setting anyway because your gaming experience suffers too much.

But good to know that it's solved now ;)

If in a practice game you set sv_fps to 125, that won't happen.

It's normally 40, which makes for 25 ms server time and that's the lag your'e seeing with tlg 0 on localhost.

Some other things you can see:

If you set cg_marks to 1, then LG along a path, with sv_fps 40 you will see the marks lag behind the beam ever so slightly. Again 125 changes that.

If you go to a laggy server and perform the same test, you'll see a huge lag between the lg beam and the marks. If you set cg_nopredict to 0, the lag with the marks will be gone.

Does nopredict have an effect on shaft accuracy, or it it purely visual? Is it something to turn on indefinitely?

Does nopredict have an effect on shaft accuracy, or it it purely visual?

I don't know.

I suspect what it does is wait for server confirmation for any motion except for turns because the mouse doesn't feel laggy.

I'm not sure what the extent of the prediction code is. Maybe what you see is more accurate but comes at a terrible price.

Is it something to turn on indefinitely?

No, I don't think so. Unless you ping something like 8 ms I wouldn't even consider such a thing. The prediction is too much of a help in terms of having a consistent comfortable experience.

Thank you muchly.

Thought I'd just make a few corrections to people's wrong assumptions and misinformation in this and every other netcode thread.
I don't really know why people find the unlagged client/server model hard to understand.
cg_nopredict 1 disables clientside prediction. Hit detection is calculated on the server. So in essence, it's just a cosmetic change. The client in QL, on brass tacks, only does a select few things:
1) Receive data from server
2) Draw approximation of data from server, showing current gamestate for that packet. ( player positions, hitbeep, scoreboard info, update damage etc )
3) Take user input
4) Send user input data

All the real calculations are done serverside. That's why hitbeep is delayed by (yourping)ms. The client waits to receive a packet from the server that confirms the last hit before playing a sound.
That's why if you set cg_nopredict to 1 and then LG the wall you'll see a delay. You're telling the client that it has to wait for confirmation of the LG hit from the server before it draws marks on the client. That's all.

I'm not sure why that article claims "Timenudge becomes less effective" as a negative side effect of higher sv_fps on unlagged, when all timenudge does is adjust the delay before a client releases the latest packet for interpolation. With higher sv_fps timenudge becomes less effective yes, because it's less necessary.
If we had ( for example ) sv_fps 125. cl_timenudge 0 would be the exact same as cl_timenudge - 17 on sv_fps 40. In fact, timenudge on sv_fps 125 would be limited to -8.

Anyway. None of this actually changes how hit detection actually works.
Nothing to do with hit detection is done on the client side at all. Timenudge / nopredict / truelightning / predictlocalrails do not change anything related to how hits are calculated .
Keep reading that till it makes sense. There is no voodoo magic to any of these cvars.
All they do is adjust how things are drawn on your screen.
The way hit detection in unlagged works is that when you pull the trigger on your railgun at a moving player, your next packet sent to the server will have the signal that a shot was fired, together with the shot vector. When this packet is received by the server. It'll 'dial back' it's internal log to check whether that shot vector intersected a player at (current time - yourping )ms ( as the server saw it, irrespective of what you saw on your screen ). If it did, then it sends your next packet with some info telling your client to turn the crosshair red, and make a sound. That's all.

Considering the way unlagged works, cg_predictlocalrailshots 0 and cg_truelightning 0 are totally unnecessary and complete placebo. All they do is change where the railbeam and LG beam are drawn. That's all. They were only ever useful before unlagged when you had to lead shots to compensate for the time difference between when things happen on the server and when your client updates.
cg_predictlocalrailshots just decides whether or not the rail is drawn immediately, or drawn when the client receives an update from the server 'confirming' the shot happened.
Considering unlagged is designed entirely to allow you to aim at the model and see the results of a shot asap, using this is totally redundant. If you have it set to 0, you'll invariably see huge gaps between the model and the railbeam everytime. The current position of the model is the best place to aim no matter what. If you have truelightning set to 0, and keep your crosshair on the enemy model the whole fight, the LG beam will be all over the place, but you'll be hitting high % LG.
Both of these cvars are placebo in the modern system. one hundred percent placebo. The fact they're still so widely used and misunderstood is just fucked up.

As for bad hit detection. Hit rego is utterly fucked on Australian Servers.
Our servers are so bad they can't even run Arkinholm without everyone getting huge lag haha.
Australian internet is so shitty, with so much jitter. That the bad servers, low sv_fps and netcode just can't handle it. At alot of times of day, LG is ridiculously unresponsive. Some players just can't be hit with anything at all.
I'd suggest someone from id take an inside look at the server logs from syd#1 and syd#2.
Syd#1 is so bad, that most players will refuse to play on that server altogether. And it's been pretty much decided by the whole community never to play a comp game on it.

Yo, although you're mainly right and have a clue lets fix a few minor things.

1) people aim based on what they see and hear.
If what you see is altered (even if it's wrongfully altered) it still effects your aim.
You're right that in order to hit you should have your crosshair at the same point at the same time regardless of the nopredict(see edit)/truelightning/predictlocalrail. However the aiming itself and the feel of when you hit change.
Therefor it's not 100% placebo.

small extra note: A lot of people also seem to have a kind of "autocorrect" in their brain... that just makes them think that rails are drawn as hits whenever they hear the hitbeep combined with a drawn rail. (which is fascenating...)

2) the server sends snapshots (not packets), minor point.

3) timenudge is slightly different.
3.1)When looking at sv_fps 125 compared to 40.
cl_timenudge 0 at sv_fps 125 is not the exact same as cl_timenudge -17 on sv_fps 40. The 2 gamestates would be similarly in sync (aka you'd have the same internal time) but the amount of information you have is different. With tn-17 you'd have to extrapolate (for 17 seconds) waiting on the next snapshot while on tn 0 you don't.

3.2)Also timenudge *should* most definitely alter at which physical time you fire and at which angle and from which possition.
This is because your own state is extrapolated the same (when compared to the server) regardless of timenudge, while your opponents possition is extrapolated further as a result of timenudge.
This means that on the whole your own state is in closer resemblance to the server state -> less lookback by the server.

3.3 or 3.2.2)Timenudge really alters your "game time" rather than speeds up the process of when snapshots are released.
So the state of the game on your screen is from another time... so you actually aim at a different place at the same physical time compared to gametime. (hard to find the right words haha :D)

-----
small edit: You probably also don't aim at the same place at the same physical time with nopredict on.
Because your own possition is not extrapolated anymore the angles on your screen should change.... I'm not sure which possition would be leading in this case, but at least your possition or the angle at which you fire should be different. Probably both are off by a bit depending on your ping.

1) This is true. The point is though that the target's *actual* location ( on the server ) remains the same.
Point I'm making though is that, largely, what you're aiming at is irrelevant. The enemy model drawn on your client is just a representation of where the enemy is on the server.
ie. If your client is animating at 30fps, you're going to have an inconsistent view of where the target is in relation to it's true location on the server.
And yeah, nopredict will cause all kinds of visual glitches, but the point remains the same.

2. You're completely right, good point.

3.1. You're also completely right here too, thanks for picking that one up. but yeah, you understand my point.

3.2. Can this be confirmed? Does timenudge actually change the client snapshot's timestamp? I'm not positive about that. Could potentially confirm this with wireshark or something, but I don't have it installed on this PC.
I know that if you use nopredict 1 and a negative timenudge value that the client will experience a "low fps" effect, because it won't interpolate your/other client positions during the "extrapolation phase". But the client state won't be extrapolated. I'm not sure exactly how that is possible.

3.2) the timestamp on outgoing packets is set by the line cmd->serverTime = cl.serverTime; (through the path of CL_SendCmd() which calls on CL_CreateNewCommands which calls CL_CreateCmd which calls CL_FinishMove which contains that line).

cl.serverTime is a global variable which is, during normal gameplay, set by cl.serverTime = cls.realtime + cl.serverTimeDelta - tn;
There are several other places where cl.serverTime gets set but they are all behind if's (like "if you're running a demo" or "if your servertime is off by more than 500ms with what's recieved" etc.)

Ofcourse I notified syncerror about this numerous times because he wouldn't believe me either... and according to his posts he still doesn't believe me.
It's in the q3 code though..... And it should be done like that..... (aka it makes sense)


As for the nopredict...... I'm not entirely sure... it's not a variable that I have checked....

reading back over your 3.2 discussion, wouldn't messing with that actually cause the effect people have been worried about all along.

ie.

modifying that WOULD then cause tn to alter everyone else perception of where you are.

?

hmmmm?
I'm not 100% how you mean that.... but the answer is probably no.

Because your own time (atm with tn-20 as max) can't possibly exceed the server's time.
So all actions recieved by the server will have a timestamp which is "in the past" (according to the server). But they will be 'less far in the past' if you use tn.

But the actions only affect the 'now' state of the game... So theres no possible difference in location. (edit: at least not in a way that is inconsistent... The other player will always see your correct possition at least as long as his timenudge remains the same... There is a possible way to get 'errors' when switching timenudge etc. But that's kinda minor and actually due to a check in q3 which may not always be smart to do. In general don't worry about it ;) )

I think the above is clear enough as an answer... but as usual I'm not that great with choosing my words :D

What does happen when using tn though is that the location you see on your screen resembles your possition on the server more closely. Also your instant hit weapons will appear to be 'more accurate' according to your opponent (less shots behind walls that hit etc).
And some more minor effects can take place but the reasons for that are all the same :D

Nice post, except aiming at the model is not the best method, you have to aim behind it :)

depends on your settings....

What settings put the hitbox on the model?

Ping as 30-40...

mostly cg_playerlean 0.
And I would advise to use keel (as his model-animation remain mostly inside of the hitbox.

Other than that I'd advise truelightning and predicted rail shots.

But in general people who think they have to aim behind the model are using playerlean 1.... which at least for moving models skews the model outside of the hitbox (to the front, aka you 'have to aim behind').

It seems I have the optimal settings already - never liked leaning, in fact think it' quite off putting. Been using since Q3.

Most certainly have to aim behind the player slightly to get consistent rail hits though :)

well I dunno about "optimal settings".
Imho it's very player/preference dependant.

i have had this from the start of quake live, very frustrating :)

Wow thanks for all the info guys. Very informative and worth testing out.

OMG what's happening!? A net code related post is idling for 9 hours without Weirds reply. Dark, dark times.

I'm somewhat inactive nowadays :p

Why can't prem/pro players configure server for sv_fps 125? Wouldn't it encourage players to pay for prem/pro? I know I definitely would.

Bandwidth or CPU overhead? I dunno. Id is cheap, maybe that's it.

Seems about right. I wonder if they increase it for QuakeCon. I'd like to think so.

http://youtu.be/TzY7dddKdo4

Last time I played, I saw every player warping and couldnt fix it. Missing every easy rail makes me want to quit the game.

wp video

Move from Mexico to some potat country, my potats hits 60% everytime

Mexico > *

in terms of beeheading and killing ppl

Mexico has a obesity problem., much worse than USA.

aiming straight behind the nmymodel since day one
ignore it or get mad how id ruins the best game

this topic is a about my problem since I started playing Quake.

The link brandan posted was really informative and might educate a lot of people here who are under the impression that higher sv_fps is better. I didn't know any of this until I read the page.

I'll just paste in some of that relevant info:

Is setting sv_fps higher than 20 still recommended?

It's a somewhat common practice to raise the server framerate to 30 or 40 to make the gameplay “smoother.” What “smoother” means in this case is that Quake 3's built-in 50ms lag becomes 33ms or 25ms, and everyone sees things a bit more like how they happen on the server.

Those are really the only two reasons to do it. Now, when Unlagged is running, full compensation or not, the built-in lag is taken care of completely. There goes one reason. It also does every hit test based on what players see rather than what's actually happening, so the second reason isn't any longer valid either.

It does have some detrimental effects:

More incoming bandwidth is required of players
cl_timenudge can't extrapolate as much, meaning it's less effective (this becomes an issue when sv_fps is over 33)
Higher pings (it seems the client engine holds onto snapshots a little longer)
Other players may be “jerkier” since more samples mean less smoothing in general
The new skip correction becomes less effective

So no, I wouldn't advise higher server framerates. There aren't any advantages anymore, and there are plenty of disadvantages.

Shortening the delay between making a shot and hearing a hitbeep by 25 ms is not an advantage?

Raising bandwidth by 0,5 KB/s is a detrimental effect in 2014?


Won't comment on the rest as 1. it's all pure speculation that 2. doesn't even apply to QL.

It already is reduced by 25ms as we run at sv_fps 40. Increasing it further most likely wouldn't make much difference, plus the server overhead/bandwidth etc bla bla, ie not worth it.

Also keep in mind that it must divide evenly with 1000.

So we could go up to 50, but the next number from there would be 100.

Need to be multiple of 20 for smooth LG hitbeeps, remember :)

So 100 is the next number after 40.

I don't remember : )

Elaborate please.

LG fires 20 times per second, every 50 ms.

Server sends an update every frame (in Q3 you could tell it to send less often but not more often).

Hence, when 2 LG cells hit, with sv_fps 50 (20 ms frames), two consecutive hit beeps will be 60 ms apart, then the next one will be in 40 ms. Not a grave problem but not smooth either.

Ahh.

Well, it already oscillates more than that in terms of the beep sound playing. You can tell with s_show and con_timeStamps on localhost.

So not sure if you'd recognize the difference. I haven't tested it though. Of course on localhost I might not be able to tell much of anything in terms of LG smoothness.

I have tested on wildly jumping FPS [1] and still I couldn't find a deviation by more than 9 ms and never two times in a row:



I can see why this isn't noticeable but jumping +- 20 ms every third hit would be.


[1] Normally people try to play on smooth FPS but some of them have some ping jitter so let's say I have simulated a real life scenario :)

Read the first column which is actually the time stamp. Notice for example: 0:22:451 and 0:22:502 is 51 ms.

Exactly, 51 ms between beeps is great! And the worst case was going from a pause of 49 to 58 ms between two beeps - 9 ms deviation.

Now imagine the commands from server are not coming every 50 ms, but random 40-60, with the current variation applied on top.

everything you said is wrong especialy for quake BECAUSE it is fast passed, its the same topic with monitor refresh rqate, people who know nothing about gamig think 60Hz is same for eyes as 120Hz etc.

indeed 60Hz monitor is ok for slow images, indeed 40 tick per second server is ok for slow fps or for RTS etc


in quake or any other fast fps u need to turn so quick, u need to track enemies going sometimes very fast in one direction (horizontal RJ, fast strafing etc) and changing directions fast.

When an enemy goes very fast you are likely to have shots going through.

While CS is extremly slow in its movements it has to be precise to make headshots more reliable. While quake hitbox is a joke it is still so fast you need high tickrate to make shots precise and not the shit we see on internet with LG vs LG meanings dodging randomly and spaming mouse movement fast left and right on the opponent's model especialy with ping higher than 20.

QL could be ok with at least 100 tickrate server, could be nice to have that for pro subscribers or even for a more expensive subscriptions.

CS servers are at 128 tick since decades and it is slow as fuck... hell even left 4 dead has 100 tickrate server. Yes all this are not official servers i know. CS official are at 60+? and L4D at 30 with some at 60.

Excuse me?

Read what you're pasting. You basically made a point that we should go back to 20.

And I'm saying 40 is easily distinguishable AND beneficial, hence the above is bullshit.

40 may be the sweet spot like you're saying. Advantages become smaller and smaller the higher you go, while disadvantages are linear and may actually matter :)

try it (sv_fps = 125) locally with bots and compare it with online server (sv_fps = 40 all players <10ms) => answer. I personally could not find any measurable difference.

If you play with less than 10 ms, practically any netcode feels fine.

If you play with less than 10 ms, practically any netcode feels fine, even more so against useless non dodging AI opponents.

i mean you try to make hits at certain situations and movment speeds targeting to find where actual hitbox is compared to rendered image. Ofc you can not just fight the bot and fight the human and compare it :D

Shots going through, false hits, shots around a corner, grenades bouncing on enemies, invisible walls with SG, stairsbug with RL, screwed up weapon balance, and, ironically, huge advantage given to low ping players... Pretty much all of these things are non-existent in Q3.

Unlagged is a lousy netcode for instagib newbs.

what is tairsbug with RL?

     [player]
   _____|
 x|
  |
  |

If player stands on stairs and you hit the stair below player (like in this HD picture above) you won't damage player at all. Even if the rocket will be 1cm from the player.

had many such rockets they do damage. Proof or did not happen.

:D
Play some more, m8

allright maybe i will see some magic :D
btw HD picture is lovely, inspected it on 1080p full screen it is simply beautifull

Thank you! I tried to choose the best colors for maximum pleasure : *
But seriously -> It's really happening D: The blast radius should go past the stair but instead it "thinks" it hit wall.

What if stairs acted as a ramp?

Y/N

The movement would go to shit?
But I guess it would "work" :)

Isn't it logical enough, not to call it 'bug'? If you draw line between explosion and player, it hits top of the stair, so there's no splash damage. It just should be made differently, like calculating splash dmg not from point of impact, but from point eg. 20 units earlier on the path of rocket.

It isn't logical for players when someone is protected from rocket that exploded in front of him by invisible wall :<

the explosion spreads from the point of impact in all directions/vectors available to them, how is that illogical

I understand the logic behind the game but if I would throw granade down the stairs I would imagine it would damage me.

the main problem in that regard is, that the ql explosion has the size of just one dot

And overlaping stairs/walls would be retarded.
Maybe in ql2.0 someone will put invisible hitboxes-ramps on every stair in game : )))))))

I actually would like to see how through wall dmg would turn out

I do actually really miss through floor damage.
You can turn it on if you want when you start a server but no-one tends to.

It added yet another aspect to the game, you had to learn hot spots in the map where it could be dangerous to walk even if you couldn't see the player. It meant being on the floor of vertical vengeance wasn't such a disadvantage at all, it made for a much faster game.
And of course it meant you could learn where the floors were thin so you could shoot rockets to take some damage/get some kills.

It was only disabled in Q3 because they felt it was too off putting for new players to die and not understand at all why o_O

The amount of "CHEATER" threads would slightly increase :D

How does a lowpinger have an huge advantage?

Currently playing on 50ms and using tl -20. Rail and lg is a piece of cake and you realise how shit the netcode is because every 2nd shot is so ridiculous behind the wall or off the model. I mean people die even tho I don't see them :D.

ping 50 with timenudge?

Feels better with than without. (on 50ms)

Huge advantage because they are kinda "playing from the future", their hitboxes are incorrectly displayed (which makes them pros dodgers even when they can barely move/strafe), and their RL/PG are much, much more devastating.

LG/RG are good at 50ms and even more since they are unlagged. The projectile weapons are shitty though, hence why the weapon balance is ruined /:

lol.

play more with someone *good* or even half decent who plays on 5ms...

Well, most ping above 20ms ;) and no worries I play only the best of the best :O

cuz you bad

hmmmm.... It seems like people are insinuating that the netcode is bad?
How can that possibly be???
And why hasn't anyone ever spoken out on this before?!?!!

Weird in netcode thread?
I wonder what is his statement on this topic!?

as for this specific video... I'm not entirely sure.
Demos kinda skew the view and theres no pings drawn etc.

My best guess would be that baksteen would be on a stable ping 35 which would put the first shot slightly infront of the opponent's hitbox (aka goiing through his face on baksteens screen at the time of play as he uses playerlean).

The 2nd shot is harder to see though... it would appear to be hitting regardless of baksteen's ping... maybe it's one of those strange rotation/animation things where the leg is misdrawn... but it doesn't seem to be so... Could be that the opponents connection wasn't entirely stable. (not sure on the 2nd shot :p)

Hey
Can you comment on this phenomen? It's not about the truelightning or any other visual stuff, but about the actual hit detection and the devinitely feelable offset of where your crosshair is and where the gun fires, which only occurs when you're moving the mouse to aim, but not when you're aiming with strafing.

This happens on all guns. I talked about the LG in the post because it's so obvious with that gun and because TrueLightning 0 (being only visual, but a nice representation of where the server registers your shots*) shows the problem quite nicely.

The problem gets worse with higher ping, but is also easily noticeable in a practice match. People can argue that this is the lag caused by ping, and that it is the reason you should lead your shots, but surely I shouldn't have to lead on an enemy who's standing perfectly still?

Thinking about this, it seems that the player's position is drawn accurately, but the "aim vector" (in lack of a better term, you know, the way your looking) gets fucked up somehow on it's way to the server. that would explain the lag when using the mouse.

*Anybody can discover that by actually using it for a bit of time. hitbeeps come in when the TL0 shaft is on the enemy model, not when the crosshair is. Plus wall marks are accurate in time as well.

Good way to verify this is checking stats of players with full aimbot and autofire. From what i have seen their rail acc is usually above 95%.
So yes, some shots go through but it's almost negligible.

Most people post videos from demo recordings and that is highly inaccurate.
There are some ways to record actual gameplay and you might wanna try one of them if you want to prove anything.

nice point btw
also from that serious cheater thread and his demos we know, that LG hits 99% if placed into the model...

The demo they took show it in the model, the game at the time may well have looked different and the bot was just tuned to hit where the hitbox actually would be.

huh? An aimbot can't magically know where the hitbox really is on the server, all it knows is where the model is drawn... which is the best known approximation of where it should be aiming. Maybe they try to compensate in >80 ms ping environment but apart from that...

ur just bad.

#dealwitit

Dang, you fired between his feet. Meh