Persuter,
Whenever I see strange stuff like that, I have one solution I try first: clean and rebuild all. Using the Edit and Continue in MSVC 6 seems to work fine for awhile, but then I'll start seeing issues like this. I haven't had these problems with other source, but using it with HL code has caused me nothing but problems. The crazy symptoms you are describing make me think you're seeing the same thing. Luckily, the fix is easy. If your machine is acting crazy, reboot. If you're code is random and nuts, rebuild all. :) Woe, is the PC programmer's mentality... Let us know if this clears it up. -Charlie >Send hlcoders mailing list submissions to > [EMAIL PROTECTED] > >To subscribe or unsubscribe via the World Wide Web, visit > http://list.valvesoftware.com/mailman/listinfo/hlcoders >or, via email, send a message with subject or body 'help' to > [EMAIL PROTECTED] > >You can reach the person managing the list at > [EMAIL PROTECTED] > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of hlcoders digest..." > > >Today's Topics: > > 1. RE: SITWFODF1D #1 (Ken Birdwell) > 2. Model sequencing woes - fixed :) (Jeff Fearn) > 3. RE: Sprite problems (Persuter) > 4. Re: 1000+ are nice? (Nathan Taylor) > 5. Entity indices (Georges Giroux) > 6. Re: Sprite problems (Cortex) > 7. RE: Sprite problems (Commando) > 8. SET_SIZE() (Daniel Johansson) > 9. Re: SET_SIZE() (Oskar 'Zoot' Lindgren) > 10. Re: SET_SIZE() (Paul 'MoOg' Samways) > >--__--__-- > >Message: 1 >From: Ken Birdwell <[EMAIL PROTECTED]> >To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> >Subject: RE: [hlcoders] SITWFODF1D #1 >Date: Tue, 23 Apr 2002 13:41:52 -0700 >Reply-To: [EMAIL PROTECTED] > >Good advice. The only hard limitations compilied into the engine are >MAXSTUDIOBONES, MAXSTUDIOVERTS, and MAXSTUDIOCONTROLLERS. The rest can be >changed. > >-----Original Message----- >From: Persuter [mailto:[EMAIL PROTECTED]] >Sent: Tuesday, April 23, 2002 10:08 AM >To: [EMAIL PROTECTED] >Subject: RE: [hlcoders] SITWFODF1D #1 > > >I don't know if this is similar, but: > >On Hostile Intent, we had oodles and oodles of player animations, and >eventually studiomdl started crapping out with amazing memory dump >errors. > >The solution, however, was simple, we simply had to increase >MAXSTUDIOSEQUENCES or MAXSTUDIOANIMATIONS, I forget which one, and >recompile studiomdl and the game, then recompile all the models with the >new studiomdl. I see in studio.h that there is a MAXSTUDIOSKINS variable >as well, set to 100. Perhaps if you increased that to something higher >and recompiled both studiomdl and the game? > >Again, it's a simple fix so you've probably already tried it, it just >seemed similar in many ways to the problem we were having (Valve's code >pooping out due to throwing way more at it than it was meant to handle). > > >Persuter > > >--__--__-- > >Message: 2 >From: "Jeff Fearn" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Date: Wed, 24 Apr 2002 07:27:34 +1000 >Subject: [hlcoders] Model sequencing woes - fixed :) >Reply-To: [EMAIL PROTECTED] > >As we seem to be sharing fixes for strange behavior, I thought I'd share >my latest >... "experience" with you. > >I have been having a problem where the incorrect animation would be >displayed for >a player, seemingly at random. So instead of running a player would swim, >or it >would say sequence 77 not in model hgrunt etc. Each class in our mod has >it's own >model, and each model only has animations for each of the weapons it uses, >no more >than 10 per class. I originally thought this was due to animations being >incorrectly named in the model, however this would only explain problems >displaying weapon animations, and should not have affected action >animations, like >swimming or running. > >The real problem was that, for some odd reason, g_ulModelIndexPlayer was being >used to reset the players pev->modelindex at every spawn. This had the >effect of >making every player reference, but not display, the model for the class of the >player that was spawned last. Thus if run, swim etc where in a different >order in >a model then the incorrect sequence would be displayed. Also as different >classes >had different weapons, which is almost always true, then it would fail to >find the >correct weapon sequence, even though it was in the players model. Needles >to say >this was a real pain in the ass to work out, especially as I had never >used, or >even noticed, g_ulModelIndexPlayer. > >The moral is that if you use models with different sequences, or different >sequence order, then you should comment out references to >g_ulModelIndexPlayer. I >have commented them all out and have not seen any effects, other than the >correct >sequences being displayed :} > >Hope this saves someone a brain tumor ;) > >Jeff "DarthBobo" Fearn >----------------------------------------------------------------- >Lead Coder, Web Master, Server Administrator for SWARM >http://swarm.edgegaming.com >----------------------------------------------------------------- > > >--__--__-- > >Message: 3 >From: "Persuter" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Subject: RE: [hlcoders] Sprite problems >Date: Tue, 23 Apr 2002 18:38:28 -0500 >Reply-To: [EMAIL PROTECTED] > >Further troubles... I tried making this a non-static function, but that >didn't work either. But here's the REALLY weird part. I was stepping >through the new function in the debugger: > >CSprite* CStreetlamp::MakeSprite( const char* pSpriteName, const Vector >&origin, BOOL animate ) >{ > CSprite* pSprite = GetClassPtr( (CSprite *)NULL ); > pSprite->SpriteInit( pSpriteName, origin ); > pSprite->pev->classname = MAKE_STRING("env_sprite"); > pSprite->pev->solid = SOLID_NOT; > pSprite->pev->movetype = MOVETYPE_NOCLIP; > if ( animate ) > pSprite->TurnOn(); > > return pSprite; >} > >It has the exact same error as before. However, I noticed that as I step >through the function that the value of this, i.e., the street lamp, >changes three times. First it goes to some seemingly random memory >location, then it changes to 1, then it goes back to its regular >location. Is that CRAZY or what? > >Upon further inspection, I found that in addition to this calamity, the >Keyvalue function for the entity is not being called at all. This, too, >seems a bit odd. My suspicion was that somehow the game is stumbling >over some of the fgd files and somehow, some way, that's messing up the >files. > >However, I then dropped into the disassembler to check what the assembly >had to say about it, and learned to my shock that CSprite* pSprite = >GetClassPtr( (CSprite *)NULL ); has absolutely no assembly counterpart. >In other words, the compiler is somehow skipping right the f**k over it. > >I have absolutely no clue. I'm going to try recompiling all the maps and >the models involved in the hopes that somehow this will fix itself. Is >there anyone who's had a similar problem with GetClassPtr? The rest of >them seem to be compiling so I can't imagine it's a problem with the >template implementation, but the problems like KeyValue suggest to me >that it's a run-time problem of some sort, because the fact that >GetClassPtr didn't compile shouldn't do anything to KeyValue... > >Persuter > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:hlcoders- > > [EMAIL PROTECTED]] On Behalf Of Persuter > > Sent: Monday, April 22, 2002 6:42 PM > > To: [EMAIL PROTECTED] > > Subject: [hlcoders] Sprite problems > > > > Hey all, having a bit of a problem here: > > > > CSprite *CSprite::SpriteCreate( const char *pSpriteName, const Vector > > &origin, BOOL animate ) > > { > > CSprite* pSprite = GetClassPtr( (CSprite *)NULL ); <-- This line > > pSprite->SpriteInit( pSpriteName, origin ); > > pSprite->pev->classname = MAKE_STRING("env_sprite"); > > pSprite->pev->solid = SOLID_NOT; > > pSprite->pev->movetype = MOVETYPE_NOCLIP; > > if ( animate ) > > pSprite->TurnOn(); > > > > return pSprite; > > } > > > > For some reason, when I execute the following code with > > "sprites/glow01.spr", multiple times, the indicated line doesn't >execute > > at all except for one instance, the last that is tried. When I use the > > debugger, it completely steps over the line, even when I try to step > > into GetClassPtr. It's like the line doesn't exist... I try pleading > > with the debugger, pointing at the line very insistently and so forth, > > but to no avail. > > > > Anyway, so it doesn't execute the line, which means that pSprite does > > not exist. This does not trouble the program, however, which happily > > goes along executing the rest of the code, even while the debugger >shows > > that pSprite doesn't exist. If I step into the function and check the > > value of this, I find that indeed it DOES have an address. But that > > address is never returned, and the program proceeds as if nothing had > > been returned from the function at all! It doesn't even throw errors. > > It's very odd. > > > > Any ideas? > > > > Persuter > > > > > > _________________________________________________________ > > Do You Yahoo!? > > Get your free @yahoo.com address at http://mail.yahoo.com > > > > _______________________________________________ > > To unsubscribe, edit your list preferences, or view the list archives, > > please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > >_________________________________________________________ >Do You Yahoo!? >Get your free @yahoo.com address at http://mail.yahoo.com > > >--__--__-- > >Message: 4 >From: "Nathan Taylor" <[EMAIL PROTECTED]> >To: "HLCoders" <[EMAIL PROTECTED]> >Subject: Re: [hlcoders] 1000+ are nice? >Date: Tue, 23 Apr 2002 18:19:57 -0400 >Reply-To: [EMAIL PROTECTED] > >-- >[ Picked text/plain from multipart/alternative ] >Oh I see! > >or no block at all ;) > >Thanks, >Lakario > >----- Original Message ----- >From: Josh Coyne >Sent: Tuesday, April 23, 2002 8:38 AM >To: [EMAIL PROTECTED] >Subject: Re: [hlcoders] 1000+ are nice? > >I think that was their 'streaming' software screwing up on you. > >An ingenious way to bypass the strict memory limitations of the PS2 was to >chop up the city streets into blocks and only render the block you're in(and >maybe some neighboring blocks) > >----- Original Message ----- >From: "Nathan Taylor" <[EMAIL PROTECTED]> >To: "HLCoders" <[EMAIL PROTECTED]> >Sent: Tuesday, April 23, 2002 3:40 AM >Subject: Re: [hlcoders] 1000+ are nice? > > >-- >[ Picked text/plain from multipart/alternative ] >One problem with LOD is that if you don't do it just perfect you get some >really nasty effects. Take GTA3 for example. Since the game contains so >many thousands of polys on the screen at once they created an LOD but the >problem is the LOD has difficult determining you distance, I was driving >down the road when the road literally disappeared because I "wasn't" close >enough to it. I personally don't know how hard it is to master, but Rockstar >is a very competent development team and they obviously had difficulty. > >- Lakario > >----- Original Message ----- >From: Sebastian Steinlechner >Sent: Monday, April 22, 2002 2:52 PM >To: [EMAIL PROTECTED] >Subject: Re: [hlcoders] 1000+ are nice? > > > yeah i guess they are, but by the time CZ comes out Unreal2 with its > > 5000+ tri models and 100,000 wpolys (that's on a geforce2 even) will be > > out too... > >Actually, you can't tell me there are really 100,000 polys on the screen. >But it looks like. I guess the biggest thing why the HL engine is outdated >is the fact that it does not support LOD. Take Serious Sam as an example. >There you can define that e.g. stairs automagically reduce their poly count >when you move away from them. You don't really notice it, and it saves a lot >of polygons. Same with models. Though you can implement a simple lod for >player models in HL (just as HolyWars did, IIRC). >And HL still supports full software rendering. You can image that eats a >hell lot of cpu time. Even if you are in hardware mode. > >I might be wrong with that, but that's how I see it. > >cya, >TheTinySteini > >_______________________________________________ >To unsubscribe, edit your list preferences, or view the list archives, >please visit: >http://list.valvesoftware.com/mailman/listinfo/hlcodersGet more from the >Web. FREE MSN Explorer download : http://explorer.msn.com >_______________________________________________ >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/hlcodersGet more from the >Web. FREE MSN Explorer download : http://explorer.msn.com > >--__--__-- > >Message: 5 >From: "Georges Giroux" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Date: Tue, 23 Apr 2002 23:25:19 -0400 >Subject: [hlcoders] Entity indices >Reply-To: [EMAIL PROTECTED] > >Hello everyone, > >I was just wondering if player indices (1-32) are assigned once >and reserved for a player? Or do they change everytime a player dies? > >Basically, I'm sending a message with a player entity index (with >entindex()) >to all clients, and on the client side, in GameStudioModelRenderer, >I check the current entity's index and if it matches, I render a particle >system >for that entity. > >The only problem is, as I add bots to the game, it seems like the entity >indices >get changed everytime a bot or player dies (I know this since a particle >system >spawns on the wrong player). Is this correct? > >Thanks! > >Georges > > >--__--__-- > >Message: 6 >From: "Cortex" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Subject: Re: [hlcoders] Sprite problems >Date: Tue, 23 Apr 2002 12:27:38 +0200 >Reply-To: [EMAIL PROTECTED] > >Rebuild ALL ??? > > - Cortex : mapper & coder www.hlalbator.fr.st > >----- Original Message ----- >From: "Persuter" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Sent: Tuesday, April 23, 2002 1:42 AM >Subject: [hlcoders] Sprite problems > > > > Hey all, having a bit of a problem here: > > > > CSprite *CSprite::SpriteCreate( const char *pSpriteName, const Vector > > &origin, BOOL animate ) > > { > > CSprite* pSprite = GetClassPtr( (CSprite *)NULL ); <-- This line > > pSprite->SpriteInit( pSpriteName, origin ); > > pSprite->pev->classname = MAKE_STRING("env_sprite"); > > pSprite->pev->solid = SOLID_NOT; > > pSprite->pev->movetype = MOVETYPE_NOCLIP; > > if ( animate ) > > pSprite->TurnOn(); > > > > return pSprite; > > } > > > > For some reason, when I execute the following code with > > "sprites/glow01.spr", multiple times, the indicated line doesn't execute > > at all except for one instance, the last that is tried. When I use the > > debugger, it completely steps over the line, even when I try to step > > into GetClassPtr. It's like the line doesn't exist... I try pleading > > with the debugger, pointing at the line very insistently and so forth, > > but to no avail. > > > > Anyway, so it doesn't execute the line, which means that pSprite does > > not exist. This does not trouble the program, however, which happily > > goes along executing the rest of the code, even while the debugger shows > > that pSprite doesn't exist. If I step into the function and check the > > value of this, I find that indeed it DOES have an address. But that > > address is never returned, and the program proceeds as if nothing had > > been returned from the function at all! It doesn't even throw errors. > > It's very odd. > > > > Any ideas? > > > > Persuter > > > > > > _________________________________________________________ > > Do You Yahoo!? > > Get your free @yahoo.com address at http://mail.yahoo.com > > > > _______________________________________________ > > To unsubscribe, edit your list preferences, or view the list archives, >please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > > > >--__--__-- > >Message: 7 >Date: Wed, 24 Apr 2002 15:16:43 +0900 >To: [EMAIL PROTECTED] >From: Commando <[EMAIL PROTECTED]> >Subject: RE: [hlcoders] Sprite problems >Reply-To: [EMAIL PROTECTED] > >It sounds to me like the DLL that the game is loading does not match your >source code. Try deleting the DLL in your mod directory, then do a >recompile all. See if the DLL gets copied over properly. See if that helps. > >Rob Prouse >http://www.tourofdutymod.com > >At 06:38 PM 4/23/02 -0500, you wrote: > >Further troubles... I tried making this a non-static function, but that > >didn't work either. But here's the REALLY weird part. I was stepping > >through the new function in the debugger: > > > >CSprite* CStreetlamp::MakeSprite( const char* pSpriteName, const Vector > >&origin, BOOL animate ) > >{ > > CSprite* pSprite = GetClassPtr( (CSprite *)NULL ); > > pSprite->SpriteInit( pSpriteName, origin ); > > pSprite->pev->classname = MAKE_STRING("env_sprite"); > > pSprite->pev->solid = SOLID_NOT; > > pSprite->pev->movetype = MOVETYPE_NOCLIP; > > if ( animate ) > > pSprite->TurnOn(); > > > > return pSprite; > >} > > > >It has the exact same error as before. However, I noticed that as I step > >through the function that the value of this, i.e., the street lamp, > >changes three times. First it goes to some seemingly random memory > >location, then it changes to 1, then it goes back to its regular > >location. Is that CRAZY or what? > > > >Upon further inspection, I found that in addition to this calamity, the > >Keyvalue function for the entity is not being called at all. This, too, > >seems a bit odd. My suspicion was that somehow the game is stumbling > >over some of the fgd files and somehow, some way, that's messing up the > >files. > > > >However, I then dropped into the disassembler to check what the assembly > >had to say about it, and learned to my shock that CSprite* pSprite = > >GetClassPtr( (CSprite *)NULL ); has absolutely no assembly counterpart. > >In other words, the compiler is somehow skipping right the f**k over it. > > > >I have absolutely no clue. I'm going to try recompiling all the maps and > >the models involved in the hopes that somehow this will fix itself. Is > >there anyone who's had a similar problem with GetClassPtr? The rest of > >them seem to be compiling so I can't imagine it's a problem with the > >template implementation, but the problems like KeyValue suggest to me > >that it's a run-time problem of some sort, because the fact that > >GetClassPtr didn't compile shouldn't do anything to KeyValue... > > > >Persuter > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] [mailto:hlcoders- > > > [EMAIL PROTECTED]] On Behalf Of Persuter > > > Sent: Monday, April 22, 2002 6:42 PM > > > To: [EMAIL PROTECTED] > > > Subject: [hlcoders] Sprite problems > > > > > > Hey all, having a bit of a problem here: > > > > > > CSprite *CSprite::SpriteCreate( const char *pSpriteName, const Vector > > > &origin, BOOL animate ) > > > { > > > CSprite* pSprite = GetClassPtr( (CSprite *)NULL ); <-- This line > > > pSprite->SpriteInit( pSpriteName, origin ); > > > pSprite->pev->classname = MAKE_STRING("env_sprite"); > > > pSprite->pev->solid = SOLID_NOT; > > > pSprite->pev->movetype = MOVETYPE_NOCLIP; > > > if ( animate ) > > > pSprite->TurnOn(); > > > > > > return pSprite; > > > } > > > > > > For some reason, when I execute the following code with > > > "sprites/glow01.spr", multiple times, the indicated line doesn't > >execute > > > at all except for one instance, the last that is tried. When I use the > > > debugger, it completely steps over the line, even when I try to step > > > into GetClassPtr. It's like the line doesn't exist... I try pleading > > > with the debugger, pointing at the line very insistently and so forth, > > > but to no avail. > > > > > > Anyway, so it doesn't execute the line, which means that pSprite does > > > not exist. This does not trouble the program, however, which happily > > > goes along executing the rest of the code, even while the debugger > >shows > > > that pSprite doesn't exist. If I step into the function and check the > > > value of this, I find that indeed it DOES have an address. But that > > > address is never returned, and the program proceeds as if nothing had > > > been returned from the function at all! It doesn't even throw errors. > > > It's very odd. > > > > > > Any ideas? > > > > > > Persuter > > > > > > > > > _________________________________________________________ > > > Do You Yahoo!? > > > Get your free @yahoo.com address at http://mail.yahoo.com > > > > > > _______________________________________________ > > > To unsubscribe, edit your list preferences, or view the list archives, > > > please visit: > > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > >_________________________________________________________ > >Do You Yahoo!? > >Get your free @yahoo.com address at http://mail.yahoo.com > > > >_______________________________________________ > >To unsubscribe, edit your list preferences, or view the list archives, > >please visit: > >http://list.valvesoftware.com/mailman/listinfo/hlcoders > > >--__--__-- > >Message: 8 >From: "Daniel Johansson" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Date: Wed, 24 Apr 2002 16:10:46 +0200 >Subject: [hlcoders] SET_SIZE() >Reply-To: [EMAIL PROTECTED] > >This is a multi-part message in MIME format. >-- >[ Picked text/plain from multipart/alternative ] >Hey all! > >Im playing around with models ingame, like spawning player models and then >make them play an animation. >But now I have come to this little problem. I have an entity so the mapper >can choose what model to spawn >and now when I spawn the model I dont know the size of it so I tried a >playermodel and set the size according >to what was set in player.cpp spawn function. But now I was kinda >wondering if there is any way of getting the >size of a model ie GET_SIZE (does not exist btw). Anyone care to enlighten >me on this if they can? > >Thanks > Daniel Johansson > [EMAIL PROTECTED] > >-- > > >--__--__-- > >Message: 9 >From: "Oskar 'Zoot' Lindgren" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Subject: Re: [hlcoders] SET_SIZE() >Date: Wed, 24 Apr 2002 16:16:54 +0200 >Reply-To: [EMAIL PROTECTED] > >ser man p=E5... en svensk till >----- Original Message ----- >From: "Daniel Johansson" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Sent: Wednesday, April 24, 2002 4:10 PM >Subject: [hlcoders] SET_SIZE() > > > > This is a multi-part message in MIME format. > > -- > > [ Picked text/plain from multipart/alternative ] > > Hey all! > > > > Im playing around with models ingame, like spawning player models and the= >n >make them play an animation. > > But now I have come to this little problem. I have an entity so the mappe= >r >can choose what model to spawn > > and now when I spawn the model I dont know the size of it so I tried a >playermodel and set the size according > > to what was set in player.cpp spawn function. But now I was kinda >wondering if there is any way of getting the > > size of a model ie GET_SIZE (does not exist btw). Anyone care to enlighte= >n >me on this if they can? > > > > Thanks > > Daniel Johansson > > [EMAIL PROTECTED] > > > > -- > > > > _______________________________________________ > > To unsubscribe, edit your list preferences, or view the list archives, >please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > > >--__--__-- > >Message: 10 >From: "Paul 'MoOg' Samways" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Subject: Re: [hlcoders] SET_SIZE() >Date: Wed, 24 Apr 2002 16:42:24 +0100 >Reply-To: [EMAIL PROTECTED] > >*cough* english mailing list *cough* > >----- Original Message ----- >From: "Oskar 'Zoot' Lindgren" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Sent: Wednesday, April 24, 2002 3:16 PM >Subject: Re: [hlcoders] SET_SIZE() > > >ser man p=E5... en svensk till >----- Original Message ----- >From: "Daniel Johansson" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Sent: Wednesday, April 24, 2002 4:10 PM >Subject: [hlcoders] SET_SIZE() > > > > This is a multi-part message in MIME format. > > -- > > [ Picked text/plain from multipart/alternative ] > > Hey all! > > > > Im playing around with models ingame, like spawning player models and the= >n >make them play an animation. > > But now I have come to this little problem. I have an entity so the mappe= >r >can choose what model to spawn > > and now when I spawn the model I dont know the size of it so I tried a >playermodel and set the size according > > to what was set in player.cpp spawn function. But now I was kinda >wondering if there is any way of getting the > > size of a model ie GET_SIZE (does not exist btw). Anyone care to enlighte= >n >me on this if they can? > > > > Thanks > > Daniel Johansson > > [EMAIL PROTECTED] > > > > -- > > > > _______________________________________________ > > 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 > > > >End of hlcoders Digest Charlie Cleveland Game programmer and designer http://www.natural-selection.org [EMAIL PROTECTED] _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
