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