Re: [hlcoders] TF2 style player collisions

[Adrian Finol]

TF2 players are only solid to enemies. The way we do all the soft
collision behavior on the client is by modifying their user commands.

Basically we figure out if you're near a non-solid team mate and modify
your forwardmove and sidemoves accordingly. Doing it this way is why it
feels smooth and prevents any prediction problems you'd run into
otherwise.

I'll talk to Mike about releasing the TF2 avoidance code either in the
SDK or maybe we'll put it on the developer page.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Maarten De
Meyer
Sent: Thursday, August 14, 2008 11:54 PM
To: Discussion of Half-Life Programming
Subject: Re: [hlcoders] TF2 style player collisions

Well I've managed to disable collisions based on team in the meantime,
but
don't have the soft physics push. Mind you I'm still in the ep1 engine.
Basically, I had already added a custom filter to the TracePlayerBBox in
gamemovement.cpp to filter gamemovement for my mod ( players can walk
through forcefields, but only belonging to their team ). I just added
the
condition for players of the same team to that filter. So they're not
blocking eachother anymore when casting rays for their movement.
VPhysics
has not been an issue at all for me, there's no collision.

> I'm looking for the same check the "Player collisions, enemies vs
> friendlies." thread for more details. I still haven't found a fix to
> the prediction issues (if you have any insight, let me know).
>
> On Tue, Aug 12, 2008 at 5:43 AM, Maarten De Meyer
<[EMAIL PROTECTED]>
> wrote:
>> Hi list,
>>
>> In my mod by default players collide ( hard ) against eachother. For
>> obvious reasons I want to disable this for teammates and rather have
a
>> soft collision/physics push like in TF2, where you still have the
option
>> to clip through a teammate if you want to, but you do get a slight
>> physics
>> resistance when you do.
>>
>> I know this isn't that hard, just wondering if someone had done it
>> before
>> and could point me in the right direction for the soft push part, I'm
>> not
>> too at home in Source's physics.
>>
>> -- Maarten
>>
>>
>> ___
>> 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

Re: [hlcoders] TF2 style player collisions

[Adrian Finol]

By the way, this is based on HL2's player push code for NPCs, so you can
look at that to get an idea on how the TF2 does it. 


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Daniel
Menard
Sent: Monday, August 18, 2008 1:20 PM
To: Discussion of Half-Life Programming
Subject: Re: [hlcoders] TF2 style player collisions

That would be very helpful. It's a common piece of code a lot of mods
want to implement.

Dan

On Fri, Aug 15, 2008 at 9:49 PM, Adrian Finol <[EMAIL PROTECTED]>
wrote:
> TF2 players are only solid to enemies. The way we do all the soft
> collision behavior on the client is by modifying their user commands.
>
> Basically we figure out if you're near a non-solid team mate and
modify
> your forwardmove and sidemoves accordingly. Doing it this way is why
it
> feels smooth and prevents any prediction problems you'd run into
> otherwise.
>
> I'll talk to Mike about releasing the TF2 avoidance code either in the
> SDK or maybe we'll put it on the developer page.
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Maarten
De
> Meyer
> Sent: Thursday, August 14, 2008 11:54 PM
> To: Discussion of Half-Life Programming
> Subject: Re: [hlcoders] TF2 style player collisions
>
> Well I've managed to disable collisions based on team in the meantime,
> but
> don't have the soft physics push. Mind you I'm still in the ep1
engine.
> Basically, I had already added a custom filter to the TracePlayerBBox
in
> gamemovement.cpp to filter gamemovement for my mod ( players can walk
> through forcefields, but only belonging to their team ). I just added
> the
> condition for players of the same team to that filter. So they're not
> blocking eachother anymore when casting rays for their movement.
> VPhysics
> has not been an issue at all for me, there's no collision.
>
>> I'm looking for the same check the "Player collisions, enemies vs
>> friendlies." thread for more details. I still haven't found a fix to
>> the prediction issues (if you have any insight, let me know).
>>
>> On Tue, Aug 12, 2008 at 5:43 AM, Maarten De Meyer
> <[EMAIL PROTECTED]>
>> wrote:
>>> Hi list,
>>>
>>> In my mod by default players collide ( hard ) against eachother. For
>>> obvious reasons I want to disable this for teammates and rather have
> a
>>> soft collision/physics push like in TF2, where you still have the
> option
>>> to clip through a teammate if you want to, but you do get a slight
>>> physics
>>> resistance when you do.
>>>
>>> I know this isn't that hard, just wondering if someone had done it
>>> before
>>> and could point me in the right direction for the soft push part,
I'm
>>> not
>>> too at home in Source's physics.
>>>
>>> -- Maarten
>>>
>>>
>>> ___
>>> 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

Re: [hlcoders] Quick List; Server Browser

[Adrian Finol]

Hey James,

Could you send me a link to your mod? I would like to take a look at why the 
quick list is behaving this way.

As for the search criteria, the list looks for "Not Empty", "Not Full", "VAC 
Enabled" and "No Password.

-Original Message-
From: hlcoders-boun...@list.valvesoftware.com 
[mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of James Gray
Sent: Monday, January 26, 2009 10:33 PM
To: hlcoders@list.valvesoftware.com
Subject: [hlcoders] Quick List; Server Browser

Hey guys,

The new quick list feature does not seem to function properly on mods.
When you do a refresh, it does not show any servers. However, when you
disable the quick list mode, and refresh, the servers do show properly
in the standard server list, and when you re-enable the quick list mode
without refreshing again, it will show the servers from the original
server list in the quick list.

What criteria does the quick list look for in a server when querying the
master? Or would that be relevant at all?

Any help anyone could provide would be greatly appreciated. We believe
it has really hurt the popularity of our mod because it immediately
appears that there are no available servers to play on (since the quick
list is enabled by default). If there is no other alternative, and if it
is at all possible, is there a way to disable the quick list feature in
the server browser in a mod? Perhaps a key in gameinfo.txt?

Thanks for your time,
James


___
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

Re: [hlcoders] Quick List; Server Browser

[Adrian Finol]

I've changed the Map List so it'll ignore ping. This way it'll show every 
server for every map regardless of latency.

It will still only show the one with the lowest ping but now it'll at least 
show a server even if its ping is 1 second.

-Original Message-
From: hlcoders-boun...@list.valvesoftware.com 
[mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of James Gray
Sent: Tuesday, January 27, 2009 3:32 PM
To: Discussion of Half-Life Programming
Subject: Re: [hlcoders] Quick List; Server Browser

Hi Adrian,

Thanks for the reply. You can find the mod @ http://www.stargatetls.net,
though in the current public release we have not yet implemented the
appropriate scheme colors, fonts, map images, etc. to make the "quick
list" look appropriate. After looking at the problem again, it appears
the quick list is actually working properly, but there also seems to be
a latency filter. When I had tested this before, the only servers with
players were in Europe, and so.. yeah you get the picture. :)

So, it seems nothing is wrong after all. Sorry for the false alarm!

Thanks again,
James

Adrian Finol wrote:
> Hey James,
>
> Could you send me a link to your mod? I would like to take a look at why the 
> quick list is behaving this way.
>
> As for the search criteria, the list looks for "Not Empty", "Not Full", "VAC 
> Enabled" and "No Password.
>
> -Original Message-
> From: hlcoders-boun...@list.valvesoftware.com 
> [mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of James Gray
> Sent: Monday, January 26, 2009 10:33 PM
> To: hlcoders@list.valvesoftware.com
> Subject: [hlcoders] Quick List; Server Browser
>
> Hey guys,
>
> The new quick list feature does not seem to function properly on mods.
> When you do a refresh, it does not show any servers. However, when you
> disable the quick list mode, and refresh, the servers do show properly
> in the standard server list, and when you re-enable the quick list mode
> without refreshing again, it will show the servers from the original
> server list in the quick list.
>
> What criteria does the quick list look for in a server when querying the
> master? Or would that be relevant at all?
>
> Any help anyone could provide would be greatly appreciated. We believe
> it has really hurt the popularity of our mod because it immediately
> appears that there are no available servers to play on (since the quick
> list is enabled by default). If there is no other alternative, and if it
> is at all possible, is there a way to disable the quick list feature in
> the server browser in a mod? Perhaps a key in gameinfo.txt?
>
> Thanks for your time,
> James
>
>
> ___
> 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

RE: [hlcoders] Physical Mayhem in progress - no crash! (yet)

[Adrian Finol]

I just tried to reproduce this by following these steps and I couldn't
get it to happen.

This is what I did so let me know if I missed something:

I changed HL2DM's GameInfo.txt to also mount the cstrike folder so I
could load cs_office and all its resources. I loaded HL2DM on msdev and
built that, then I added the propdata folder and renamed Cstrike's
propdata.txt to cs.txt and placed it there.

Loaded cs_office and ran around shooting rockets trying to get as many
physics objects in motion as I could. After 5 minutes running around
everything was behaving fine.

Did I miss anything?



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Garry Newman
Sent: Tuesday, May 23, 2006 8:21 AM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] Physical Mayhem in progress - no crash! (yet)

Hey exactly a month later!

Here's what I'm doing to cause the physical mayhem.

In my mod/scripts folder I made a folder called propdata. I copied
CS:S's propdata.txt to this folder and renamed in cs.txt.

In CPropData::ParsePropDataFile I changed the loadfromfile line to

if ( !m_pKVPropData->LoadFromFile( filesystem,
"scripts/propdata/cs.txt" ) )


So I start my mod and go to cs_office. It's fine for about 20 seconds of
shooting props then they all start bouncing around.


I find that this has prevented it.. (props.cpp:4747)

//LINK_ENTITY_TO_CLASS( prop_physics_multiplayer,
CPhysicsPropMultiplayer );

LINK_ENTITY_TO_CLASS( prop_physics_multiplayer, CPhysicsProp );

Obviously it's going to change all prop_physics_multiplayer into
prop_physics.. so it might not be ideal for your mod. I'm guessing that
my problem is different from yours though, somehow.. even if the
symptoms are the same.



On 4/23/06, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> The mod players were getting restless so I couldn't wait any longer
for a response from Valve so I had to shut it down.  Unfortunately
there's no documentation on how most of that stuff is supposed to work,
and there are frightfully few asserts in the SDK.  I guess I'll have to
do a lot of research to compare a working vphysics.dll to a broken
vphysics.dll in order to pin down the exact problem.
>
> At 2006/04/20 08:03 PM, Aaron Schiff wrote:
> >--
> >[ Picked text/plain from multipart/alternative ]
> >USE_OBB_COLLISION_BOUNDS just says to search within the bounding box
> >constructed around a physical model to detect other objects.  It's
> >not the matter you should be worried about.
> >--
> >
> >___
> >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

RE: [hlcoders] Physical Mayhem in progress - no crash! (yet)

[Adrian Finol]

This works, thanks.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Garry Newman
Sent: Wednesday, May 24, 2006 3:14 AM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] Physical Mayhem in progress - no crash! (yet)

Ok done it. It happens.

I found the exact cause too. When you shoot these pictures they fall on
the other physics objects..

http://www.garry.tv/img/cs_office_phys.jpg

And then the physical mayhem happens. Which is weird because I always
thought those pictures were clientside so they shouldn't even be
touching the other stuff..

Here's the test mod

http://www.garry.tv/img/phys_testmod.zip

And here's the code changes (based on hl2mp mod)

GameInterface.cpp line 493 after TheNavMesh = ...

filesystem->MountSteamContent( 240 );
filesystem->AddSearchPath( "cstrike", "GAME" );

cdll_client_int.cpp line 523 after ClientWorldFactoryInit();

filesystem->MountSteamContent( 240 );
filesystem->AddSearchPath( "cstrike", "GAME" );

props_shared.cpp line195

if ( !m_pKVPropData->LoadFromFile( filesystem, "scripts/propdata_cs.txt"
) )

I changed the spawnpoints to use info_player_counterterrorist too but I
doubt that affected it.



On 5/24/06, Garry Newman <[EMAIL PROTECTED]> wrote:
> Yeah kinda. I'm based off HL2, and mounting CS:S using the
> filesystem->mount and addsearchpath (to tail) commands.
>
> I'll try it with a new mod to make sure it isn't something that only
> happens with GMod..
>
> On 5/23/06, Adrian Finol <[EMAIL PROTECTED]> wrote:
> > I just tried to reproduce this by following these steps and I
> > couldn't get it to happen.
> >
> > This is what I did so let me know if I missed something:
> >
> > I changed HL2DM's GameInfo.txt to also mount the cstrike folder so I

> > could load cs_office and all its resources. I loaded HL2DM on msdev
> > and built that, then I added the propdata folder and renamed
> > Cstrike's propdata.txt to cs.txt and placed it there.
> >
> > Loaded cs_office and ran around shooting rockets trying to get as
> > many physics objects in motion as I could. After 5 minutes running
> > around everything was behaving fine.
> >
> > Did I miss anything?
> >
> >
> >
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of Garry
> > Newman
> > Sent: Tuesday, May 23, 2006 8:21 AM
> > To: hlcoders@list.valvesoftware.com
> > Subject: Re: [hlcoders] Physical Mayhem in progress - no crash!
> > (yet)
> >
> > Hey exactly a month later!
> >
> > Here's what I'm doing to cause the physical mayhem.
> >
> > In my mod/scripts folder I made a folder called propdata. I copied
> > CS:S's propdata.txt to this folder and renamed in cs.txt.
> >
> > In CPropData::ParsePropDataFile I changed the loadfromfile line to
> >
> > if ( !m_pKVPropData->LoadFromFile( filesystem,
> > "scripts/propdata/cs.txt" ) )
> >
> >
> > So I start my mod and go to cs_office. It's fine for about 20
> > seconds of shooting props then they all start bouncing around.
> >
> >
> > I find that this has prevented it.. (props.cpp:4747)
> >
> > //LINK_ENTITY_TO_CLASS( prop_physics_multiplayer,
> > CPhysicsPropMultiplayer );
> >
> > LINK_ENTITY_TO_CLASS( prop_physics_multiplayer, CPhysicsProp );
> >
> > Obviously it's going to change all prop_physics_multiplayer into
> > prop_physics.. so it might not be ideal for your mod. I'm guessing
> > that my problem is different from yours though, somehow.. even if
> > the symptoms are the same.
> >
> >
> >
> > On 4/23/06, [EMAIL PROTECTED]
> > <[EMAIL PROTECTED]> wrote:
> > > The mod players were getting restless so I couldn't wait any
> > > longer
> > for a response from Valve so I had to shut it down.  Unfortunately
> > there's no documentation on how most of that stuff is supposed to
> > work, and there are frightfully few asserts in the SDK.  I guess
> > I'll have to do a lot of research to compare a working vphysics.dll
> > to a broken vphysics.dll in order to pin down the exact problem.
> > >
> > > At 2006/04/20 08:03 PM, Aaron Schiff wrote:
> > > >--
> > > >[ Picked text/plain from multipart/alternative ]
> > > >USE_OBB_COLLISION_BOUNDS just says to search within the bounding
> > > >box constructed around a physical model to detect other objects.

> > > >It's not the matter you

RE: [hlcoders] CrossBow_Bolt: Stick Out More...

[Adrian Finol]

