RE: [hlcoders] Re: hl1 engine suggestions

2003-09-19 Thread Ken Birdwell
The definitive statement on the subject:

http://collective.valve-erc.com/index.php?go=q1_or_q2

-Original Message-
From: tei [mailto:[EMAIL PROTECTED]
Sent: Friday, September 19, 2003 2:57 PM
To: [EMAIL PROTECTED]
Subject: [hlcoders] Re: hl1 engine suggestions


Hello Cale,

CMD You do that then you have HL2 :)

CMD HL1 was based on a Quake 1 graphics engine, and part of a Quake 2
engine
CMD for net code. Which means: no shaders, no video's as textures, no neato
CMD video console...

Humm.. no.
Thats not really true. Most modified Quake2 engines support shaders or
something similar (rscripts). QuakeWorld support uploading skins.


CMD  and why would anybody need an avatar? It's a game, not
CMD a chat system.

Avatars?
+showscores

Maybe is a good idea, and modders will use this feature to show the
avatar of the guy has kill you. People like avatars :*]

Chats?
GameSpy alike chats, helpfull to start games?


CMD I have many more things to say, but I better keep my comments about
this
CMD post to myself or I'll get myself in trouble.

Hehehe.. thanks!


End of file underconstruction.


___
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] Emiters and Attachments

2003-07-18 Thread Ken Birdwell
It's not really clear from your email, but you should only use attachments
on the client.  They're fairly useless on the server since they're not frame
accurate. On the client they are frame accurate, though they're calculated
only AFTER the model has been drawn.  On HL1, everything connected to
attachment points were tagged as being partially transparent, which would
guarentee the correct evaluation order.

For player attachment points, their weapon's attachment points can/will
override any built-in player attachment point calculations.  This is so that
the same attachment point index can be used when connecting to either a view
model or world model, even though they're in radically different places.

All undefined attachment points default to the model's origin, which in
the case of the player is in the very center of their bounding box, 36 units
off the ground.  If your seeing this, you may be using the wrong index.
Attachment point indexes are 1 off when networking, so refer to attachment
points 1-4 on the server when you're trying to connect to the model's
attachment point 0-3.  Yes, this is confusing.

I'm not sure exactly what your bug is, but it's either wrong index, which
is an easy fix, or you're asking for the value too soon in the rendering
loop, which is a harder problem.

-Original Message-
From: Michael [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 16, 2003 5:28 PM
To: [EMAIL PROTECTED]
Subject: [hlcoders] Emiters and Attachments


What i know about attachments? i know attachments are part of the model
file and i know each model can only have 4 attachment points. i know the
attachments are defined in the model's .qc. i also know that the model's
attachment data is stored in a structure called, cl_entity_t, or
cl_entity_s. i also know how to figure out the attachment point, more
specific the attachment point of the v_ model from the client in an
instance of an event system call.

Now to the problem. i want to make a flame thrower. a flame thrower that
emits particles. i've created an emiter that emits particles that  fits
my flamethrower's needs. i also made my flamethrower to emit by using
the event system ( those .sc files), the event system emits partilces
correctly in first person only. in third person the emiter is stuck
where was the last position the emiter was set in first person and it's
also near the gonad area if you just switch to thirdperson without
moving the player. now i want to solve this problem and the problem is
that i wish to set the emiter at the location of the attachment of the
player where normally the muzzle flash is, and i want to transmite this
to all clients that can see this happening.

my solution to this problem was to get the attachment point of the
player on the server and using an entity, that represents the emiter, to
place the entity origin to the attachment point and transmiting the
origin of  the entity. the problem is that none of the attachment points
i used worked, there were no offset to the player origin. i even look at
the source code for egon and i notice the beam doesn't start from the
tip of the egon world model but rather it starts from somewhere near the
end arm and close to the base of the elbow. that wouldn't work well for
my particles because they are big and the arm doesnt cover it and it
expands, the particle, in size. also this might increase the network
traffic.

i was told to take a look at HUD_AddEntity. the comment above it says
that it gets a list of visible entities. this functionlooks attractive
because it gets a list of visible entites and that means i do not have
to worrie about the extra network traffic. now if i was to use this
function i would like a way to identify my entity and add members to
entity_state_s so i can send the emiter's  emission, and i would also
like to set the entity, on server side, origin to an attachment point.


___
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] Emiters and Attachments

2003-07-18 Thread Ken Birdwell
I'd recommend you just delay evaluation until rendering.  Even doing what
maxor recommended won't fix the view model/world model problem.

-Original Message-
From: zmeko [mailto:[EMAIL PROTECTED]
Sent: Friday, July 18, 2003 3:25 PM
To: [EMAIL PROTECTED]
Subject: Re: [hlcoders] Emiters and Attachments


if I was to call the when the player press fire, is it too early in the
rendering loop? Anyways, I might was well use offsets as mazor recommended.

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



RE: [hlcoders] Additive Rendermode

2003-03-03 Thread Ken Birdwell
It sounds like you're trying to synthesize a texture by blending two
paletted textures in-memory before you render.  Neat idea, but I'm not sure
anyone here (Valve) can help you, Half-Life doesn't do that anywhere.
Palettes aren't used during blending, they're only used for the on-disk (and
sometimes in-memory) format.  Blending in Half-life is always done in screen
format, which is either 15, 16, or 24 bit color depending on your hardware
or software mode.  At that stage, it's never returned to paletted mode.

Since HL doesn't do anything like what you're trying to do, I'm not sure
that anyone here has thought through all the issues.  If you're calling
through tri-api, the first problem you may be hitting is that HL optimizes
the palette list, all textures that share the same palette get indexed to
the same GL palette entry.  One problem you may be having is that your new
palette may not actually be getting loaded, or, well, any one of many other
possibilities.  You may want to ask Alfred Reynolds directly, I think he's
done some work with loading textures post initialization.

-Original Message-
From: Skyler York [mailto:[EMAIL PROTECTED]
Sent: Monday, March 03, 2003 3:55 PM
To: [EMAIL PROTECTED]
Subject: [hlcoders] Additive Rendermode


[ Converted text/html to text/plain ]
Please excuse my last e-mail, Hotmail is a piece of sh*t... :(

Anyway, I am working on a few features/additions for the compile tools and
wanted to use Half-Life's additive rendering to blend two textures together.
Not literally, of course, but simply use the same equation used in Half-Life
to blend two textures together additively.  Now, before you say STFW!!! I
already have, and to my surprise I couldn't find much info.  I did happen to
read that additive blending was like glBlendFunc(GL_ONE, GL_ONE), however I
couldn't decipher the MSDN docs to figure out what the actual equation would
be :)

One problem is that the texture miptex's in the WAD files are using 8-bit
palettes.  So while I can do the blending in 24-bit, I have to regenerate a
new palette based on the end blend.  Luckily, I am able to generate pretty
good palettes with NeuQuant, an algorithm which uses Kohenen's
self-organizing
neural networks.  However it isn't perfect.  The problem I'm having here is
that whenever I test out a new blending algorithm in an attempt to emulate
Half-Life's, it's difficult to tell whether or not the error is with the
algorithm or with the palette generated.

I know a lot of Valve programmers hang out here, so if anyone could lead me
in
the right direction for the additive blending in Half-Life, that would be
much
appreciated.  I'm pretty sure it's a OpenGL/D3D thing, but I couldn't
decipher
the docs and the web hasn't been helpful. :)

And if anyone knows of a good palette generation algorithm, I'd like to hear
about it :)  Neural networks are supposed to be pretty dang good, but the
code
I'm using is from 1994, so who knows :P


--
Add photos to your messages with MSN 8. [1] Get 2 months FREE*.

===References:===
  1. http://g.msn.com/8HMBENUS/2749

___
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] Additive Rendermode

