Yeah, that's because the new SDK has the lag compensation code back in. -Mike
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Benjamin Davison Sent: Wednesday, November 01, 2006 2:04 AM To: [email protected] Subject: Re: [hlcoders] poorer prediction with new SDK? -- [ Picked text/plain from multipart/alternative ] I got this in my inbox today. [EMAIL PROTECTED] changed: What |Removed |Added ------------------------------------------------------------------------ ---- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- Additional Comments From [EMAIL PROTECTED] 2006-10-31 15:47 ------- The 10/31/2006 SDK release supports both Visual Studio 2005 and Visual Studio 2003. On 10/31/06, Nick <[EMAIL PROTECTED]> wrote: > > Is the next update still on for next week? > > On 10/11/06, Mike Durand <[EMAIL PROTECTED]> wrote: > > 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/listin > > > >> > > > > > >> >>> > fo/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/h > > > >> > > > > > >> >>lcod > > > >> > > > > > >> >>ers > > > >> > > > > > >> >> > > > >> > > > > > >> > > > > >> > > > > > >> >_______________________________________________ > > > >> > > > > > >> >To unsubscribe, edit your list preferences, or > > > >> > > > > > >> >view the list > > > >> > > > > > archives, > > > >> > > > > > >> please visit: > > > >> > > > > > >> >http://list.valvesoftware.com/mailman/listinfo/hl > > > >> > > > > > >> >code > > > >> > > > > > >> >rs > > > >> > > > > > >> > > > >> > > > > > >> _______________________________________________ > > > >> > > > > > >> To unsubscribe, edit your list preferences, or > > > >> > > > > > >> view the list > > > >> > > > > > archives, > > > >> > > > > > >> please visit: > > > >> > > > > > >> http://list.valvesoftware.com/mailman/listinfo/hlc > > > >> > > > > > >> oder > > > >> > > > > > >> s > > > >> > > > > > >> > > > >> > > > > > >> > > > >> > > > > > >-- > > > >> > > > > > > > > > >> > > > > > >_______________________________________________ > > > >> > > > > > >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/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 > > -- - Benjamin Davison -- _______________________________________________ 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