Look for CreateCrossbowBolt inside c_stickybolt.cpp on the client
project, that's where the client side bolt is created.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Gus
Sent: Thursday, December 28, 2006 8:42 AM
To: hlcoders@list.valvesoftware.com
Subject: [hlcoders] CrossBow_Bolt: Stick Out More...

This is a cryptographically signed message in MIME format.
--
Hi all, am trying to figure how to get the CrossBow_Bolt to stick out
more from the wall when shot. Anybody know the answer to this?

Gus
--
Content-Description: S/MIME Cryptographic Signature

[ smime.p7s of type application/x-pkcs7-signature deleted ]
--

___
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

RE: [hlcoders] [OT] question to valve, curious

[Adrian Finol]

 Last time we have you for a sleep over!, I'm telling mom!.

-Original Message-
From: Ken Birdwell
To: '[EMAIL PROTECTED]'
Sent: 12/5/01 6:39 PM
Subject: RE: [hlcoders] [OT] question to valve, curious

"no" sounds kind of nasty, like we're refusing and keeping it to
ourselves.  The answer is "we can't".  The bsp's won't load with your
version of the engine.  A lot of the demo map files are either lost,
changed beyond recognition, never checked in, reference textures that
don't exist anymore, or are interim .rmf versions that WC can't read
anymore.  The monsters either were never finished, were done with out of
date versions of Max, only work in the demo area, only work on privates
builds of the engine, or got cut and AI code for them is long gone and
nasty to try to dig back out.  Our content database also has limits, so
when the level designers are checking in their 1.5MB bsp's once every
few days, it doesn't take long with 115+ files to fill up the database
(most maps went through 30-50 iterations) and things need to get
flushed.  With older content, typically versions only work with very
specific builds of the engine, so we'd have to hunt through and recover
everything in a hopes that just maybe _all_ the different files still
exist somewhere for that date.  You have everything we still have, I
spent quiet a while hunting it down to put in the SDK.
 
Okay, I suspect some of us have CD's buried somewhere at home that have
really early builds of the engine.  But, looking at it critically is
really embarrassing.  You know those school pictures your mom has of you
in 2nd grade wearing that purple and brown velour shirt with you just
after losing your front teeth and you had that really bad haircut your
dad gave you?  Remember those pictures?  Well, without being very very
careful with getting just the right shot, early versions of half-life
look like that, except that it's also just about to sneeze.  Hmm.  Okay,
maybe "no" is the correct answer.
 
 -Original Message-
From: Biggs [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 03, 2001 10:22 PM
To: [EMAIL PROTECTED]
Subject: Re: [hlcoders] [OT] question to valve, curious



I asked this question years ago right after HL was released. The whole
reason i wanted HL was because of most of what i saw in the demos that
never made it in the game. I asked if they would concider releasing the
old maps, monsters and other various stuff as kinda like an SDK addon.
The answer i got was no.
 
~Biggs

- Original Message - 
From: Andrew Foss   
To: [EMAIL PROTECTED]
  
Sent: Tuesday, December 04, 2001 12:59 AM
Subject: [hlcoders] [OT] question to valve, curious

I was digging around in my old CD's box, when I came upon a diamond
viper driver disc. it contained a Half-life trailer.
 
upon watching it, I noticed some cool bits. almost all the monsters in
the demo are not seen in the game. (the models still exist) there are
also a bunch of maps that didn't make the cut. Datacore is an example,
it was originally a singleplayer map.
 
My question is this:
Since HL is actually HL2, because a lot of code, maps, textures, and
models were cut/not in the final game, do you still have any of the old
stuff laying around, and B: would you consider releasing any of it? I
would love to see the original maps, because they look pretty cool.
also, does the smelling gibs code work? can the mosters smell out the
stinky bodies? :)
 
--cannibal

___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

RE: [hlcoders] MOVETYPE_NONE for player

[Adrian Finol]

 Actually, It would be better if you used g_engfuncs.pfnSetClientMaxspeed.

 Setting it to something really low, 1 would do just fine:
 g_engfuncs.pfnSetClientMaxspeed( ENT( player->pev ), 1 );

 The reason I dont recomend using EnableControl, is cause some player gets
halted too ( not only movement ), You'll notice that you wont see players
turn around, or even be affected by gravity.

 Btw, CS uses the MaxSpeed method.


-Original Message-
From: Cortex
To: [EMAIL PROTECTED]
Sent: 12/17/01 12:13 PM
Subject: Re: [hlcoders] MOVETYPE_NONE for player

IT WORKS !!! I love you :-D
 
I've taken a look to EnableControl code. It's quite simple :)
I didn't know the existance of the FL_FROZEN flag, but it's
really useful :)
 

Cortex
HL Albator coder & mapper
www.hlalbator.fr.st  


- Original Message - 
From: Georges   Giroux 
To: [EMAIL PROTECTED]
  
Sent: Monday, December 17, 2001 8:59 PM
Subject: RE: [hlcoders] MOVETYPE_NONE for player

You can use EnableControl(FALSE) in player.cpp, this will freeze
the player on the spot.
 
Georges

-Original Message-
From: [EMAIL PROTECTED]

[mailto:[EMAIL PROTECTED]]On Behalf Of Cortex
Sent: Monday, December 17, 2001 2:53 PM
To: [EMAIL PROTECTED]
 
Subject: Re: [hlcoders] MOVETYPE_NONE for player


I'm trying to prevent the player to move before the
round starts (like in CS : buy time).
 

Cortex
HL Albator coder & mapper
www.hlalbator.fr.st  


- Original Message - 
From: botman   
To: [EMAIL PROTECTED]
  
Sent: Monday, December 17, 2001 8:41 PM
Subject: Re: [hlcoders] MOVETYPE_NONE for player

> I wanted to set the player's movetype to MOVETYPE_NONE.
> I set pev->movetype to MOVETYPE_NONE, but when I play,
> the movetype is MOVETYPE_WALK ! I don't know why !
> I tried debugging it for a day :( In pm_shared.c,
> the ppmode->movetype is MOVETYPE_WALK instead of
> MOVETYPE_NONE :(
>
> If I set player's movetype to MOVETYPE_NOCLIP,
> it takes effect ! So, it's not my code...
>
> Is there anybody else having this trouble ?

Perhaps the engine is automatically changing it to MOVETYPE_WALK in a
similar way that it automatically changes it to MOVETYPE_FLY when the
player
touches a ladder.

Why are you setting the movetype to MOVETYPE_NONE (what are you trying
to
do)?

Jeffrey "botman" Broome


___
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

RE: [hlcoders] GetBonePosition

[Adrian Finol]

 Do you want to get the World position for that bone, or just the relative
position for the bone?.

-Original Message-
From: Patrick Phillips
To: [EMAIL PROTECTED]
Sent: 12/20/01 3:19 AM
Subject: [hlcoders] GetBonePosition

People on the Wavelength forums seem to have a hard time replying to
things 
beyond the usual "How do I make a vehicle?" or "I need help coding my
mod!", 
so I've resorted to using this list (also because Valve reads it too).
GetBonePosition is whack.  In the first and second versions of the SDK 2
it 
worked somewhat correctly, but now it's either giving nothing or crap.
In example, I try to get bone 59 (right hand) in the player/player model
and 
I get (0, 0, 0) for the origin vector.
I made a test file with all bone positions and angles from 0 to 68, and
0 to 
48 had contents, although crap, but all others didn't.
So, I'm thinking this already-buggy function just doesn't work in the
new 
versions.
I'll gladly accept it otherwise if anyone's willing to enlighten me on
"how 
to do it". I'll even post my entire entitie's code for this if that's 
required.

_
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

___
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

RE: [hlcoders] GetBonePosition

[Adrian Finol]

 Well, if it's on the client.dll, you can always get the bone position from
m_rgCachedBoneTransform. That'll give you a world space bone position.

-Original Message-
From: Patrick Phillips
To: [EMAIL PROTECTED]
Sent: 12/20/01 10:52 AM
Subject: RE: [hlcoders] GetBonePosition

It doesn't matter.  I want the world position, but either way it does it
all 
I have to do is either add or subtract the entity's origin.


>From: Adrian Finol <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: 'Patrick Phillips ' <[EMAIL PROTECTED]>, 
>"'[EMAIL PROTECTED] '" <[EMAIL PROTECTED]>
>Subject: RE: [hlcoders] GetBonePosition
>Date: Thu, 20 Dec 2001 07:26:22 -0800
>
>  Do you want to get the World position for that bone, or just the
relative
>position for the bone?.
>
>-Original Message-
>From: Patrick Phillips
>To: [EMAIL PROTECTED]
>Sent: 12/20/01 3:19 AM
>Subject: [hlcoders] GetBonePosition
>
>People on the Wavelength forums seem to have a hard time replying to
>things
>beyond the usual "How do I make a vehicle?" or "I need help coding my
>mod!",
>so I've resorted to using this list (also because Valve reads it too).
>GetBonePosition is whack.  In the first and second versions of the SDK
2
>it
>worked somewhat correctly, but now it's either giving nothing or crap.
>In example, I try to get bone 59 (right hand) in the player/player
model
>and
>I get (0, 0, 0) for the origin vector.
>I made a test file with all bone positions and angles from 0 to 68, and
>0 to
>48 had contents, although crap, but all others didn't.
>So, I'm thinking this already-buggy function just doesn't work in the
>new
>versions.
>I'll gladly accept it otherwise if anyone's willing to enlighten me on
>"how
>to do it". I'll even post my entire entitie's code for this if that's
>required.
>
>_
>MSN Photos is the easiest way to share and print your photos:
>http://photos.msn.com/support/worldwide.aspx
>
>___
>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
>


_
Send and receive Hotmail on your mobile device: http://mobile.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/hlcoders

RE: [hlcoders] Items.cpp (MyTouch)

[Adrian Finol]

#define TE_BOX  31
// coord, coord, coord  boxmins
// coord, coord, coord  boxmaxs
// short life in 0.1 s
// 3 bytes r, g, b

Use that TempEnt on the server.

- Adrian


-Original Message-
From: Yacketta, Ronald [mailto:[EMAIL PROTECTED]]
Sent: Saturday, January 05, 2002 6:34 AM
To: [EMAIL PROTECTED]
Subject: RE: [hlcoders] Items.cpp (MyTouch)


Thanxs folks!

Another question, I am looking to physically display the FB's
UTIL_SetSize() in the game under
DEBUG conditions. What could I use to display this? Maybe a triapi? Not
sure...

-Ron

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Reedbeta
Sent: Friday, January 04, 2002 9:11 PM
To: [EMAIL PROTECTED]
Subject: Re: [hlcoders] Items.cpp (MyTouch)


> If you are using UTIL_FindEntityByClassname() for "player"

Or if you're using any other method of locating players.  The point is,
subtract the grenade's origin from the player's origin and take the
length of the resulting vector.

__
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/
___
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

RE: [hlcoders] Items.cpp (MyTouch)

[Adrian Finol]

 Of course. BBoxes are vectors. You want something like this:

MESSAGE_BEGIN( MSG_PVS, SVC_TEMPENTITY, pev->origin );
WRITE_BYTE( TE_BOX);
WRITE_COORD( mins.x );
WRITE_COORD( mins.y );
WRITE_COORD( mins.z );
WRITE_COORD( maxs.x );
WRITE_COORD( maxs.y );
WRITE_COORD( maxs.Z );
WRITE_SHORT( 25 );
WRITE_BYTE( 255  ); 
WRITE_BYTE( 255  ); 
WRITE_BYTE( 255 );
MESSAGE_END();


- Adrian


-Original Message-
From: Yacketta, Ronald [mailto:[EMAIL PROTECTED]]
Sent: Saturday, January 05, 2002 12:33 PM
To: [EMAIL PROTECTED]
Subject: RE: [hlcoders] Items.cpp (MyTouch)


Found it ;)

But it crashes...


MESSAGE_BEGIN( MSG_PVS, SVC_TEMPENTITY, pev->origin );
WRITE_BYTE( TE_BOX);
WRITE_COORD( pev->origin.x );
WRITE_COORD( pev->origin.x);
WRITE_SHORT( 25 );
WRITE_BYTE( 255  ); 
WRITE_BYTE( 255  ); 
WRITE_BYTE( 255 );
MESSAGE_END();

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Yacketta,
Ronald
Sent: Saturday, January 05, 2002 12:48 PM
To: [EMAIL PROTECTED]
Subject: RE: [hlcoders] Items.cpp (MyTouch)


Lad you know what your talking about.. I sure in the heck don't ;)

-Ron

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Adrian Finol
Sent: Saturday, January 05, 2002 7:53 AM
To: '[EMAIL PROTECTED]'
Subject: RE: [hlcoders] Items.cpp (MyTouch)


#define TE_BOX  31
// coord, coord, coord  boxmins
// coord, coord, coord  boxmaxs
// short life in 0.1 s
// 3 bytes r, g, b

Use that TempEnt on the server.

- Adrian


-Original Message-
From: Yacketta, Ronald [mailto:[EMAIL PROTECTED]]
Sent: Saturday, January 05, 2002 6:34 AM
To: [EMAIL PROTECTED]
Subject: RE: [hlcoders] Items.cpp (MyTouch)


Thanxs folks!

Another question, I am looking to physically display the FB's
UTIL_SetSize() in the game under
DEBUG conditions. What could I use to display this? Maybe a triapi? Not
sure...

-Ron

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Reedbeta
Sent: Friday, January 04, 2002 9:11 PM
To: [EMAIL PROTECTED]
Subject: Re: [hlcoders] Items.cpp (MyTouch)


> If you are using UTIL_FindEntityByClassname() for "player"

Or if you're using any other method of locating players.  The point is,
subtract the grenade's origin from the player's origin and take the
length of the resulting vector.

__
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/
___
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

RE: [hlcoders] Items.cpp (MyTouch)

[Adrian Finol]

 Actually, I just noticed, you're sending the TE to pev->origin. Thats whats
crashing you. Should be only pev.

- Adrian


-Original Message-
From: Adrian Finol [mailto:[EMAIL PROTECTED]]
Sent: Saturday, January 05, 2002 12:40 PM
To: '[EMAIL PROTECTED]'
Subject: RE: [hlcoders] Items.cpp (MyTouch)


 Of course. BBoxes are vectors. You want something like this:

MESSAGE_BEGIN( MSG_PVS, SVC_TEMPENTITY, pev->origin );
WRITE_BYTE( TE_BOX);
WRITE_COORD( mins.x );
WRITE_COORD( mins.y );
WRITE_COORD( mins.z );
WRITE_COORD( maxs.x );
WRITE_COORD( maxs.y );
WRITE_COORD( maxs.Z );
WRITE_SHORT( 25 );
WRITE_BYTE( 255  ); 
WRITE_BYTE( 255  ); 
WRITE_BYTE( 255 );
MESSAGE_END();


- Adrian


-Original Message-
From: Yacketta, Ronald [mailto:[EMAIL PROTECTED]]
Sent: Saturday, January 05, 2002 12:33 PM
To: [EMAIL PROTECTED]
Subject: RE: [hlcoders] Items.cpp (MyTouch)


Found it ;)

But it crashes...


