-- [ 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
