Hi All- I'm working through the Visual Studio 2005 SDK work. So once I'm done making sure that it works using both 2003 and 2005 I will put it out. Probably some time next week.
With regard to the lag compensation - that code will be back in the SDK with the next release. -Mike -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nick Sent: Tuesday, October 10, 2006 1:13 PM To: [email protected] Subject: Re: [hlcoders] poorer prediction with new SDK? I wonder when the next sdk code update will be released? On 10/7/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > 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/h > >> > > > > > >> >>> > lcoders > >> > > > > > >> >>> > > >> > > > > > >> >>> > > >> > > > > > >> >>> -- > >> > > > > > >> >>> > >> > > > > > >> >>> _______________________________________________ > >> > > > > > >> >>> To unsubscribe, edit your list preferences, or > >> > > > > > >> >>> view the > >> > list > >> > > > > > archives, > >> > > > > > >> >>> please visit: > >> > > > > > >> >>> http://list.valvesoftware.com/mailman/listinfo/hlc > >> > > > > > >> >>> oders > >> > > > > > >> >>> > >> > > > > > >> >>> > >> > > > > > >> >>-- > >> > > > > > >> >> > >> > > > > > >> >>_______________________________________________ > >> > > > > > >> >>To unsubscribe, edit your list preferences, or view > >> > > > > > >> >>the > >> list > >> > > > > > archives, > >> > > > > > >> please visit: > >> > > > > > >> >>http://list.valvesoftware.com/mailman/listinfo/hlcod > >> > > > > > >> >>ers > >> > > > > > >> >> > >> > > > > > >> > > >> > > > > > >> >_______________________________________________ > >> > > > > > >> >To unsubscribe, edit your list preferences, or view > >> > > > > > >> >the list > >> > > > > > archives, > >> > > > > > >> please visit: > >> > > > > > >> >http://list.valvesoftware.com/mailman/listinfo/hlcode > >> > > > > > >> >rs > >> > > > > > >> > >> > > > > > >> _______________________________________________ > >> > > > > > >> To unsubscribe, edit your list preferences, or view > >> > > > > > >> the list > >> > > > > > archives, > >> > > > > > >> please visit: > >> > > > > > >> http://list.valvesoftware.com/mailman/listinfo/hlcoder > >> > > > > > >> s > >> > > > > > >> > >> > > > > > >> > >> > > > > > >-- > >> > > > > > > > >> > > > > > >_______________________________________________ > >> > > > > > >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