MESSAGE_BEGIN( MSG_PVS, SVC_TEMPENTITY, pev->origin );
WRITE_BYTE( TE_BOX);
WRITE_COORD( pev->origin.x );
WRITE_COORD( pev->origin.x);
WRITE_SHORT( 25 );
WRITE_BYTE( 255  ); 
WRITE_BYTE( 255  ); 
WRITE_BYTE( 255 );
MESSAGE_END();

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Yacketta,
Ronald
Sent: Saturday, January 05, 2002 12:48 PM
To: [EMAIL PROTECTED]
Subject: RE: [hlcoders] Items.cpp (MyTouch)


Lad you know what your talking about.. I sure in the heck don't ;)

-Ron

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Adrian Finol
Sent: Saturday, January 05, 2002 7:53 AM
To: '[EMAIL PROTECTED]'
Subject: RE: [hlcoders] Items.cpp (MyTouch)


#define TE_BOX  31
// coord, coord, coord  boxmins
// coord, coord, coord  boxmaxs
// short life in 0.1 s
// 3 bytes r, g, b

Use that TempEnt on the server.

- Adrian


-Original Message-
From: Yacketta, Ronald [mailto:[EMAIL PROTECTED]]
Sent: Saturday, January 05, 2002 6:34 AM
To: [EMAIL PROTECTED]
Subject: RE: [hlcoders] Items.cpp (MyTouch)


Thanxs folks!

Another question, I am looking to physically display the FB's
UTIL_SetSize() in the game under
DEBUG conditions. What could I use to display this? Maybe a triapi? Not
sure...

-Ron

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Reedbeta
Sent: Friday, January 04, 2002 9:11 PM
To: [EMAIL PROTECTED]
Subject: Re: [hlcoders] Items.cpp (MyTouch)


> If you are using UTIL_FindEntityByClassname() for "player"

Or if you're using any other method of locating players.  The point is,
subtract the grenade's origin from the player's origin and take the
length of the resulting vector.

__
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/
___
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

RE: [hlcoders] Models and sequences

[Adrian Finol]

 One thing to remember is that any transformation applied to the model
client side has to be duplicated on the server in order to mantain hit
detection in order.

 We had this problem with CS, where the client was doing all the blendings (
9 to be exact ) while the server had no idea about what was going on. Hence
the old CS hitbox problem.


-Original Message-
From: Ken Birdwell
To: '[EMAIL PROTECTED]'
Sent: 1/23/02 4:26 PM
Subject: RE: [hlcoders] Models and sequences

Leon is mostly correct, though the engine IS limited to only supporting
4,294,967,296 sequences. :P

In any case, the whole business of needing the sequence to line up is
ONLY
if you're displaying a different model on the client than the one the
server
is using.  Since HL and TFC allow clients to replace models locally,
it's
important to mention that for authoring purposes the sequences are
referenced on the client by index number, not animation name (which is
only
looked at on the server).

If you're always using the SAME model on both the client and server for
any
given player, then they automatically line up (since they're the same,
duh)
and you can ignore the "all models must have the same animations, etc.
etc."
issue, cause, well, they're the same on both.

-Original Message-
From: Leon Hartwig [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 23, 2002 12:46 PM
To: [EMAIL PROTECTED]
Subject: RE: [hlcoders] Models and sequences


The only circumstance in which this is handled in 8 bits is network
transmission, which can be changed by modifying delta.lst.  That's what
it's there for.  Surprise or no surprise, it's not hard coded in the
engine and the engine will happily handle as many sequences as you like.
You should be able to witness this personally within a few days; DoD 2.0
will have > 256 sequences.


> -Original Message-
> From: David Flor [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, January 23, 2002 8:17 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [hlcoders] Models and sequences
> 
> 
> I believe "pev->sequence" is handled as 8 bits, or maximum of 
> 256. Also,
> since I see that inside "studiomdl.exe" it uses a hard-coded array, I
> wouldn't be surprised if a limitation like that does exist in 
> the engine
> because of coding practices. As much as I have the utmost 
> confidence and
> trust in the Valve development team, there are many bad practices and
> programming no-nos that are common to every programmer... I use fixed
> length arrays without range checking sometimes; the horror! :)
> 
> And, Pat, there are 32 maximum weapons, not 35. 32x4 = 128. ;)
> 
> Besides, 256 animations is almost ungodly, isn't it? Your 
> animator must
> be going crazy... We had well over 77 animations in our mod 
> (I think at
> last count we had over 160 of them).

___
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

RE: [hlcoders] Models and sequences

[Adrian Finol]

 Same way you do on the client, but this time you apply your transformations
to the server side partners of the cliet StudioModelRenderer. It's all on
animation.cpp.

-Original Message-
From: David Flor
To: [EMAIL PROTECTED]
Sent: 1/24/02 8:40 AM
Subject: RE: [hlcoders] Models and sequences

You know, it never dawned on me that that could be the cause of some of
the hit detection issues in my mod. 

OK, so refresh my memory: how do I define the transformations on the
SERVER?

Tnx & Rgds...
David "Nighthawk" Flor ( [EMAIL PROTECTED] )
Lead Programmer, The Persistence Engine - http://www.persistengine.com/
Lead Programmer, "The Opera" - http://opera.redeemedsoft.com/
President, Mach III Enterprises

"When Alexander saw the breadth of his domain he wept for there were no
more worlds to conquer..."

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Adrian Finol
Sent: Wednesday, January 23, 2002 11:31 PM
To: Ken Birdwell; ''[EMAIL PROTECTED]' '
Subject: RE: [hlcoders] Models and sequences


 One thing to remember is that any transformation applied to the model
client side has to be duplicated on the server in order to mantain hit
detection in order.

 We had this problem with CS, where the client was doing all the
blendings ( 9 to be exact ) while the server had no idea about what was
going on. Hence the old CS hitbox problem.

___
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

RE: [hlcoders] Making WorldCraft's editing area bigger?

[Adrian Finol]

 Actually, last time I checked the Polyfighter guys had maps 4 times as big
as the current limits.

- Adrian


-Original Message-
From: Tom [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 29, 2002 2:12 AM
To: [EMAIL PROTECTED]
Subject: Re: [hlcoders] Making WorldCraft's editing area bigger?


I remember some dum ass mod (I think it was uncrossable parallel) leader
trying to convince aload of people that they way they made the maps like 4x
as big wasnt my shrinking players on its forums. Im not sure he realised why
there is the limit which is currently in place


- Original Message -
From: "Jeff Fearn" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, January 29, 2002 3:00 AM
Subject: Re: [hlcoders] Making WorldCraft's editing area bigger?


> > I don't believe this can be done.  In order to extend the limits, one
> would
> > have to modify not only Worldcraft, but the compile tools and the engine
> BSP
> > reading code as well.  As I understand it, spatial locations in BSP
files
> are
> > stored as a 16-bit integer for each coordinate.  The number is stored in
> 13.3
> > format, which means there are 3 bits past the radix point (allowing
> precision
> > up to 1/8 unit), but the maximum and minimum numbers that can be stored
> are
> > 4095 and -4096 respectively (therefore the world is 8192x8192x8192).  It
> would
> > be possible, if one could modify the engine, to extend this limit, but
> > precision would have to be given up.  For example, the numbers could be
> stored
> > in 14.2 format, allowing the world to be 16384 units in each direction,
> but
> > with precision only up to 1/4 unit.  It is possible for doors and such
to
> > extend beyond the 8192 limit in-game, because the engine uses a
> floating-point
> > representation for the coordinates internally---I assume so, at least,
but
> > please remember this is all guesswork.
>
> Of course if you had access to the engine you'd just store each
co-ordinate
> as a 32bit integer and use 29.3, which is about 536 million each axis,
> lol.You would still have the engine limits as to how large a particular
> room/area could be, i.e large == laggy. I wonder how this would impact on
> performance, especially memory use and how that would affect locality. A
> large map may cause a lot of page faults etc ... unless your a lucky boy
> with a Xeon :) then again if you started going in to the millions each
> direction I bet any computer will have a hard time :P
>
> Jeff.
> ___
> 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

RE: [hlcoders] Info on a client command

[Adrian Finol]

Straight from the comment in the code:

Returns the keyname to which a binding string is bound.  E.g., if
TAB is bound to +use then searching for +use will return "TAB"

- Adrian


-Original Message-
From: _Phantom_ [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 07, 2002 12:14 AM
To: [EMAIL PROTECTED]
Subject: [hlcoders] Info on a client command


morning,

could someone please give me some info on the following client command
(found in cl_enginefunc_t in cl_dll.h)

const char *( *Key_LookupBinding )  ( const char *pBinding );

what would ya put in and what would it give out? Do ya feed in say
'+altfire' and get out the key which is bound to it? or is it the other way
around? this would seam to make more sense coz you can have 2 keys bound to
one function :)

Any light would be appricated :)
Rob

"cause I dont wanna be a hero
and I dont wanna be a zero" - Feeder, Turn
Jon Henry Lee, Your memory will live on in your fans and your music, Rest In
Peace

___
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

RE: [hlcoders] Re: hlcoders digest, Vol 1 #291 - 14 msgs

[Adrian Finol]

Here we go, just put this on hl_weapons.cpp.

// For storing predicted sequence and gaitsequence and origin/angles data
static int g_rseq = 0, g_gaitseq = 0;
static vec3_t g_clorg, g_clang;

/*
==
Game_GetSequence

==
*/
void Game_GetSequence( int *seq, int *gaitseq )
{
*seq = g_rseq;
*gaitseq = g_gaitseq;
}

/*
==
Game_SetSequence

==
*/
void Game_SetSequence( int seq, int gaitseq )
{
g_rseq = seq;
g_gaitseq = gaitseq;
}

/*
==
Game_SetOrientation

==
*/
void Game_SetOrientation( vec3_t o, vec3_t a )
{
g_clorg = o;
g_clang = a;
}

/*
==
Game_GetOrientation

==
*/
void Game_GetOrientation( float *o, float *a )
{
int i;

for ( i = 0; i < 3; i++ )
{
o[ i ] = g_clorg[ i ];
a[ i ] = g_clang[ i ];
}
}

- Adrian


-Original Message-
From: Seth Malaki [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 18, 2002 6:51 AM
To: [EMAIL PROTECTED]
Subject: [hlcoders] Re: hlcoders digest, Vol 1 #291 - 14 msgs


i still can seem to compile the code... it has the errors void
Game_GetSequence( int float ) LNK 2001 unresolved externals (well..
something like that) and that goes to the GetOrientation func too...
BTW.. Shimms from tae-mod informed me that it was Adrian that wrote the
code.. so where could i find him?


>From: [EMAIL PROTECTED]
>Reply-To: [EMAIL PROTECTED]
>To: [EMAIL PROTECTED]
>Subject: hlcoders digest, Vol 1 #291 - 14 msgs
>Date: Sun, 17 Feb 2002 12:04:01 -0800 (PST)
>
>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. Monster Speeds (Varlock)
>2. Re: Monster Speeds ([EMAIL PROTECTED])
>3. Re: Monster Speeds (Reedbeta)
>4. Re: Monster Speeds (Varlock)
>5. Re: Monster Speeds (Cortex)
>6. 9 way blending? (Seth Malaki)
>7. Re: Monster Speeds (botman)
>8. Re: Monster Speeds (botman)
>9. Re: Monster Speeds (Commando)
>   10. DMC strafing effect (Cortex)
>   11. Re: Monster Speeds (Cortex)
>   12. Re: 9 way blending? (botman)
>   13. Re: 9 way blending? (Georges Giroux)
>   14. Re: DMC strafing effect (Cortex)
>
>--__--__--
>
>Message: 1
>From: "Varlock" <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>
>Date: Sat, 16 Feb 2002 18:53:39 -0800
>Subject: [hlcoders] Monster Speeds
>Reply-To: [EMAIL PROTECTED]
>
> I'll be quick and to the point. How do I change the speed of a
>monster?
>I've looked high and low in the SDK but I haven't found anything at all
>related to monster speeds. pev->maxspeed doesn't seem to affect anything.
>Is
>it hidden in the model or .qc file or something?
> Thanks for any replies.
>
>- Varlock
>
>
>--__--__--
>
>Message: 2
>From: [EMAIL PROTECTED]
>Date: Sat, 16 Feb 2002 22:22:20 EST
>Subject: Re: [hlcoders] Monster Speeds
>To: [EMAIL PROTECTED]
>Reply-To: [EMAIL PROTECTED]
>
>--
>[ Picked text/plain from multipart/alternative ]
>I would guess its the speed of the animation..  or, something to due with
>the
>models.  Unless your changing Controllers or other flying mosters.
>
>~Ghoul
>
>Lets leave it at that...
>
>--__--__--
>
>Message: 3
>Date: Sat, 16 Feb 2002 23:38:32 -0800 (PST)
>From: Reedbeta <[EMAIL PROTECTED]>
>Subject: Re: [hlcoders] Monster Speeds
>To: [EMAIL PROTECTED]
>Reply-To: [EMAIL PROTECTED]
>
>The model movement speed is in the animation.  See, models appear to
>run/walk
>in place in the model viewer, but if you decompile them and load the
>animation
>SMDs, you'll find that they move correctly (ie, not running/walking in
>place).
>During the model compilation process, something called "motion extraction"
>is
>applied which removes the motion (so to speak) from the actual animation
>and
>encodes it separately in the MDL file.
>
>--- Varlock <[EMAIL PROTECTED]> wrote:
> > I'll be quick and to the point. How do I change the speed of a
>monster?
> > I've looked high and low in the SDK but I haven't found anything at all
> > related to monster speeds. pev->maxspeed doesn't seem to affect
>anything. Is
> > it hidden in the model or .qc file or something?
> > Thanks for any replies.
> >
> > - Varlock
> >
> > ___
> > To unsubscribe, edit your list preferences, or view the list archives,
>please
> > visit:
> > http://list.valvesoftware.com/mailman/listinfo/hlcoders
> >
>
>
>

RE: [hlcoders] Egon gun - Yellow beam or Blue beam?

[Adrian Finol]

 Egon is the Ghostbusters-Like gun, It shoots Blue beams. The Gauss is the
one that can penetrate walls ( the one that charges up ), it shoots a Yellow
beam when not charged and a White beam when it has been charged.

