Just because i see alot of questions going around about it.
Ok Hit detection the way it "should" work.
As you all know you are firing bullets. These more damn quick and for every bullet for every server game tick "moving the game on one step" gets very large very quickly. Sometimes you could have hundreds of bullets flying around the play. That the server needs to track.
In quake 3 the rail gun has an infinite slug velocity. i.e. it exsists at all points along a straight line, AT the same time. I know that is physicaly impossible but not when you code it that way.
UrT bullets im guessing have a velocity, "like lets say Quake 3's starting weapon". So the further away the target the more you have to fire where they will be not were they are.
If this was all said and done then hit detection would not be a real issue. Since the hit detection remains true. Now here is the snag.
Most FPS games suffer from this same problem and the best example to describe is "tickrate" from CS : Source.
Because the load of tracking each bullet from 16 players on every game move along, unless you have alot of $$$$ or a monster server. It just cant handle the number of calculations to make this happen. Not to mention the bandwidth to trasmit the data. So FPS developers like ID and VALUE have come up with a system to fairly reduce load.
This is the "tickrate".
Tickrate is the number of times the server checks for bullet collisions "hits" with solid object "you or the map". The higher the tickrate the more times the server checks per server cycle. The lower this number the less times it check and hence results in "WTF, were are the hits". The higher the server rate the bigger the CPU drain, however, you have a better chanch of you bullet getting a collision.
Urban Terror MUST have some similar system. It is probably set and fixed to prevent abuse. However if this was made into a cvar. eg. sv_tickrate . if you increase this number you will spend some more money but your server would be more accurate.
That is how i understand the system with FPS games.
Hope it is good reading for those interested.
Regards,
RaideR
Advertisement
Hit Detection Explained
#3
Posted 15 August 2006 - 01:28 PM
Well it depends on the Hit Detection system, some engins work it out with lines.
X = Player 1
Y = Player 2
*=Bullet
X*------------------------------------------------------------------------Y
after 1 tick
X______________________________________________*-------------------Y
no hit
after 2 ticks
X-----------------------------------------------------__________________Y_____*
hit
That is one possible way of detection. But this adds to the "rail gun" effect that is used in the Rail Gun in quake 3 arena.
But in answer server ticks are many, where as the hit detection code are alot less.
but seriously this is the only way they can do it. Unless they do bullet prediction but in the end that will still give a rail effect.
Hit detection is very trick, and exspensive! People moving easy, 80 bullets all moving on there own vectors ? Harder!
X = Player 1
Y = Player 2
*=Bullet
X*------------------------------------------------------------------------Y
after 1 tick
X______________________________________________*-------------------Y
no hit
after 2 ticks
X-----------------------------------------------------__________________Y_____*
hit
That is one possible way of detection. But this adds to the "rail gun" effect that is used in the Rail Gun in quake 3 arena.
But in answer server ticks are many, where as the hit detection code are alot less.
but seriously this is the only way they can do it. Unless they do bullet prediction but in the end that will still give a rail effect.
Hit detection is very trick, and exspensive! People moving easy, 80 bullets all moving on there own vectors ? Harder!
#4
Posted 15 August 2006 - 01:31 PM
exactly...it wouldn't add much to realism or hitdetection...but would raise the server load heavily
fyi: baseq3 does this only for grenades and rockets and other slow projectiles like plasma...the machine gun does full traces. i.e. the bullet exists all along the line. i can't imagine q3ut does that differently
fyi: baseq3 does this only for grenades and rockets and other slow projectiles like plasma...the machine gun does full traces. i.e. the bullet exists all along the line. i can't imagine q3ut does that differently
#5
Posted 15 August 2006 - 01:35 PM
Its the only real mathmatical way to do it. But luckyly for us computers can now do it quicker.
When the game was orgignaly launched "quake 3 arena" im talking about. The rates had to be set so that computers on the market could handle it.
Computers these days are up to 6 time faster if not more. So naturaly you could increase the rates to match the current PC specs. so rather than lets say a 500 Mhz chip you would now require a 1.2GHz chip and increase the hit detection ratio by abit.
Because the hit detection is just maths the number of calculations we can handle is based on our CPU. Hence in 3.8 if FS have the ability. Hit detection could be greatly improved.
When the game was orgignaly launched "quake 3 arena" im talking about. The rates had to be set so that computers on the market could handle it.
Computers these days are up to 6 time faster if not more. So naturaly you could increase the rates to match the current PC specs. so rather than lets say a 500 Mhz chip you would now require a 1.2GHz chip and increase the hit detection ratio by abit.
Because the hit detection is just maths the number of calculations we can handle is based on our CPU. Hence in 3.8 if FS have the ability. Hit detection could be greatly improved.
Advertisement
#6
Posted 15 August 2006 - 01:38 PM
o and in reply, so if full traces are done for all UrT weapons "nades excluded" how is the hit detection comprimised. Because if all bullets where under this way of detection. Hits would be exactly right. Is there something to with the Hit Boxes, but i bet bladey has them done real well so i doubt that.
#7
Posted 15 August 2006 - 01:42 PM
'tickrate' in q3 is sv_fps (on server) and snaps (on client). in urt 3.7 that's locked to 20, or 20 frames per second. it's the snapshots per second, or 'what's going on in the game world' per second.
btw, it may be suggested 'cpu drain' is the most fundamental reason currently for 'lost hits'. unless servers limit cpu usage that doesn't seem to be the case. on a pentium-m 1.6 (a laptop) I've seen a full 16 player server absorbing around 10 percent cpu.
a higher sv_fps/snaps value may improve 'accuracy' of the gameworld in general, which has been suggested before, but has its critics.
btw, it may be suggested 'cpu drain' is the most fundamental reason currently for 'lost hits'. unless servers limit cpu usage that doesn't seem to be the case. on a pentium-m 1.6 (a laptop) I've seen a full 16 player server absorbing around 10 percent cpu.
a higher sv_fps/snaps value may improve 'accuracy' of the gameworld in general, which has been suggested before, but has its critics.
#8
Posted 15 August 2006 - 01:46 PM
yeah that was my conclusion. Because i havent seen code or anything of course my statement is not based on how the engine does it, but how the maths seemed to point towards it being done.
That is a remarkable statistic. i have never got a q3 server to run that low
Nice!
And will we have a ability to change this value ? sv_fps ?
maybe open up some options ? sv_fps 20 / 30 / 40
giving us the option to run our servers on which ever load base we wish ?
That is a remarkable statistic. i have never got a q3 server to run that low
Nice!
And will we have a ability to change this value ? sv_fps ?
maybe open up some options ? sv_fps 20 / 30 / 40
giving us the option to run our servers on which ever load base we wish ?
1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users
Advertisement