DghelneshiAims to surpass Fana in post edits.Join Date: 2011-11-01Member: 130634Members, Squad Five Blue, Reinforced - Shadow
<!--quoteo(post=1902124:date=Feb 11 2012, 03:59 PM:name=Skie)--><div class='quotetop'>QUOTE (Skie @ Feb 11 2012, 03:59 PM) <a href="index.php?act=findpost&pid=1902124"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Except there is in a way. If you shoot a fade that blinks away right after your hit, you see the splash of green blood (client side I'm presuming), but the hit doesn't register because he blinks immediately after (happens before server-side). Same thing when you shoot at something right before you die. You see blood, but nothing happens damage-wise.
I also find that seeing creatures move so much behind on the server is really annoying. Like if you are a skulk and biting down an extractor, it's pretty much impossible to run around the extractor and avoid hits from the marine's gun because on the marine's screen, he's already around the building and shooting at you when you still see him exactly on the other side. This definitely needs improvement.<!--QuoteEnd--></div><!--QuoteEEnd--> Blood is client side, yes. Would be way too much network and server cpu usage to make it server side.
For the extractor thing: I agree, but also watch yourself in third person or watch skulks in spec mode. Your body is not always pointing exactly behind you, but sometimes it's just your head tilting to one side. Also, you need to account for tickrate. If the server tickrate is 30, your actual latency should fluctuate by 1/30th of a second (33ms) due to data arriving early/late (if I understand it correctly).
<!--quoteo(post=1901827:date=Feb 10 2012, 05:26 PM:name=Max)--><div class='quotetop'>QUOTE (Max @ Feb 10 2012, 05:26 PM) <a href="index.php?act=findpost&pid=1901827"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->t I can't speak for the Source engine, but this is not true for Spark. The exact same interpolation that occurs on your client will happen on the server during lag compensation (based on exactly the same data that was sent to the client). It's always possible there are bugs, but there's nothing in design of the network system that should allow for hit registration errors.
I don't understand why Source works this way, but the situation depicted in this image shouldn't happen in Spark.
<img src="http://developer.valvesoftware.com/w/images/c/ca/Lag_compensation.jpg" border="0" class="linked-image" /><!--QuoteEnd--></div><!--QuoteEEnd--> Situation on this picture doesn't happen in Source either. It shows different hitboxes but it's compensated properly on server as far as I remember.
// correct tick send by player int targettick = cmd->tick_count - lerpTicks;
// calc difference between tick send by player and our latency based tick float deltaTime = correct - TICKS_TO_TIME(gpGlobals->tickcount - targettick);
if ( fabs( deltaTime ) > 0.2f ) { // difference between cmd time and latency is too big > 200ms, use time correction based on latency // DevMsg("StartLagCompensation: delta too big (%.3f)\n", deltaTime ); targettick = gpGlobals->tickcount - TIME_TO_TICKS( correct ); }<!--c2--></div><!--ec2-->
After that it interpolates between proper ticks wrt all animation layers and all of this stuff.
<!--quoteo(post=1901835:date=Feb 10 2012, 05:48 PM:name=Mkk_Bitestuff)--><div class='quotetop'>QUOTE (Mkk_Bitestuff @ Feb 10 2012, 05:48 PM) <a href="index.php?act=findpost&pid=1901835"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I believe that happens in source is because of the way it calculates the time difference between when the shot was fired client side, and the current server time when received. It moves everything backwards based on that time differential, but I think that timing is a problem since hit box information is only calculated per server tick, and if your shot occurred between ticks there can be a slight difference in the hit box position. Generally Source helps get around that by increasing the tick rates to 66 or 100 and decreasing interpolation.
On another note I notice a lot of choke in NS2 when a lot is going on, not sure if that may also be causing issues.<!--QuoteEnd--></div><!--QuoteEEnd--> It isn't exactly true that "hitboxes are only 66 times per second". It can store several unlag records and use them to linearly interpolate to time of shot and get some of non-linear stuff in there by replaying all animation layers that were playing at that time. Unlag records are kept for 1s. Each contains cycle, sequence, weight per anim and origin, angles per record.
If your server is running faster than 66 times per second it can run more Think functions/movement/shooting code and what matters is code that simulates non-linear stuff - what can't be replaced by running bigger dt in 1 frame instead of several ones.
Valve rightfully limited interp commands because total tools started changing settings they didn't understand after seeing this hitbox screenshot/video.
Code that most people get wrong is semiautomatic weapons. Pressing/release state and/or max bullets that can be shot until next key release MUST be stored in prediction. I had this code in input sampling in my mod for idiotic reasons and lots of weird things were caused by it, some people could even fire all bullets at once with small tweaks.
Wilson lower interp doesn't mean better precision. It means that your shots arrive at server slightly earlier so you're at advantage wrt people with stock interp and same latency.
matso: I'd rather have cl_pdump equivalent and just look at what turned red than try to interpret hundreds of lines.
<!--quoteo(post=1902166:date=Feb 12 2012, 04:07 AM:name=Dghelneshi)--><div class='quotetop'>QUOTE (Dghelneshi @ Feb 12 2012, 04:07 AM) <a href="index.php?act=findpost&pid=1902166"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Blood is client side, yes. Would be way too much network and server cpu usage to make it server side.<!--QuoteEnd--></div><!--QuoteEEnd--> But why not just do the blood effect once the client has been updated by the server? Blood is supposed to be a hit indicator, but if it isn't indicating hits correctly, then it's not working as intended. Having said that, the issue does appear to be the fact that what appears on screen is different to what is in the server, so doing what I just said would only hide the real problem rather than fix a problem.
<!--quoteo(post=1902239:date=Feb 12 2012, 02:57 PM:name=Harimau)--><div class='quotetop'>QUOTE (Harimau @ Feb 12 2012, 02:57 PM) <a href="index.php?act=findpost&pid=1902239"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->But why not just do the blood effect once the client has been updated by the server? Blood is supposed to be a hit indicator, but if it isn't indicating hits correctly, then it's not working as intended. Having said that, the issue does appear to be the fact that what appears on screen is different to what is in the server, so doing what I just said would only hide the real problem rather than fix a problem.<!--QuoteEnd--></div><!--QuoteEEnd--> Having the blood delayed by 100-200ms after the bullet impact would look weird...
Perhaps leave the blood splatter client-side, but have other client-side things that trigger when the health of another unit changes (such as body flinching and vocal grunts of pain)?
<!--quoteo(post=1902201:date=Feb 12 2012, 01:20 AM:name=MOOtant)--><div class='quotetop'>QUOTE (MOOtant @ Feb 12 2012, 01:20 AM) <a href="index.php?act=findpost&pid=1902201"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Wilson lower interp doesn't mean better precision. It means that your shots arrive at server slightly earlier so you're at advantage wrt people with stock interp and same latency.<!--QuoteEnd--></div><!--QuoteEEnd-->
I understand that, but my experience has been hits fail to register with higher interp. Especially if the other player is uploading a low amount of packets per second.
matsoMaster of PatchesJoin Date: 2002-11-05Member: 7000Members, Forum Moderators, NS2 Developer, Constellation, NS2 Playtester, Squad Five Blue, Squad Five Silver, Squad Five Gold, Reinforced - Shadow, NS2 Community Developer
<!--quoteo(post=1902239:date=Feb 12 2012, 05:57 AM:name=Harimau)--><div class='quotetop'>QUOTE (Harimau @ Feb 12 2012, 05:57 AM) <a href="index.php?act=findpost&pid=1902239"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->But why not just do the blood effect once the client has been updated by the server? Blood is supposed to be a hit indicator, but if it isn't indicating hits correctly, then it's not working as intended. Having said that, the issue does appear to be the fact that what appears on screen is different to what is in the server, so doing what I just said would only hide the real problem rather than fix a problem.<!--QuoteEnd--></div><!--QuoteEEnd-->
You can test how that would work (or rather, how it does NOT work). If you hit with a melee attack on a wall, you get a server-generated feedback event. Start a local server, cheats 1, net_lag 500, step up to a wall, start strafing and melee the wall.
You will get the hit-feedback a second or so late, which I personally feel is really confusing.
That being said, yea, I also find that there is something funny with the hitreg.
matsoMaster of PatchesJoin Date: 2002-11-05Member: 7000Members, Forum Moderators, NS2 Developer, Constellation, NS2 Playtester, Squad Five Blue, Squad Five Silver, Squad Five Gold, Reinforced - Shadow, NS2 Community Developer
edited February 2012
<!--quoteo(post=1902115:date=Feb 11 2012, 01:24 PM:name=Wilson)--><div class='quotetop'>QUOTE (Wilson @ Feb 11 2012, 01:24 PM) <a href="index.php?act=findpost&pid=1902115"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Seems weird that the bullets origin is directly inside the marines head. Shouldn't it be a bit lower, like at shoulder level in line with the weapon?<!--QuoteEnd--></div><!--QuoteEEnd-->
That's the path used to trace the bullet hits. Yea, marines shoots with their eyes. Think of it as an advanced targeting system - the rifle hits where you look.
Tracing the bullets from the muzzle just don't work well, unless you are willing to start using hip fire and iron-sight mode stuff.
About the blood I think it would look better it the splash was given the entity speed when created, now when you shoot a fast moving creature you often have the splash animation playing itself alone in the air, which looks a bit weird.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->Except there is in a way. If you shoot a fade that blinks away right after your hit, you see the splash of green blood (client side I'm presuming), but the hit doesn't register because he blinks immediately after (happens before server-side).<!--QuoteEnd--></div><!--QuoteEEnd-->
If I understand correctly what max said, this is impossible. Well maybe the 100% choke rate we sometimes have in combat could explain it, but I'm not sure what choke is exactly.
<!--quoteo(post=1901948:date=Feb 11 2012, 12:40 AM:name=Krizzen)--><div class='quotetop'>QUOTE (Krizzen @ Feb 11 2012, 12:40 AM) <a href="index.php?act=findpost&pid=1901948"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Back on topic: In 195, skulk bites don't seem to be registering like they were in 194. Maybe it's just me or maybe I'm attacking some really slippery marines.<!--QuoteEnd--></div><!--QuoteEEnd-->
I feel the same i had to bite this marine 5 times as a skulk and hit markers everytime. 5 times????
For the fade shooting issue, that is expected and is a fault of lag compensation, just like getting shot around corners. You shoot the fade and on your screen he is still outside blink, but you are X MS behind him and on his screen he is already blinking.
<!--quoteo(post=1902383:date=Feb 12 2012, 07:09 PM:name=Mkk_Bitestuff)--><div class='quotetop'>QUOTE (Mkk_Bitestuff @ Feb 12 2012, 07:09 PM) <a href="index.php?act=findpost&pid=1902383"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->For the fade shooting issue, that is expected and is a fault of lag compensation, just like getting shot around corners. You shoot the fade and on your screen he is still outside blink, but you are X MS behind him and on his screen he is already blinking.<!--QuoteEnd--></div><!--QuoteEEnd--> Exactly, I got killed as fade behind corner lots of times. People that were shooting at me had 150-300 ms latency + 100 ms interp.
<!--quoteo(post=1901827:date=Feb 10 2012, 11:26 AM:name=Max)--><div class='quotetop'>QUOTE (Max @ Feb 10 2012, 11:26 AM) <a href="index.php?act=findpost&pid=1901827"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I don't understand why Source works this way, but the situation depicted in this image shouldn't happen in Spark.
This picture is an extraordinary exaggeration using net_fakelag of 200ms, and sv_showimpacts 1 on a listen server to show the differences in time of a player model, and it's hitboxes. It's only a debugging tool, it's not actually representative of what happens in source.
Also:
<!--quoteo(post=0:date=:name=Valve Software)--><div class='quotetop'>QUOTE (Valve Software)</div><div class='quotemain'><!--quotec-->Then the server moves all other players - only players - back to where they were at the command execution time. The user command is executed and the hit is detected correctly. After the user command has been processed, the players revert to their original positions.<!--QuoteEnd--></div><!--QuoteEEnd-->
With that said, source and spark are doing the same thing, based on what you said, Max. However with source, as mentioned in the source multiplayer networking article, tiny interpolation errors happen as objects move at high speed since it processes hits on ticks. Is it possible Spark could have a similar issue?
Today I read on this forum topic it takes ~10 marine bullets to kill a skulk.
Now people argue left, right and centre about client/server etc.
But, if on the client side, I am shown, maybe identified for all using fraps, that there are more than 10 skulk blood splashes but no dead skulk, then....
Something is going wrong, yeah?
Which is pretty easy to show really. So, something is going wrong? are we agreed on that?
I keep getting cases where a skulk is still and biting a power node. I shoot 20 bullets close-up and instinctively reload immediately after because that <b>should</b> kill the skulk. But then I'm left stupefied as he does not and suddenly runs at me and kills me while I'm reloading. It's really frustrating.
Edit: I managed to get 3 skulks with one clip yesterday when they were all neatly bunched up around an IP. So sometimes it works pretty well. But I feel like when the server starts getting laggy, it loses some hit-regs.
Also skulk hitreg (biting marines) feels definitely worse in 195. I don't see what was improved.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->But, if on the client side, I am shown, maybe identified for all using fraps, that there are more than 10 skulk blood splashes but no dead skulk, then....
Something is going wrong, yeah?<!--QuoteEnd--></div><!--QuoteEEnd-->
As I have said on the first page the "shooting code" is executed like ten times for each bullets you fire, I'm not sure if it triggers the splashes, but if it does it might explain the problem.
1) What has changed from NS1 to NS2 that the server(s) are using a ridiculous amount of power? I understand that NS1 servers used a ton of resources, but I don't remember (on good servers) having a difficult time with hit-reg/lag. Maybe generating a game design solution that encourages fewer spammable structures would help. Also, hydras seem way too small. They are frustrating to hit when you know your lmg has a spread and only half your bullets are hitting it.
2) [hard] What is the difference between the half-life prediction/hit-reg code and yours? Very simply, half-life had 'interp' to plop the models at the proper 'time' for the person to shoot at. A too-low interp gave you models that were too far ahead for your lag, and too-high interp gave you models that were too far behind for your lag. Both of these caused you to miss. However, some people were used to aiming slightly ahead or slightly behind models, so that they preferred one slightly higher or lower interp than the technical proper interp value. That's why for pros, they were always kinda wondering what other people had for interp. It wasn't ever one set number. That's also why Valve had a client setting where you could changed the interp within certain limits to different numbers. Different ping needed different interp values. In addition a too-low interp often had the effect of causing the models to be jittery because the client didn't have enough data values to average so as to make smooth movements.
AsranielJoin Date: 2002-06-03Member: 724Members, Playtest Lead, Forum Moderators, NS2 Playtester, Squad Five Blue, Reinforced - Shadow, WC 2013 - Shadow, Subnautica Playtester, Retired Community Developer
<!--quoteo(post=1902563:date=Feb 13 2012, 10:48 AM:name=OnosFactory)--><div class='quotetop'>QUOTE (OnosFactory @ Feb 13 2012, 10:48 AM) <a href="index.php?act=findpost&pid=1902563"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I have a question.
Today I read on this forum topic it takes ~10 marine bullets to kill a skulk.
Now people argue left, right and centre about client/server etc.
But, if on the client side, I am shown, maybe identified for all using fraps, that there are more than 10 skulk blood splashes but no dead skulk, then....
Something is going wrong, yeah?
Which is pretty easy to show really. So, something is going wrong? are we agreed on that?<!--QuoteEnd--></div><!--QuoteEEnd-->
Such a video would surelly be very useful. Together with the weapon and armor upgrades of both sides.
<!--quoteo(post=1902563:date=Feb 13 2012, 09:48 AM:name=OnosFactory)--><div class='quotetop'>QUOTE (OnosFactory @ Feb 13 2012, 09:48 AM) <a href="index.php?act=findpost&pid=1902563"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->But, if on the client side, I am shown, maybe identified for all using fraps, that there are more than 10 skulk blood splashes but no dead skulk, then.... Something is going wrong, yeah? agreed on that?<!--QuoteEnd--></div><!--QuoteEEnd--> In Source you set cl_pdump to your weapon entity and check for pred vars in red. Blood is predicted on client but if data used to predict or method to compute are wrong then you'll get wrong blood splash. You have to identify the cause and not late effect - blood splash. It's very easy to make mistake in code and use non-shared RNG or do something else to diverge.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->But I feel like when the server starts getting laggy, it loses some hit-regs.<!--QuoteEnd--></div><!--QuoteEEnd--> Duh, Mr. obvious. There are no unlag records then telling where to move players. Having them at 2-5x lower frequency makes errors from interpolation a lot worse.
<!--quoteo(post=1902612:date=Feb 13 2012, 01:20 PM:name=MasterPTG)--><div class='quotetop'>QUOTE (MasterPTG @ Feb 13 2012, 01:20 PM) <a href="index.php?act=findpost&pid=1902612"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Different ping needed different interp values. In addition a too-low interp often had the effect of causing the models to be jittery because the client didn't have enough data values to average so as to make smooth movements.<!--QuoteEnd--></div><!--QuoteEEnd--> That's not true. Interp delay is there to have something to interpolate with EVEN if some packets are lost. No matter the latency if interp is high enough to have 2 points of history then it interpolates. Higher interp delay can make you have 3, 4 and so on packets to interpolate from which is safer for smooth movement over connection that drops packets.
You receive new packet every cl_updaterate and that doesn't rely on your latency.
Jitter is effect of code no longer interpolating (there's no sample to do that with) but EXTRApolating last movement there was for this entity. Game characters make very rapid movements so extrapolation is very often wrong. Jitter is game snapping object position/angles to what it received from network when extrapolation put it in wrong place.
I have a video of some of my play, however its far from perfect as it was the first time i had played with fraps on in NS2 and it reallllllly hurts my input responsiveness. There are a couple times where i felt skulks should have died easier then they did, however I do not know what upgrades they had when.
One other thing i have noticed with spark is it seems that there is no extrapolating at all, when you join servers with less that 7 or so updates a second it is quite noticeable. This is not really a huge problem but does make the bad servers seem even worse.
I tried to deactivate client blood splash and recorded some online play. Looking at the recording in slow motion I failed to notice any reg errors, only bad aim. I had a pretty good ping though.
<!--quoteo(post=1902817:date=Feb 14 2012, 05:16 AM:name=Plasma)--><div class='quotetop'>QUOTE (Plasma @ Feb 14 2012, 05:16 AM) <a href="index.php?act=findpost&pid=1902817"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->What about adding a hit 'ping' sound (like Quake 3 has), even just temporarily, to verify the hits are working right while playing a real game?<!--QuoteEnd--></div><!--QuoteEEnd--> I modded that in earlier but the game doesn't have really good hit tick sounds by default, which you have to use for it to work client side. I used the menu mouse-hovers-over-button sound but the pistol is so loud you can barely hear it.
<!--quoteo(post=1902854:date=Feb 13 2012, 11:54 PM:name=Plasma)--><div class='quotetop'>QUOTE (Plasma @ Feb 13 2012, 11:54 PM) <a href="index.php?act=findpost&pid=1902854"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->... the server should tell the client to make the ping sound, after a hit is detected, so that its only playing when actual damage occurs.<!--QuoteEnd--></div><!--QuoteEEnd-->
This shouldn't be necessary. If it is, client side prediction has failed. Might as well go back to a Quake style lag system (for the uninitiated: aim ahead. Way ahead) so we can b**ch about LPBs schooling us.
PlasmaJoin Date: 2003-04-26Member: 15855Members, Constellation, Squad Five Blue
That should be okay though, like Quake 3 (I believe?), since you just want to get real time feedback (even 200ms lagged) about how much of those bullets you just shot seemed to hit the target.
Comments
I also find that seeing creatures move so much behind on the server is really annoying. Like if you are a skulk and biting down an extractor, it's pretty much impossible to run around the extractor and avoid hits from the marine's gun because on the marine's screen, he's already around the building and shooting at you when you still see him exactly on the other side. This definitely needs improvement.<!--QuoteEnd--></div><!--QuoteEEnd-->
Blood is client side, yes. Would be way too much network and server cpu usage to make it server side.
For the extractor thing: I agree, but also watch yourself in third person or watch skulks in spec mode. Your body is not always pointing exactly behind you, but sometimes it's just your head tilting to one side.
Also, you need to account for tickrate. If the server tickrate is 30, your actual latency should fluctuate by 1/30th of a second (33ms) due to data arriving early/late (if I understand it correctly).
I can't speak for the Source engine, but this is not true for Spark. The exact same interpolation that occurs on your client will happen on the server during lag compensation (based on exactly the same data that was sent to the client). It's always possible there are bugs, but there's nothing in design of the network system that should allow for hit registration errors.
I don't understand why Source works this way, but the situation depicted in this image shouldn't happen in Spark.
<img src="http://developer.valvesoftware.com/w/images/c/ca/Lag_compensation.jpg" border="0" class="linked-image" /><!--QuoteEnd--></div><!--QuoteEEnd-->
Situation on this picture doesn't happen in Source either. It shows different hitboxes but it's compensated properly on server as far as I remember.
Tick selection is:
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1--> INetChannelInfo *nci = engine->GetPlayerNetInfo( player->entindex() );
if ( nci )
{
// add network latency
correct+= nci->GetLatency( FLOW_OUTGOING );
}
// calc number of view interpolation ticks - 1
int lerpTicks = TIME_TO_TICKS( player->m_fLerpTime );
// add view interpolation latency see C_BaseEntity::GetInterpolationAmount()
correct += TICKS_TO_TIME( lerpTicks );
// check bouns [0,sv_maxunlag]
correct = clamp( correct, 0.0f, sv_maxunlag.GetFloat() );
// correct tick send by player
int targettick = cmd->tick_count - lerpTicks;
// calc difference between tick send by player and our latency based tick
float deltaTime = correct - TICKS_TO_TIME(gpGlobals->tickcount - targettick);
if ( fabs( deltaTime ) > 0.2f )
{
// difference between cmd time and latency is too big > 200ms, use time correction based on latency
// DevMsg("StartLagCompensation: delta too big (%.3f)\n", deltaTime );
targettick = gpGlobals->tickcount - TIME_TO_TICKS( correct );
}<!--c2--></div><!--ec2-->
After that it interpolates between proper ticks wrt all animation layers and all of this stuff.
On another note I notice a lot of choke in NS2 when a lot is going on, not sure if that may also be causing issues.<!--QuoteEnd--></div><!--QuoteEEnd-->
It isn't exactly true that "hitboxes are only 66 times per second". It can store several unlag records and use them to linearly interpolate to time of shot and get some of non-linear stuff in there by replaying all animation layers that were playing at that time. Unlag records are kept for 1s. Each contains cycle, sequence, weight per anim and origin, angles per record.
If your server is running faster than 66 times per second it can run more Think functions/movement/shooting code and what matters is code that simulates non-linear stuff - what can't be replaced by running bigger dt in 1 frame instead of several ones.
Valve rightfully limited interp commands because total tools started changing settings they didn't understand after seeing this hitbox screenshot/video.
Code that most people get wrong is semiautomatic weapons. Pressing/release state and/or max bullets that can be shot until next key release MUST be stored in prediction. I had this code in input sampling in my mod for idiotic reasons and lots of weird things were caused by it, some people could even fire all bullets at once with small tweaks.
Wilson lower interp doesn't mean better precision. It means that your shots arrive at server slightly earlier so you're at advantage wrt people with stock interp and same latency.
matso: I'd rather have cl_pdump equivalent and just look at what turned red than try to interpret hundreds of lines.
But why not just do the blood effect once the client has been updated by the server? Blood is supposed to be a hit indicator, but if it isn't indicating hits correctly, then it's not working as intended.
Having said that, the issue does appear to be the fact that what appears on screen is different to what is in the server, so doing what I just said would only hide the real problem rather than fix a problem.
Having said that, the issue does appear to be the fact that what appears on screen is different to what is in the server, so doing what I just said would only hide the real problem rather than fix a problem.<!--QuoteEnd--></div><!--QuoteEEnd-->
Having the blood delayed by 100-200ms after the bullet impact would look weird...
Perhaps leave the blood splatter client-side, but have other client-side things that trigger when the health of another unit changes (such as body flinching and vocal grunts of pain)?
I understand that, but my experience has been hits fail to register with higher interp. Especially if the other player is uploading a low amount of packets per second.
Having said that, the issue does appear to be the fact that what appears on screen is different to what is in the server, so doing what I just said would only hide the real problem rather than fix a problem.<!--QuoteEnd--></div><!--QuoteEEnd-->
You can test how that would work (or rather, how it does NOT work). If you hit with a melee attack on a wall, you get a server-generated feedback event.
Start a local server, cheats 1, net_lag 500, step up to a wall, start strafing and melee the wall.
You will get the hit-feedback a second or so late, which I personally feel is really confusing.
That being said, yea, I also find that there is something funny with the hitreg.
That's the path used to trace the bullet hits. Yea, marines shoots with their eyes. Think of it as an advanced targeting system - the rifle hits where you look.
Tracing the bullets from the muzzle just don't work well, unless you are willing to start using hip fire and iron-sight mode stuff.
/Mats
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->Except there is in a way. If you shoot a fade that blinks away right after your hit, you see the splash of green blood (client side I'm presuming), but the hit doesn't register because he blinks immediately after (happens before server-side).<!--QuoteEnd--></div><!--QuoteEEnd-->
If I understand correctly what max said, this is impossible. Well maybe the 100% choke rate we sometimes have in combat could explain it, but I'm not sure what choke is exactly.
In 195, skulk bites don't seem to be registering like they were in 194. Maybe it's just me or maybe I'm attacking some really slippery marines.<!--QuoteEnd--></div><!--QuoteEEnd-->
I feel the same i had to bite this marine 5 times as a skulk and hit markers everytime. 5 times????
Exactly, I got killed as fade behind corner lots of times. People that were shooting at me had 150-300 ms latency + 100 ms interp.
<img src="http://developer.valvesoftware.com/w/images/c/ca/Lag_compensation.jpg" border="0" class="linked-image" /><!--QuoteEnd--></div><!--QuoteEEnd-->
This picture is an extraordinary exaggeration using net_fakelag of 200ms, and sv_showimpacts 1 on a listen server to show the differences in time of a player model, and it's hitboxes. It's only a debugging tool, it's not actually representative of what happens in source.
Also:
<!--quoteo(post=0:date=:name=Valve Software)--><div class='quotetop'>QUOTE (Valve Software)</div><div class='quotemain'><!--quotec-->Then the server moves all other players - only players - back to where they were at the command execution time. The user command is executed and the hit is detected correctly. After the user command has been processed, the players revert to their original positions.<!--QuoteEnd--></div><!--QuoteEEnd-->
With that said, source and spark are doing the same thing, based on what you said, Max. However with source, as mentioned in the source multiplayer networking article, tiny interpolation errors happen as objects move at high speed since it processes hits on ticks. Is it possible Spark could have a similar issue?
Today I read on this forum topic it takes ~10 marine bullets to kill a skulk.
Now people argue left, right and centre about client/server etc.
But, if on the client side, I am shown, maybe identified for all using fraps, that there are more than 10 skulk blood splashes but no dead skulk, then....
Something is going wrong, yeah?
Which is pretty easy to show really. So, something is going wrong? are we agreed on that?
I keep getting cases where a skulk is still and biting a power node. I shoot 20 bullets close-up and instinctively reload immediately after because that <b>should</b> kill the skulk. But then I'm left stupefied as he does not and suddenly runs at me and kills me while I'm reloading. It's really frustrating.
Edit: I managed to get 3 skulks with one clip yesterday when they were all neatly bunched up around an IP. So sometimes it works pretty well. But I feel like when the server starts getting laggy, it loses some hit-regs.
Also skulk hitreg (biting marines) feels definitely worse in 195. I don't see what was improved.
The lethality of my machine gun seemed inversely proportional to the number of players on the server...
Something is going wrong, yeah?<!--QuoteEnd--></div><!--QuoteEEnd-->
As I have said on the first page the "shooting code" is executed like ten times for each bullets you fire, I'm not sure if it triggers the splashes, but if it does it might explain the problem.
1) What has changed from NS1 to NS2 that the server(s) are using a ridiculous amount of power? I understand that NS1 servers used a ton of resources, but I don't remember (on good servers) having a difficult time with hit-reg/lag. Maybe generating a game design solution that encourages fewer spammable structures would help. Also, hydras seem way too small. They are frustrating to hit when you know your lmg has a spread and only half your bullets are hitting it.
2) [hard] What is the difference between the half-life prediction/hit-reg code and yours? Very simply, half-life had 'interp' to plop the models at the proper 'time' for the person to shoot at. A too-low interp gave you models that were too far ahead for your lag, and too-high interp gave you models that were too far behind for your lag. Both of these caused you to miss. However, some people were used to aiming slightly ahead or slightly behind models, so that they preferred one slightly higher or lower interp than the technical proper interp value. That's why for pros, they were always kinda wondering what other people had for interp. It wasn't ever one set number. That's also why Valve had a client setting where you could changed the interp within certain limits to different numbers. Different ping needed different interp values. In addition a too-low interp often had the effect of causing the models to be jittery because the client didn't have enough data values to average so as to make smooth movements.
Today I read on this forum topic it takes ~10 marine bullets to kill a skulk.
Now people argue left, right and centre about client/server etc.
But, if on the client side, I am shown, maybe identified for all using fraps, that there are more than 10 skulk blood splashes but no dead skulk, then....
Something is going wrong, yeah?
Which is pretty easy to show really. So, something is going wrong? are we agreed on that?<!--QuoteEnd--></div><!--QuoteEEnd-->
Such a video would surelly be very useful. Together with the weapon and armor upgrades of both sides.
Something is going wrong, yeah?
agreed on that?<!--QuoteEnd--></div><!--QuoteEEnd-->
In Source you set cl_pdump to your weapon entity and check for pred vars in red. Blood is predicted on client but if data used to predict or method to compute are wrong then you'll get wrong blood splash. You have to identify the cause and not late effect - blood splash. It's very easy to make mistake in code and use non-shared RNG or do something else to diverge.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->But I feel like when the server starts getting laggy, it loses some hit-regs.<!--QuoteEnd--></div><!--QuoteEEnd--> Duh, Mr. obvious. There are no unlag records then telling where to move players. Having them at 2-5x lower frequency makes errors from interpolation a lot worse.
That's not true. Interp delay is there to have something to interpolate with EVEN if some packets are lost. No matter the latency if interp is high enough to have 2 points of history then it interpolates. Higher interp delay can make you have 3, 4 and so on packets to interpolate from which is safer for smooth movement over connection that drops packets.
You receive new packet every cl_updaterate and that doesn't rely on your latency.
Jitter is effect of code no longer interpolating (there's no sample to do that with) but EXTRApolating last movement there was for this entity. Game characters make very rapid movements so extrapolation is very often wrong. Jitter is game snapping object position/angles to what it received from network when extrapolation put it in wrong place.
<a href="http://www.youtube.com/watch?v=Pd4Ch4PBCqQ&" target="_blank">http://www.youtube.com/watch?v=Pd4Ch4PBCqQ&</a>
One other thing i have noticed with spark is it seems that there is no extrapolating at all, when you join servers with less that 7 or so updates a second it is quite noticeable. This is not really a huge problem but does make the bad servers seem even worse.
I guess we'll agree to disagree. :)
I modded that in earlier but the game doesn't have really good hit tick sounds by default, which you have to use for it to work client side. I used the menu mouse-hovers-over-button sound but the pistol is so loud you can barely hear it.
This shouldn't be necessary. If it is, client side prediction has failed. Might as well go back to a Quake style lag system (for the uninitiated: aim ahead. Way ahead) so we can b**ch about LPBs schooling us.