dealing with lag...

[wardz]

Actually wilhulf that doesn't sound like such a bad idea, all the complainers can off on their own and us poor relations of the gaming community can please ourselves.

 

wardz

[Wilhuf]

To answer the original question, 'how will a laggy player affect overal gameplay in the quake 3 engine?'

 

To a low ping bastard, the effect of a laggy opponent will be minimal to the extent that collision detection is done server side, rather than client-side. Since the q3 client-server model does not use synchronous clients, players can move about and shoot independent of other players' latency.

 

If there is client-side collision detection for hitscan weapons (as is done in Half-Life), then laggy players will enjoy a real advantage over LPBers. According to the June Game Developers Magazine, for example, to compensate for lag, Half-Life uses client-side collision detection for hitscan weapons such as the mp5 and shotgun.

 

Under this lag compensation, even if you lag as a 'slodem' player, if you see a target and shoot it, your PC will make the caclulation locally (client side) to determine if you've hit the target. The hit is sent to the server, which then assesses if the collision is plausible. If it is plausible, then the hit is registered. So, in Half-Life, with hitscan weapons you shoot at what you see, not at where you 'think' the target is. This is not the case with projectile weapons, such as rockets, where the server determines the collision detection, not the client.

 

So, how is this a disadvantage to the LPBer? Well, if the target is an LPBer, the HPBer could be looking at a gamestate that is a few hundred miliseconds behind what the LPBer sees. This means the LPBer could be shot by the HPBer 'back in time.' The LPBer may not even see where the shots come from, but still take hits.

 

The LPBer may think, "hey, I hid behind this crate, I should take no damage!" But that doesn't matter, since on the HPB's screen, the HPB saw the LPB target and was able to shoot it before the LPBer hid behind the crate. The server agreed with the client-side collision judgement, and registered a hit against the LPB.

 

There are cases also, where even if a hit is made client-side, that the server determines that a hit really is not possible. This is lag compensation, especially for HPBs.

 

The knife cuts both ways, however. The LPBer can use client-side collision detection as well. The difference is that LPBers won't be shooting from as far 'back in time' against their targets.

 

It's all hypothetical anyway. JKO may not even use client-side collision detection. I'd prefer that it doesn't, and instead use the server-side collision detection to reduce the incentive for client-side cheating.

 

[ July 05, 2001: Message edited by: Wilhuf ]

[WD_ToRMeNt]

If JK uses client side BS I just might get mad enough to dig out my 33.6 slodem and sign up for netzero. I would rather not have to do that however. Im sick of laggers in JK, in JK2 I might just join them if I have to.

 

In truth though, i doubt JK2 will use client side anything to prevent many kinds of cheating (like q3 does).

[Wilhuf]

You won't get any real advantage if you join the laggers (excluding the lag compensation, if it is even implemented. Even if it were, LPBers could also use client-side collision detection).

 

There is no large, invisible target bubble that varies with latency in Q3 tech. Instead you shoot at what you see, with only minor forward shooting adjustment if you have high latency. You'd be better off sticking with the LPBs. As has been said, high latency will not effectively shield you from opponents in Q3 tech. Moreover, the high latency makes it that much more difficult for you to shoot targets.

 

And it won't be possible to 'block' the 'you've been hit' packets since the server will determine player health and shields, not the client.

 

Actually, if client-side collision could be insulated from cheats, it could work. For instance, JKO 'pure servers' could validate that the client-side collision detection was also 'pure' by checking the pak or other source files.

 

Although it's not impossible to hack client collision detection and still pass the checksum. There are additional checks that would also have to be passed.

 

Also, it would be critical that the server could override a client-side collision determination. This would address the 'getting shot from back in time' problem somewhat.

 

Would be nice to get Kenn Hoekstra's feedback on how JKO's networking is going to be implemented.

 

[ July 06, 2001: Message edited by: Wilhuf ]

[PreTZeL]

yes...wouldnt that be nice, a professional opinion for once heh, just kiddin, but wilhuf, id like to say that you are very computer smart, and im glad you had things to offer regarding lag, it sheds some light on the game immersed in shadow!

[CaptainRAVE]

Actually, if im the one with lag, when i used to have my 56K modem it was quite fun. Now with my T3 when other people get lag it is really annoying. And when you say "there was lag, thats why i lost", they dont believe you. Noone should be allowed onto a server if they have got a rubbish connection. No offence to anyone with a rubbish modem

[Mattpitt]

Well i live in this place called the UK. I have a 56k modem as do most people in this country but i'd love a T3 pr ADSL connection the thing is everything that is remotely good over herte is expensive! So the chances of me and others getting these broadband connections isn't likely in the next year at least. Well ythats wat i think

[CaptainRAVE]

56k modems are annoying. The computer im on at the moment has a 56K modem. It totally sucks and web pages take ages to load.

[acdcfanbill]

well, i tweaked my 56k modem to run at a hundred something, and no one complain about lag to me... course i dont play a lot of big laggy games on the net, but JK runs just fine.

[Luck]

Wilhuf are you sure thats how it works? That makes no sense really.

 

If a person shoots at another client, why would the server have to verify anything with what you just described? seeing if it *was* possible is essentially seeing if the client hit what he shot at on his own computer. I mean there's nothing for the server to verify. I mean you'd think that system would just about never work, it would work if someone was standing still or if they ran in a straight line or happened to recross where they just were.

 

BTW, there's no "sphere" that you can hit in JK, its just where the person actually is, its a person sized object, that looks and is animated just like the person. a "sphere" is just a way of thinkin about it.

 

Lucky

[PreTZeL]

wilhuf is right, its called lag compensation, i forgot how it works, but it is integrated into the serverside cvars and such (maybe not cvars, but serverside)

as for the sphere issue, yeah, you are right, but sometimes people say "sphere" for easier reference, as compared to "an animated person sized object"

later

[Wilhuf]

The lag compensation I described is a paraphrase from Yahn Bernier, a member of Half-Life's developer team. He wrote an article in the June Game Developer magazine describing Half-Life's lag compensation based on client side collision detection.

 

Yes, the Half-Life server does verify client-side determinations for hits. This is to ensure that players aren't being hit in completely impossible ways, such as far around corners.

 

As I said, this type of lag compensation is for Half-Life, which uses a heavily modified Quake engine. Jedi Outcast may not even use this type of compensation.