2003-03-03 Thread Ken Birdwell
For now, if possible, I recommend using a fixed palette. :/ It won't be real
pretty, but it'll get your mod up and running and folks playing it.

-Original Message-
From: Alfred [mailto:[EMAIL PROTECTED]
Sent: Monday, March 03, 2003 6:18 PM
To: [EMAIL PROTECTED]
Subject: Re: [hlcoders] Additive Rendermode


snip
  You may want to ask Alfred Reynolds directly, I think he's
 done some work with loading textures post initialization.

Unfortunately I haven't done anything like this with the SDK codebase :(

___
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 memory management

2003-01-29 Thread Ken Birdwell

 I also recommend against loading a private copy of the model

 Any particular reason, other than not wasting RAM?  At this point, I don't
really plan to, just curious.

Just a memory issue.  It's something that's easily overlooked on a machine
with a lot of RAM that can cause serious slowdowns on lower end machines.
___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders




RE: [hlcoders] Models and memory management

2003-01-28 Thread Ken Birdwell
I'm pretty sure my posting said the exact opposite of botman's response.

Precacheing only allocates a name slot for model.  It doesn't force it to
be in memory.  The HL engine demand loads model data only when needed.

It rarely happens, but you can't count on the pointer being valid between
subsequent calls to g_engfuncs.pfnGetModelPointer(), since the engine can
move or throw away model data if something else needs the memory.  In
theory, each call to g_engfuncs.pfnGetModelPointer() could force a cache
flush and any pointers it returned earlier will no longer be valid.

I also recommend against loading a private copy of the model, you should
just write your code so it calls Mod_g_engfuncs.pfnGetModelPointer() when it
needs  a pointer to your model data.

-Original Message-
From: botman [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 28, 2003 10:30 AM
To: [EMAIL PROTECTED]
Subject: Re: [hlcoders] Models and memory management


 Does the model data for monsters remain in memory for the duration of a
 map, or is it dynamically loaded/unloaded?  I'm guessing that the player
 model remains in memory.  What I really need to know is, if I use
 g_engfuncs.pfnGetModelPointer, will that pointer remain valid or do I need
 to call it each time I need the data?  I'm trying to decide whether to use
 the engine's copy of the model or just load it myself - it just seems a
 waste of memory to have the same thing loaded twice.

Everything that get's precached stays loaded into memory until the level is
unloaded.  There was a discussion a few months ago in this group about
precacheing and when memory is allocated for parts of a model.  Here's Ken's
reply...

http://list.valvesoftware.com/mailman/private/hlcoders/2002-October/004928.h
tml

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




RE: [hlcoders] SDK Licence applies to HL PS2?

2003-01-09 Thread Ken Birdwell
Officially: We're planning to add those to the SDK.  When we do they would
be available under the SDK license.

There's part of your question that indirectly deals with reading data off of
a PS2 disc, with all the Sony copyright and copy protection issues.  Valve
can obviously NOT give you permission to do that as it's an issue between
you and Sony.  I don't have a Sony EULA handy, though I'm sure it'll cover
exactly those questions.

Given the interest in the models, we're currently planning on adding them to
our SDK, at which time you'll be able to use them in your mod, as stated in
the SDK license.

-Original Message-
From: Ken Birdwell [mailto:[EMAIL PROTECTED]]
Sent: Sunday, January 05, 2003 4:01 PM
To: '[EMAIL PROTECTED]'
Subject: RE: [hlcoders] SDK Licence applies to HL PS2?


No word yet.  I've ping'd Scott and Doug again and see where this is at.

-Original Message-
From: Kratisto [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 03, 2003 6:34 PM
To: [EMAIL PROTECTED]
Subject: RE: [hlcoders] SDK Licence applies to HL PS2?


Back in november I posted a open question about using
content from the PS2 version of HL in user mods. I
would really need to know if that is allowed or not.
So, what's the answer?

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




RE: [hlcoders] SDK Licence applies to HL PS2?

2003-01-05 Thread Ken Birdwell
No word yet.  I've ping'd Scott and Doug again and see where this is at.

-Original Message-
From: Kratisto [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 03, 2003 6:34 PM
To: [EMAIL PROTECTED]
Subject: RE: [hlcoders] SDK Licence applies to HL PS2?


Back in november I posted a open question about using
content from the PS2 version of HL in user mods. I
would really need to know if that is allowed or not.
So, what's the answer?

--- Ken Birdwell [EMAIL PROTECTED] wrote:
 Some of these questions take a few days to answer,
 especially if they're
 questions we haven't heard before.  If it's IP built
 by us and published
 exclusively by Sierra on the PC then the question is
 easy, it would be yes,
 but for stuff where we had the work done by a third
 parties and/or the
 publisher was someone other than Sierra and/or if
 there are other contracts
 involved - i.e. Sony - then the immediate answer is
 let's ask the lawyers
 to double check before we say anything.  Both Doug
 Lombardi and Scott Lynch
 are looking into this question, and they'll let
 everyone know when they hear
 back, which will probably be sometime early next
 week.

 -Original Message-
 From: Kratisto [mailto:[EMAIL PROTECTED]]
 Sent: Friday, November 15, 2002 9:56 AM
 To: [EMAIL PROTECTED]
 Subject: [hlcoders] SDK Licence applies to HL PS2?


 Im planning to use some HL PS2 models in my little
 mod...

 As far I know, the HL SDK licence for mods covers
 content in the original game, CS, opfor and blue
 shift.

 But, its ok to use content from the Half-Life PS2
 port?


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




RE: [hlcoders] QC $flag ?

2002-12-20 Thread Ken Birdwell
Yep, these are still supported, though I'm no longer sure they all do the
exact same thing as Quake 1.

From engine\model.h

#define EF_ROCKET   (10)  // leave a trail
#define EF_GRENADE  (11)  // leave a trail
#define EF_GIB  (12)  // leave a trail
#define EF_ROTATE   (13)  // rotate (bonus items)
#define EF_TRACER   (14)  // green split trail
#define EF_ZOMGIB   (15)  // small blood trail
#define EF_TRACER2  (16)  // orange split trail +
rotate
#define EF_TRACER3  (17)  // purple trail

#define EF_FLYMODEL (18)  // illuminate as flying
model
#define EF_COMPLEX  (19)  // does complex entity to
entity intersection
#define EF_ENVLIGHT (110) // only uses environment
light


-Original Message-
From: omega [mailto:[EMAIL PROTECTED]]
Sent: Friday, December 20, 2002 8:02 AM
To: [EMAIL PROTECTED]
Subject: RE: [hlcoders] QC $flag ?


Quake engine stuff.
The flags are uhm /me pulls up engine source..

#define EF_ROCKET   1   // leave a trail
#define EF_GRENADE  2   // leave a trail
#define EF_GIB  4   // leave a trail
#define EF_ROTATE   8   // rotate (bonus items)
#define EF_TRACER   16  // green split trail
#define EF_ZOMGIB   32  // small blood trail
#define EF_TRACER2  64  // orange split trail +
rotate
#define EF_TRACER3  128 // purple trail

however, I don't know how much of it still exists in the hl engine.


-omega
Blackened Interactive - http://blackened-interactive.com
Front Line Force - http://www.flfmod.com


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of
[EMAIL PROTECTED]
Sent: December 20, 2002 11:06 AM
To: [EMAIL PROTECTED]
Subject: [hlcoders] QC $flag ?

[ Converted text/html to text/plain ]
All (especially Valve):

In a model .qc file, there is the option $flags followed by a integer.
I see
that this is stored in the .mdl file and can be read from the .mdl as
part of
the studiomdl_t structure.  But is there an easy way to access this
value on
the client side without reloading the model header?  Also, what do the
$flag
values represent?  It seems a value of 3 causes the model to light up.

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




[hlcoders] testing hlcoders

2002-12-17 Thread Ken Birdwell
valvesoftware.com switched to a new IP address, seeing if the routing tables
have propagated yet..
___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders




RE: [hlcoders] SDK Licence applies to HL PS2?

2002-11-15 Thread Ken Birdwell
Some of these questions take a few days to answer, especially if they're
questions we haven't heard before.  If it's IP built by us and published
exclusively by Sierra on the PC then the question is easy, it would be yes,
but for stuff where we had the work done by a third parties and/or the
publisher was someone other than Sierra and/or if there are other contracts
involved - i.e. Sony - then the immediate answer is let's ask the lawyers
to double check before we say anything.  Both Doug Lombardi and Scott Lynch
are looking into this question, and they'll let everyone know when they hear
back, which will probably be sometime early next week.

-Original Message-
From: Kratisto [mailto:kratisto;yahoo.com]
Sent: Friday, November 15, 2002 9:56 AM
To: [EMAIL PROTECTED]
Subject: [hlcoders] SDK Licence applies to HL PS2?


Im planning to use some HL PS2 models in my little
mod...

As far I know, the HL SDK licence for mods covers
content in the original game, CS, opfor and blue
shift.

But, its ok to use content from the Half-Life PS2
port?


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




RE: [hlcoders] Weapons and bones

2002-11-04 Thread Ken Birdwell
Any and all bones are possible.  As an example, look at the Tau cannon (call
the egon gun internally). It's the large backpack+hose weapon connected to
the arm, hand, and spine.

The weapons just inherit the bone values that name-match from the player.

-Original Message-
From: Neale Roberts [mailto:neale;pimurho.co.uk]
Sent: Monday, November 04, 2002 6:41 AM
To: [EMAIL PROTECTED]
Subject: [hlcoders] Weapons and bones


Hello!

Brief and (hopefully) simple question - Do weapon models need to be linked
to the Bip 01 R Hand bone, or can they be linked to *any* bone?

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




RE: [hlcoders] Sprite File Format

2002-10-27 Thread Ken Birdwell
Look in engine\spritegn.h, and the source for sprgen.exe in utils\sprgen.c
for more details.  This the program that turns lists of bmp's into spr
files.

-Original Message-
From: Michael Shimmins [mailto:shimms;tae-mod.com]
Sent: Sunday, October 27, 2002 7:39 PM
To: HLCoders
Subject: [hlcoders] Sprite File Format

Hi,

This may be one for Valve, but who knows someone else may know.  I'm
after information on the .spr file format, how it differs from BMPs etc.
What I want to do is load a SPR image on a Visual Basic form.  I can
code my own container for it if there is some information available on
the format.

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




RE: [hlcoders] Dual usage of a bone controller

2002-10-16 Thread Ken Birdwell

From your description, I'm not sure why you want to control them with a
single bonecontroller.  It seems that you should just set up two
bonecontrollers, one that controls the Z axis (or whatever it really is) of
the neck bone, and one that controls the X axis (or whatever) of the neck
bone.

$controller 0 Bip01Neck ZR -45 45
$controller 1 Bip01Neck YR -30 30

If you really want a single controller to modify both at the same time, you
can do that as well, though they'll move as a single unit.

$controller 0 Bip01Neck ZR -45 45
$controller 0 Bip01Neck YR -30 30

For controllers, it's:  $controller input channel type start stop

input channel can be 0 through 3, or mouth.  type can be X, Y, Z, XR,
YR, or ZR.

-Original Message-
From: Peter Immarco [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 16, 2002 12:16 PM
To: HLCODERS
Subject: [hlcoders] Dual usage of a bone controller


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

I'm talking with a graphics artist that has made many terrifice 3D models
that support skeletal animation.  Although I have written extensive code in
the past with the HL SDK, that used the up to 4 bone controllers that a HL
model supports, I'm a graphics and animation ignoramus so I need help asking
the graphics artist the right questions, or giving him the correct
information.

The character the graphics artist is designing will have a neck bone that
allows the characters head to both:

1) Rotate left to right like the standard HL human model does
2) But also move the head up and down along the Y axis.  Think of someone
nodding their head yes.

What confuses me is, how would that bone be controllable from the HL SDK?
All the bone controllers I've seen map the movement of a single bone to a
single operation, not more than one operation.  Do I need to have the
artist do something different in the model's skeletal structure?  Or is this
simply a simple 3D model bone labeling trick or, a DLL coding trick that I
am unaware of?  If it is the latter please point me to an example(s) so I
can know how to code it.

Hopefully this makes sense and someone can help me communicate the proper
language to the graphics artist.

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




RE: [hlcoders] Lots 'o precaching.

2002-10-14 Thread Ken Birdwell

Precacheing only allocates a name slot for model.  It doesn't force it to be
in memory.  The HL engine demand loads model data only when needed.

To further help reduce memory footprint, use $externaltextures (though this
only really helps in software) and use $sequencegroupsize to break the .mdl
file into multiple smaller chunks so that blocks of animation data are also
demand loaded.

http://www.thewavelength.net/oldsite/models/reference/qcscript.html



-Original Message-
From: Daniel Koppes
To: [EMAIL PROTECTED]
Sent: 10/12/2002 7:39 AM
Subject: [hlcoders] Lots 'o precaching.

I have a rather big problem.

I need some way to precache ~200 models but I cannot think of anyway
to
do this.

I can't guarantee that any of them won't be in a level, but loading all
of
them would be a terrible waste of memory (even  @ 500k per model thats
100mb of ram gone).

All attempts I have made were (mostly) met with that horrible
'Precaching
can only be done in Precache function'

Does anyone have any ideas?

(If this seems vague, I blame it on 4am).

___
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] gaitsequence problems

2002-06-06 Thread Ken Birdwell

Don't use sequence 0.  Sequence 0 is special when used as a gaitsequence. It
means, don't calculate any gait sequence animation info.

In CStudioModelRenderer::StudioDrawPlayer() you'll find:

...
if (pplayer-gaitsequence)
{
// calculate gait animation and blend parameters for aiming
}
else
{
// initialize bone controllers to default values
}
...

and in CStudioModelRenderer::StudioSetupBones() you'll find:

...
// calc gait animation
if ( m_pPlayerInfo  m_pPlayerInfo-gaitsequence != 0 )
{
// merge upper body with lower body
}
...


-Original Message-
From: Jeff Fearn [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 05, 2002 10:59 PM
To: [EMAIL PROTECTED]
Subject: Re: [hlcoders] gaitsequence problems


poke :)

 I am having a strange problem with player models. The problem is that if
the
idle
 sequence selected for the gait sequence is in position 0 then the model is
always
 bent forward, facing toward the ground at about 45%. Idle animations in
other
 positions do not have this problem. Also if I switch the idle sequences
around,
 then this behaviour will occur on the sequence moved to position 0 and the
idle
 sequence that was in position 0 will now look up/down correctly.

 This only seems to occur for idle animation, although these are always
first in
 our models and are therefor the only type of ACT's in position 0. It is
very
 strange that setting gait sequence to 0 would affect the top half of the
model
 anyway. I have not modified any of the model display code.

 It does look rather silly having your model switch between bending forward
at
45%
 and standing upright looking up/down as the idle sequence changes.

 My work around at the moment is to put a dummy ACT in position 0, like
ACT_SLEEP,
 which seems to work fine.

 We generaly have 3 idle sequences per player model, named idle, look_idle
and
 deep_idle.

 It looks like the croch idle top has been used with the standing legs from
idle.

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




RE: [hlcoders] p/w model skins

2002-06-02 Thread Ken Birdwell

The call to IEngineStudio.StudioSetupSkin( pweaponmodel, 1 ) won't do what
you want.  This function just readies the texture to be used by the graphics
card, which will get overridden inside of IEngineStudio.StudioDrawPoints().

The hidden magic undocumented info is to set
m_pCurrentEntity-curstate.skin to your desired texturegroup.  This is used
deep inside of IEngineStudio.StudioDrawPoints() when it iterates through all
the different textures used by your model.

Since your weapon doesn't have an entity of its own on the client, most
people will just tell you to change the players skin, which will also work
by may not be what you want.

-Original Message-
From: DarkCloud14 [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 31, 2002 4:37 PM
To: [EMAIL PROTECTED]
Subject: Re: [hlcoders] p/w model skins


 Hi again I've found the following in StudioModelRender.cpp
and tried to change skin with StudioSetupSkin but with no luck
can someone tell me what's wrong ??

  if (pplayer-weaponmodel)
  {
   cl_entity_t saveent = *m_pCurrentEntity;

   model_t *pweaponmodel = IEngineStudio.GetModelByIndex(
pplayer-weaponmodel );

   // Test Test Test
   IEngineStudio.StudioSetupSkin( pweaponmodel, 1 );

   m_pStudioHeader = (studiohdr_t *)IEngineStudio.Mod_Extradata
(pweaponmodel);
   IEngineStudio.StudioSetHeader( m_pStudioHeader );

   StudioMergeBones( pweaponmodel);

   IEngineStudio.StudioSetupLighting (lighting);

   StudioRenderModel( );

   StudioCalcAttachments( );

   *m_pCurrentEntity = saveent;
  }

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




RE: [hlcoders] Limiting events to entities in the PVS

2002-05-15 Thread Ken Birdwell

Look in common\const.h.  Change your MESSAGE_BEGIN() event to use MSG_PVS

MSG_BROADCAST   // unreliable to all
MSG_ONE // reliable to one (msg_entity)
MSG_ALL // reliable to all
MSG_INIT// write to the init string
MSG_PVS // Ents in PVS of org
MSG_PAS // Ents in PAS of org
MSG_PVS_R   // Reliable to PVS
MSG_PAS_R   // Reliable to PAS
MSG_ONE_UNRELIABLE // Send to one client, but don't put in reliable stream,
put in unreliable datagram ( could be dropped )
MSG_SPEC// Sends to all spectator proxies

-Original Message-
From: Matthew Lewis [mailto:[EMAIL PROTECTED]]
Sent: Monday, May 13, 2002 8:12 PM
To: [EMAIL PROTECTED]
Subject: [hlcoders] Limiting events to entities in the PVS


Here's a tough problem. I have an event handler that handles the firing of a
lightning gun. The event handler uses a R_BeamEnt entity to draw a lighting
bolt from the shooter's weapon off into the direction the shooter is facing.
The problem is that it seems the event message is sent to all clients even
when the entity triggering the event is outside the PVS. Unfortunately, the
entity's origin and angles don't appear to get updated on the client when
it's outside the client's PVS so the result is that I have lightning bolts
appearing from thin air randomly in the level since the event handler is
using obsolete coordinate information. So here's the question: Is there a
way to tell if the entity wishing to send the event is in the client's PVS
(and hence is receiving coordinate updates about the entity)? Or is there a
way on the clientside to tell that the event came from an entity in its
current PVS or that the coordinate infomation to that entity is currently
valid?

___
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] Maximum bone controllers? Anyone or Valve know?

2002-04-30 Thread Ken Birdwell

The model format can handle any number of them, but studiomdl is limited to
128, the engine limited to 8, and the networking (and probably the
modelviewer) is limited to 4 inputs.

In the clientdll, look at CStudioModelRenderer::StudioCalcBoneAdj() to see
how they're implemented.  At minimun you may just need to rework the
networking and temporary allocation.  At the extreme end, you may have to
implement a custom bone movement layer in
CStudioModelRenderer::StudioSetupBones().

-Original Message-
From: Chris Blane [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, April 30, 2002 1:48 PM
To: [EMAIL PROTECTED]
Subject: [hlcoders] Maximum bone controllers? Anyone or Valve know?


Ok, I recently decided to expand the Emotion System for DarkTruths, which
uses bone controllers to dynamically alter the face of the models in
realtion to certain Ai sceduals and such, and added 2 extra controllers for
the mouths to allow for smiling and such. However, the HLmodel viewer will
ONLY render the model from above if I do this. It appears on only screw up
if the number of bone controllers exceeds 5. Is this a bug in the viewer or
a limitation with HL? I need to know so that I knwo if this generic human
skeleton we use for all of DT's human NPC's needs altering.

Thnx.

:Tal-N

___
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] UTIL_SetSize

2002-04-25 Thread Ken Birdwell

In the studiohdr_t struct, there are both min/max and bbmin/bbmax which
_should_ have been used to set both movement hull and view clipping hull (qc
commands $bbox and $cbox respectively), but were never used in HL so
typically remain uninitialized.  If it's all your own models, you may want
set the values in your QC files and rely on that.

The other option is to use the bbmin/bbmax of some specific sequence, such
as an idle or maybe sequence 0.  The bbmin/bbmax of a sequence is the
studiomdl calculated box (studiomdl.c:842-902) around all the vertices in
all the animation frames of that sequence.  This is normally used by the
model renderer for view frustum clipping, though it's not a totally bad
choice for deciding what rough size to set your entity.

-Original Message-
From: botman [mailto:[EMAIL PROTECTED]]
Sent: Thursday, April 25, 2002 2:28 PM
To: [EMAIL PROTECTED]
Subject: Re: [hlcoders] UTIL_SetSize


 Ok, Im still fooling around with this model thing. I link the entity/model
to
 world with SET_MODEL then I go into the game realizing that the model is
not
 solid. I go back to code to fix this and I have now come to the conclusion
 that you need to set a size for the model to be solid. Now my question
 is, how can I find out these model size values, without having to type
them
 myself? Is there any more automatic way, like being able to just get the
size
 from a model in the .mdl file?

I would think it would be MUCH easier to hard code these based on the model
name than it would be to parse the .mdl file, scan through all the bones and
bone controllers and trying to determine the limits of the model's size
based
on that.  Just get your modeler to tell you what the bounding box of the
model
is and use those values for the UTIL_SetSize().

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] SITWFODF1D #1

2002-04-23 Thread Ken Birdwell

Good advice.  The only hard limitations compilied into the engine are
MAXSTUDIOBONES, MAXSTUDIOVERTS, and MAXSTUDIOCONTROLLERS.  The rest can be
changed.

-Original Message-
From: Persuter [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, April 23, 2002 10:08 AM
To: [EMAIL PROTECTED]
Subject: RE: [hlcoders] SITWFODF1D #1


I don't know if this is similar, but:

On Hostile Intent, we had oodles and oodles of player animations, and
eventually studiomdl started crapping out with amazing memory dump
errors.

The solution, however, was simple, we simply had to increase
MAXSTUDIOSEQUENCES or MAXSTUDIOANIMATIONS, I forget which one, and
recompile studiomdl and the game, then recompile all the models with the
new studiomdl. I see in studio.h that there is a MAXSTUDIOSKINS variable
as well, set to 100. Perhaps if you increased that to something higher
and recompiled both studiomdl and the game?

Again, it's a simple fix so you've probably already tried it, it just
seemed similar in many ways to the problem we were having (Valve's code
pooping out due to throwing way more at it than it was meant to handle).


Persuter

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




RE: [hlcoders] Demo formatting

2002-04-19 Thread Ken Birdwell

Are you all saying that host_framerate doesn't work anymore?  You're just
supposed to record your demos, then set host_framerate to something like
0.033 for 30fps or 0.05 for 20fps or whatever you want, then use startmovie
and endmovie to make long runs of screencaptures at a fixed fps.  At least
that's how it used to work.  Is it broke?

-Original Message-
From: Steven Guy [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 19, 2002 12:29 AM
To: [EMAIL PROTECTED]
Subject: Re: [hlcoders] Demo formatting


lol there's a better way. The way I do it I can get about 32.2 fps and it
runs very smoothly. Use timedemo to play a pre-recorded demo then use
startmovie endmovie
timedemo will force HL to play as many frames as it can from the demo. So at
most you can pull off 100fps from a movie but most likly you'll get around
32 if you got a really good computer

Such as mine.

-Ms

From: Roachfood - the-coming.com [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [hlcoders] Demo formatting
Date: Fri, 19 Apr 2002 02:20:05 -0500

That website is somewhat helpful, but wont be for his purposes.  It talks
about recording movies via startmovie and endmovie in the console.  It
basically takes screenshot after screenshot, throws it in a big file which
you run mkmovie on and it spits out the bmps.  Those can then be compiled
into a crude movie.  (Thats how I do demo stuff for my mod for right now)

Eventually I am going to do it a different way.  This is most likely the
best way for him to do it.  Too bad what you need is a video out on your
PC,
a VCR and a lot of time.  When I want to do a nice demo preview of my mod
to
publicize it, Ill record onto a VHS recapture it with sound etc then
cut
paste do whatever I need to do for a final product.

Too bad with the HL demos there is no way to parse (? right word?) it into
individual images or capture it into an AVI that I know of.  The startmovie
method results in about 5 fps (you have to drop your resolution down low to
keep some speed up) and it just looks goofy.  =)

Hopefully I have helped for once!

Roachfood
Programmer, Project Head of The Coming (http://www.the-coming.com)

- Original Message -
From: Michael Shimmins [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, April 19, 2002 2:09 AM
Subject: RE: [hlcoders] Demo formatting


  If you just want to edit your demos why not just use an external program
  to convert them to avis then edit them in Premier or some other edit
  program?
 
  http://www.planethalflife.com/vision has some good tuts I think.
 
  Michael Shimmins
  The Absconder Effect (http://www.tae-mod.com)
 
  -Original Message-
  From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED]] On Behalf Of geoff c
  Sent: Thursday, April 18, 2002 2:15 PM
  To: [EMAIL PROTECTED]
  Subject: [hlcoders] Demo formatting
 
 
  Out of curiosity, can anyone give me details on the demo format that HL
  uses? There are hardly any resources devoted to this. Even premade tools
  would help.
 
  I'm trying to make a highlights reel, see, but 50% of my DoD games
  consist of me respawning and running to the front lines - nothing
  terribly interesting. All I need to do is split segments and append
  them.
 
  thanks
  geoff
___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders




RE: [hlcoders] Demo formatting

2002-04-19 Thread Ken Birdwell

Why timedemo?  Timedemo won't give you a fixed and locked fps.  It'll just
give you frames at fast but somewhat variable intervals, which isn't what
mpeg generating systems want.  Using host_framerate returns images at a
constant fps, regardless of render performance.

-Original Message-
From: Steven Guy [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 19, 2002 12:43 AM
To: [EMAIL PROTECTED]
Subject: RE: [hlcoders] Demo formatting



just record a demo
play demo using timedemo
start recording movie: startmovie
stop recording at end: endmovie
use mkmovie to get the screen shots
use some program to slap all the screen shots together
encode
all done

I suggest using Divx Fast motion for encoding

-Ms

___
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

2002-04-15 Thread Ken Birdwell

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 the player?  If you're
 calling SET_VIEW() anywhere, such as your using a camera or something,
then
 you're not using the player.  I thought I mentioned this earlier.  Oh
well,
 the problem is that the skin is being taken from this entity, not the
 player.  Opps, oh well, hack that entities skin to something other than 0
 and try it.  It'll change now.  If not, then you're probably doing
something
 too complicated and I can't help you.

 9) Cool, but that's probably not quite what you want.  You have players
 skins, but they don't match the viewmodel skins so you don't want to use
 that variable.  Well, you can either make them match (textures are unique
by
 name per model so if you list the same textures multiple times it won't
use
 up more memory so just make them match) or you can find some spot on the
 client to overwrite the clients skin value, maybe in
HUD_WeaponsPostThink(),
 but to be honest I'm not sure that's the best place.

 -Original Message-
 From: Christopher Long [mailto:[EMAIL PROTECTED]]
 Sent: Sunday, April 14, 2002 4:08 AM
 To: [EMAIL PROTECTED]
 Subject: Re: [hlcoders] v_weaponmodels skin changing


 in other words since the player skin is changing the weapon one should as
 well... but there is something wrong with the weapon models qc file or
 something? Is that what your saying... if its not could please explain
 better i find the last bit hard to follow... do you mean if the players
skin

RE: [hlcoders] v_weaponmodels skin changing

2002-04-15 Thread Ken Birdwell

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 the player?  If you're
 calling SET_VIEW() anywhere, such as your using a camera or something,
then
 you're not using the player.  I thought I mentioned this earlier.  Oh
well,
 the problem is that the skin is being taken from this entity, not the
 player.  Opps, oh well, hack that entities skin to something other than 0
 and try it.  It'll change now.  If not, then you're probably doing
something
 too complicated and I can't help you.

 9) Cool, but that's probably not quite what you want.  You have players
 skins, but they don't match the viewmodel skins so you don't want to use
 that variable.  Well, you can either make them match (textures are unique
by
 name per model so if you list the same textures multiple times it won't
use
 up more memory so just make them match) or you can find some spot on the
 client to overwrite the clients skin value, maybe

RE: [hlcoders] v_weaponmodels skin changing

2002-04-13 Thread Ken Birdwell

The viewmodel inherits the skin setting (and everything else except model,
frame, and sequence) of the client's viewent, which is typically the player.
If you can locally - on the client - change the players skin (and body,
etc.) then the weapon should work how you want.

-Original Message-
From: Christopher Long [mailto:[EMAIL PROTECTED]]
Sent: Saturday, April 13, 2002 6:44 PM
To: [EMAIL PROTECTED]
Subject: Re: [hlcoders] v_weaponmodels skin changing


bump does anyone know the answer to this i'd like to clear it up for
myself.
- Original Message -
From: Christopher Long [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, April 13, 2002 5:59 PM
Subject: [hlcoders] v_weaponmodels skin changing

I've noticed that the python weapon model has submodel groups in it but what
i really want to do is change the v_models skins on demand. you can set a
players skin by playerPointer-pev-skin but it doesn't seem to work on
v_weaponmodels... i tried adding it to the deploy function (pev-skin = 2)
but it doesn't do anything the model stays its first skin.

I have a compiled model with multiple skins already set up and i have done
skin changes with player models before but it doesn't seem to work with the
weapons for me.

desert crisis did multiple submodels for each skin change. Am i not able to
change the skin colour of a v_weaponmodel without making each skin colour
change a submodel of the v_weaponmodel?

Anyone got any ideas about this as to whether you can do it? maybe i am
doing it wrong but i dunno. All that changes in the v_weaponmodel is the
hands skins the weapon itself stays untouched but since the hands are
compiled into the weapons its really part of the weapon so it should change
:/ i dunno..

help anyone??? it'd be appreciated.
___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders




RE: [hlcoders] no sequence for act:59 ( for a Gonome)

2002-04-10 Thread Ken Birdwell

Activities are enum'ed in activity.h.  Assuming you haven't edited it, the
59th one is ACT_EXCITED.  The most likely problem is that you have a
schedule telling your monster to play that activity, but your model doesn't
have any animations for it.  An alternate cause could be that maybe you've
edited activity.h and not updated activitymap.h to match.

You may want to change to error message to be:

ALERT ( at_aiconsole, %s has no sequence for %s\n, STRING(pev-classname),
activity_map[NewActivity]-name );


-Original Message-
From: Chris Blane [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, April 10, 2002 5:33 PM
To: [EMAIL PROTECTED]
Subject: [hlcoders] no sequence for act:59 ( for a Gonome)


This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
We've got a recreation of the Gonome that's got a single annoying bug with
it and we can't seem to find the casue. Everything is a preferect recreation
of the Op4 original apart from some improvements and what is going to be on
release a whoel new model anyway but we still want this old version to work
since the new models Qc file will be based on it. The problems is that since
it's based on the Bullsquid it needed some tweaking to begin with. The last
bug in it is that it's got an action which has no sequence attached to it.
Obviously the code reports that this entity has not got a sequence for this
action, but it uses %d and fills in the blank somehow. But for the love of
god there's only two mentions of the number 59 in the whole code. And none
apply to to the gonome in anyway.

We've worked it down to the fact that it must be an AI scedual or something
releated to New Activity but how does HL number the routiens?

Is this going to be a matter of trail and error? Please says it's not.

Thnx for any help.
Tal-N [project leader for DarkTruths]
--

___
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

2002-03-25 Thread Ken Birdwell

If you have models that don't animate - such as lamps, trash cans, etc. -
then even making them cyclers is expensive.  Just encoding the
pev-animtime and pev-frame can eat up tons of network (even single player)
and CPU bandwidth when you have a lot of them visible.  To get that overhead
back, make a version of cycler that doesn't ever call StudioFrameAdvance()
and use it for all your models that don't move.

Each bone used by a model also eats performance.  Depending on the specifics
of your CPU and graphics hardware, each bone can cost the performance
equivalent of anywhere from 5 to 30 polygons.  If you're building simple
models, be sure to create them with as few bones as possible.

Each time a model changes texture it costs performance.  If you're fond of
using lots of small textures on models then you may be wasting graphics
performance on switching textures instead of drawing polygons.

-Original Message-
From: ryan [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 25, 2002 6:35 PM
To: [EMAIL PROTECTED]
Subject: [hlcoders] Counter-Strike : Condition Zero


Well, my problem is sorta on both world poly and model poly counts. Because
my mod requires large map areas, though not so detailed. The amount of
models that will be on screen causes me to have a limited amount of polys
per model.

In other words, there will be too much going on to have nice detailed
models. =\
___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders




RE: [hlcoders] Bone position

2002-02-10 Thread Ken Birdwell

Look up the bone by name.  Bone names are stored in the models bone array.

int LookupBone( void *pmodel, char *name )
{
studiohdr_t *pstudiohdr = (studiohdr_t *)pmodel;
if (! pstudiohdr)
return -1;

mstudiobone_t *pbones = (mstudiobone_t *)( (byte *)pstudiohdr +
pstudiohdr-boneindex );

for (int i = 0; i  pstudiohdr-numbones; i++)
{
if (stricmp(pbones[i].name, name) == 0)
{
return i;
}
}
return -1;
}

-Original Message-
From: Cortex [mailto:[EMAIL PROTECTED]]
Sent: Saturday, February 09, 2002 11:25 AM
To: coders
Subject: [hlcoders] Bone position


This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
Sorry, I've send this message on topica list too :( I made a mistake :(

Hello,

I wanted to get the world position of a bone (Right and left foot) client
side.
I've only the id of the concerned entity...

After searching, I've found the GET_BONE_POSITION function but I don't know
what value to use for the first parameter (int iBone)...

If someone could give me some light, it would be very appreciated :)

  - 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] GetAttachment for server-side collision detection

2002-02-05 Thread Ken Birdwell

See Eric Smith's message of 1/24/02.
___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders




RE: [hlcoders] (no subject) (Skeletal Errors)

2002-01-27 Thread Ken Birdwell



Well, the other thing to 
look at isstudiomdl will also remove all bones that have no effect on the 
rendered model. If your animator created a model with no vertices attached 
to either "Bip01 L Leg" or any of its children, then studiomdl will remove this 
bone from the bone hierarchy and when it goes to attach your hitbox, it won't be 
able to find it.

-Original 
Message-From: Nathan Taylor 
[mailto:[EMAIL PROTECTED]]Sent: Saturday, January 26, 2002 7:28 
PMTo: HLCodersSubject: Re: [hlcoders] (no subject) 
(Skeletal Errors)

  None of the files have been renamed I said. Besides I am running a 
  millkshape environment, not a MAX environment.
  
  
- Original Message -
From: Pat 
Magnan
Sent: Saturday, January 26, 2002 8:02 
PM
To: 
[EMAIL PROTECTED]
Subject: Re: [hlcoders] (no subject) 
(Skeletal Errors)
Ken answered your question already dude :P Just rename the 
bones inthe .qc file.. Some versions of Max rename the 
bones without asking.Use "$renamebone from to" 
to make a unified list. See player_shared.qc for 
anexample. :P Umm can 
anyone like actually help me with the info I have 
provided?---Eighty 
percent of life is showing up. -- Woody 
Allen___To unsubscribe, 
edit your list preferences, or view the list archives, please 
visit:http://list.valvesoftware.com/mailman/listinfo/hlcoders
  
  Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com
  


Re: [hlcoders] Constructors

2002-01-23 Thread Ken Birdwell

Repeat of destructor/constructor C++ discussion.  TFC uses them.  HL
doesn't.  Read why and how below.

-Original Message-
From: Ken Birdwell 
Sent: Thursday, September 13, 2001 2:31 AM
To: '[EMAIL PROTECTED]'
Subject: RE: [HLCoders] CBaseEntity Memory Mgmnt Q.


I guess an important point to remember is that there is NO C++ in the
engine.  It's 100% C and assembly*.  The only C++ portions are the game
(server) and client dll.  Their interface to the engine is 100% C, that's
what all the Dispatchblah functions are for in cbase.cpp; they resolve the
C interface to their C++ counterparts.

During initialization, the engine calls the game dll's GetEntityAPI()
function.  This returns a structure filled in with function pointers to all
the game dll's dispatch functions, functions that the engine can then call
at the appropriate time.  Half-life implemented its game DLL in C++, though
you don't have to. At an early stage of the project the game dll was in fact
written completely in C - it was quicker to convert the original Quake 1 QC
code to C first instead of directly to C++ - your game dll could also be
written completely in C, but I can't think of why you'd ever want to.

Besides calling GetEntityAPI() during initialization, the engine also calls
the function GetEntityAPI2(), in which the game dll can return back another
list of dispatch functions, most notably containing the function
OnFreeEntPrivateData.  This function is called by the engine whenever it is
going to free up an edict, it's basically giving the game dll an opportunity
to do something - such as calling a local destructor on the private data -
before that memory becomes invalid.

As to constructors and destructors, we never used them.  The reasons are
mostly historical, there's no fundamental reason why we didn't, it's just
that the during the conversion from C to C++ they were never needed and we
just got into the habit of not using them.  Well, that's not totally true,
you may also notice that there's not a single** call to new in the entire
game dll, it (was) 100% written to just use the engine's memory management
system.  The driving force behind that coding standard was that the game
needed to run on a 16MB console machine with no virtual memory, and you
should also note that there's no (okay, hardly any) explicit CBaseEntity
pointers in any of the base classes since in some configurations (that you
don't have to worry about) the engines garbage collection memory system can
(could) move the addresses of everything on you between calls to
DispatchThink().  Not really something that's very clean to do on a real
free form C++ system, so avoiding calls to new and calls to destructors and
constructors made it a lot simpler to avoided bugs when that happened,
though I don't think the code works perfectly in its current configuration
(ie the GearBox guys had to beat on it some to make in run on a machine like
the PS2 again).

So who cares, call new all you want, make your mod run on a system that
needs 128MB of ram and go for it, you don't need to make sure it runs on all
the computers that people bought in 1995 like we had to (boo hoo, now I'm
just whining).  If you want your destructors called, do this:

NEW_DLL_FUNCTIONS gNewDLLFunctions =
{
OnFreeEntPrivateData,   //pfnOnFreeEntPrivateData
NULL,   //pfnGameShutdown
NULL,   //pfnShouldCollide
};

int GetNewDLLFunctions(NEW_DLL_FUNCTIONS *pFunctionTable, int
*interfaceVersion)
{
if(!pFunctionTable || *interfaceVersion !=
NEW_DLL_FUNCTIONS_VERSION)
{
*interfaceVersion = NEW_DLL_FUNCTIONS_VERSION;
return FALSE;
}

memcpy(pFunctionTable, gNewDLLFunctions, sizeof(gNewDLLFunctions));
return TRUE;
}

void OnFreeEntPrivateData(edict_s *pEdict)
{
if(pEdict  pEdict-pvPrivateData)
{
((CBaseEntity*)pEdict-pvPrivateData)-~CBaseEntity();
}
}

*okay, technically there's C++ in the engine for VGUI and audio stuff, but
it's very small and only went in the last year or so and it wasn't there
last time I worked on it.
**not sure if that's true anymore, it was true last time I checked.

-Original Message-
From: Soul Sounds [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 12, 2001 10:10 AM
To: [EMAIL PROTECTED]
Subject: [HLCoders] CBaseEntity Memory Mgmnt Q.



Should You Check Your Credit Report? Of course! We all check
our credit card statements for inaccuracies and we should do
the same for our credit history. Click here now to check
yours FOR FREE at ConsumerInfo.Com!
http://click.topica.com/caaadcTclvXIra2kxuha/ConsumerInfo


Hello,
 
I tried adding a destructor to a class I derived from CBaseEntity and 
got the following error:
 
C:\SIERRA\Half-Life\SDK

RE: [hlcoders] Models and sequences

2002-01-23 Thread Ken Birdwell

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




RE: [hlcoders] Hull3?

2002-01-20 Thread Ken Birdwell

I'm still not exactly sure what the problem is you're having, so here's some
basics:

1) The model the client is displaying has no effect on hitbox-traceline
intersection calculations (i.e. shooting the player).

2) The model (and specific pose) the client draws to represent the player
can be and is often a very different from the one the server uses.

3) r_drawentities 3 and r_drawentities 4 shows you where the CLIENT
thinks the hitboxes are.  It does not show you where the SERVER thinks they
are.  In fact, all r_drawentities # commands are client based and what is
displayed does not necessarily represent the servers view of the
model/world. I'm not aware of any debug output that will show you were the
server thinks a given models hitboxes are.

4) For all hitbox calculations, the SERVER uses the model referenced by the
players server side pev-model variable, and nothing else.

5) For display, the client uses a number of different methods to override
the model is shows for any given player, most commonly through something
like: m_pRenderModel = IEngineStudio.SetupPlayerModel( m_nPlayerIndex );.
As a test, you should elimiate these overrides and change all occurances of
the above to: m_pRenderModel = m_pCurrentEntity-model;.

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




RE: [hlcoders] Basic Problem, many a hairs lost!

2002-01-18 Thread Ken Birdwell

What's your MAX_PARTICLES defined as?  Is there is ; at the end?  If so,
then that's the problem.

-Original Message-
From: Philip Plante [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 18, 2002 8:10 PM
To: [EMAIL PROTECTED]
Subject: Re: [hlcoders] Basic Problem, many a hairs lost!


It points to the for statement.  Thanks
- Original Message -
From: Persuter [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, January 18, 2002 5:21 PM
Subject: RE: [hlcoders] Basic Problem, many a hairs lost!


 I dunno if you typed this in, but if you copy/pasted it, it should be

 size = particle[i1].size / 2;

 not paricle[i1].size.

 And what line is the compiler pointing at?

 Persuter

  -Original Message-
  From: [EMAIL PROTECTED] [mailto:hlcoders-
  [EMAIL PROTECTED]] On Behalf Of Philip Plante
  Sent: Friday, January 18, 2002 7:57 PM
  To: [EMAIL PROTECTED]
  Subject: Re: [hlcoders] Basic Problem, many a hairs lost!
 
  Funny thing when I tried that it fixed the error.  So what if i paste
 the
  whole func here:
 
  void ParticleSystem::Render(void)
  {
   float size;
   Vector vert, temporg, pos, viewangles;
 
   gEngfuncs.pTriAPI-RenderMode(kRenderTransAdd);
 
 
   cl_entity_t *player = gEngfuncs.GetLocalPlayer();
   if (!player) return;
 
   vec3_t v_up, v_forward, v_right;
   gEngfuncs.GetViewAngles( (float *)viewangles );
   AngleVectors(viewangles, v_forward, v_right, v_up);
 
   for(int i1 = 0; i1  MAX_PARTICLES; i1++)
   {
   size = paricle[i1].size / 2;
   particle[i1].color[4] = particle[i1].alpha;
   // Draw code here
  }
  }
 
 
  Thanks :)
 
  - Original Message -
  From: botman [EMAIL PROTECTED]
  To: [EMAIL PROTECTED]
  Sent: Friday, January 18, 2002 2:58 PM
  Subject: Re: [hlcoders] Basic Problem, many a hairs lost!
 
 
Ok when I try to compile my particle engine code I am for
 somereason
   getting:
error C2143: syntax error : missing ')' before ';'
on this code:
void ParticleSystem::Render(void)
{
   
 int i;
 while( i  MAX_PARTICLES)
 {
/*code*/
}
}
   
But I dont know why the hell its doing that  Any clues why it is?
  
   I suspect your error is actually caused by a line further up in your
  code.
   The compiler is just recovering from the error at the it is showing
 you.
   I'll bet if you comment out that whole block (all code shown), you
 will
   still get the error in something later on in the file.
  
   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


 _
 Do You Yahoo!?
 Get your free @yahoo.com address at http://mail.yahoo.com

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


___
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] Hull3?

2002-01-17 Thread Ken Birdwell

Yes, sort of.  You'll still have problems with hitbox collisions if the
hitboxes extend outside of the collision box.  This is why the tentacle
sets its collision box to a 800x800x850 area (see SetObjectCollisionBox())
even though it uses a relatively small hull.  If it didn't set its collision
box, the hull collisions routines will short circuit the finer resolution
test and you'd never be able to tell when the players (or Barney's) bounding
box was intersecting with one of the tentacle body segments.  You'll also
have visibility problems with models if they extend outside their collision
box, entities get linked into visibility/collision leafs based on their
collision box size, so if it's too small the engine will optimize out
rendering and intersection tests when it shouldn't.