-Original Message-
From: Philip Plante [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 04, 2002 5:31 PM
To: [EMAIL PROTECTED]
Subject: Re: [hlcoders] Egon gun - Yellow beam or Blue beam?


The egon has always been yellow for me, aleast aslong as I can remember.

Sarge_Spank
www.illicitstudios.com
- Original Message -
From: "Nathan Taylor" <[EMAIL PROTECTED]>
To: "HLCoders" <[EMAIL PROTECTED]>
Sent: Monday, March 04, 2002 1:01 PM
Subject: Re: [hlcoders] Egon gun - Yellow beam or Blue beam?


> --
> [ Picked text/plain from multipart/alternative ]
> Cuz I have windows XP and my gf3 doesnt like the seXp enviro so it crashes
24/7 in opengl.  it only crashes 10/7 in d3d...
>
> - Original Message -
> From: [EMAIL PROTECTED]
> Sent: Monday, March 04, 2002 1529 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [hlcoders] Egon gun - Yellow beam or Blue beam?
>
> --
> [ Picked text/plain from multipart/alternative ]
> Why are you using D3D?
>
> ~Ghoul
>
> Lets leave it at that...
> ___
> 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/hlcoders
___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

RE: [hlcoders] Egon gun - Yellow beam or Blue beam?

[Adrian Finol]

 It only seems to happen on software, I'll take a look at it.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 04, 2002 5:19 PM
To: [EMAIL PROTECTED]
Subject: Re: [hlcoders] Egon gun - Yellow beam or Blue beam?


--
[ Picked text/plain from multipart/alternative ]
Wow, I can hardly see it.  Those screens look pixelated...  hmm.

~Ghoul

Lets leave it at that...
___
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

RE: [hlcoders] iuser4 variable ??

[Adrian Finol]

 The value on the server will stay correct cause it's not sent over the
wire. You need to add your var to the delta.lst file so you can send it
correctly to the client.

 Check your delta.lst file, you'll see that the other 3 iusers are already
there.

-Original Message-
From: Cortex [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 20, 2002 8:44 AM
To: [EMAIL PROTECTED]
Subject: [hlcoders] iuser4 variable ??


Hello,

I'm having trouble with the iuser4 variable... I use the 3 other iuser
variables for the spectator mode, but the iuser4 doens't work :( The
pmove->iuser4 is always at zero :( However, the pPlayer->pev->iuser4 (so,
server side) is normally set...

I added this two lines in entity.cpp (if I good remember me, they were
already present...) :
state->iuser4 = client->iuser4; // in HUD_TxferLocalOverrides
pcd->iuser4 = ppcd->iuser4; // in HUD_TxferPredictionData


Any idea ??

  - Cortex : mapper & coder www.hlalbator.fr.st


___
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

RE: [hlcoders] iuser4 variable ??

[Adrian Finol]

 Woah, I sent this a day ago.

-Original Message-
From: Adrian Finol [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 20, 2002 12:39 PM
To: '[EMAIL PROTECTED]'
Subject: RE: [hlcoders] iuser4 variable ??


 The value on the server will stay correct cause it's not sent over the
wire. You need to add your var to the delta.lst file so you can send it
correctly to the client.

 Check your delta.lst file, you'll see that the other 3 iusers are already
there.

-Original Message-
From: Cortex [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 20, 2002 8:44 AM
To: [EMAIL PROTECTED]
Subject: [hlcoders] iuser4 variable ??


Hello,

I'm having trouble with the iuser4 variable... I use the 3 other iuser
variables for the spectator mode, but the iuser4 doens't work :( The
pmove->iuser4 is always at zero :( However, the pPlayer->pev->iuser4 (so,
server side) is normally set...

I added this two lines in entity.cpp (if I good remember me, they were
already present...) :
state->iuser4 = client->iuser4; // in HUD_TxferLocalOverrides
pcd->iuser4 = ppcd->iuser4; // in HUD_TxferPredictionData


Any idea ??

  - Cortex : mapper & coder www.hlalbator.fr.st


___
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

RE: [hlcoders] Counter-Strike : Condition Zero

[Adrian Finol]

 Most of the tech will indeed be avaliable for people to use since most
changes where done in the engine. Stuff like the use of masked textures on
models and stuff like that.

 I've been working on moving the whole particle system into a separate .dll
so that can be distributed and mod authors can just plug that in and use it.
We'll see how it goes.



-Original Message-
From: Chris Blane
To: [EMAIL PROTECTED]
Sent: 3/25/2001 5:28 PM
Subject: Re: [hlcoders] Counter-Strike : Condition Zero

Hehhe maybe I should try to talk nicely to Marc Schröder and see what I
can
get out of him. :) I doubt I'll get anywhere though but he's the only
guy on
the team I've spoken with alot.  LOL!


- Original Message -
From: Philip (Fiber) <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, March 24, 2002 7:40 AM
Subject: RE: [hlcoders] Counter-Strike : Condition Zero


> From CSNation -
>
> "The current models are 750 polygons each. The ones in Condition Zero
> are 1,250 polygons each, meaning there's a 66% increase in the amount
of
> polygons per model. All the models will have full lip-synching with
the
> sounds and some facial animation to go with it. The skins on those
> models don't disappoint, either.
>
> The new model system supports alpha blending. Along with RGB values in
> colors, systems that allow for 32-bit rendering have 8-bits set aside
> for an alpha channel, which controls attributes like transparency or
> opacity. A good use would be glass or eye-holes on a mask. This will
be
> used in the "window" of the shield, which will actually hold glass.
> Another place it will be used, for sure, is the molotov cocktail.
You'll
> be able to see inside the bottle and can see the liquid move around.
>
> Condition Zero includes a level of detail system so the the high
detail
> of models will be scaled down to the benefit of your framerate, while
> those with fast computers can experience full detail.
>
> Since you can change the face, skin tone, and other attributes of a
> model, there are over 160 different combinations."
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]] On Behalf Of Georges
> Giroux
> Sent: Sunday, March 24, 2002 6:09 PM
> To: [EMAIL PROTECTED]
> Subject: [hlcoders] Counter-Strike : Condition Zero
>
> Hey guys,
>
> Short and sweet, I was just wondering, will the graphical
> improvements of Condition Zero be eventually available to Half-Life
> mod makers?
>
> Georges
> ___
> 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

RE: [hlcoders] Problems with 2.2 SDK Weapon Bodies

[Adrian Finol]

 This was done for the HLDM weapons, you can always remove that bit of code
for your own mod use.

-Original Message-
From: Commando [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 25, 2002 12:29 PM
To: [EMAIL PROTECTED]
Subject: [hlcoders] Problems with 2.2 SDK Weapon Bodies


I just found a horrible hack in the SDK that has been causing weird
problems for my mod and I thought I should post it here in case anyone runs
into similar problems.  Some of the weapons in my mod depend on multiple
bodies in the model. In the 2.0 SDK, the body got sent automatically
whenever you called SendWeaponAnim(), but in the 2.2 SDK they added a new
default parameter to SendWeaponAnim().  The new last parameter is body and
it defaults to 0, so you can no longer just set pev->body and then send off
an animation, you must add the body to the end of all your SendWeaponAnim
calls for that weapon.

This is not the hack though, it is just an inconvenience that you should
know about.  The hack is this bit of code in hl_weapons.cpp on the client;

// Make sure that weapon animation matches what the game .dll is telling us
//  over the wire ( fixes some animation glitches )
if ( g_runfuncs && ( HUD_GetWeaponAnim() != to->client.weaponanim ) )
{
int body = 2;

//Pop the model to body 0.
if ( pWeapon == &g_Tripmine )
 body = 0;

//Show laser sight/scope combo
if ( pWeapon == &g_Python && bIsMultiplayer() )
 body = 1;

// Force a fixed anim down to viewmodel
HUD_SendWeaponAnim( to->client.weaponanim, body, 1 );
}

Apparently they were having animation glitches when the client and server
got out of sync occasionally, so they threw this hack in to fix it.  The
problem is though, that it does not care what body your weapon is using, it
automatically sets it to 2.  I tried commenting this out and there are
animation glitches when the player spawns.

So, the moral of the story is, if you have a weapon that depends on
multiple bodies, add an if (pWeapon == &gYourWeapon) and set the body to
the correct value.  Talk about a maintenance nightmare and bugs waiting to
happen ;-)

Hope this helps someone, I spent enough hours tearing my hair out over it
:D  Anyone think this is worth writing a tutorial over?

Rob Prouse
Tour of Duty Mod
http://www.tourofdutymod.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/hlcoders

RE: [hlcoders] Accessing another client's iuser variable

[Adrian Finol]

 You can always check the sequence number on the client, in the model
rendering code for that player. If it's set to your animation you can just
tag that player as swinging the sword and do your magic trail thingy =).

-Original Message-
From: Georges Giroux [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 26, 2002 12:07 PM
To: [EMAIL PROTECTED]
Subject: Re: [hlcoders] Accessing another client's iuser variable


Maybe I'm taking the wrong approach...
I want to render a sword trail for any clients
that have the iuser3 variable set...but this trail should
only be rendered when his sword is swinging.
So, in SetAnimation I set iuser3 to a value, and when the animation
end, I reset it.

All that is sent is 1 bit from iuser3 (specified in the delta.lst file).

There is no way information like this is available to all clients without
having the server transmit this information via messages?

Georges

- Original Message -
From: "Dynerman David M" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, March 26, 2002 3:00 PM
Subject: RE: [hlcoders] Accessing another client's iuser variable


> What you're proposing defeats the point of the client-specific (i.e.
> *user*) variables.
>
> Might as well just maintain the values on the server and transmit to all
> clients.
>
> david
>
> -Original Message-
> From: Georges Giroux [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, March 26, 2002 1:51 PM
> To: [EMAIL PROTECTED]
> Subject: [hlcoders] Accessing another client's iuser variable
>
> This is a multi-part message in MIME format.
> --
> [ Picked text/plain from multipart/alternative ]
> Hello,
>
> I need some help or advice...this is my problem:
> -Two clients, client A, client B.
> -1 server
>
> -On the server, iuser3 for client A is set to 55 (for example)
> -On the server, iuser3 for client B is set to 45 (for example)
>
> When client A receives entity information, I'd like to be able to access
> client B's iuser3 variable as well. The problem is, it is always set to
> 0!
> Client A's own iuser3 is properly sent (delta.lst, etc etc) as well
> as Client B's own iuser3. It's just from Client A I want to access
> Client B's iuser3 in these two functions (in cl_dll\entity.cpp):
>
> HUD_ProcessPlayerState
> HUD_TxferPredictionData
>
> Any ideas/suggestions?
>
> Georges
>
> --
>
> ___
> 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

RE: [hlcoders] v_weaponmodels skin changing

[Adrian Finol]

 I tried changing the skin from HUD_DrawNormalTriangles and the engine got
the skin info correctly when it was going to render the model. So it should
work fine if called from the client.dll. It seems the skin value is not
getting propagated for the View model from the server to the client.

 This is the code I used to test it:

 cl_entity_t *pViewModel = gEngfuncs.GetViewModel();
 pViewModel->curstate.skin = 40;

 I didn't have a Viewmodel with two skins to test it with, but the value was
used when trying to setup the skin.

 If Christopher could test if this works for him, or email me the Viewmodel
so I can do more testing it would be great.

-Original Message-
From: Ken Birdwell [mailto:[EMAIL PROTECTED]]
Sent: Monday, April 15, 2002 1:55 PM
To: '[EMAIL PROTECTED]'
Subject: RE: [hlcoders] v_weaponmodels skin changing


Christopher, as a quick test on the client where it references
GetViewEntity() or gEngfuncs.GetViewModel(), set that entities curstate.skin
to your test skin index.  Maybe try it in EV_MuzzleFlash() or some place
similar.  You may be forced to do it all client side with your own
networking, maybe in one of the players user fields or inside clientside
weapon code.

-Original Message-
From: Ken Birdwell [mailto:[EMAIL PROTECTED]]
Sent: Monday, April 15, 2002 1:40 PM
To: '[EMAIL PROTECTED]'
Subject: RE: [hlcoders] v_weaponmodels skin changing


I am 100% sure as of June 1999 when I last compiled the SDK that my
description of how it do it is correct.  As of Apr 2002 and the current code
base, if you're telling me it doesn't work then I'll go make Adrian test it
out and find out why it doesn't.  HEY ADRIAN!

-Original Message-
From: Christopher Long [mailto:[EMAIL PROTECTED]]
Sent: Monday, April 15, 2002 5:32 AM
To: [EMAIL PROTECTED]
Subject: Re: [hlcoders] v_weaponmodels skin changing


The player model changes fine Ken and there are 4 subskins. The view weapon
model also has 4 subskins but it won't change i set the player skin and
from what you say it should also change the view model but it doesn't
and this is from a fresh sdk install.

I used a fresh sdk straight off the assembly line and changed the player
model and the weapon view model(v_myweapon) still remains skin 1.

I'll look over the model again to make sure its all ok... but its showing
itself properly in half life model viewer so i don't see how it can have a
problem.

You sure its possible to change the skin on the weapon view model without
incorporating it into a submodel of the weapon like what is done with the
python
cause to date i haven't seen a mod that does it with no sub groups and just
a skin list.

- Original Message -
From: Ken Birdwell <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, April 15, 2002 10:40 AM
Subject: RE: [hlcoders] v_weaponmodels skin changing


> how to debug your problem:
>
> 1) Test your model in either the model viewer or as a cycler in a map
where
> you've set its "skin" to be something other than 0 and you're sure that
your
> textures are in fact changing
>
> 2) As a test, hack into your game dll and set the players skin to
something
> other than 0.  In firstperson mode you should see that the viewmodel also
> changes its skin.  If so, go to #9
>
> 3) Huh, didn't work.  Is pev->skin being networked for the player?  Is it
> being overwritten somewhere on the client?  As a test, make a version of
the
> player model that has a obvious skin change (like bright purple or
> something) and make sure you can see it in thirdperson mode (and not just
to
> other clients).
>
> 4) If you can't see the skin change on the player, then the data is
probably
> not being networked or it's being overwritten somewhere on your client.
Do
> you have any code on the client that changes skin?  If so, comment it out
or
> hack it to be something other the skin you want to see.  Does it change?
>
> 5) Still not working? Is it being networked?  Look at your network tables
> and see if its there.  If so, make sure it's being set in the game dll
(and
> it is stable, i.e. not being overwritten with some other code in your game
> dll) and then check its state in the client dll (write some code that'll
hit
> your breakpoint if the skin value is non-zero).  They should match.
>
> 6) Your player model should be working now and using the alternate skin.
If
> it's still not, then you've probably missed something in your client dll
> where you're stomping on your skin setting.  I can't help you, you just
need
> to find your bug and restart at #2.
>
> 7) Yeah!  It works, the player model is changing!  Go back into
firstperson
> and look to see if the viewmodel is now also changing.  If it's not, are
you
> sure you're sending down a valid skin number?  They wrap ya know. If like,
> you set it to "2" and you only have skin 0 and skin 1, then it'll wrap
> around and pick skin 0 again.  Make sure you're picking a valid skin
number.
>
> 8) Still doesn't work?  You sure your viewent is 

RE: [hlcoders] Scope Sprites

[Adrian Finol]

 You can also check if the currententity is the viewmodel on the model
rendering code and just return when it goes to draw it.

-Original Message-
From: Sebastian Steinlechner
To: [EMAIL PROTECTED]
Sent: 4/30/2002 4:03 AM
Subject: Re: [hlcoders] Scope Sprites

