--
[ 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/listinfo/h
> > > >> > > > > > >> >>> > lcoders
> > > >> > > > > > >> >>> >
> > > >> > > > > > >> >>> >
> > > >> > > > > > >> >>> --
> > > >> > > > > > >> >>>
> > > >> > > > > > >> >>> _______________________________________________
> > > >> > > > > > >> >>> To unsubscribe, edit your list preferences, or
> > > >> > > > > > >> >>> view the
> > > >> > list
> > > >> > > > > > archives,
> > > >> > > > > > >> >>> please visit:
> > > >> > > > > > >> >>> http://list.valvesoftware.com/mailman/listinfo/hlc
> > > >> > > > > > >> >>> oders
> > > >> > > > > > >> >>>
> > > >> > > > > > >> >>>
> > > >> > > > > > >> >>--
> > > >> > > > > > >> >>
> > > >> > > > > > >> >>_______________________________________________
> > > >> > > > > > >> >>To unsubscribe, edit your list preferences, or view
> > > >> > > > > > >> >>the
> > > >> list
> > > >> > > > > > archives,
> > > >> > > > > > >> please visit:
> > > >> > > > > > >> >>http://list.valvesoftware.com/mailman/listinfo/hlcod
> > > >> > > > > > >> >>ers
> > > >> > > > > > >> >>
> > > >> > > > > > >> >
> > > >> > > > > > >> >_______________________________________________
> > > >> > > > > > >> >To unsubscribe, edit your list preferences, or view
> > > >> > > > > > >> >the list
> > > >> > > > > > archives,
> > > >> > > > > > >> please visit:
> > > >> > > > > > >> >http://list.valvesoftware.com/mailman/listinfo/hlcode
> > > >> > > > > > >> >rs
> > > >> > > > > > >>
> > > >> > > > > > >> _______________________________________________
> > > >> > > > > > >> To unsubscribe, edit your list preferences, or view
> > > >> > > > > > >> the list
> > > >> > > > > > archives,
> > > >> > > > > > >> please visit:
> > > >> > > > > > >> http://list.valvesoftware.com/mailman/listinfo/hlcoder
> > > >> > > > > > >> s
> > > >> > > > > > >>
> > > >> > > > > > >>
> > > >> > > > > > >--
> > > >> > > > > > >
> > > >> > > > > > >_______________________________________________
> > > >> > > > > > >To unsubscribe, edit your list preferences, or view the
> > > >> > > > > > >list
> > > >> > > > archives,
> > > >> > > > > > please visit:
> > > >> > > > > > >http://list.valvesoftware.com/mailman/listinfo/hlcoders
> > > >> > > > > >
> > > >> > > > > > _______________________________________________
> > > >> > > > > > To unsubscribe, edit your list preferences, or view the
> > > >> > > > > > list
> > > >> > > archives,
> > > >> > > > > > please visit:
> > > >> > > > > > http://list.valvesoftware.com/mailman/listinfo/hlcoders
> > > >> > > > > >
> > > >> > > > > >
> > > >> > > > >
> > > >> > > > --
> > > >> > > >
> > > >> > > > _______________________________________________
> > > >> > > > To unsubscribe, edit your list preferences, or view the list
> > > >> archives,
> > > >> > > > please visit:
> > > >> > > > http://list.valvesoftware.com/mailman/listinfo/hlcoders
> > > >> > > >
> > > >> > > >
> > > >> > > --
> > > >> > >
> > > >> > > _______________________________________________
> > > >> > > To unsubscribe, edit your list preferences, or view the list
> > > >> > > archives, please visit:
> > > >> > > http://list.valvesoftware.com/mailman/listinfo/hlcoders
> > > >> > >
> > > >> > >
> > > >> > --
> > > >> >
> > > >> > _______________________________________________
> > > >> > To unsubscribe, edit your list preferences, or view the list
> > > >> > archives, please visit:
> > > >> > http://list.valvesoftware.com/mailman/listinfo/hlcoders
> > > >> >
> > > >> >
> > > >> --
> > > >>
> > > >> _______________________________________________
> > > >> To unsubscribe, edit your list preferences, or view the list
> > > >> archives, please visit:
> > > >> http://list.valvesoftware.com/mailman/listinfo/hlcoders
> > > >>
> > > >>
> > > >--
> > > >
> > > >_______________________________________________
> > > >To unsubscribe, edit your list preferences, or view the list
> > archives, please visit:
> > > >http://list.valvesoftware.com/mailman/listinfo/hlcoders
> > >
> > > _______________________________________________
> > > To unsubscribe, edit your list preferences, or view the list archives,
> > please visit:
> > > http://list.valvesoftware.com/mailman/listinfo/hlcoders
> > >
> > >
> >
> > _______________________________________________
> > To unsubscribe, edit your list preferences, or view the list archives,
> > please visit:
> > http://list.valvesoftware.com/mailman/listinfo/hlcoders
> >
> >
> > _______________________________________________
> > To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> > http://list.valvesoftware.com/mailman/listinfo/hlcoders
> >
> >
>
> _______________________________________________
> 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

Reply via email to