-Original Message-
From: _Phantom_ [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 17, 2002 9:31 PM
To: [EMAIL PROTECTED]
Subject: Re: [hlcoders] Hull3?


Correct me if I'm wrong, but, this email implys that hull size (should) have
no effect on hit boxes as long as the are defined right and the client and
server are both running the same model?

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




RE: [hlcoders] Hull3?

2002-01-14 Thread Ken Birdwell

You may have bugs with the animations that are being hidden by the gait
sequence.  As a test case, run your players with their gaitsequence always
set to 0 and see where their model is draw.  Where they are drawn is the
location the server is using for traceline collisions.  If these are
radically different from where they appear when the gaitsequence is active,
you'll have problems.

-Original Message-
From: Jeff Fearn [mailto:[EMAIL PROTECTED]]
Sent: Monday, January 14, 2002 8:45 PM
To: [EMAIL PROTECTED]
Subject: Re: [hlcoders] Hull3?


I am still having trouble getting the hit boxes to work on players using
hull 3. The models clip correctly but they are hard to shoot, bullets etc go
right through them, or hit them in an unexpected location. Like shooting
them in the groin results in a head shot!. Below is code we use:


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




RE: [hlcoders] sub models related question...

2002-01-11 Thread Ken Birdwell



You'll 
have problems with the encoding for pev-body. It's a packed encoding 
based on the number of elements in each group. In your example, let's say 
the game dll had selected body #1 and head #2. pev-body would be 
encoded with the value of 7 ((2)*3+1). The client dll would they try to 
apply that to the local model and gethead #1 and body #3 (7/4, 
7%4).