Actually, there IS a drawback in my code. As the weapon model is
rendered
AFTER triapi (or with depthfunc disabled), it shows in front of the
polygons. I tried to get a viewmodel pointer clientside and set its
renderamount to 0, but that did not work. I got it to be halfway
transparent, but it never disappeared completely. So what you have to do
is
to set the viewmodel to NULL either serverside or clientside (the first
way
definitely works - I haven't tried the second yet).


> Cool :)
>
> good coded LOL
>
>   - Cortex : mapper & coder www.hlalbator.fr.st
>
> - Original Message -
> From: "Sebastian Steinlechner" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, April 29, 2002 9:30 PM
> Subject: Re: [hlcoders] Scope Sprites
>
>
> > Yes, it does... here's how I did it, I'm calling this from
> > HUD_DrawTransparentTriangles (well, not exactly this, it's somewhat
> > different in Poke646, but the idea & maths is the same):
> >
> > --- snip ---
> >
> > #define SCOPE_DISTANCE 10
> > #define M_PI   3.14159265358979323846
> >
> > extern vec3_t v_angles, v_origin;
> >
> > void CSniperScope::DrawScope( void )
> > {
> >  if( !fActive )
> >   return;
> >
> >  cl_entity_t *player;
> >
> >  // make sure the player is up and running
> >  player = gEngfuncs.GetLocalPlayer();
> >  if ( !player )
> >   return;
> >
> >  // load sniper scope sprite if necessary
> >  if ( hsprSniperScope == 0 )
> >  {
> >   char sz[256];
> >   sprintf( sz, "sprites/scopeborder.spr" );
> >   hsprSniperScope = SPR_Load( sz );
> >  }
> >
> >  vec3_t viewAngles, v_up, v_right, v_forward;
> >
> >  gEngfuncs.GetViewAngles( viewAngles );
> >  AngleVectors( viewAngles, v_forward, v_right, v_up );
> >
> >  // the sprite's origin
> >  vec3_t org = v_origin + v_forward * SCOPE_DISTANCE;
> >
> >  // adjust size to fov (simple triangular maths)
> >  float fovadjust = tan( gHUD.m_iFOV / 360.0 * M_PI );
> >  float size = (SCOPE_DISTANCE + 1.0) * fovadjust; // little bigger
than
> > necessary
> >
> >  // use this to overlap the triangles a bit
> >  float pixel = size / 256.0;
> >
> >  float r, g, b, brightness;
> >
> >  r = g = b = brightness = 1.0;
> >
> >  vec3_t temporg;
> >
> >  // now set up triapi code
> >  gEngfuncs.pTriAPI->RenderMode( kRenderTransTexture );
> >  gEngfuncs.pTriAPI->CullFace( TRI_NONE );
> >
> >  for( int i = 0; i < 4; i++ )
> >  {
> >   if ( !gEngfuncs.pTriAPI->SpriteTexture( (struct model_s
> > *)gEngfuncs.GetSpritePointer( hsprSniperScope ), i ))
> >   {
> >return;
> >   }
> >
> >   gEngfuncs.pTriAPI->Color4f( r, g, b , brightness);
> >   gEngfuncs.pTriAPI->Begin( TRI_QUADS );
> >
> >   gEngfuncs.pTriAPI->Brightness( 1 );
> >   gEngfuncs.pTriAPI->TexCoord2f( 0, 1 );
> >   switch( i )
> >   {
> >case 0: temporg = org + (v_right * -size); break;
> >case 1: temporg = org; break;
> >case 2: temporg = org + (v_right * -size) + (v_up * -size);
break;
> >case 3: temporg = org + (v_up * -size); break;
> >   }
> >   gEngfuncs.pTriAPI->Vertex3fv( temporg );
> >
> >   gEngfuncs.pTriAPI->Brightness( 1 );
> >   gEngfuncs.pTriAPI->TexCoord2f( 0, 0 );
> >   switch( i )
> >   {
> >case 0: temporg = org + (v_right * -size) + (v_up * size); break;
> >case 1: temporg = org + (v_up * size); break;
> >case 2: temporg = org + (v_right * -size) + (v_up * pixel);
break;
> >case 3: temporg = org; break;
> >   }
> >   gEngfuncs.pTriAPI->Vertex3fv( temporg );
> >
> >   gEngfuncs.pTriAPI->Brightness( 1 );
> >   gEngfuncs.pTriAPI->TexCoord2f( 1, 0 );
> >   switch( i )
> >   {
> >case 0: temporg = org + (v_up * size); break;
> >case 1: temporg = org + (v_right * size) + (v_up * size); break;
> >case 2: temporg = org; break;
> >case 3: temporg = org + (v_right * size) + (v_up * pixel); break;
> >   }
> >   gEngfuncs.pTriAPI->Vertex3fv( temporg );
> >
> >   gEngfuncs.pTriAPI->Brightness( 1 );
> >   gEngfuncs.pTriAPI->TexCoord2f( 1, 1 );
> >   switch( i )
> >   {
> >case 0: temporg = org; break;
> >case 1: temporg = org + (v_right * size); break;
> >case 2: temporg = org + (v_up * -size); break;
> >case 3: temporg = org + (v_right * size) + (v_up * -size); break;
> >   }
> >   gEngfuncs.pTriAPI->Vertex3fv( temporg );
> >
> >   gEngfuncs.pTriAPI->End();
> >  }
> >
> > }
> >
> > -- snap --
> >
> > cya,
> > TheTinySteini
> >
> >
> > - Original Message -
> > From: "Cortex" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Monday, April 29, 2002 7:56 PM
> > Subject: Re: [hlcoders] Scope Sprites
> >
> >
> > I don't understand how you got it to work using TriApi ! How did you
get
> the
> > coordinate of the polys you had to display ? It has to depend from
the
> view
> > angles, don't they ?
> >
> >
> 

RE: [hlcoders] 3 round burst bug

[Adrian Finol]

 The prediciton code will call it every frame. Thats why your PrimaryAttack
function kerps getting called. You should check if runfuncs is true wich
gets set only for one frame when the update comes. That way you can be sure
that it will only be done once.

 Thats why events only get fired once, so even tho your PrimaryAttack
function keeps getting called over and over again you only see your event
fired one time.

-Original Message-
From: Commando
To: [EMAIL PROTECTED]
Sent: 5/3/2002 2:12 AM
Subject: Re: [hlcoders] 3 round burst bug

We saw something similar with Tour of Duty when we added recoil to our
weapons in the PrimaryAttack.  When playing locally or a lan game,
everything worked fine, but when playing on the network, I found that
the
PrimaryAttack got called three times for every shot on client side.  It
was
as if the m_flNextPrimaryAttack was not being used on the client in
network
games.  The weird thing was that m_iClip had the same value each of the
three times, even though we decremented it each time.  We never noticed
this before we put in the recoil because it happened so quickly, it
looked
like one shot.  Once we put the recoil in, it got applied three times
client side.

I just figured that I had broken something when I ported from 2.0 to
2.2,
but maybe it is a bug in client side prediction.  I was never able to
track
it down because debugging a network game is no fun.  I just fixed it by
not
applying recoil client side ;)  A hack, but it works.

I would be interested to know if anyone else experiences this and it is
a
bug in the SDK.  It is simple to check, just put a breakpoint in your
primary attack and connect to a net server (not lan) and give it a try.

Maybe you are experiencing the same thing, but it is manifesting a
different way.

Rob Prouse
http://www.tourofdutymod.com

