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