What 
you'll have to do is to have the client dll first decode pev-body based on 
the game dll's model, then reencode them for the model that the client dll is 
using. You can look through the mstudiobodyparts_t data to make the 
mapping.

  -Original Message-From: Christopher Long 
  [mailto:[EMAIL PROTECTED]]Sent: Friday, January 11, 2002 
  12:57 AMTo: [EMAIL PROTECTED]Subject: 
  [hlcoders] sub models related question...
  I am currently adding support for player 
  character submodels and have come to a little question that i can't figure the 
  answer out to and no its not coding related just more of a what would happen 
  if this was done.
  
  Ok question time.
  Say i have created a model for a certain class 
  and it has 2 subgroups
  - body
  - head
  and each of this models subgroups has 3 different 
  values
  Now i also have another model that can replace 
  this model(call it a downloaded model) and it has the same sub groups but 4 
  different values for each.
  
  Now in game if i use a vgui menu to allow 
  manipulation of the model piece what happens if there is a 2 player game and 1 
  person has the first model and the other person has the second model i 
  stated.
  
  Lets say that the player then changes his model 
  to parts
  body - 4
  head - 4
  how does the first player view the model? Will it 
  be acceptable for the player with the more sub group model to see it while the 
  first player won't or will this cause some kind of confussion with what 
  the server has and what the players don't have???
  
  Cause what i am trying to think if i can do and i 
  can do it if it will work is have it so say you download different models for 
  the mod and models you download may have different amounts of subgroups and 
  differing amounts of values for each of these sub groups. Now if it will work 
  but say if another player in the server doesn't have these extended models 
  will the model they see be just the model with the first value of each sub 
  group in the list??
  
  This might be a question for valve if any watch 
  over us hereunless others have thought the same and KNOW the 
  answer.
  
  Also other questions i had in mind. I haven't 
  looked at this yet but in model viewer each group and is named and each value 
  for that group is numbered. Is there someway via coding that i can extract the 
  name from the model ie extract its sub group name so i can list it under the 
  vgui menu
  
  Soz for the bloody long post but at least i got 
  it all out.
  If there is confussion i will try to clarify with 
  a better example
  
  NOTE - i am not after code as i have that part 
  sorted out i know how to approach anddo it. I am just asking if it will 
  work else there is no point adding the code now is there :).
  
  Cheers all and thanks to whoever 
  responds.