At 06:12 PM 03/05/2002 +1000, you wrote:
>Firearms suffers from the same bug :(
>We have yet to track it down, but it will be related to how the client
>predicts the operation of weapons code. I suspect something is getting
reset
>when it shouldn't be and allowing more bullets to fire.
>
>A quick fix can be to have a special 3 round bust mode (and anim), but
this
>isn't ideal.
>
>- Original Message -
>From: "Josh Coyne" <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>
>Sent: Friday, May 03, 2002 2:32 PM
>Subject: [hlcoders] 3 round burst bug
>
>
> > This is a multi-part message in MIME format.
> > --
> > [ Picked text/plain from multipart/alternative ]
> > Hey guys, one our weapons, the SMG9, has a 3 round burst toggle
mode;
> >
> > for the most part it works perfectly in no lag and even 'low' lag
>situations, up to about 200ms or so.
> >
> > but once you go past 200ms, the gun starts shooting extra bullets.
its
>kind of weird; and im pretty much clueless on how to stop it.
> >
> > Now i made some support functions a while ago (PackWeapon and
>UnpackWeapon) to transfer data from the server to the client for
prediction,
>and i properly send the m_iAllowFire, and m_iBulletCount variables for
the
>prediciton, and it works lovely.
> >
> >  Can anyone offer hints on making sure the client will only fire 3
times ?

___
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

RE: [hlcoders] Crashing Me...why?

[Adrian Finol]

 Whats the debugger saying when you crash?, put a breakpoint there and see
what doesn't look right in the watch window.

-Original Message-
From: Nate Lovallo
To: [EMAIL PROTECTED]
Sent: 5/3/2002 7:18 PM
Subject: [hlcoders] Crashing Me...why?

This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
Heres the scoop

 hud_player_info_t *hpll_info;
 hpll_info = &g_PlayerInfoList[m_nPlayerIndex];
 ConsolePrint(hpll_info->name);

Being ran in
int CStudioModelRenderer::StudioDrawPlayer( int flags, entity_state_t
*pplayer )

StudioModelRenderer.cpp

Compiles fine, crashes w/ no error straight to desktop.

Thx
Inbeastic
--

___
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

RE: [hlcoders] Wierdest thing ever....

[Adrian Finol]

 It's not safe to try to draw anything to the HUD outside the HUD Draw code.


 If you try to call it from someplace else, the screen might not be set in
the proper way to render them. DrawPlayer is further down the pipeline and
is not set to draw in ortho projection mode. Hence it will rendered in a 3D
space rather than the tipical HUD mode ( plus it will get z clipped if it's
behind anything ). You should store the names and position you want and
render them later ( one frame late ) from a HUD element's draw function.

 Hope this works.

-Original Message-
From: Nate Lovallo
To: [EMAIL PROTECTED]
Sent: 5/4/2002 6:14 PM
Subject: [hlcoders] Wierdest thing ever

This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
OK, so I got my names to work. But now when i try to hud rendering code
from the studiomodelrender heres what happened.

http://home.attbi.com/~inbeastic/images/airplane2.jpg

>From what i can see, the hud is being rendered in space?
heres my code in DrawPlayer

 if (cl_drawpnames->value > 0)
 {
  vec3_t screen;
  int nx, ny, orgx, orgy;

  gEngfuncs.pTriAPI->WorldToScreen(m_pCurrentEntity->origin,screen);

  screen[0] = XPROJECT(screen[0]);
  screen[1] = YPROJECT(screen[1]);
  screen[2] = 0.0f;


  nx = static_cast(screen[1]);

  ny = static_cast(screen[0]);

  gHUD.DrawHudString(nx, ny, ScreenWidth, m_pPlayerInfo->name , 0, 128,
255);

}
--

___
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

RE: [hlcoders] Confusing bit of code in the HL AI

[Adrian Finol]

 That code sets the COND_ENEMY_OCCLUDE flag if the enemy is NOT visible.
Hence the !FVisible. If it's visible, then it removes the flag.

 Assert is a debug function, it will break (stop) the debugger if the
condition passed is not met.

-Original Message-
From: geoff c [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 06, 2002 6:22 PM
To: [EMAIL PROTECTED]
Subject: [hlcoders] Confusing bit of code in the HL AI


ladies and gentlemen of the jury, please direct your attention towards
monsters.cpp, line 1065:
if ( !FVisible( pEnemy ) )
{
ASSERT(!HasConditions(bits_COND_SEE_ENEMY));
SetConditions( bits_COND_ENEMY_OCCLUDED );
}
else
ClearConditions( bits_COND_ENEMY_OCCLUDED );

I looked up the definition for ASSERT, which was #define ASSERT(f) . I
don't know what that does so it scares me.

Am I correct in guessing that the above snippet of code checks (if the
enemy is visible) if the monster currently sees the enemy, and if so, turns
COND_ENEMY_OCCLUDED on? And what would that be used for, and why?

AI confuses me.

-geoff c

___
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

RE: [hlcoders] Confusing bit of code in the HL AI

[Adrian Finol]

 And that too.

-Original Message-
From: Leon Hartwig [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 06, 2002 6:30 PM
To: '[EMAIL PROTECTED]'
Subject: RE: [hlcoders] Confusing bit of code in the HL AI


ASSERT() in the HL SDK will actually just print a message to the console
(when your have compiled in Debug mode), such as:

ASSERT FAILED: 


> -Original Message-
> From: Adrian Finol [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 06, 2002 6:27 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE: [hlcoders] Confusing bit of code in the HL AI
>
>
>  That code sets the COND_ENEMY_OCCLUDE flag if the enemy is
> NOT visible.
> Hence the !FVisible. If it's visible, then it removes the flag.
>
>  Assert is a debug function, it will break (stop) the debugger if the
> condition passed is not met.
>
> -Original Message-
> From: geoff c [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 06, 2002 6:22 PM
> To: [EMAIL PROTECTED]
> Subject: [hlcoders] Confusing bit of code in the HL AI
>
>
> ladies and gentlemen of the jury, please direct your attention towards
> monsters.cpp, line 1065:
>   if ( !FVisible( pEnemy ) )
>   {
>   ASSERT(!HasConditions(bits_COND_SEE_ENEMY));
>   SetConditions( bits_COND_ENEMY_OCCLUDED );
>   }
>   else
>   ClearConditions( bits_COND_ENEMY_OCCLUDED );
>
> I looked up the definition for ASSERT, which was #define ASSERT(f) . I
> don't know what that does so it scares me.
>
> Am I correct in guessing that the above snippet of code checks (if the
> enemy is visible) if the monster currently sees the enemy,
> and if so, turns
> COND_ENEMY_OCCLUDED on? And what would that be used for, and why?
>
> AI confuses me.
>
> -geoff c
>
> ___
> 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

RE: [hlcoders] decals

[Adrian Finol]

 gEngfuncs.pEfxAPI->R_DecalRemoveAll ( int i );

 The name is missleading, since it doesn't remove all decals but one. So you
want to do something like this:

 for ( int i = 0; i < (int)CVAR_GET_FLOAT( "r_decals" ); i++ )
 gEngfuncs.pEfxAPI->R_DecalRemoveAll ( i );

 If you don't have the latest SDK, add this to the end of efx_api_s (after
R_LookupColor ) in r_efx.h:

 void   ( *R_DecalRemoveAll )   ( int textureIndex
);


-Original Message-
From: omega [mailto:[EMAIL PROTECTED]]
Sent: Friday, November 29, 2002 1:29 PM
To: [EMAIL PROTECTED]
Subject: [hlcoders] decals


About a year ago now, Adrian (pink) had mentioned in irc that he was
adding an engine command to globally clear all decals on a map (for
round resets and such)



Does anybody know if he ever implemented it or not? I'd like to add it
to FLF now that I've returned to FLF to using a custom decals.wad so
that quads don't stick in place, or hang over edges anymore.

-omega
Blackened Interactive - http://blackened-interactive.com
Front Line Force - http://www.flfmod.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/hlcoders

RE: [hlcoders] Transparent color on model?

[Adrian Finol]

 There will be after we release the next patch. You can assign rendermodes
to textures, like additive. You can also mask out colors in a texture.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 23, 2002 10:57 AM
To: [EMAIL PROTECTED]
Subject: [hlcoders] Transparent color on model?


All:

Is there a way to make a single color on a model transparent, like the
alphatest color on a sprite?

Thanks,
Scott

___
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

RE: [hlcoders] ATI RADEON [7200] card problems.

[Adrian Finol]

 You can turn this off by setting the ati_npatch cvar to 0.

 Just enter "ati_npatch 0" in the console.

 -Adrian

-Original Message-
From: Vyacheslav Djura [mailto:[EMAIL PROTECTED]]
Sent: Monday, January 13, 2003 9:34 AM
To: [EMAIL PROTECTED]
Subject: [hlcoders] ATI RADEON [7200] card problems.


Hi! I think you know that on ATI RADEON video cards models geometry is
smoothed by hadware. That makes a lot of our models looking ugly, is
there any way to disable this feature of video card in engine?


Best regards,
 Vyacheslav "Hoaxer" Djura


Distinct Reality mod   (www.wrenchsoftware.com/dreal/dreal.html)

___
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

RE: [hlcoders] Mouth movement for voice

[Adrian Finol]

 You shouldn't need to do anything code wise. Does your model has a
controller called mouth? That should be all you need to get voice comm to do
what you want.

-Original Message-
From: Mazor [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 26, 2003 2:19 PM
To: [EMAIL PROTECTED]
Subject: RE: [hlcoders] Mouth movement for voice


Then how did CS manage to do it?

If I'm not mistaken, if you hooked the engine audio, wouldn't you be
hooking EVERYTHING? I just want the mouths to move when someone uses
voice communication.

-Cale

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of botman
Sent: Wednesday, February 26, 2003 3:53 PM
To: [EMAIL PROTECTED]
Subject: Re: [hlcoders] Mouth movement for voice

> Well, I meant 'I can figure out how to move the mouth without sound'.
I
> have no idea how to hook the audio stream... that's what I needed help
> with.

AFAIK, there is no interface between the engine and the game DLL (or
client
DLL) to allow you to modify or monitor the audio data stream.

You'll have to create your own audio output routines and use those
instead
of letting the engine play the audio.

I think I remember a post by Yahn on the topica.com discussion from a
few
years ago where someone asked about how to override the engine audio
output
and Yahn posted some code that showed how it might be done.

Jeffrey "botman" Broome

___
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

RE: [hlcoders] 9wb problems

[Adrian Finol]

 If they are always looking to the right maybe you still have controllers in
your model? I've seen that behavior before and it was caused by that.

 About the animations that don't play properly, what happens? There is
hardcoded numbers for animations that are full body (no gait sequence). You
might want to look at these numbers:

#define ANIM_WALK_SEQUENCE  2
#define ANIM_JUMP_SEQUENCE  28
#define ANIM_LAST_NONGAIT_SEQUENCE  27 //Marks the latest non gaited
sequence

 About the server side code, I don't remember if we ever released this, I'll
get it together and post it here if we didn't.

-Original Message-
From: jc [mailto:[EMAIL PROTECTED]
Sent: Saturday, March 29, 2003 4:50 AM
To: [EMAIL PROTECTED]
Subject: [hlcoders] 9wb problems


This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
hey. im trying to get the 9-way-blending code to work. i got the files
shimms posted compiled in and working. there are few problems tho (third
person mod):

all my models seem to look to the right (depends on animation - eg swim
works :S)

jump and some other anims dont play properly.

i understand there is some related server side code, has anyone here got it?
also, did anyone have the above problems?

(oh, the m_bLocal thing is set to false so its)

jc
--

___
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

RE: [hlcoders] default.cfg

[Adrian Finol]

 If what you want is set default keys when a config file is not found, the
values are in the kb_def.lst file under /gfx.

-Original Message-
From: Kyle [mailto:[EMAIL PROTECTED]
Sent: Saturday, April 12, 2003 12:37 PM
To: [EMAIL PROTECTED]
Subject: RE: [hlcoders] default.cfg


Yes, when config is deleted, I want to exec from the mod/pak0.pac file
"default.cfg" exactly like valve does

I thought all you had to do was place the default.cfg in the pac. I did
notice another file called valve.rc within it there was a line commented
out //exec default.cfg  im not sure if that matters tho. I tried
uncommenting that line but it did not seem to help.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Friday, April 11, 2003 2:05 AM
To: [EMAIL PROTECTED]
Subject: RE: [hlcoders] default.cfg

I'm not 100% sure what you want...

I'm gathering that you want it to exec default.cfg when config.cfg is
deleted?

-Cale

-Original Message-
Wrom: LBDXRQBGJSNBOHMKHJYFMYXOEAIJJPHSCRTNH
[mailto:[EMAIL PROTECTED] On Behalf Of Kyle
Sent: Thursday, April 10, 2003 11:42 PM
To: [EMAIL PROTECTED]
Subject: RE: [hlcoders] default.cfg

??? Is this a tuff question, I did not think it was

-Original Message-
Wrom: GSWZIDREXCAXZOWCONEUQZAAFXISHJEXXIMQZ
[mailto:[EMAIL PROTECTED] On Behalf Of Kyle
Sent: Friday, April 04, 2003 3:55 PM
To: [EMAIL PROTECTED]
Subject: [hlcoders] default.cfg

This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
>From what I understand this file gets exec'ed if there is no config
file? I guess im wrong because that doest work. It always reverts back
to the valve/default.cfg
How can I make a default.cfg specific to my mod that gets set when the
config gets deleted?

--

___
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

RE: [hlcoders] (no subject)

[Adrian Finol]

 Just ran out of coffee, Anyone seen Alfred lately?

-Original Message-
From: Erik Johnson [mailto:[EMAIL PROTECTED]
Sent: Friday, July 18, 2003 2:37 PM
To: '[EMAIL PROTECTED]'
Subject: RE: [hlcoders] (no subject)


For now, we're going to keep Alfred around at Valve.

-Original Message-
From: Michael A. Hobson [mailto:[EMAIL PROTECTED]
Sent: Friday, July 18, 2003 2:34 PM
To: [EMAIL PROTECTED]
Subject: Re: [hlcoders] (no subject)


Alfred:

You don't appear to be a Valve employee.

Please provide us with a copy of whatever communication you
have from someone at Valve stating this:

At 11:03 AM 7/18/2003 -0700, Alfred wrote:
>The HL2 SDK (when its released) will compile under msvc 6.0 and gcc 3.2.
>I suspect with a bit of tweaking you could use mingw in windows to
>compile the dlls as well.
>

Michael A. Hobson
email: [EMAIL PROTECTED]
(310) 649-0792

___
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

RE: [hlcoders] PM_PreventMegaBunnyJumping()

[Adrian Finol]

 The 1.7 and 0.65 are just two numbers we chose after testing and tweaking
the code around.

 If you read the code, BUNNYJUMP_MAX_SPEED_FACTOR is used as a cap on how
fast you can go. We still let you bunny hop, but instead of going uncapped
like before (reaching speeds of mach 3!) we now slow you down so you can't
exceed the player's maxspeed * 1.7, which is still a little high, but we
thought it fit TFC since we didn't want to get rid of all the little tricks
you could do with the rocket launcher and grenades.

 The 0.65 is how fast we slow you down, we didn't want it to feel like
hitting wall once you went over the maxspeed.

 For reference, CS's numbers are 1.2 and 0.8.

-Original Message-
From: Brian A. Stumm [mailto:[EMAIL PROTECTED]
Sent: Saturday, August 23, 2003 9:52 AM
To: [EMAIL PROTECTED]
Subject: [hlcoders] PM_PreventMegaBunnyJumping()



Can someone explain to me the reasoning behind this code (code at bottom)?

I understand this is to limit bunny hopping but why 1.7X the player max
speed? Is there a reason this was not set lower? Also why the .65 speed
reduction? 400 x 1.7 * 0.65 = 443 ???

I would like to further prevent bhoping and thought I would follow Valves
approach only with different multipliers but wonder why Valve didn't do
this originally. Was there some problem that prevented using a factor of
1.0 or 1.2 for example? Why was 1.7 chosen as the limit?

[code]

FROM VALVE SDK FILE: pm_shared.c

#define BUNNYJUMP_MAX_SPEED_FACTOR 1.7f

//--
---
// Purpose: Corrects bunny jumping ( where player initiates a bunny jump
before other
//  movement logic runs, thus making onground == -1 thus making PM_Friction
get skipped and
//  running PM_AirMove, which doesn't crop velocity to maxspeed like the
ground / other
//  movement logic does.
//--
---
void PM_PreventMegaBunnyJumping( void )




___
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

RE: [hlcoders] PM_PreventMegaBunnyJumping()

[Adrian Finol]

 Bunny hopping in TFC could be done in several ways, you could do it the old
fashioned way, which was just jumping and strafing so you could gain
velocity. Or you could fire a rocket behind you so it'd push you forward and
then continue hopping along without losing speed.

 Tweaking those values shouldn't prevent rocket jumping since you gain the
extra push AFTER you've jumped. This code is only run everytime you jump,
but if after you're in the air you get pushed, your velocity won't be capped
until you try to jump again.



-Original Message-
From: Brian A. Stumm [mailto:[EMAIL PROTECTED]
Sent: Saturday, August 23, 2003 3:27 PM
To: '[EMAIL PROTECTED]'
Subject: RE: [hlcoders] PM_PreventMegaBunnyJumping()


On Sat, 23 Aug 2003, Adrian Finol wrote:

>  The 1.7 and 0.65 are just two numbers we chose after testing and tweaking
> the code around.
>
>  If you read the code, BUNNYJUMP_MAX_SPEED_FACTOR is used as a cap on how
> fast you can go. We still let you bunny hop, but instead of going uncapped
> like before (reaching speeds of mach 3!) we now slow you down so you can't
> exceed the player's maxspeed * 1.7, which is still a little high, but we
> thought it fit TFC since we didn't want to get rid of all the little
tricks
> you could do with the rocket launcher and grenades.

Are you saying that values lower (perhaps I should say too much lower)
than 1.7 would eliminate rocket jumping and conc jumping in TFC? I do not
wish to do that and have other ideas on how to rid bhop from tfc without
losing the various rocket/gren jumps. But when I stumbled upon the valve
bhop prevention code I thought perhaps I could just tweak that in some
seperate hooking code (botmans not metamod).


___
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

RE: [hlcoders] Weeeeee! ;)))

[Adrian Finol]

We have replaced Alfred with a monkey, it might take a while to get used
to it, so don't freak out!

Thanks!

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Friday, March 05, 2004 1:38 AM
To: [EMAIL PROTECTED]
Subject: [hlcoders] Wee! ;)))

--
I don't bite, weah!

pass: 40327
--
[ Text.zip of type application/octet-stream deleted ]
--


___
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

RE: [hlcoders] Weeeeee! ;)))

[Adrian Finol]

This is a multi-part message in MIME format.
--
Yes, but nobody will ever match Alfred's speed and accuracy.



From: [EMAIL PROTECTED] on behalf of Jeffrey "botman" Broome
Sent: Sat 3/6/2004 6:30 AM
To: [EMAIL PROTECTED]
Subject: Re: [hlcoders] Wee! ;)))



Adrian Finol wrote:

> We have replaced Alfred with a monkey, it might take a while to get used
> to it, so don't freak out!

Does the monkey fling his poo like Alfred does?  :)

--
Jeffrey "botman" Broome

___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders



--
[ winmail.dat of type application/ms-tnef deleted ]
--

___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

RE: [hlcoders] pwd?

[Adrian Finol]

 weah!

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Saturday, March 13, 2004 2:52 AM
To: [EMAIL PROTECTED]
Subject: [hlcoders] pwd?

This is a multi-part message in MIME format.
--
is that your website?
--
[ details.zip of type application/x-zip-compressed deleted ]
--



___
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

RE: [hlcoders] ^_^ mew-mew (-:

[Adrian Finol]

 tl;dr

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of StealthMode
Sent: Thursday, May 13, 2004 10:51 AM
To: [EMAIL PROTECTED]
Subject: Re: [hlcoders] ^_^ mew-mew (-:

It would be real easy for Valves IT people to block this lamers ip on
the incoming  mail server or even on the router the mail server is
plugged into.

Wonder who Valves IT guy is. He should be fired or reprimanded. I know
the companies I worked for in the past would not tolerate a hole like
this in their network security (especially one that is continually
abused/exploited.
Least the lamer isn't smart and trying to attach the virus (which IS
blocked by Valves mail server), instead of just linking to it (my god he
could trick a lot of people with just links, thank god the virus author
is an idiot).
Still a lapse in Valves network security though. Like I said, if this
thing just added links it would sneak right past the no attachments
filter. And most people thinking its from Valve (since it lacks
attachments), would click the link and get a virus. Valve had better
hope no one gets that smart, or else VALVE could be liable for
distributing the virus, even though unintentionally, through a hacked
means, they still would be liable.

In summary, BLOCK THE IP THAT IS SPAMMING THIS LIST WITH VIRUS
ATTACHMENTS BEFORE IT/THEY CAN CAUSE MORE DAMAGE!

The guy above posted the header info, the ip its being sent from is
quite easily blocked. Someone at Valve needs to start doing their job.

One corporate email from Valves legal dept. to the cybercafe I am sure
would stop the mails (least from the polish cyber cafe). And to that
owner of the cafe, ever hear of a virus scan on your network? Trend
Micro offers a real good online one that is FREE... www.antivirus.com ,
www.trendmicro.com

Kudoes to the guy who backtraced the email. Maybe the guy whose email
box just got spammed by everyone on this list (I know I mailed them),
will do the work the IT guy at Valve should be doing.

For now (no offense to Alfred) I am filtering all mails from Alfred at
this point, just in case this lamer reads this list and gets some ideas
from my reply. Once Valve announces they have blocked the ip from the
mail server I shall unfilter alfred mails to this and the other lists.
Until then, I guess I don't read anything posted by Alfred.

I mean honestly, lets say some noob joins this list. He doesn't know
about the lamer spoofing Alfreds email. He looks at the file and says
gee it wont let me get it, but thats Alfred Reynolds from Valve and
thats probably something important, and googles the file attachment.
Valve is now resonsible for distributing a virus, a serious liability.

-=]H[=-StealthMode


___
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

RE: [hlcoders] client side PVS/PAS ent question

[Adrian Finol]

Try this:

//returns true if the player is in the same PVS
bool CheckPVS(int iPlayerIndex)
{
cl_entity_t *pLocalPlayer = gEngfuncs.GetLocalPlayer();
cl_entity_t *pPlayer;

pPlayer = gEngfuncs.GetEntityByIndex( iPlayerIndex );

if( pPlayer == NULL || pLocalPlayer == NULL )
return false;

if( pPlayer->curstate.messagenum <
pLocalPlayer->curstate.messagenum )
  return false;

return true;
}

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Josh Coyne
Sent: Sunday, May 16, 2004 7:51 PM
To: [EMAIL PROTECTED]
Subject: [hlcoders] client side PVS/PAS ent question

When it comes to reading players into cl_entity structs, is there any
simple way to check if the players in question are in the local players
PVS/PAS ?

I ask because I'm doing alot of things client side such as blood trails
and laser beams and last time around i ran into a big problem where
blood and laser beams would come out at random areas because the
client.dll's locations for these players wasn't updated.

Regards,
Josh


___
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

RE: [hlcoders] :-)

[Adrian Finol]

Now that's funny.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of tei
Sent: Wednesday, May 19, 2004 8:15 AM
To: [EMAIL PROTECTED]
Subject: Re: [hlcoders] :-)



the virus come from here:

(map)
http://telejano.berlios.de/option/tomasz1.gif

(city itself)
http://www.nofrag.com/image.php?url=/screenshots/actualite/2003-09-01_ha
lflife2_04.jpg


I suggest to send our agent Gordon Freeman to this location AS FAST AS
POSIBLE.


