Do Some Collisions Have To Be Server Side
ViPr
Resident naysayer Join Date: 2002-10-17 Member: 1515Members
Resident naysayer Join Date: 2002-10-17 Member: 1515Members
i don't know exactly what's going on but if you stand on or go near buildings or resource nozzles you notice that you move strangely. also there's a window on one level with this radar dish thing outside and you can run right through the window but a moment later you get replaced back in front of the window. seems these things are being handled server side. most of this doesn't need to be server side coz these things hardly move around except when buildings are on moving platforms like lifts. if the server cpu load is too high then i think you gotta look for things to move client side. this is one of those things i think can be moved client side. what do you think?
Comments
the collision detection is build-in in the engine and it's impossible to change. and if it'd get changed, you'll see many cheats appear :/
1) the server has to believe you (this is what you are suggesting)
2) the server has to make sure you can be there (the way it is now)
If the server believes the client then that opens the way for cheats. IE you could hack the halflife engine so that you have noclip on. The server wouldn't check and say 'HEY no going through walls', it would just say 'Ok, you're in the wall'. Unfortunately, a LOT of pretty basic stuff has to be kept server side to prevent abuse.
Regarding seeing this effect for buildings vs walls, i'd assume thats because the HL client KNOWS where the walls of the level are, nothing changes there from the map load (so the HL client will stop you from going into the wall, therefore the server never decides you are in the wall and have to be pushed out). But buildings and other players are dynamic, and HL doesn't like dynamic as much as newer engines do. Therefore your client incorrectly judges the positions of things (compounded with lag) and so the server has to correct your position sometimes.
client checks for WORLD collisions (map collisions)
you can do noclip only whenb the server lets you do that (sv_cheats 1)
If all collision detection could be done on the client side, servers would really just need to be glorified routers, funneling player movement data among all the players.
Oh well, reality intrudes.
the collision detection is build-in in the engine and it's impossible to change. and if it'd get changed, you'll see many cheats appear :/<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
it lags when on buildings.
It also lags when u jump on a player.
well the turret factory shakes when it is being upgraded.
Okay, grunts! Time for a lesson on Half-Life, networking, and <i>What Lag Can Really Do</i> I'm afraid. This is <b>patently</b> untrue folks, as to what lag does. :-)
Lag does one thing, and one thing <u>only</u> in almost all on-line games.
It delays information between you and the server you're playing on.
Yes, that's it. It puts a pause on you talking to it, and it talking to you.
It does not change the information you recieve from the server, or that the server recieves from you. Full stop. Period. End of story.
Packet loss and corruption does that, and if you're playing on a link with corruption or lost packets, you have far larger problems than latency.
Lag does not cause buildings to move, you're told precisely where that building is, at all times. Any 'jittering' they do, for a fully stationary object, is animations, not physical jittering on your end that would make them jittery to stand on.
As a note however... I've found that 'crouching' is what causes almost all the view-jittering, as many times if I'm jittering, I crouch-walk a bit then let go, and when I let go it stops jittering.
Mind you, this is completely seperate from the 'pause' that occurs when you try to run through a weldable point, or the 'pushback' that happens on some windows and similair, or the 'pushback' on moving across buildings.
<b>That</b> is caused by an erroneous prediction of if you'll collide with a model or not, something that I believe has plagued Half-Life since it's original release. As proof it's purely a prediction issue, go to your console, <b>cl_nopred 1</b>, and try running through those weldable points leading to the elevator on NS_Bast from the Engine Room Hive or Feedwater Hive. No more 'glitch' in the motion.
Basically, the client isn't using the same math to test for collision as the server somehow, so one says Yea while the other says Nay, and the server wins the argument. :-) Most of the client-side-scriptable Quake-based engines have this discrepancy, in some cases simply being a difference in functions available between client and server, or a subtle difference in how a single function actually performs it's test due to the difference in data available. (all vs limited to prevent cheating)