RE: [hlcoders] it's quiet...too quiet

2002-01-11 Thread Ken Birdwell

college classes start back up this week?

-Original Message-
From: Reedbeta [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 11, 2002 8:53 PM
To: [EMAIL PROTECTED]
Subject: Re: [hlcoders] sub models related question...


Yeah, it has died down.  I got 12 messages in 3 days this week.  Normally
I'd
get like 50 in that time span.

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




RE: [hlcoders] what a bloody n00b

2001-12-27 Thread Ken Birdwell



Okay, 
just to be really clear, it's a COPYright, not a SELLright. The control is 
at the COPYING stage of the process, not why you're doing it or what you're 
doing with it. A COPYRIGHT actually does refer "the right to copy". 
It doesn't mater if you're giving it away, bundling it, selling it, whatever, 
it's illegal to COPY any material where you don't own the copyright, unless you 
have explicit permission to copy that material. Your half-life 
EULA and SDK EULA grants you certainrights that let you make certain types 
of copies (such as are needed to run the software on a single computer) but 
nothing past that (read your EULA, it goes into more 
detail).

As to 
Tom's questions, yes, it IS illegal for folks to "sell stuff on cd such as game 
demos and patches" regardless of their motives unless they've received 
permission from the copyright holders. It doesn't mater what sort of 
tricky convoluted rationalization they use, they've made a copy of something 
they do not have permission to copy. This is the wholepoint of a 
copyright:controlling who is allowed to copy your 
material.

That 
said, it's usually pretty easy to get permission for stuff like the SDK, 
patches, etc., just send email to Scott Lynch at Valve and ask. Demos are 
a little harder since they're often part of other deals (magazine covers, new 
hardware, etc.) but if you have something interestingyou're trying to do 
with it then you'll probably get permission, though you still have to 
ask.

