Well, there is a gamestats.cpp and a gamestats.h in our production build we kinda left that out on purpose for now because we don't mods to cause stats traffic problems on our Steam servers. Our stats implementation is very much bound to Steam at this point and we would potentially be opening ourselves up for a security problem if we expose those APIs.
I talked to the engineer who implemented the game stats and he says that he thinks the best thing to do would be for mods to roll their own stats solution since there isn't anything miraculous in the gamestats.cpp and gamestats.h files that we are excluding. All that we're doing is creating an object that can serialize itself over a the wire, unserializing it on the other side, and inserting data into a SQL database. We happen to be doing this through the engine, but there's no reason you couldn't implement this completely in the server. You could even make SQL calls from the server DLL if you didn't want to bother with the serialization bit. -Mike -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Benjamin Davison Sent: Tuesday, October 10, 2006 5:27 PM To: [email protected] Subject: Re: [hlcoders] poorer prediction with new SDK? -- [ Picked text/plain from multipart/alternative ] Good to know Mike, but I have a request to make :) Is there any chance we could get the stats upload code? And the corresponding webpage code you guys use? I think that would be interesting to have a look at and to be able to use :D 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/listinfo > > >> > > > > > >> >>> > /h > > >> > > > > > >> >>> > lcoders > > >> > > > > > >> >>> > > > >> > > > > > >> >>> > > > >> > > > > > >> >>> -- > > >> > > > > > >> >>> > > >> > > > > > >> >>> _______________________________________________ > > >> > > > > > >> >>> To unsubscribe, edit your list preferences, or > > >> > > > > > >> >>> view the > > >> > list > > >> > > > > > archives, > > >> > > > > > >> >>> please visit: > > >> > > > > > >> >>> http://list.valvesoftware.com/mailman/listinfo/h > > >> > > > > > >> >>> lc > > >> > > > > > >> >>> oders > > >> > > > > > >> >>> > > >> > > > > > >> >>> > > >> > > > > > >> >>-- > > >> > > > > > >> >> > > >> > > > > > >> >>_______________________________________________ > > >> > > > > > >> >>To unsubscribe, edit your list preferences, or > > >> > > > > > >> >>view the > > >> list > > >> > > > > > archives, > > >> > > > > > >> please visit: > > >> > > > > > >> >>http://list.valvesoftware.com/mailman/listinfo/hlc > > >> > > > > > >> >>od > > >> > > > > > >> >>ers > > >> > > > > > >> >> > > >> > > > > > >> > > > >> > > > > > >> >_______________________________________________ > > >> > > > > > >> >To unsubscribe, edit your list preferences, or view > > >> > > > > > >> >the list > > >> > > > > > archives, > > >> > > > > > >> please visit: > > >> > > > > > >> >http://list.valvesoftware.com/mailman/listinfo/hlco > > >> > > > > > >> >de > > >> > > > > > >> >rs > > >> > > > > > >> > > >> > > > > > >> _______________________________________________ > > >> > > > > > >> To unsubscribe, edit your list preferences, or view > > >> > > > > > >> the list > > >> > > > > > archives, > > >> > > > > > >> please visit: > > >> > > > > > >> http://list.valvesoftware.com/mailman/listinfo/hlcod > > >> > > > > > >> er > > >> > > > > > >> s > > >> > > > > > >> > > >> > > > > > >> > > >> > > > > > >-- > > >> > > > > > > > > >> > > > > > >_______________________________________________ > > >> > > > > > >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 > > -- - 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
