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