And yes, we have 
actually have agreements with the fileservers we know about to allow them to 
redistribute our material.

-Original Message-From: 
Tom [mailto:[EMAIL PROTECTED]]Sent: Thursday, December 27, 
2001 10:19 AMTo: [EMAIL PROTECTED]Subject: 
Re: [hlcoders] what a bloody n00b

  its not illegal to sell stuff on cd such as game 
  demos and patches is it? They are paying for your time to get hold of the 
  demo/patch and then put it on cd, not the actual 
demo/patch.


RE: [hlcoders] what a bloody n00b

2001-12-26 Thread Ken Birdwell



Yes, 
selling* copyrighted material w/o permission is illegal.Sierra goes 
through and has ebay remove these items when they find them, but it looks like 
they missed a few. Thanks.


-Original Message-From: 
Christopher Long [mailto:[EMAIL PROTECTED]]Sent: Wednesday, 
December 26, 2001 2:26 AMTo: 
[EMAIL PROTECTED]Subject: [hlcoders] what a bloody 
n00b

  http://cgi.ebay.com/aw-cgi/eBayISAPI.dll?ViewItemitem=1314287113
  
  
  Now is it just me or is selling valve owned programs and update 
  patches not only wrong but illegal? i'd really like to see this dork punished. 
  So feel free to spam him with emails detailing how big a dork he is.. and 
  for doing the biggest injustice of it all trying to extend the already huge 
  cheating problem in online 