Ryan "Professional Victim" Desgroseilliers wrote:
> The Polish Conspiracy strikes again!
>
> - Original Message -
> From: "K. Mike Bradley" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, May 19, 2004 9:45 AM
> Subject: RE: [hlcoders] :-)
>
>
>
>>LOL !
>>
>>-Original Message-
>>From: [EMAIL PROTECTED]
>>[mailto:[EMAIL PROTECTED] On Behalf Of McCormack,
>
> Chris
>
>>Sent: Wednesday, May 19, 2004 4:17 AM
>>To: [EMAIL PROTECTED]
>>Subject: RE: [hlcoders] :-)
>>
>>get him tei GET HIM !
>>
>>-Original Message-
>>From: [EMAIL PROTECTED]
>>[mailto:[EMAIL PROTECTED] Behalf Of
>>[EMAIL PROTECTED]
>>Sent: 18 May 2004 21:35
>>To: [EMAIL PROTECTED]
>>Subject: [hlcoders] :-)
>>
>>
>>--
>>Looking forward  for  a  response :P
>>
>>password for archive: 54213
>>--
>>[ AttachedFile.zip of type application/octet-stream deleted ]
>>--
>>
>>
>>___
>>To unsubscribe, edit your list preferences, or view the list archives,

>>please visit:
>>http://list.valvesoftware.com/mailman/listinfo/hlcoders
>>
>>
>>***
>>This e-mail and its attachments are confidential and are intended for
>>the above named recipient only. If this has come to you in error,
>>please
>
> notify
>
>>the sender immediately and delete this e-mail from your system.
>>You must take no action based on this, nor must you copy or disclose
>>it or any part of its contents to any person or organisation.
>>Statements and opinions contained in this email may not necessarily
>>represent those of Littlewoods.
>>Please note that e-mail communications may be monitored.
>>The registered office of Littlewoods Limited and its subsidiaries is
>>100
>
> Old
>
>>Hall Street, Liverpool, L70 1AB.
>>Registered number of Littlewoods Limited is 262152.
>>
>>
>>
>>___
>>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

RE: [hlcoders] Quiet!!!!

[Adrian Finol]

Shhh, Alfred's sleeping.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jeffrey
"botman" Broome
Sent: Friday, June 04, 2004 3:52 PM
To: [EMAIL PROTECTED]
Subject: [hlcoders] Quiet

Hello?... Hello?  Is anyone there?...  (tumbleweed rolls by)...

It shore has been quiet on this here e-mail list lately.

Oh well, if you're the last one to leave, don't forget to turn the
lights out.  :)

--
Jeffrey "botman" Broome

___
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

RE: [hlcoders] RE: Incoming Msg

[Adrian Finol]

Agreed!

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Pavol Marko
Sent: Wednesday, September 01, 2004 10:52 AM
To: [EMAIL PROTECTED]
Subject: Re: [hlcoders] RE: Incoming Msg

omg anyone ban this one please :)
It's annoying...

- Original Message -
From: "Jeffrey "botman" Broome" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, September 01, 2004 7:18 PM
Subject: Re: [hlcoders] RE: Incoming Msg


> Alfred wrote:
>
>> --
>> [ Converted text/html to text/plain ]
>>
>> --
>> [ Details.hta of type application/octet-stream deleted ]
>> --
>
> INCOMING  Everyone get their heads down!!!  :)
>
> --
> Jeffrey "botman" Broome
>
> ___
> 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

RE: [hlcoders] Shield

[Adrian Finol]

Having a shield is a state. When you pickup a "weapon_shield" it removes
that entity and then sets the picker's m_bOwnsShield (part of CSPlayer)
to true.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Freecode
Sent: Saturday, September 25, 2004 2:02 PM
To: [EMAIL PROTECTED]
Subject: [hlcoders] Shield

If a shield is on the ground its a valid entity and its classname is
"weapon_shield" but when u pick it up the entity is removed. Now but you
still have the shield why isnt it an entity? And Besides checking users
viewmodel is there any way of checking if a player has shield?

___
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

RE: [hlcoders] Shield

[Adrian Finol]

But did you know the name of the variable? I think not!

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jeffrey
"botman" Broome
Sent: Saturday, September 25, 2004 4:29 PM
To: [EMAIL PROTECTED]
Subject: Re: [hlcoders] Shield

Adrian Finol wrote:
> Having a shield is a state. When you pickup a "weapon_shield" it
> removes that entity and then sets the picker's m_bOwnsShield (part of
> CSPlayer) to true.

It's that what I said?  ;)

--
Jeffrey "botman" Broome

___
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

RE: [hlcoders] HL2 Dev CPU Requirements

[Adrian Finol]

Hah!

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Brian
"Satertek" Irelan
Sent: Thursday, October 21, 2004 3:30 PM
To: [EMAIL PROTECTED]
Subject: Re: [hlcoders] HL2 Dev CPU Requirements

You have to have a widescreen LCD monitor like all the guys at Valve.


On Thu, 21 Oct 2004 15:01:32 -0400, Jonathan Dance <[EMAIL PROTECTED]>
wrote:
> Hi,
>
> I'm trying to prepare for doing HL2 mod development, and I know my
> computer is not ready to handle this task. I am wondering if Valve can

> give me an idea on what they have been using to do HL2 development.
> This is for actual coding and playing the game in Debug mode with MSVC

> open. I'd also be interested in knowing what is being used for running

> the new Hammer.
>
> In other words, we have minimum system requirements if you want to
> play the game, but what do you suggest if you want to develop the
game?
>
> --JD
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>


--
http://www.spreadfirefox.com/?q=affiliates&id=25779&t=86";>
http://spreadfirefox.com/community/images/affiliates/Buttons/125x50
/takebacktheweb_125x50.png"/>

___
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

RE: [hlcoders] NPCs acting differently

[Adrian Finol]

Is your gamerules initializing relationships correctly?

Check CHalfLife2::InitDefaultAIRelationships in hl2_gamerules.cpp to see
how HL2 does it.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Gerald
Sent: Saturday, December 04, 2004 4:21 PM
To: [EMAIL PROTECTED]
Subject: [hlcoders] NPCs acting differently

Hi

I'm trying to get NPCs to work in a multiplayer mod. What I've done use
use the single player code and run it with a net_start, sv_lan 1,
maxplayers 10 before starting the map. Players join fine, but NPCs just
sit there.

I worked out that it is the maxplayers variable that changes how NPCs
behave. As soon as it's bigger then 1, NPCs just stop working properly.

Also, NPCs obey the npc_go, etc commands just fine with any maxplayer
value.

I've trolled through the NPC code and the AI code, but can't find the
particular thing that changes this logic.

Any ideas?

Thanks,
Gerald


___
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

RE: [hlcoders] M_iPrimaryAmmoType

[Adrian Finol]

Did you add the ammo type? Search for CAmmoDef *GetAmmoDef() and you'll see how 
HL2 adds ammo types.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Xas
Sent: Tuesday, December 14, 2004 12:17 AM
To: [EMAIL PROTECTED]
Subject: RE: [hlcoders] M_iPrimaryAmmoType

I know that.
I was asking about their initialization, because my GiveAmmo() doesn't work.
Isn't it supposed to add the value of default_clip variable in the script 
weapon file ?
In my script file I have :
"clip_size" "1"
"default_clip"  "5"

But when I made an impulse 101, my weapon get 1 ammo, and nothing into the clip.
I got nothing in my reserv. I don't understand why.
Why GiveAmmo returns me 0 ?



-Message d'origine-
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] De la part de Mike Dussault Envoyé : mardi 14 
décembre 2004 02:35 À : [EMAIL PROTECTED] Objet : RE: [hlcoders] 
M_iPrimaryAmmoType

m_iPrimaryAmmo tells the ammo type that a gun uses. It comes from the 
"primary_ammo" field of the weapon's script file (in scripts\weapon_.txt). m_iAmmo tells how much of each type of ammo a character has
name>on
them.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Xas
Sent: Sunday, December 12, 2004 6:57 AM
To: [EMAIL PROTECTED]
Subject: [hlcoders] M_iPrimaryAmmoType

Can someone explain me how works the m_iPrimaryAmmoType.
How is it initialized exactly ?
How the m_iAmmo array of CBaseCombatCharacter class is initialized too ?

Because I'm missing something about adding a new weapon (and not replacing one).

Xas.


___
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

RE: [hlcoders] should I wait for hl2dm sdk?

[Adrian Finol]

We are planning on releasing the HL2DM source code but don't have a date
for it right now.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Kyle Keating
Sent: Wednesday, December 15, 2004 8:35 PM
To: [EMAIL PROTECTED]
Subject: Re: [hlcoders] should I wait for hl2dm sdk?

I worked on and complete a hl1 mod for two years. I became very
efficient with that SDK and so far, hl2 seems very similar. If I need to
learn anything, its the new entity structure and some new variable names
and vgui 2.0. Other than that I just want to improve hldm2. My entire
hl1 mod was aimed at improving hldm1 and we developed lots of robust
features that we would like to incorporated into hldm2 before it gets
boring and dies out. With only 2 maps and and no features, the mod
(hldm2) as it stands is pretty bare, and valve would do itself justice
by realising the SDK to the experience programmers who have the
motivation and enthusiasm to help the game. I don't want the SDK to
learn. I did that, I want the SDK to make hl2dm worthy of its name.


On Wed, 15 Dec 2004 22:35:23 -0500, John bKT Bellone
<[EMAIL PROTECTED]> wrote:
> ChessMess wrote:
>
> >Learning through example is much more efficient then learning by
> >trial. If you have the time to spare, learn by trial. If you need to
> >get up to speed quickly or you don't have the time to spare, learn by

> >example.
> >
> >What ever became of that Book that was suppose to be published about
> >modding for HL2?
> >
> >http://www.amazon.com/exec/obidos/tg/detail/-/0761543635/qid=11031454
> >08/sr=1-3/ref=sr_1_3/102-8508584-8465730?v=glance&s=books
> >
> >___
> >To unsubscribe, edit your list preferences, or view the list
archives, please visit:
> >http://list.valvesoftware.com/mailman/listinfo/hlcoders
> >
> >
> >
> >
> >
> >
> >
> Not sure... I usually learn faster by learning by trial because I know

> exactly what is happening, and I don't need to fish around someone
> elses' code.
>
> Normally I look at entities (in this SDK at least) that would most
> resemble what I am attempting to create, therefore I have somewhat of
> a basis when creating mine. The power of "Find in Files" :)
>
> --
> -John "bKT" Bellone
> Project Manager, Programmer
> Flipside Software
> http://www.flipsidesoftware.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/hlcoders




___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

RE: [hlcoders] Multiplayer NPCs

[Adrian Finol]

The most expensive thing NPCs do network wise is animation. They don't
do client side animations, so their animation cycle is always being
transmitted to each client. Another thing is, animation layers are also
networked and they are a bit expensive.

We mostly use layers during choreo scenes (several per character at a
time) but only a few NPCs use them while running their normal behavior
(striders and antlion guards come to mind).

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of David Byttow
Sent: Friday, December 17, 2004 9:19 AM
To: [EMAIL PROTECTED]
Subject: Re: [hlcoders] Multiplayer NPCs

How do you know it's not exactly optimal? Have you done testing? You
have to think of what can be done clientside. Obviously you want all
logic and movement to be on serverside. So that leaves very little to
client-side aside from FX, sounds and death effects.


On Fri, 17 Dec 2004 11:00:15 -0500, wheaty <[EMAIL PROTECTED]> wrote:
> I've been able to get a fully working headcrab in a multiplayer mod
> (basically copied the npc_headcrab code and spent a while trimming it
> until it compiled).  As it stands right now, *everything* is done on
> the server side, which isn't exactly optimal.  My question is, should
> I attempt to hack the headcrab into the "shared" code?
>
> ___
> 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

RE: [hlcoders] Is Per-Entity Gravity Possible ?

[Adrian Finol]

Did you check GAME_SHARED\physics_main_shared.cpp ?

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Michael
Hobson
Sent: Friday, December 17, 2004 10:29 AM
To: [EMAIL PROTECTED]
Subject: RE: [hlcoders] Is Per-Entity Gravity Possible ?

Yahn:

Thank you for the speedy response.

At 08:58 AM 12/17/2004, Yahn  wrote:
>Correct, you'd have to convert gravity to a vector, which should be
>doable.  Brian was going to do this at one point for kicks, not sure if

>he has any suggestions on what the biggest issues will be.  My gut is
>that the FL_ONGROUND assumptions about the z axis in the movement code
>would take a bit of time to unwind, but you do have all of that code in

>the SDK at this point, so this should be very possible.

The code in GAME_SHARED/GAMEMOVEMENT.* appears to only apply to
*players* (like HL 1's PM_SHARED subsystem).

In looking around in the SDK code, I haven't yet found anything that
would allow me to control the movement for any other entity types.  Am I
missing something here ?



>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of Xas
>Sent: Friday, December 17, 2004 1:09 AM
>To: [EMAIL PROTECTED]
>Subject: RE: [hlcoders] Is Per-Entity Gravity Possible ?
>
>For what I found, gravity is used as a float, not a vector...=20 Even
>if we can found a vector gravity in low level include, it seems = that
>it have not been generalized (in sense that I can easily decide that my

>world has a gravity like (-1, = 5,
>64))
>
>
>-Message d'origine-
>De : [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] De la part de Michael =
>Hobson
>Envoy=E9 : vendredi 17 d=E9cembre 2004 09:51 =C0 :
>[EMAIL PROTECTED] Objet : [hlcoders] Is Per-Entity
>Gravity Possible ?
>
>Yahn or Alex:
>
>Do we have sufficient low-level access to Havok in order to allow =
>per-entity gravity magnitude and direction vectors ?
>

{OLD}Sneaky_Bastard!
email:  [EMAIL PROTECTED]
Michael A. Hobson
icq:#2186709
yahoo: warrior_mike2001
IRC:  Gamesurge channel #wavelength


___
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

RE: [hlcoders] Blame Yahn for this one?

[Adrian Finol]

Something like that...

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Yahn Bernier
Sent: Thursday, January 06, 2005 9:00 PM
To: hlcoders@list.valvesoftware.com
Subject: RE: [hlcoders] Blame Yahn for this one?

I think Adrian was trying to get the HL2 teleporter sequence to feel
"lethargic" so I told him to scale all of the player movement... :)

Something like that

Yahn

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of r00t 3:16
Sent: Thursday, January 06, 2005 7:29 PM
To: hlcoders@list.valvesoftware.com
Subject: [hlcoders] Blame Yahn for this one?

gamemovement.cpp
around line 677

//!!HACK HACK: Adrian - slow down all player movement by this factor.
//!!Blame Yahn for this one.

Thought that was kind of funny :P


r00t 3:16
CQC Gaming
www.cqc-gaming.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/hlcoders




___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

RE: [hlcoders] Player animation ?

[Adrian Finol]

Actually, it looks like he's not loading the HL2DM models but the HL2
ones. In HL2DM Humans and Combine share the same animations.

Make sure you are loading from the right *_animations.mdl animation
files. Both set of models should have the same animation and activity
names.

Other than that Major Boone speaks the truth. Using the Weapon's
activity translation table is the cleanest way to handle different
animations per weapon.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Matt Boone
Sent: Tuesday, January 11, 2005 2:05 PM
To: hlcoders@list.valvesoftware.com
Subject: RE: [hlcoders] Player animation ?

HL2DM player animation uses a different system than is in the sdk.
Basically you have a list of base sequences, preblended with 9-way aims
and 9-way runs - those are the aim animations and are called in game
code via activities ( why you see different animation names in combine
vs rebels ).

