The kind of stats that are collected in the files that we exclude from the SDK are mostly things like you see on this page: http://www.steampowered.com/status/ep1/
Obviously we've cooridinated the collection of game stats with the a particular steampowered.com web page and we'd prefer not to share the code that handles the transport between the game and our Steam servers. But as I said earlier we aren't doing anything particularly fancy so we think that the best thing would be for mod makers to come up with their own back-channel for their own game stats to their own web servers. I think it would be a good idea to add the request for customized columns in the server list and see if other people in the community agree that it would be an attractive feature. Please include a couple of real-life example columns you are interested in having. -Mike -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, October 10, 2006 7:02 PM To: [email protected] Subject: RE: [hlcoders] poorer prediction with new SDK? What kind of stats are you talking about? Like in game stats like the gamespy program sort of allowed or aggregate game stats like http://aoa.planethalflife.gamespy.com/stats/frag-stats.html or something? I guess I should zilla this, but what I'd really like is the ability for a mod to show some more stats on the game in steam, ie add another few columns to the Steam server list page. At 2006/10/10 07:57 PM, Mike Durand wrote: >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/listinf >> > >> > > > > > >> >>> > o >> > >> > > > > > >> >>> > /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/hl >> > >> > > > > > >> >>c >> > >> > > > > > >> >>od >> > >> > > > > > >> >>ers >> > >> > > > > > >> >> >> > >> > > > > > >> > >> > >> > > > > > >> >_______________________________________________ >> > >> > > > > > >> >To unsubscribe, edit your list preferences, or >> > >> > > > > > >> >view > >> > >> > > > > > >> >the list >> > >> > > > > > archives, >> > >> > > > > > >> please visit: >> > >> > > > > > >> >http://list.valvesoftware.com/mailman/listinfo/hlc >> > >> > > > > > >> >o >> > >> > > > > > >> >de >> > >> > > > > > >> >rs >> > >> > > > > > >> >> > >> > > > > > >> _______________________________________________ >> > >> > > > > > >> To unsubscribe, edit your list preferences, or view >> > >> > > > > > >> the list >> > >> > > > > > archives, >> > >> > > > > > >> please visit: >> > >> > > > > > >> http://list.valvesoftware.com/mailman/listinfo/hlco >> > >> > > > > > >> d >> > >> > > > > > >> er >> > >> > > > > > >> s >> > >> > > > > > >> >> > >> > > > > > >> >> > >> > > > > > >-- >> > >> > > > > > > >> > >> > > > > > >_______________________________________________ >> > >> > > > > > >To unsubscribe, edit your list preferences, or view >> > >> > > > > > >the list >> > >> > > > archives, >> > >> > > > > > please visit: >> > >> > > > > > >http://list.valvesoftware.com/mailman/listinfo/hlcode >> > >> > > > > > >r >> > >> > > > > > >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 >> >> > > >-- >- 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 _______________________________________________ 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