games.


RE: [hlcoders] what a bloody n00b

2001-12-26 Thread Ken Birdwell




http://pages.ebay.com/help/community/png-software.html

http://pages.ebay.com/help/community/png-copyrighteditems.html

ebay is very good about 
this sort of thing.



  


RE: [hlcoders] Full body animation

2001-12-07 Thread Ken Birdwell



Just 
set the players pev-gaitsequence to 0 and nothing will play on the lower 
body. Look at case statement for ACT_HOP, ACT_DIESIMPLE, etc. in 
CBasePlayer::SetAnimation() for examples. Those are all full body 
animations.

-Original Message-From: 
Georges Giroux [mailto:[EMAIL PROTECTED]]Sent: Friday, December 
07, 2001 6:43 AMTo: 
[EMAIL PROTECTED]Subject: [hlcoders] Full body 
animation

  Hello,
  
  Does anyone know which flags have to be set for a 
  full body
  animation (like the death animations)? If I don't 
  set
  the pev-deadflag to something other than 
  DEAD_NO, 
  my animation is only played by the player's top 
  half. Basically, my
  animation has the player kneel down, so I can't 
  separate it
  between the pev-sequence and 
  pev-gaitsequence.
  
  If I set pev-deadflag to anything other than 
  DEAD_NO, the animation
  plays out perfectly, the only problem is that the 
  player is not really dead!
  This causes all kinds of animation problems when 
  the player really does get killed (he doesn't end up lying down, just standing 
  with the dead pose).
  
  Any ideas?
  Thanks!
  
  Georges


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

2001-12-05 Thread Ken Birdwell



"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+ filesto 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 PMTo: [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. Theanswer 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


RE: [hlcoders] Impulse Commands

2001-11-22 Thread Ken Birdwell

These only work in software.

r_fullbright 1  - show textures only
r_fullbright 2  - show lightmaps only
r_fullbright 3  - show lightmaps with luxel grids
r_fullbright 4  - show mip level


-Original Message-

2)  Is there a command to illuminate a dark map (besides the flashlight)?
  (for testing purposes)
___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders