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/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 _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