Shooting is done by adding the fire animation as a gesture over top of
the base sequence.

For Dod we're doing a hybird, with the activities on base sequence and
fire/reload/hand signal gestures over top, but non-networked like the
sdk does it to reduce net traffic.

I would recommend moving at least to using activities for your player
animations so avoid all the nasty string construction and comparing.

As far as your animations only playing the first and last frame, this
function doesn't appear to be causing that. I would check with a a
different model/sequence to see if it's a problem in your model.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Patrick
Flanagan
Sent: Tuesday, January 11, 2005 11:33 AM
To: hlcoders@list.valvesoftware.com
Subject: [hlcoders] Player animation ?

I'm trying to get player animation working with some non-CS models.
Specifically, I'd like to get animations working with the models used in
HL2DM. I used model viewer to load up the combine models from HL2DM and
some of the resistance models from HL2DM.

Not only are their animations totally different from CS, they're
different from each other. The combine models have different animations
than the resistance models. I've been working on converting the
animation names in sdk_playeranimstate.cpp to call the animations in
combine_solder.mdl, which I think is the one used in HL2DM.

I've run into some problems with this though.

First off, there's doesn't seem to be any walking or running shooting
animations. There are animations like ShootSGs, ShootSGc, ShootSMG1s,
ShootSMG1c, etc but there's no walk_upper_mp5 or run_upper_mp5 like in
the CS models. There doesn't seem to be any animation to be running and
shooting at the same time.

Second, the animations seem to only play the first frame and then stop.
For example, I changed CalcFireLayerSequence to look like this:


int CSDKPlayerAnimState::CalcFireLayerSequence(PlayerAnimEvent_t event)
{
// Figure out the weapon suffix.
CWeaponSDKBase *pWeapon = m_pHelpers->SDKAnim_GetActiveWeapon();
if ( !pWeapon )
return 0;

const char *pSuffix = GetWeaponSuffix();
if ( !pSuffix )
return 0;

// Don't rely on their weapon here because the player has
usually switched to their
// pistol or rifle by the time the PLAYERANIMEVENT_THROW_GRENADE
message gets to the client.
if ( event == PLAYERANIMEVENT_THROW_GRENADE )
{
pSuffix = "Gren";
}

switch ( GetCurrentMainSequenceActivity() )
{
case ACT_PLAYER_RUN_FIRE:
case ACT_RUN:
//return CalcSequenceIndex( "%s%s",
DEFAULT_FIRE_RUN_NAME, pSuffix );
return CalcSequenceIndex( "ShootSMG1s" );
//FIXME: totally wrong

case ACT_PLAYER_WALK_FIRE:
case ACT_WALK:
//return CalcSequenceIndex( "%s%s",
DEFAULT_FIRE_WALK_NAME, pSuffix );
return CalcSequenceIndex( "ShootSMG1s" );
//FIXME: totally wrong

case ACT_PLAYER_CROUCH_FIRE:
case ACT_CROUCHIDLE:
return CalcSequenceIndex( "%s%s",
DEFAULT_FIRE_CROUCH_NAME, pSuffix );

case ACT_PLAYER_CROUCH_WALK_FIRE:
case ACT_RUN_CROUCH:
return CalcSequenceIndex( "%s%s",
DEFAULT_FIRE_CROUCH_WALK_NAME, pSuffix );

default:
case ACT_PLAYER_IDLE_FIRE:
//return CalcSequenceIndex( "%s%s",
DEFAULT_FIRE_IDLE_NAME, pSuffix );
return CalcSequenceIndex( "ShootSMG1s" );
//FIXME: pick the right weapon
}
}

I've set my player model to be combine_soldier. When I spawn in third
person and watch my player model, if I run along start shooting it looks
like it plays only the first frame or two and then immediately goes back
to idle/jittering. If I'm running, it looks even worse since

RE: [hlcoders] RE: HL2DM SDK in January or February? Matt, i discovered something

[Adrian Finol]

Random number? Where is that number coming from? We need more info to
help you fix this problem.

What happens if you do this:

 int pitch = GetOuter()->LookupPoseParameter( "aim_pitch" );

 if ( pitch < 0 )
return;

 SetOuterPoseParameter( pitch, -90 );

Does your player model pitch change at all?

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jose Luis
Gonzalez
Sent: Tuesday, January 18, 2005 3:05 PM
To: hlcoders@list.valvesoftware.com
Subject: [hlcoders] RE: HL2DM SDK in January or February? Matt, i
discovered something

This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ] One note, Matt.



First:

I fixed the physics bugs with the code in  
www.sourcewiki.org



Well, when I walk in a room and touch a physics object (a chair or a
table),

the pitch parameter turns, but only one time.



I used cl_showanimstate to see it.



The aim_pitch turns from 0.0 to random number and the HL2DM model

change the pose animation



Why this change??



Sorry for my English.



>I change the pose parameter in this function in
>base_playeranimstate.cpp,

>Using HL2DM animations.



>void CBasePlayerAnimState::ComputePoseParam_BodyPitch()

>{

>  // Get pitch from v_angle

>  float flPitch = m_flEyePitch;

>  if ( flPitch > 180.0f )

>  {

>flPitch -= 360.0f;

>  }

>  flPitch = clamp( flPitch, -90, 90 );

>

>  // See if we have a blender for pitch

>  int pitch = GetOuter()->LookupPoseParameter( "aim_pitch" );

>  if ( pitch < 0 )

>return;

>  SetOuterPoseParameter( pitch, flPitch );

>  g_flLastBodyPitch = flPitch;

>}

>

>I changed LookupPoseParameter("body_pitch")

>with LookupPoseParameter( "aim_pitch"). But don't work.

>

>Can this be a pitch bug in SDK??

--



___
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

RE: [hlcoders] Valve's Zoom Function

[Adrian Finol]

CHudZoom in cl_dll\hl2_hud\hud_zoom.cpp is what you're looking for.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of David Nelson
Sent: Saturday, January 22, 2005 3:01 PM
To: hlcoders@list.valvesoftware.com
Subject: [hlcoders] Valve's Zoom Function

Ok when you press Z it invokes +zoom function.  It has a fuzzy circular
blackout around the outside of the screen as it zooms in.  How do they
do the blackout on the screen.  I've been looking for that effect for
awhile now.  How do you do a blackout?

Thanks,
David


___
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

RE: [hlcoders] Assert error

[Adrian Finol]

What does GetClassname() return?

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of r00t 3:16
Sent: Tuesday, February 22, 2005 4:43 PM
To: hlcoders@list.valvesoftware.com
Subject: [hlcoders] Assert error

This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ] In
basecombatweapon_shared.cpp

Around line 198.

else

{

Assert( !"Missing weapon script file" );

// Couldn't read data file, remove myself

Msg( "Error reading weapon data file for: %s\n", GetClassname() );

// Remove( ); //don't remove, this gets released soon!

}

When launching the HL2DM sdk it starts to load a map and gives an assert
which breaks at the above code.
What weapon is it looking for? I have all the script files in the
scripts directory?


r00t 3:16
CQC Gaming
www.cqc-gaming.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/hlcoders

RE: [hlcoders] Using "Dissolve" to make disappear a ragdoll.

[Adrian Finol]

Yes, the ragdoll is released as soon as the effect is done.

Check C_EntityDissolve::ClientThink( void ) in c_entitydissolve.cpp.


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jose Luis
Gonzalez
Sent: Wednesday, March 02, 2005 7:05 AM
To: hlcoders@list.valvesoftware.com
Subject: [hlcoders] Using "Dissolve" to make disappear a ragdoll.

Hi. I'm now using the dissolve function to make disappear a ragdoll:

pRagdoll->Dissolve( ... );

When entity disolves, disappear. But, in memory too??

Do ragdoll disappear in memory too or only becomes invisible and
untouchable after dissolve?.

Thanks.

Sorry for my english



___
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

RE: [hlcoders] HL2MP Speed hack

[Adrian Finol]

You forgot to preface your email with "ProTip:"

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Lance Vorgin
Sent: Friday, March 04, 2005 10:59 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] HL2MP Speed hack

Dude put all anticheat related code on the server whenever possible :o

___
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

RE: [hlcoders] Anyone know how VICE works?

[Adrian Finol]

Your Gamerules should have this method defined and returning the same
key you used to encrypt the files:

virtual const unsigned char *GetEncryptionKey() { return NULL; }

We only use this for the weapon script files. Also the code looks for a
script file with the extension '.ctx' and if not found then fallbacks to
the .txt file of the same name.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dave R.
Meyers
Sent: Tuesday, March 29, 2005 6:09 PM
To: hlcoders@list.valvesoftware.com
Subject: [hlcoders] Anyone know how VICE works?

Just kind of curious.  I was wondering how this works code wise.

I understand the command line stuff, but once the files are encrypted,
how do you use them in your mod?

Dave



___
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

RE: [hlcoders] How to make a beam fade out?

[Adrian Finol]

Creating the beam with the FBEAM_FADEOUT flag should do what you want.

By the way, you can find all the valid beam flags in
game_shared\beam_flags.h.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ian Warwick
Sent: Monday, June 20, 2005 7:33 AM
To: hlcoders@list.valvesoftware.com
Subject: [hlcoders] How to make a beam fade out?

I am trying to make a beam fade away, I was thinking kRenderFxFadeFast
would do the trick, but where to specify this when creating a beam using
BeamCreate() method of CBeam, once I have an instance of CBeam I am
unsure where to specify the renderfx that the sprite will use.

Any help on this would be much appreciated.

Kind Regards

Ian



This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error you are on notice of
its status. Please notify us immediately by return email if you are not
the intended recipient and delete this message. Please note that any
views or opinions presented in this email are solely those of the author
and do not necessarily represent those of FusionPeople Ltd.

FusionPeople Ltd may monitor outgoing and incoming emails and other
telecommunications on its email and telecommunication systems.

===
This message has been checked for all known viruses by MessageLabs, The
service does not scan any password protected or encrypted attachments.
FusionPeople Ltd accepts no liability for any damage caused by any virus
transmitted by this email.

___
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

RE: [hlcoders] poser parameters in a v_ model?

[Adrian Finol]

Pose Parameters can be used to blend between frames or animations.

Most of the NPCs in Half-Life 2 use pose parameters to blend between 8
different run or walk animations (One for each direction). And in the
case of the AR2 it just blends between two keyframes (one open and one
closed).

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Maurino
Berry
Sent: Wednesday, September 07, 2005 11:26 AM
To: hlcoders@list.valvesoftware.com
Subject: RE: [hlcoders] poser parameters in a v_ model?

I'm not 100% so someone may correct me (please do) But I think a pose
parameter being set is simply the delta between the positon/rotation of
2 keyframes, not a set of actual animation frames.

Regardless, the AR2 model uses a poseparameter in the v model to control
the vent (for some weird reason) so take a look at that.



>From: Tim Holt <[EMAIL PROTECTED]>
>Reply-To: hlcoders@list.valvesoftware.com
>To: hlcoders@list.valvesoftware.com
>Subject: [hlcoders] poser parameters in a v_ model?
>Date: Tue,  6 Sep 2005 13:43:04 -0700
>
>Is there any reason one couldn't put a poser parameter on a v_ model's
>arm, so that code could control where the arm is positioned?
>
>I'm thinking of how to make very fine action controls that have to be
>dynamic.
>Getting a pointing finger to exactly hit a button rather than vaguely
>"poke" at the middle of the POV.
>
>___
>To unsubscribe, edit your list preferences, or view the list archives,
>please visit:
>http://list.valvesoftware.com/mailman/listinfo/hlcoders
>

_
Take charge with a pop-up guard built on patented Microsoft(r)
SmartScreen Technology
http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU
=http://hotmail.com/enca&HL=Market_MSNIS_Taglines
  Start enjoying all the benefits of MSN(r) Premium right now and get
the first two months FREE*.


___
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

RE: [hlcoders] Is it possible to have client-side Entity only?

[Adrian Finol]

There are a few examples of client-side only entities in the SDK.

Check c_gib.cpp for C_Gib or c_baseanimating for C_ClientRagdoll.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marcus Matèrn
Sent: Tuesday, September 20, 2005 9:14 AM
To: hlcoders@list.valvesoftware.com
Subject: [hlcoders] Is it possible to have client-side Entity only?

Is it possible to have an entity only on the client side without the server 
knowing about it? Or do I have to do something like:

IMPLEMENT_CLIENTCLASS_DT(C_Crosshair, DT_Crosshair, CCrosshair)

and have a responding class (CCrosshair) at server side?

I've tried setting it up using this following code but it will not draw.
Do I have to implement my own DrawModel( int flags ) ?

The crosshair should be a entity with x,y,z. Not a 2D HUD object.

Thanks in advance!



class C_Crosshair : public C_BaseAnimating {
   DECLARE_CLASS( C_Crosshair, C_BaseAnimating ); ...
}


void C_Crosshair::Init( void )
{
   // Precache();

   InitializeAsClientEntity( ENTITY_MODEL,  ENDER_GROUP_OPAQUE_ENTITY );

}

void C_Crosshair::SpawnClientEntity( void ) {
   SetMoveType( MOVETYPE_NONE );
   SetSolid( SOLID_BBOX );
}


void C_Crosshair::Precache( void )
{
PrecacheModel( ENTITY_MODEL );
}


static void CreateCrosshairCallback( void ) {
   C_Crosshair *pCrosshair = new C_Crosshair;
   pCrosshair->Init();
...
   pCrosshair->SetLocalOrigin( pPlayer->GetAbsOrigin() );

}




___
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

RE: [hlcoders] Is there such a thing as a NULL model?

[Adrian Finol]

You can always return false in C_BaseCombatWeapon::ShouldDraw if is not
being carried by the local player.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Teddy
Sent: Saturday, November 26, 2005 6:28 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] Is there such a thing as a NULL model?

I did this for the "Fatman Fist" weapon in dystopia. I modified the
SetWeaponVisible() for the fist, so it would AddEffects( EF_NODRAW );
(which hides the world model) and then  vm->RemoveEffects( EF_NODRAW );
so it shows the viewmodel

On 11/27/05, Chris Janes <[EMAIL PROTECTED]> wrote:
> For early versions of hidden we just commented out the world model
> from the weapon script - it threw an error in the console, but didn't
> crash and the model was invisible (no error model either). Might be a
> good place to start looking.
>
> If that doesn't work for you, could you not maybe set the models alpha
to 0?
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Imperio59
> Sent: 26 November 2005 20:20
> To: hlcoders@list.valvesoftware.com
> Subject: [hlcoders] Is there such a thing as a NULL model?
>
> Hi,
> I'm faced with a problem right now, and i've been trying a few
> solutions but to no avail so far...
> I'm trying to create a weapon that has a first person view model, but
> no third person model at all (the character model will display the
animation).
> I've tried SetModel(NULL); or putting "" as the world model name in
> the script file, both those crash me... I've tried putting a bunch of
> AddEffect(EF_NODRAW) everywhere in my weapon class, no luck there,
> i've had a modeller make me an empty model, and that also crashes...
>
> Anyone got a simple solution for me to fix this problem?
>
>
> --
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.1.362 / Virus Database: 267.13.8/183 - Release Date:
> 25/11/2005
>
>
>
> ___
> 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