Well I've added back the lag compensation calls in player_command.cpp that the old SDK had. Seemingly 100% of the players that were complaining before now agree that everything is much better (as it was prior to the SDK update).
At 2006/09/24 08:40 AM, Robbie Groenewoudt wrote: >-- >[ Picked text/plain from multipart/alternative ] >Ah yes, you are right. Interpolation plays a roll. > >Are there any other situations that needs lagcompensation? Also, if you do >it in player_command, player's physics position also gets updated with the >lagcompensated-position, which may give funny results... > >On 9/23/06, Paul Peloski <[EMAIL PROTECTED]> wrote: >> >> -- >> [ Picked text/plain from multipart/alternative ] >> I have to disagree. Right in the StartLagCompensation function you will >> see >> that the amount of time to back track the enemy player is calculated like >> this: >> >> back track time = cmd transit time (net. latency) + cl_interp value >> >> Check the first 10-15 lines of StartLagCompensation to see that in action >> (note that player->m_fLerpTime is elswhere set to the player's value for >> cl_interp.) cl_interp is the determining factor in how far behind the >> client >> renders an entity vs. the servers position data. >> >> The amount the player is moved back is not simply the players ping, its a >> composite of how far behind their rendering is (cl_interp) and how long it >> took for their ucmd to reach the server. >> >> And yes, like I said you can do it in FireBullets if you use IsPlayer and >> cast the entity to CBasePlayer, but you can also do it in RunCommand and >> catch other situations where you use tracelines but are not necessarily >> calling FireBullets. >> >> On 9/23/06, Robbie Groenewoudt <[EMAIL PROTECTED]> wrote: >> > >> > -- >> > [ Picked text/plain from multipart/alternative ] >> > In fact, I already moved it to CBaseEntity::FireBullets and I tested it >> > and >> > it works. player_command.cpp sets the last usercmd in the player class, >> > which you can get via CBasePlayer::GetLastUserCommand(). Also, func_tank >> > gives the player as an argument to FireBullets() so in the class itself >> I >> > do >> > a pAttacker->IsPlayer() check, which works for everything. >> > >> > You are forgetting something. It's ping. And if you have a ping of >> 250ms, >> > you don't hit anything because the location of players are different >> 250ms >> > ago. Lagcompensation fixes this by moving all other players, that the >> > player >> > could shoot, back in time (amount is equivalent to the player's ping ) >> and >> > then execute the tracelines to check if a bullet has hit someone. >> > Interpolation has nothing to do with lagcompensation. >> > >> > On 9/23/06, Paul Peloski <[EMAIL PROTECTED]> wrote: >> > > >> > > -- >> > > [ Picked text/plain from multipart/alternative ] >> > > What Teddy said is probably the best place. CBaseEntity::FireBullets >> is >> > > probably not good because StartLagCompensation takes CBasePlayer and >> > > CUserCmd as parameters so passing the this pointer from within >> > > CBaseEntity::FireBullets won't compile, you'd have to wrap it in >> > > IsPlayer(), >> > > so there's no benefit to func_tank. >> > > >> > > Garry's right, the lag compensation moves the player back to match >> what >> > > the >> > > client would have been shooting at since the client is behind the >> > server. >> > > Client rendering is always kept (cl_interp 0.1, ~100 ms) behind the >> > server >> > > so that the client can keep enough data ahead of the actual rendering >> to >> > > smoothly interpolate movement. >> > > >> > > You can get a really good idea what's going on by adding a bot, >> turning >> > on >> > > >> > > sv_showhitboxes 2 >> > > sv_showlagcompensation 1 >> > > host_timescale 0.1 >> > > >> > > Now you should see some colorful hitboxes that are the servers >> position, >> > > the >> > > rendered enemy player is the clients which lags behind those hitboxes >> > > because of cl_interp, and when you shoot at the bot, you should see a >> > > bunch >> > > of blue hitboxes which are the lag compensated hitboxes that are >> > actually >> > > used when tracing your shots. In slowmo you can see that the blue >> boxes >> > > overlap the client-rendered player pretty well. >> > > >> > > Hope that helps, BK & Robbie. >> > > >> > > On 9/23/06, Robbie Groenewoudt <[EMAIL PROTECTED]> wrote: >> > > > >> > > > -- >> > > > [ Picked text/plain from multipart/alternative ] >> > > > Let me rephrase that last. Maybe the best place to lagcompensate >> would >> > > be >> > > > CBaseEntity:FireBullets(). Then you are sure no other things get >> > messed >> > > > up... (there's some other stuff in CBasePlayer::PostThink that may >> not >> > > > like >> > > > changing positions). >> > > > >> > > > Also, it's possible that the func_tank has no lagcompensation at the >> > > > moment >> > > > (I'm not sure) so moving it to FireBullets() would do >> lagcompensation >> > > for >> > > > everything that fires bullets ;) I doubt that it's called more then >> > once >> > > > in >> > > > a frame so moving it shouldn't be harmfull. >> > > > >> > > > Just thinking out loud here... Please tell me if I am wrong :) >> > > > >> > > > On 9/23/06, Robbie Groenewoudt <[EMAIL PROTECTED]> wrote: >> > > > > >> > > > > FX_FireBullets() calls CSDKPlayer::FireBullet() and that's where >> the >> > > > > bullet-code is done. >> > > > > >> > > > > However, with mods based on HL2DM, it's a bit different. >> > > > > CBasePlayer::PostThink() calls CBasePlayer::ItemPostFrame() and >> that >> > > > calls >> > > > > the ItemPostFrame() of the weapon.. And that calls via via the >> > > function >> > > > > CBaseEntity::FireBullets(), which is the equivalent of >> > > > > CSDKPlayer::FireBullet(). >> > > > > >> > > > > So lagcompensation in HL2DM mods should be done in PostThink() or >> > > > > ItemPostFrame(). >> > > > > >> > > > > On 9/23/06, [EMAIL PROTECTED] < >> > > > [EMAIL PROTECTED]> >> > > > > wrote: >> > > > > > >> > > > > > Ah I think I'm starting to see how the pieces fit together >> > then. I >> > > > was >> > > > > > thrown off by all the FX code, thinking it was a client-side >> > > function, >> > > > but >> > > > > > there's a surprisingly useful comment at the top of >> > FX_FireBullets: >> > > > > > >> > > > > > // This runs on both the client and the server. >> > > > > > // On the server, it only does the damage calculations. >> > > > > > // On the client, it does all the effects. >> > > > > > >> > > > > > So client-rendering prediction is completely unrelated to all of >> > > this. >> > > > > > >> > > > > > It looks like bullet weapons should still be fine (which is what >> I >> > > > > > tested previously, and they did seem fine) but that bludgeon >> > weapons >> > > > in the >> > > > > > SDK are no broken with respect to lag-compensated hit >> > > detection. I'll >> > > > look >> > > > > > into that more. >> > > > > > >> > > > > > At 2006/09/23 04:18 AM, Garry Newman wrote: >> > > > > > >-- >> > > > > > >[ Picked text/plain from multipart/alternative ] >> > > > > > >I think it's the other way around. >> > > > > > > >> > > > > > >The server is moving the other players back to where it thinks >> > they >> > > > > > were >> > > > > > >when you fired the bullets, then tracing and seeing if you hit >> > > then, >> > > > > > then >> > > > > > >moving them back. >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > >On 9/23/06, [EMAIL PROTECTED] < >> > > > > > [EMAIL PROTECTED]> >> > > > > > >wrote: >> > > > > > >> >> > > > > > >> Forgive my perhaps naive question, but if you only lag >> > compensate >> > > > > > during >> > > > > > >> bullet firing, and not the rest of the time, won't you be >> > > rendering >> > > > > > your >> > > > > > >> opponents on screen in the wrong position? >> > > > > > >> >> > > > > > >> At 2006/09/22 06:48 PM, Teddy wrote: >> > > > > > >> >In the new SDK, StartLagCompensation happens on line #193 of >> > > > > > >> >sdk_fx_shared.cpp, during the FX_FireBullets() function. >> It's >> > > done >> > > > > > >> >here so it doesn't effect player movement (aka sticky player >> > > > > > >> >collisions). The problem with this is if your weapon needs >> > > > unlagged >> > > > > > >> >positions for anything other than firing bullets, it won't >> > work. >> > > > > > >> > >> > > > > > >> >I would recommend you instead StartLagCompensation before >> > > > > > >> >RunPostThink( player ) in the CPlayerMove::RunCommand() >> > > function. >> > > > > > >> > >> > > > > > >> >On 9/23/06, Robbie Groenewoudt < [EMAIL PROTECTED]> wrote: >> > > > > > >> >>-- >> > > > > > >> >>[ Picked text/plain from multipart/alternative ] >> > > > > > >> >>Damn, you are right. There's no StartLagCompensation-call >> in >> > > the >> > > > > > entire >> > > > > > >> >>code. I don't see any reason why it isn't because it worked >> > > good. >> > > > > > In the >> > > > > > >> new >> > > > > > >> >>SDK-code the lagcompensation-code is even expended... It's >> a >> > > bug >> > > > I >> > > > > > >> guess.... >> > > > > > >> >> >> > > > > > >> >>On 9/22/06, Paul Peloski <[EMAIL PROTECTED]> wrote: >> > > > > > >> >>> >> > > > > > >> >>> -- >> > > > > > >> >>> [ Picked text/plain from multipart/alternative ] >> > > > > > >> >>> I'm at home now, sv_showlagcompensation the right name, >> > it's >> > > > > > >> implemented >> > > > > > >> >>> in >> > > > > > >> >>> player_lagcompensation.cpp with the following >> description: >> > > > "Show >> > > > > > lag >> > > > > > >> >>> compensated hitboxes whenever a player is lag >> compensated." >> > > > > > >> >>> >> > > > > > >> >>> If you compare the file player_command.cpp between the >> old >> > > SDK >> > > > > > source >> > > > > > >> and >> > > > > > >> >>> the Aug 11 source, you should notice that the call to >> > > > > > >> StartLagCompensation >> > > > > > >> >>> is missing from CPlayerMove::StartCommand in >> > > player_command.cpp >> > > > > > >> >>> >> > > > > > >> >>> I wondered about this when I merged the new SDK, and >> > decided >> > > to >> > > > > > keep >> > > > > > >> the >> > > > > > >> >>> startLagCompensation for our mod and haven't had any >> > problems >> > > > > > with >> > > > > > >> shots >> > > > > > >> >>> registering. Maybe this is a bug in the new SDK? >> > > > > > >> >>> >> > > > > > >> >>> On 9/22/06, [EMAIL PROTECTED] < >> > > > > > >> [EMAIL PROTECTED] >> > > > > > >> >>> > >> > > > > > >> >>> wrote: >> > > > > > >> >>> > >> > > > > > >> >>> > Closest I see is player_showpredictedposition, but it >> > > doesn't >> > > > > > seem >> > > > > > >> to >> > > > > > >> >>> > visually change anything at all. >> > > > > > >> >>> > >> > > > > > >> >>> > At 2006/09/21 08:41 AM, Paul Peloski wrote: >> > > > > > >> >>> > >-- >> > > > > > >> >>> > >[ Picked text/plain from multipart/alternative ] >> > > > > > >> >>> > >Check that the lag compensation system is still being >> > used >> > > > to >> > > > > > move >> > > > > > >> >>> > entities >> > > > > > >> >>> > >when a player is shooting, IIRC you can use >> > > > > > sv_showlagcompensation >> > > > > > >> 1 or >> > > > > > >> >>> > >something similar to show some hitboxes when a player >> is >> > > > being >> > > > > > lag >> > > > > > >> >>> > >compensated (ie, you have to be shooting at him and >> lag >> > > > > > >> compensation >> > > > > > >> >>> has >> > > > > > >> >>> > to >> > > > > > >> >>> > >be turned on, etc.) I remember the >> > > > > > >> >>> lagcompensation->StartLagCompensation >> > > > > > >> >>> > was >> > > > > > >> >>> > >missing in the player command code on the server side >> > with >> > > > > > regard >> > > > > > >> to >> > > > > > >> >>> the >> > > > > > >> >>> > lag >> > > > > > >> >>> > >compensation system when I first merged with the new >> > SDK. >> > > > > > >> >>> > > >> > > > > > >> >>> > >Sorry I can't be more specific, I'm at work and don't >> > have >> > > > > > access >> > > > > > >> to >> > > > > > >> >>> the >> > > > > > >> >>> > SDK >> > > > > > >> >>> > >right now. >> > > > > > >> >>> > > >> > > > > > >> >>> > >On 9/21/06, [EMAIL PROTECTED] < >> > > > > > >> >>> > [EMAIL PROTECTED]> >> > > > > > >> >>> > >wrote: >> > > > > > >> >>> > >> >> > > > > > >> >>> > >> I'm getting lots of complaints from my user base >> that, >> > > > > > following >> > > > > > >> the >> > > > > > >> >>> > SDK >> > > > > > >> >>> > >> update, lag prediction has gotten worse. Has anyone >> > > else >> > > > > > >> experienced >> > > > > > >> >>> > >> this? I haven't really experienced much of a >> change, >> > > but >> > > > > > then I >> > > > > > >> >>> don't >> > > > > > >> >>> > have >> > > > > > >> >>> > >> as large of a ping to any of my mod's servers as >> some >> > of >> > > > my >> > > > > > users >> > > > > > >> do. >> > > > > > >> >>> > >> >> > > > > > >> >>> > >> After receiving complaints a few days ago I reviewed >> > SDK >> > > > > > changes >> > > > > > >> and >> > > > > > >> >>> > >> noticed massive amounts of code changes around >> > > > > > prediction. But >> > > > > > >> most >> > > > > > >> >>> of >> > > > > > >> >>> > it >> > > > > > >> >>> > >> seems to be centered around the creation of a >> > seemingly >> > > > > > unused >> > > > > > >> and >> > > > > > >> >>> > pointless >> > > > > > >> >>> > >> NO_ENTITY_PREDICTION define to segregate out the >> > > > prediction >> > > > > > >> >>> > code. Maybe >> > > > > > >> >>> > >> it's used by Valve for debugging or something? >> > > > > > >> >>> > >> >> > > > > > >> >>> > >> It's unclear whether any behavioral changes exist - >> > > anyone >> > > > > > found >> > > > > > >> >>> > evidence >> > > > > > >> >>> > >> of any? Unfortunately we got a years worth of SDK >> > code >> > > > > > thrash in >> > > > > > >> one >> > > > > > >> >>> > patch, >> > > > > > >> >>> > >> so it's a bit much to try to code review. >> > > > > > >> >>> > >> >> > > > > > >> >>> > >> -bk >> > > > > > >> >>> > >> >> > > > > > >> >>> > >> _______________________________________________ >> > > > > > >> >>> > >> To unsubscribe, edit your list preferences, or view >> > the >> > > > list >> > > > > > >> >>> archives, >> > > > > > >> >>> > >> please visit: >> > > > > > >> >>> > >> >> > http://list.valvesoftware.com/mailman/listinfo/hlcoders >> > > > > > >> >>> > >> >> > > > > > >> >>> > >> >> > > > > > >> >>> > >-- >> > > > > > >> >>> > > >> > > > > > >> >>> > >_______________________________________________ >> > > > > > >> >>> > >To unsubscribe, edit your list preferences, or view >> the >> > > list >> > > > > > >> archives, >> > > > > > >> >>> > please visit: >> > > > > > >> >>> > > >> http://list.valvesoftware.com/mailman/listinfo/hlcoders >> > > > > > >> >>> > >> > > > > > >> >>> > _______________________________________________ >> > > > > > >> >>> > To unsubscribe, edit your list preferences, or view the >> > > list >> > > > > > >> archives, >> > > > > > >> >>> > please visit: >> > > > > > >> >>> > http://list.valvesoftware.com/mailman/listinfo/hlcoders >> > > > > > >> >>> > >> > > > > > >> >>> > >> > > > > > >> >>> -- >> > > > > > >> >>> >> > > > > > >> >>> _______________________________________________ >> > > > > > >> >>> To unsubscribe, edit your list preferences, or view the >> > list >> > > > > > archives, >> > > > > > >> >>> please visit: >> > > > > > >> >>> http://list.valvesoftware.com/mailman/listinfo/hlcoders >> > > > > > >> >>> >> > > > > > >> >>> >> > > > > > >> >>-- >> > > > > > >> >> >> > > > > > >> >>_______________________________________________ >> > > > > > >> >>To unsubscribe, edit your list preferences, or view the >> list >> > > > > > archives, >> > > > > > >> please visit: >> > > > > > >> >>http://list.valvesoftware.com/mailman/listinfo/hlcoders >> > > > > > >> >> >> > > > > > >> > >> > > > > > >> >_______________________________________________ >> > > > > > >> >To unsubscribe, edit your list preferences, or view the list >> > > > > > archives, >> > > > > > >> please visit: >> > > > > > >> >http://list.valvesoftware.com/mailman/listinfo/hlcoders >> > > > > > >> >> > > > > > >> _______________________________________________ >> > > > > > >> To unsubscribe, edit your list preferences, or view the list >> > > > > > archives, >> > > > > > >> please visit: >> > > > > > >> http://list.valvesoftware.com/mailman/listinfo/hlcoders >> > > > > > >> >> > > > > > >> >> > > > > > >-- >> > > > > > > >> > > > > > >_______________________________________________ >> > > > > > >To unsubscribe, edit your list preferences, or view the list >> > > > archives, >> > > > > > please visit: >> > > > > > >http://list.valvesoftware.com/mailman/listinfo/hlcoders >> > > > > > >> > > > > > _______________________________________________ >> > > > > > To unsubscribe, edit your list preferences, or view the list >> > > archives, >> > > > > > please visit: >> > > > > > http://list.valvesoftware.com/mailman/listinfo/hlcoders >> > > > > > >> > > > > > >> > > > > >> > > > -- >> > > > >> > > > _______________________________________________ >> > > > To unsubscribe, edit your list preferences, or view the list >> archives, >> > > > please visit: >> > > > http://list.valvesoftware.com/mailman/listinfo/hlcoders >> > > > >> > > > >> > > -- >> > > >> > > _______________________________________________ >> > > To unsubscribe, edit your list preferences, or view the list archives, >> > > please visit: >> > > http://list.valvesoftware.com/mailman/listinfo/hlcoders >> > > >> > > >> > -- >> > >> > _______________________________________________ >> > To unsubscribe, edit your list preferences, or view the list archives, >> > please visit: >> > http://list.valvesoftware.com/mailman/listinfo/hlcoders >> > >> > >> -- >> >> _______________________________________________ >> To unsubscribe, edit your list preferences, or view the list archives, >> please visit: >> http://list.valvesoftware.com/mailman/listinfo/hlcoders >> >> >-- > >_______________________________________________ >To unsubscribe, edit your list preferences, or view the list archives, please >visit: >http://list.valvesoftware.com/mailman/listinfo/hlcoders _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
