Re: [hlcoders] Steam messes up Half-Life

[leming]

Which might even be a better way to go, rtcw released source for mods
recently (april 12), and the engine is much more powerful and flexible.
Sorry if this offends those who are die-hard HL fans.

At 23:24 4/24/2000 -0700, you wrote:
>Well, of course you do! You have the choice to stop developing anything
>based on the Half-Life SDK if you don't accept what Valve has planned for
>it. Their business isn't a democracy.
>
>- Original Message -
>From: "klank" <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>
>Sent: Wednesday, April 24, 2002 11:15 PM
>Subject: Re: [hlcoders] Steam messes up Half-Life
>
>
> > Have no choice?  LOL   We as a people ALWAYS have a choice.
> >
> > -klank
> >
> >
> > >Only thing I can say is
> > > adapt... you have no choice.
> >
> >
> >
> >
> > ___
> > 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] Steam messes up Half-Life

[Gollum]

Well, of course you do! You have the choice to stop developing anything
based on the Half-Life SDK if you don't accept what Valve has planned for
it. Their business isn't a democracy.

- Original Message -
From: "klank" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, April 24, 2002 11:15 PM
Subject: Re: [hlcoders] Steam messes up Half-Life


> Have no choice?  LOL   We as a people ALWAYS have a choice.
>
> -klank
>
>
> >Only thing I can say is
> > adapt... you have no choice.
>
>
>
>
> ___
> 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] Fun and games and amateur analysis of 1.1.0.9 update hardware survey results...

[Chris Glein]

Eek!

A 700 MHz machine is what we're terming an "older box" now?  Makes my dev
machine look ancient :(

-PNB

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Tim Holt
Sent: Wednesday, April 24, 2002 11:12 PM
To: [EMAIL PROTECTED]
Subject: Re: [hlcoders] Fun and games and amateur analysis of 1.1.0.9
update hardware survey results...


> Thats good having an older box actually.  Sometimes I think one can fall
> into the trap of developing (testing) on a "nice" box - and not really
> know how it behaves on older boxes.

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

RE: [hlcoders] Fun and games and amateur analysis of 1.1.0.9 update hardware survey results...

[Chris Glein]

One thing to take into consideration while looking at this survey is that
lower end players are less likely to have filled it out.  Why?  If you're on
dial-up, you're less likely to fill out an online survey than someone on
broadband.

It's the same reason that I'm sure registration results show a larger
proportion of broadband users.  If you're on broadband, you'll fill out a
quick online registration no problem.  If you're on dial-up, you're more
likely to click "register later" for when you're online, and then never do
it.

Or at least that's how I did things when I was on dial-up.  You're online
time is managed differently; more tightly.


Given my experience, the overall numbers seem a bit high.  Maybe S&I just
caters to lower end players.  The second we do something that inadvertedly
inconveniences people running 320x200, we hear about it.  It's not the
majority of players - not by far.  But there are *plenty* of players running
with slower computers, slower connections, or whatever.  If you cease to
support them, thats less people to play your mod.  When you're a smaller
mod, every player counts.

I'm not saying cling to HL's out of the box system requirements as the world
wizzes by.  I'm just saying that you should respect the lower end player.

-PNB


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of David Sassen
Sent: Wednesday, April 24, 2002 10:47 PM
To: [EMAIL PROTECTED]
Subject: RE: [hlcoders] Fun and games and amateur analysis of 1.1.0.9
update hardware survey results...



By any comparison, my computer's at the low end of the
spectrum. I run a 700 MHz P3 with Geforce 256 with a
near-full hard drive. However, I absolutely never have
problems with slowdowns in my games. I play Tribes 2
at 1024x768 with settings all the way up and get
smooth 30-40 fps.

The only reason I can do this is I have 640 MB of RAM
(PC100 RAM, even). Lots of memory, even relatively
slow memory, easily compensates for a somewhat
deficient processor. Most of the games written today
are expected to fill up the memory space and spill
over into virtual memory. As such, they have a lot of
overhead left over when you drop the hard drive access
times.

In short, it's time to go up, not down. The 3% of
people on there who used less than 640x480 were most
likely mistaken or joking, and if they weren't, it's
hardly reasonable to design games specifically aimed
at those 3% to the detriment of everyone else. The
cheapness of memory is quickly driving Half-Life's
total system usage bill down.

Backwards compatibility is admirable, but I have near
the slowest processor and definitely the slowest named
video card on that survey, and my computer runs fine.
The fact that the majority of people have over 128 MB
of memory is what should be telling.

Persuter gettin his two bits in... :)

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

Re: [hlcoders] Steam messes up Half-Life

[klank]

Have no choice?  LOL   We as a people ALWAYS have a choice.

-klank


>Only thing I can say is
> adapt... you have no choice.




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

Re: [hlcoders] Fun and games and amateur analysis of 1.1.0.9 updatehardware survey results...

[Tim Holt]

--
[ Picked text/plain from multipart/alternative ]
Thats good having an older box actually.  Sometimes I think one can fall
into the trap of developing (testing) on a "nice" box - and not really
know how it behaves on older boxes.

David Sassen wrote:

>By any comparison, my computer's at the low end of the
>spectrum. I run a 700 MHz P3 with Geforce 256 with a
>near-full hard drive. However, I absolutely never have
>problems with slowdowns in my games. I play Tribes 2
>at 1024x768 with settings all the way up and get
>smooth 30-40 fps.
>
>The only reason I can do this is I have 640 MB of RAM
>(PC100 RAM, even). Lots of memory, even relatively
>slow memory, easily compensates for a somewhat
>deficient processor. Most of the games written today
>are expected to fill up the memory space and spill
>over into virtual memory. As such, they have a lot of
>overhead left over when you drop the hard drive access
>times.
>
>In short, it's time to go up, not down. The 3% of
>people on there who used less than 640x480 were most
>likely mistaken or joking, and if they weren't, it's
>hardly reasonable to design games specifically aimed
>at those 3% to the detriment of everyone else. The
>cheapness of memory is quickly driving Half-Life's
>total system usage bill down.
>
>Backwards compatibility is admirable, but I have near
>the slowest processor and definitely the slowest named
>video card on that survey, and my computer runs fine.
>The fact that the majority of people have over 128 MB
>of memory is what should be telling.
>
>Persuter gettin his two bits in... :)
>
>
>--- Kuja <[EMAIL PROTECTED]> wrote:
>
>>I was the first one to submit that survey :D
>>
>>-Original Message-
>>From: [EMAIL PROTECTED]
>>[mailto:[EMAIL PROTECTED]]On
>>Behalf Of Tim Holt
>>Sent: Wednesday, April 24, 2002 4:07 PM
>>To: [EMAIL PROTECTED]
>>Subject: [hlcoders] Fun and games and amateur
>>analysis of 1.1.0.9 update
>>hardware survey results...
>>
>>
>>--
>>[ Picked text/plain from multipart/alternative ]
>>Dunno of you all like to read the hardware survey
>>results from the
>>1.1.0.9 update, but I do.  See
>>http://valve.speakeasy.net/
>>
>>Stuff I see that catches my eyes...
>>
>>* People with fast connections get the patch
>>first (hence the huge
>>  skew towards high speed with only 14,000
>>responces  :^)
>>* A lot of ppl are still using what you'd call
>>"crappy" video cards.
>>   Voodoo 3 + TNT2 accounts for 10.4%. of all
>>responses
>>* Most ppl have around 256 MB of RAM.  You'd
>>think it would be more
>>  like 512 because it's cheap.
>>* Double peaked bell curve for processors.  Lots
>>in the 800-900 mhz
>>  camp, and another bunch in the over 1 ghz
>>range
>>* Most ppl run video at 1024x768, but there's a
>>pretty surpising #
>>  at 800x600.  And who are these morons running
>>320x200? :D
>>
>>So what's that make me think?  We (as game
>>developers) need to be
>>careful we don't unconciously make our games
>>unplayable by what we
>>consider the "fringe" of low end users - who are
>>actually a pretty big
>>percentage.  Of course one can clearly decide
>>"Minimum specs are Geforce
>>2, 512 MB of RAM, 1 gig processor" and go from
>>there.
>>
>>The other thing that comes to mind is this:  don't
>>waste time
>>complaining about all those old vid card users, or
>>ppl who don't upgrade
>>their RAM, because that isn't going to make them
>>upgrade (unless you're
>>willing to pay).  It's not about how you think it
>>should be, it's about
>>what it really is.
>>
>>I know with DoD we kinda have been pushing the
>>"minimum configuration"
>>limits, but not necessarily by planning.  DoD's next
>>release (2.1) is
>>going to include a big revamp of all our maps with
>>this in mind.  We
>>asked all the mappers to reduce their texture usage
>>down to 5 meg or
>>less.  Testing shows us they run MUCH faster now on
>>the "lower end"
>>video systems.  Made some mappers (ok, just one)
>>really really mad, but
>>I think it was worth it for the players.
>>
>>So anyone else have any
>>observations/conclusions/etc. from the stats?
>>
>>--
>>I think...I think it's in my basement. Let me go
>>upstairs and check. -M.C.
>>Escher
>>
>>
>>--
>>
>>___
>>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
>
>
>
>=
>[EMAIL PROTECTED]
>
>"Humanity I love you for when you're hard up you pawn your intelligence for a drink" 
>-e.e. cummings
>
>__
>Do You Yahoo!?
>Yahoo! Games - play chess, backgammon, pool and more
>http://games.yahoo.com/
>___
>To unsubscribe, edit your list preferences, or vie

Re: [hlcoders] Steam messes up Half-Life

[Gollum]

 They already mentioned a while back that the logging is going to be
altered. It doesn't mess up Half-Life as your title suggests. Can't speak
for the new ID's circumventing previous Won ID bans. Only thing I can say is
adapt... you have no choice.

- Original Message -
From: "[DRP]Avatar-X" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, April 24, 2002 10:41 PM
Subject: [hlcoders] Steam messes up Half-Life


> I was looking at the list of players in my server and suddenly noticed
> that a bunch of
> them had really wierd UniqueID's.
>
> Here:
>
> 46 : 495254 : Mann auf Feuer
> 53 : 558185 : [BD]MaKaVeLi
> 43 : 46537 : Venom, Homeless Kitty
> 44 : 399677 : Ryan
> 38 : 42354 : Phut
> 52 : STEAM_0:3424 : ceown, Monk
>
> Now, my software parses this user list. It does this by looking for
> comma's. Note how
> each value is seperated by a comma. Now, also note how the uniqueID on
> the last line
> also has a comma in it. See a problem?
>
> Changing my code is relatively easy, but this problem should not even
> have happened in
> the first place.
>
> Another thing i notice is that the number... 3424.. is NOT "ceown" 's
> original uniqueID
> number. This means that banlists are now useless, anyone that was
> previously banned can
> now join again at ease.
>
> Any comments, valve?
> ___
> 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] Fun and games and amateur analysis of 1.1.0.9 update hardware survey results...

[David Sassen]

By any comparison, my computer's at the low end of the
spectrum. I run a 700 MHz P3 with Geforce 256 with a
near-full hard drive. However, I absolutely never have
problems with slowdowns in my games. I play Tribes 2
at 1024x768 with settings all the way up and get
smooth 30-40 fps.

The only reason I can do this is I have 640 MB of RAM
(PC100 RAM, even). Lots of memory, even relatively
slow memory, easily compensates for a somewhat
deficient processor. Most of the games written today
are expected to fill up the memory space and spill
over into virtual memory. As such, they have a lot of
overhead left over when you drop the hard drive access
times.

In short, it's time to go up, not down. The 3% of
people on there who used less than 640x480 were most
likely mistaken or joking, and if they weren't, it's
hardly reasonable to design games specifically aimed
at those 3% to the detriment of everyone else. The
cheapness of memory is quickly driving Half-Life's
total system usage bill down.

Backwards compatibility is admirable, but I have near
the slowest processor and definitely the slowest named
video card on that survey, and my computer runs fine.
The fact that the majority of people have over 128 MB
of memory is what should be telling.

Persuter gettin his two bits in... :)


--- Kuja <[EMAIL PROTECTED]> wrote:
> I was the first one to submit that survey :D
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On
> Behalf Of Tim Holt
> Sent: Wednesday, April 24, 2002 4:07 PM
> To: [EMAIL PROTECTED]
> Subject: [hlcoders] Fun and games and amateur
> analysis of 1.1.0.9 update
> hardware survey results...
>
>
> --
> [ Picked text/plain from multipart/alternative ]
> Dunno of you all like to read the hardware survey
> results from the
> 1.1.0.9 update, but I do.  See
> http://valve.speakeasy.net/
>
> Stuff I see that catches my eyes...
>
> * People with fast connections get the patch
> first (hence the huge
>   skew towards high speed with only 14,000
> responces  :^)
> * A lot of ppl are still using what you'd call
> "crappy" video cards.
>Voodoo 3 + TNT2 accounts for 10.4%. of all
> responses
> * Most ppl have around 256 MB of RAM.  You'd
> think it would be more
>   like 512 because it's cheap.
> * Double peaked bell curve for processors.  Lots
> in the 800-900 mhz
>   camp, and another bunch in the over 1 ghz
> range
> * Most ppl run video at 1024x768, but there's a
> pretty surpising #
>   at 800x600.  And who are these morons running
> 320x200? :D
>
> So what's that make me think?  We (as game
> developers) need to be
> careful we don't unconciously make our games
> unplayable by what we
> consider the "fringe" of low end users - who are
> actually a pretty big
> percentage.  Of course one can clearly decide
> "Minimum specs are Geforce
> 2, 512 MB of RAM, 1 gig processor" and go from
> there.
>
> The other thing that comes to mind is this:  don't
> waste time
> complaining about all those old vid card users, or
> ppl who don't upgrade
> their RAM, because that isn't going to make them
> upgrade (unless you're
> willing to pay).  It's not about how you think it
> should be, it's about
> what it really is.
>
> I know with DoD we kinda have been pushing the
> "minimum configuration"
> limits, but not necessarily by planning.  DoD's next
> release (2.1) is
> going to include a big revamp of all our maps with
> this in mind.  We
> asked all the mappers to reduce their texture usage
> down to 5 meg or
> less.  Testing shows us they run MUCH faster now on
> the "lower end"
> video systems.  Made some mappers (ok, just one)
> really really mad, but
> I think it was worth it for the players.
>
> So anyone else have any
> observations/conclusions/etc. from the stats?
>
> --
> I think...I think it's in my basement. Let me go
> upstairs and check. -M.C.
> Escher
>
>
> --
>
> ___
> 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
>


=
[EMAIL PROTECTED]

"Humanity I love you for when you're hard up you pawn your intelligence for a drink" 
-e.e. cummings

__
Do You Yahoo!?
Yahoo! Games - play chess, backgammon, pool and more
http://games.yahoo.com/
___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

[hlcoders] Steam messes up Half-Life

[[DRP]Avatar-X]

I was looking at the list of players in my server and suddenly noticed
that a bunch of
them had really wierd UniqueID's.

Here:

46 : 495254 : Mann auf Feuer
53 : 558185 : [BD]MaKaVeLi
43 : 46537 : Venom, Homeless Kitty
44 : 399677 : Ryan
38 : 42354 : Phut
52 : STEAM_0:3424 : ceown, Monk

Now, my software parses this user list. It does this by looking for
comma's. Note how
each value is seperated by a comma. Now, also note how the uniqueID on
the last line
also has a comma in it. See a problem?

Changing my code is relatively easy, but this problem should not even
have happened in
the first place.

Another thing i notice is that the number... 3424.. is NOT "ceown" 's
original uniqueID
number. This means that banlists are now useless, anyone that was
previously banned can
now join again at ease.

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

RE: Re[2]: [hlcoders] Sprite problems

[David Sassen]

errr... which ones should they be loading? It's not
loading anything in Additional DLLs right now.

Persuter

--- Ken Birdwell <[EMAIL PROTECTED]> wrote:
> This should work correct, so check which DLL's your
> DevStudio is loading
> (Project>Settings>Debug>Additional DLLs).  It's
> probably not loading the
> ones you want.
>
> -Original Message-
> From: Cruise [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, April 24, 2002 10:25 AM
> To: Persuter
> Subject: Re[2]: [hlcoders] Sprite problems
>
>
> I've not had the same problem with GetClassPtr...but
> I have noticed
> the same problem when stepping through code...
>
> The mod runs fine, but if I try to step through
> code, everything is
> haywire...the stack trace is nonsense (function
> above has no reference
> to the function I'm in), this pointers changing
> their value as I step
> through a member function, memeber variables treated
> as out of scope.
>
> Basically, really insane stuff...but the code is
> actually executing
> fine...I can see the effects on screen. Basically it
> means I can't
> step through the code at all...
>
> All the latest service packs, etc. Very odd...
> ___
> To unsubscribe, edit your list preferences, or view
> the list archives, please visit:
>
http://list.valvesoftware.com/mailman/listinfo/hlcoders
>


=
[EMAIL PROTECTED]

"Humanity I love you for when you're hard up you pawn your intelligence for a drink" 
-e.e. cummings

__
Do You Yahoo!?
Yahoo! Games - play chess, backgammon, pool and more
http://games.yahoo.com/
___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: Re[2]: [hlcoders] Sprite problems

[David Sassen]

KeyValue wasn't being called for the streetlamps upon
which I was placing the glow sprite, not the sprites
themselves (which, you are correct, should not have
KeyValue called at all).

Persuter

--- Jeff Fearn <[EMAIL PROTECTED]> wrote:
> > However, KeyValue still isn't being called and the
> > GetClassPtr function is still being skipped over.
> So
> > it was a map problem masquerading as a code
> problem.
> > Oh that tricky MSVC!!! :)
> >
> > I suppose I'll just let it go on doing that,
> although
> > I suspect when the keyvalue data actually becomes
> > important I'll have to look into it. Ah well.
> Thanks
> > all.
>
> I am assuming that you mean that keyvalue is not
> being called for entities you
> create with GetClassPtr ... else this is meaningless
> and I should not be wating my
> own damn time! ;)
>
> I believe that keyvalue is only called for map based
> entities, i.e. those placed
> in a map by a mapper. Needless to say that if you
> are using GetClassPtr to create
> an entity, then it is not map based and therefore
> keyvalue will not be called.
>
> Jeff.
>
> ___
> To unsubscribe, edit your list preferences, or view
> the list archives, please visit:
>
http://list.valvesoftware.com/mailman/listinfo/hlcoders
>


=
[EMAIL PROTECTED]

"Humanity I love you for when you're hard up you pawn your intelligence for a drink" 
-e.e. cummings

__
Do You Yahoo!?
Yahoo! Games - play chess, backgammon, pool and more
http://games.yahoo.com/
___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] SET_SIZE()

[Cortex]

I think so. Use UTIL_SetOrigin before calling SET_MODEL.

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

- Original Message -
From: "Daniel Johansson" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, April 25, 2002 12:44 AM
Subject: Re: [hlcoders] SET_SIZE()


Ok, thanks.

How about UTIL_SetOrigin, should I use that?

/Daniel

- Original Message -
From: "Oskar 'Zoot' Lindgren" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, April 24, 2002 10:31 PM
Subject: Re: [hlcoders] SET_SIZE()


pev->mini?
- Original Message -
From: "Cortex" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, April 24, 2002 10:08 PM
Subject: Re: [hlcoders] SET_SIZE()


Why don't you use the "SET_MODEL ( pev, your_model );" ? This links the
model into world and set automatically its size..

I think this should help you :)

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

- Original Message -
From: "Paul 'MoOg' Samways" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, April 24, 2002 5:42 PM
Subject: Re: [hlcoders] SET_SIZE()


*cough* english mailing list *cough*

- Original Message -
From: "Oskar 'Zoot' Lindgren" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, April 24, 2002 3:16 PM
Subject: Re: [hlcoders] SET_SIZE()


ser man på... en svensk till
- Original Message -
From: "Daniel Johansson" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, April 24, 2002 4:10 PM
Subject: [hlcoders] SET_SIZE()


> This is a multi-part message in MIME format.
> --
> [ Picked text/plain from multipart/alternative ]
> Hey all!
>
> Im playing around with models ingame, like spawning player models and then
make them play an animation.
> But now I have come to this little problem. I have an entity so the mapper
can choose what model to spawn
> and now when I spawn the model I dont know the size of it so I tried a
playermodel and set the size according
> to what was set in player.cpp spawn function. But now I was kinda
wondering if there is any way of getting the
> size of a model ie GET_SIZE (does not exist btw). Anyone care to enlighten
me on this if they can?
>
> Thanks
> Daniel Johansson
> [EMAIL PROTECTED]
>
> --
>
> ___
> 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: Re[2]: [hlcoders] Sprite problems

[Jeff Fearn]

> However, KeyValue still isn't being called and the
> GetClassPtr function is still being skipped over. So
> it was a map problem masquerading as a code problem.
> Oh that tricky MSVC!!! :)
>
> I suppose I'll just let it go on doing that, although
> I suspect when the keyvalue data actually becomes
> important I'll have to look into it. Ah well. Thanks
> all.

I am assuming that you mean that keyvalue is not being called for entities you
create with GetClassPtr ... else this is meaningless and I should not be wating my
own damn time! ;)

I believe that keyvalue is only called for map based entities, i.e. those placed
in a map by a mapper. Needless to say that if you are using GetClassPtr to create
an entity, then it is not map based and therefore keyvalue will not be called.

Jeff.

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

RE: Re[2]: [hlcoders] Sprite problems

[David Sassen]

To update: I sent out the latest fgd and they sent
back a map that works. The maps they send Persuter on
a whim no workyworky, although they tell me to fix the
problems. :)

However, KeyValue still isn't being called and the
GetClassPtr function is still being skipped over. So
it was a map problem masquerading as a code problem.
Oh that tricky MSVC!!! :)

I suppose I'll just let it go on doing that, although
I suspect when the keyvalue data actually becomes
important I'll have to look into it. Ah well. Thanks
all.

Persuter

--- Persuter <[EMAIL PROTECTED]> wrote:
> Lol, oh great. So now not only do I have a major
> problem, MSVC has
> decided not to tell me what it is. :) Well, I knew
> that it was somehow
> screwed up (since this pointers really oughtn't to
> change) but I was
> hoping it was the code. Sgh...
>
> OK, well then has anyone else had a problem with
> sprites refusing to
> attach themselves to multiple entities? I've got a
> streetlamp entity
> that I want to have a glow sprite on (I'm lighting
> the area around it
> with dlighting, but I want a glow sprite on the lamp
> itself). I call
> MakeSprite in the spawn function and use
> SetAttachment and
> SetTransparency to attach it to the lamp.
>
> At first, they would all attach to one particular
> lamp. Now they don't
> seem to do that, they just don't attach to any lamp.
> (Or possibly they
> are still attached to that lamp but aren't
> displayed, or don't do the
> same washing out as it did before when they all
> displayed.) I'm not sure
> why they attach to the lamp that they do.
>
> Persuter
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> [mailto:hlcoders-
> > [EMAIL PROTECTED]] On Behalf Of Cruise
> > Sent: Wednesday, April 24, 2002 12:25 PM
> > To: Persuter
> > Subject: Re[2]: [hlcoders] Sprite problems
> >
> > I've not had the same problem with
> GetClassPtr...but I have noticed
> > the same problem when stepping through code...
> >
> > The mod runs fine, but if I try to step through
> code, everything is
> > haywire...the stack trace is nonsense (function
> above has no reference
> > to the function I'm in), this pointers changing
> their value as I step
> > through a member function, memeber variables
> treated as out of scope.
> >
> > Basically, really insane stuff...but the code is
> actually executing
> > fine...I can see the effects on screen. Basically
> it means I can't
> > step through the code at all...
> >
> > All the latest service packs, etc. Very odd...
> >
> >
> > [ Cruise / www.casual-tempest.net ]
> >
> > 
> >
> > > Further troubles... I tried making this a
> non-static function, but
> that
> > > didn't work either. But here's the REALLY weird
> part. I was stepping
> > > through the new function in the debugger:
> >
> > > CSprite* CStreetlamp::MakeSprite( const char*
> pSpriteName, const
> Vector
> > > &origin, BOOL animate  )
> > > {
> > > CSprite* pSprite = GetClassPtr( (CSprite
> *)NULL );
> > > pSprite->SpriteInit( pSpriteName, origin
> );
> > > pSprite->pev->classname =
> MAKE_STRING("env_sprite");
> > > pSprite->pev->solid = SOLID_NOT;
> > > pSprite->pev->movetype =
> MOVETYPE_NOCLIP;
> > > if ( animate )
> > > pSprite->TurnOn();
> >
> > > return pSprite;
> > > }
> >
> > > It has the exact same error as before. However,
> I noticed that as I
> step
> > > through the function that the value of this,
> i.e., the street lamp,
> > > changes three times. First it goes to some
> seemingly random memory
> > > location, then it changes to 1, then it goes
> back to its regular
> > > location. Is that CRAZY or what?
> >
> > > Upon further inspection, I found that in
> addition to this calamity,
> the
> > > Keyvalue function for the entity is not being
> called at all. This,
> too,
> > > seems a bit odd. My suspicion was that somehow
> the game is stumbling
> > > over some of the fgd files and somehow, some
> way, that's messing up
> the
> > > files.
> >
> > > However, I then dropped into the disassembler to
> check what the
> assembly
> > > had to say about it, and learned to my shock
> that CSprite* pSprite =
> > > GetClassPtr( (CSprite *)NULL ); has absolutely
> no assembly
> counterpart.
> > > In other words, the compiler is somehow skipping
> right the f**k over
> it.
> >
> > > I have absolutely no clue. I'm going to try
> recompiling all the maps
> and
> > > the models involved in the hopes that somehow
> this will fix itself.
> Is
> > > there anyone who's had a similar problem with
> GetClassPtr? The rest
> of
> > > them seem to be compiling so I can't imagine
> it's a problem with the
> > > template implementation, but the problems like
> KeyValue suggest to
> me
> > > that it's a run-time problem of some sort,
> because the fact that
> > > GetClassPtr didn't compile shouldn't do anything
> to KeyValue...
> >
> > > Persuter
> >
> > >> -Original Message-
> > >> From: [EMAIL PROTECTED]
> [mailto:hlcoders-
> > >> [EM

[hlcoders] Tracker anyone???

[MaJ-ReD]

This is a multi-part message in MIME format.
--
--
[ Picked text/plain from multipart/alternative ]
I was just wondering if anyone know if or when the tracker will be
released out of Steam. I expected it to be with CS1.4 and HL1109, but so
far it's a no show anywhere. I know this isn't a coding question, but we
seem to get a lot of replies from folks at VALVe so I figured I would
get the best answer here :-)

__
MaJ-ReD
Mr
ICQ#: 57889069

Current ICQ status:

*    More ways to contact me
i    See more about
me:
__

--
[ image001.gif of type image/gif deleted ]
___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] SET_SIZE()

[Daniel Johansson]

Ok, thanks.

How about UTIL_SetOrigin, should I use that?

/Daniel

- Original Message -
From: "Oskar 'Zoot' Lindgren" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, April 24, 2002 10:31 PM
Subject: Re: [hlcoders] SET_SIZE()


pev->mini?
- Original Message -
From: "Cortex" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, April 24, 2002 10:08 PM
Subject: Re: [hlcoders] SET_SIZE()


Why don't you use the "SET_MODEL ( pev, your_model );" ? This links the
model into world and set automatically its size..

I think this should help you :)

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

- Original Message -
From: "Paul 'MoOg' Samways" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, April 24, 2002 5:42 PM
Subject: Re: [hlcoders] SET_SIZE()


*cough* english mailing list *cough*

- Original Message -
From: "Oskar 'Zoot' Lindgren" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, April 24, 2002 3:16 PM
Subject: Re: [hlcoders] SET_SIZE()


ser man på... en svensk till
- Original Message -
From: "Daniel Johansson" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, April 24, 2002 4:10 PM
Subject: [hlcoders] SET_SIZE()


> This is a multi-part message in MIME format.
> --
> [ Picked text/plain from multipart/alternative ]
> Hey all!
>
> Im playing around with models ingame, like spawning player models and then
make them play an animation.
> But now I have come to this little problem. I have an entity so the mapper
can choose what model to spawn
> and now when I spawn the model I dont know the size of it so I tried a
playermodel and set the size according
> to what was set in player.cpp spawn function. But now I was kinda
wondering if there is any way of getting the
> size of a model ie GET_SIZE (does not exist btw). Anyone care to enlighten
me on this if they can?
>
> Thanks
> Daniel Johansson
> [EMAIL PROTECTED]
>
> --
>
> ___
> 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: Re[2]: [hlcoders] Sprite problems

[Persuter]

Lol, oh great. So now not only do I have a major problem, MSVC has
decided not to tell me what it is. :) Well, I knew that it was somehow
screwed up (since this pointers really oughtn't to change) but I was
hoping it was the code. Sgh...

OK, well then has anyone else had a problem with sprites refusing to
attach themselves to multiple entities? I've got a streetlamp entity
that I want to have a glow sprite on (I'm lighting the area around it
with dlighting, but I want a glow sprite on the lamp itself). I call
MakeSprite in the spawn function and use SetAttachment and
SetTransparency to attach it to the lamp.

At first, they would all attach to one particular lamp. Now they don't
seem to do that, they just don't attach to any lamp. (Or possibly they
are still attached to that lamp but aren't displayed, or don't do the
same washing out as it did before when they all displayed.) I'm not sure
why they attach to the lamp that they do.

Persuter

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:hlcoders-
> [EMAIL PROTECTED]] On Behalf Of Cruise
> Sent: Wednesday, April 24, 2002 12:25 PM
> To: Persuter
> Subject: Re[2]: [hlcoders] Sprite problems
>
> I've not had the same problem with GetClassPtr...but I have noticed
> the same problem when stepping through code...
>
> The mod runs fine, but if I try to step through code, everything is
> haywire...the stack trace is nonsense (function above has no reference
> to the function I'm in), this pointers changing their value as I step
> through a member function, memeber variables treated as out of scope.
>
> Basically, really insane stuff...but the code is actually executing
> fine...I can see the effects on screen. Basically it means I can't
> step through the code at all...
>
> All the latest service packs, etc. Very odd...
>
>
> [ Cruise / www.casual-tempest.net ]
>
> 
>
> > Further troubles... I tried making this a non-static function, but
that
> > didn't work either. But here's the REALLY weird part. I was stepping
> > through the new function in the debugger:
>
> > CSprite* CStreetlamp::MakeSprite( const char* pSpriteName, const
Vector
> > &origin, BOOL animate  )
> > {
> > CSprite* pSprite = GetClassPtr( (CSprite *)NULL );
> > pSprite->SpriteInit( pSpriteName, origin );
> > pSprite->pev->classname = MAKE_STRING("env_sprite");
> > pSprite->pev->solid = SOLID_NOT;
> > pSprite->pev->movetype = MOVETYPE_NOCLIP;
> > if ( animate )
> > pSprite->TurnOn();
>
> > return pSprite;
> > }
>
> > It has the exact same error as before. However, I noticed that as I
step
> > through the function that the value of this, i.e., the street lamp,
> > changes three times. First it goes to some seemingly random memory
> > location, then it changes to 1, then it goes back to its regular
> > location. Is that CRAZY or what?
>
> > Upon further inspection, I found that in addition to this calamity,
the
> > Keyvalue function for the entity is not being called at all. This,
too,
> > seems a bit odd. My suspicion was that somehow the game is stumbling
> > over some of the fgd files and somehow, some way, that's messing up
the
> > files.
>
> > However, I then dropped into the disassembler to check what the
assembly
> > had to say about it, and learned to my shock that CSprite* pSprite =
> > GetClassPtr( (CSprite *)NULL ); has absolutely no assembly
counterpart.
> > In other words, the compiler is somehow skipping right the f**k over
it.
>
> > I have absolutely no clue. I'm going to try recompiling all the maps
and
> > the models involved in the hopes that somehow this will fix itself.
Is
> > there anyone who's had a similar problem with GetClassPtr? The rest
of
> > them seem to be compiling so I can't imagine it's a problem with the
> > template implementation, but the problems like KeyValue suggest to
me
> > that it's a run-time problem of some sort, because the fact that
> > GetClassPtr didn't compile shouldn't do anything to KeyValue...
>
> > Persuter
>
> >> -Original Message-
> >> From: [EMAIL PROTECTED] [mailto:hlcoders-
> >> [EMAIL PROTECTED]] On Behalf Of Persuter
> >> Sent: Monday, April 22, 2002 6:42 PM
> >> To: [EMAIL PROTECTED]
> >> Subject: [hlcoders] Sprite problems
> >>
> >> Hey all, having a bit of a problem here:
> >>
> >> CSprite *CSprite::SpriteCreate( const char *pSpriteName, const
Vector
> >> &origin, BOOL animate )
> >> {
> >>   CSprite* pSprite = GetClassPtr( (CSprite *)NULL ); <-- This
line
> >>   pSprite->SpriteInit( pSpriteName, origin );
> >>   pSprite->pev->classname = MAKE_STRING("env_sprite");
> >>   pSprite->pev->solid = SOLID_NOT;
> >>   pSprite->pev->movetype = MOVETYPE_NOCLIP;
> >>   if ( animate )
> >>   pSprite->TurnOn();
> >>
> >>   return pSprite;
> >> }
> >>
> >> For some reason, when I execute the following code with
> >> "sprites/glow01.spr", multiple times, the indicated line doesn't
> > execute
> >> at all excep

[hlcoders] 1109 HLTV bugs

[Mugsy _]

Just testing out Dod 2.1 on 1109 and I noticed a few changes

- for the first little while, it doesnt go into any spectator mode, so
you're just free flying. After a while it usually kicks into auto free chase
mode and you can start toggling

- the overview map does not render. I have .bmp and .tga overview files, and
they worked in 1108. The sprites on top are rendered, but the base image is
not

- the inset window in the corner does not render for either the minimap or
the chase / first person view

- I had an engine crash while watching HLTV

And I was so ready to release this version *cries*






_
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

RE: [hlcoders] Fun and games and amateur analysis of 1.1.0.9 update hardware survey results...

[Erik Johnson]

Yes, OpenGL and D3D were switched. The info up there now is all correct.

The survey refreshes about every 3 hours.

The other piece of info that isn't up there just yet is what TelCo folks are
using. Speakeasy is going to reverse DNS a bunch of the Class C IP ranges
that were collected and match them to what ISPs people are using.

-Original Message-
From: Tim Holt [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, April 24, 2002 2:42 PM
To: [EMAIL PROTECTED]
Subject: Re: [hlcoders] Fun and games and amateur analysis of 1.1.0.9
update hardware survey results...


Hehe - i want to know who the one person is with 14.4 dialup and who the
ppl running at 320x200 are (unless it's a bug)

Speaking of bugs, I noticed that early on, the majority of vid configs
were D3D with OpenGL way down there.  But suddenly it switched.  /me
thinks someone had a little booboo and fixed it in the survey :^P

Kuja wrote:

>I was the first one to submit that survey :D
>
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED]]On Behalf Of Tim Holt
>Sent: Wednesday, April 24, 2002 4:07 PM
>To: [EMAIL PROTECTED]
>Subject: [hlcoders] Fun and games and amateur analysis of 1.1.0.9 update
>hardware survey results...
>
>
>--
>[ Picked text/plain from multipart/alternative ]
>Dunno of you all like to read the hardware survey results from the
>1.1.0.9 update, but I do.  See http://valve.speakeasy.net/
>
>Stuff I see that catches my eyes...
>
>* People with fast connections get the patch first (hence the huge
>  skew towards high speed with only 14,000 responces  :^)
>* A lot of ppl are still using what you'd call "crappy" video cards.
>   Voodoo 3 + TNT2 accounts for 10.4%. of all responses
>* Most ppl have around 256 MB of RAM.  You'd think it would be more
>  like 512 because it's cheap.
>* Double peaked bell curve for processors.  Lots in the 800-900 mhz
>  camp, and another bunch in the over 1 ghz range
>* Most ppl run video at 1024x768, but there's a pretty surpising #
>  at 800x600.  And who are these morons running 320x200? :D
>
>So what's that make me think?  We (as game developers) need to be
>careful we don't unconciously make our games unplayable by what we
>consider the "fringe" of low end users - who are actually a pretty big
>percentage.  Of course one can clearly decide "Minimum specs are Geforce
>2, 512 MB of RAM, 1 gig processor" and go from there.
>
>The other thing that comes to mind is this:  don't waste time
>complaining about all those old vid card users, or ppl who don't upgrade
>their RAM, because that isn't going to make them upgrade (unless you're
>willing to pay).  It's not about how you think it should be, it's about
>what it really is.
>
>I know with DoD we kinda have been pushing the "minimum configuration"
>limits, but not necessarily by planning.  DoD's next release (2.1) is
>going to include a big revamp of all our maps with this in mind.  We
>asked all the mappers to reduce their texture usage down to 5 meg or
>less.  Testing shows us they run MUCH faster now on the "lower end"
>video systems.  Made some mappers (ok, just one) really really mad, but
>I think it was worth it for the players.
>
>So anyone else have any observations/conclusions/etc. from the stats?
>
>--
>I think...I think it's in my basement. Let me go upstairs and check. -M.C.
>Escher
>
>
>--
>
>___
>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
>

--
I think...I think it's in my basement. Let me go upstairs and check. -M.C.
Escher



___
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] Fog, sprites, and 1.1.0.9

[Persuter]

I had a question about that: I remember with fog in 1108, things like
func_illusionary were not fogged. Is that part of this fix or will we
remain with fogged forests and unfogged bushes? D:

Persuter

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:hlcoders-
> [EMAIL PROTECTED]] On Behalf Of Tim Holt
> Sent: Wednesday, April 24, 2002 12:21 PM
> To: [EMAIL PROTECTED]
> Subject: [hlcoders] Fog, sprites, and 1.1.0.9
>
> Anyone played with the "sprites in fog" fix in 1.1.0.9 to see how it
> works?
>
> --
> I think...I think it's in my basement. Let me go upstairs and check.
-M.C.
> Escher
>
>
>
> ___
> 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

Re: [hlcoders] Fun and games and amateur analysis of 1.1.0.9 updatehardware survey results...

[Tim Holt]

Hehe - i want to know who the one person is with 14.4 dialup and who the
ppl running at 320x200 are (unless it's a bug)

Speaking of bugs, I noticed that early on, the majority of vid configs
were D3D with OpenGL way down there.  But suddenly it switched.  /me
thinks someone had a little booboo and fixed it in the survey :^P

Kuja wrote:

>I was the first one to submit that survey :D
>
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED]]On Behalf Of Tim Holt
>Sent: Wednesday, April 24, 2002 4:07 PM
>To: [EMAIL PROTECTED]
>Subject: [hlcoders] Fun and games and amateur analysis of 1.1.0.9 update
>hardware survey results...
>
>
>--
>[ Picked text/plain from multipart/alternative ]
>Dunno of you all like to read the hardware survey results from the
>1.1.0.9 update, but I do.  See http://valve.speakeasy.net/
>
>Stuff I see that catches my eyes...
>
>* People with fast connections get the patch first (hence the huge
>  skew towards high speed with only 14,000 responces  :^)
>* A lot of ppl are still using what you'd call "crappy" video cards.
>   Voodoo 3 + TNT2 accounts for 10.4%. of all responses
>* Most ppl have around 256 MB of RAM.  You'd think it would be more
>  like 512 because it's cheap.
>* Double peaked bell curve for processors.  Lots in the 800-900 mhz
>  camp, and another bunch in the over 1 ghz range
>* Most ppl run video at 1024x768, but there's a pretty surpising #
>  at 800x600.  And who are these morons running 320x200? :D
>
>So what's that make me think?  We (as game developers) need to be
>careful we don't unconciously make our games unplayable by what we
>consider the "fringe" of low end users - who are actually a pretty big
>percentage.  Of course one can clearly decide "Minimum specs are Geforce
>2, 512 MB of RAM, 1 gig processor" and go from there.
>
>The other thing that comes to mind is this:  don't waste time
>complaining about all those old vid card users, or ppl who don't upgrade
>their RAM, because that isn't going to make them upgrade (unless you're
>willing to pay).  It's not about how you think it should be, it's about
>what it really is.
>
>I know with DoD we kinda have been pushing the "minimum configuration"
>limits, but not necessarily by planning.  DoD's next release (2.1) is
>going to include a big revamp of all our maps with this in mind.  We
>asked all the mappers to reduce their texture usage down to 5 meg or
>less.  Testing shows us they run MUCH faster now on the "lower end"
>video systems.  Made some mappers (ok, just one) really really mad, but
>I think it was worth it for the players.
>
>So anyone else have any observations/conclusions/etc. from the stats?
>
>--
>I think...I think it's in my basement. Let me go upstairs and check. -M.C.
>Escher
>
>
>--
>
>___
>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
>

--
I think...I think it's in my basement. Let me go upstairs and check. -M.C. Escher



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

Re: [hlcoders] Fun and games and amateur analysis of 1.1.0.9 update hardware survey results...

[botman]

> I was the first one to submit that survey :D

For a long time (since late last week) the survey site only showed 1 user
response.  I submitted mine from the hl1109.exe at about 13:20 CST today and
the speakeasy.net site still showed only 1 user (even though I know hundreds of
people had already downloaded, installed and completed the survey).

It seems like somebody forgot to turn on the "let this site update now" flag
and people were submitting surveys that didn't get recorded.

Jeffrey "botman" Broome

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

RE: [hlcoders] Fun and games and amateur analysis of 1.1.0.9 update hardware survey results...

[Kuja]

I was the first one to submit that survey :D

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Tim Holt
Sent: Wednesday, April 24, 2002 4:07 PM
To: [EMAIL PROTECTED]
Subject: [hlcoders] Fun and games and amateur analysis of 1.1.0.9 update
hardware survey results...


--
[ Picked text/plain from multipart/alternative ]
Dunno of you all like to read the hardware survey results from the
1.1.0.9 update, but I do.  See http://valve.speakeasy.net/

Stuff I see that catches my eyes...

* People with fast connections get the patch first (hence the huge
  skew towards high speed with only 14,000 responces  :^)
* A lot of ppl are still using what you'd call "crappy" video cards.
   Voodoo 3 + TNT2 accounts for 10.4%. of all responses
* Most ppl have around 256 MB of RAM.  You'd think it would be more
  like 512 because it's cheap.
* Double peaked bell curve for processors.  Lots in the 800-900 mhz
  camp, and another bunch in the over 1 ghz range
* Most ppl run video at 1024x768, but there's a pretty surpising #
  at 800x600.  And who are these morons running 320x200? :D

So what's that make me think?  We (as game developers) need to be
careful we don't unconciously make our games unplayable by what we
consider the "fringe" of low end users - who are actually a pretty big
percentage.  Of course one can clearly decide "Minimum specs are Geforce
2, 512 MB of RAM, 1 gig processor" and go from there.

The other thing that comes to mind is this:  don't waste time
complaining about all those old vid card users, or ppl who don't upgrade
their RAM, because that isn't going to make them upgrade (unless you're
willing to pay).  It's not about how you think it should be, it's about
what it really is.

I know with DoD we kinda have been pushing the "minimum configuration"
limits, but not necessarily by planning.  DoD's next release (2.1) is
going to include a big revamp of all our maps with this in mind.  We
asked all the mappers to reduce their texture usage down to 5 meg or
less.  Testing shows us they run MUCH faster now on the "lower end"
video systems.  Made some mappers (ok, just one) really really mad, but
I think it was worth it for the players.

So anyone else have any observations/conclusions/etc. from the stats?

--
I think...I think it's in my basement. Let me go upstairs and check. -M.C.
Escher


--

___
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] Fun and games and amateur analysis of 1.1.0.9 updatehardware survey results...

[Tim Holt]

Good point - the concept that some ppl just don't know


Scott Velasquez wrote:

>Well what comes to mind immediately about 4.9% of software users is that HL
>defaults to this and I'm sure that the software mode people have no idea how
>to change this.  In CS:CZ we'll probably autodetect the user's video card
>and try and set them up in OpenGL or Direct3D by default.
>
>Scott Velasquez
>Programmer
>Gearbox Software (www.gearboxsoftware.com)
>--
>re·cur·sion n.: See Recursion.
>--
>
>
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED]]On Behalf Of Tim Holt
>Sent: Wednesday, April 24, 2002 3:07 PM
>To: [EMAIL PROTECTED]
>Subject: [hlcoders] Fun and games and amateur analysis of 1.1.0.9 update
>hardware survey results...
>
>
>--
>[ Picked text/plain from multipart/alternative ]
>Dunno of you all like to read the hardware survey results from the
>1.1.0.9 update, but I do.  See http://valve.speakeasy.net/
>
>Stuff I see that catches my eyes...
>
>* People with fast connections get the patch first (hence the huge
>  skew towards high speed with only 14,000 responces  :^)
>* A lot of ppl are still using what you'd call "crappy" video cards.
>   Voodoo 3 + TNT2 accounts for 10.4%. of all responses
>* Most ppl have around 256 MB of RAM.  You'd think it would be more
>  like 512 because it's cheap.
>* Double peaked bell curve for processors.  Lots in the 800-900 mhz
>  camp, and another bunch in the over 1 ghz range
>* Most ppl run video at 1024x768, but there's a pretty surpising #
>  at 800x600.  And who are these morons running 320x200? :D
>
>So what's that make me think?  We (as game developers) need to be
>careful we don't unconciously make our games unplayable by what we
>consider the "fringe" of low end users - who are actually a pretty big
>percentage.  Of course one can clearly decide "Minimum specs are Geforce
>2, 512 MB of RAM, 1 gig processor" and go from there.
>
>The other thing that comes to mind is this:  don't waste time
>complaining about all those old vid card users, or ppl who don't upgrade
>their RAM, because that isn't going to make them upgrade (unless you're
>willing to pay).  It's not about how you think it should be, it's about
>what it really is.
>
>I know with DoD we kinda have been pushing the "minimum configuration"
>limits, but not necessarily by planning.  DoD's next release (2.1) is
>going to include a big revamp of all our maps with this in mind.  We
>asked all the mappers to reduce their texture usage down to 5 meg or
>less.  Testing shows us they run MUCH faster now on the "lower end"
>video systems.  Made some mappers (ok, just one) really really mad, but
>I think it was worth it for the players.
>
>So anyone else have any observations/conclusions/etc. from the stats?
>
>--
>I think...I think it's in my basement. Let me go upstairs and check. -M.C.
>Escher
>
>
>--
>
>___
>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
>

--
I think...I think it's in my basement. Let me go upstairs and check. -M.C. Escher



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

RE: Re[2]: [hlcoders] Sprite problems

[Ken Birdwell]

This should work correct, so check which DLL's your DevStudio is loading
(Project>Settings>Debug>Additional DLLs).  It's probably not loading the
ones you want.

-Original Message-
From: Cruise [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, April 24, 2002 10:25 AM
To: Persuter
Subject: Re[2]: [hlcoders] Sprite problems


I've not had the same problem with GetClassPtr...but I have noticed
the same problem when stepping through code...

The mod runs fine, but if I try to step through code, everything is
haywire...the stack trace is nonsense (function above has no reference
to the function I'm in), this pointers changing their value as I step
through a member function, memeber variables treated as out of scope.

Basically, really insane stuff...but the code is actually executing
fine...I can see the effects on screen. Basically it means I can't
step through the code at all...

All the latest service packs, etc. Very odd...
___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] SET_SIZE()

[Oskar 'Zoot' Lindgren]

pev->mini?
- Original Message -
From: "Cortex" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, April 24, 2002 10:08 PM
Subject: Re: [hlcoders] SET_SIZE()


Why don't you use the "SET_MODEL ( pev, your_model );" ? This links the
model into world and set automatically its size..

I think this should help you :)

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

- Original Message -
From: "Paul 'MoOg' Samways" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, April 24, 2002 5:42 PM
Subject: Re: [hlcoders] SET_SIZE()


*cough* english mailing list *cough*

- Original Message -
From: "Oskar 'Zoot' Lindgren" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, April 24, 2002 3:16 PM
Subject: Re: [hlcoders] SET_SIZE()


ser man på... en svensk till
- Original Message -
From: "Daniel Johansson" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, April 24, 2002 4:10 PM
Subject: [hlcoders] SET_SIZE()


> This is a multi-part message in MIME format.
> --
> [ Picked text/plain from multipart/alternative ]
> Hey all!
>
> Im playing around with models ingame, like spawning player models and then
make them play an animation.
> But now I have come to this little problem. I have an entity so the mapper
can choose what model to spawn
> and now when I spawn the model I dont know the size of it so I tried a
playermodel and set the size according
> to what was set in player.cpp spawn function. But now I was kinda
wondering if there is any way of getting the
> size of a model ie GET_SIZE (does not exist btw). Anyone care to enlighten
me on this if they can?
>
> Thanks
> Daniel Johansson
> [EMAIL PROTECTED]
>
> --
>
> ___
> 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] Fun and games and amateur analysis of 1.1.0.9 update hardware survey results...

[Scott Velasquez]

Well what comes to mind immediately about 4.9% of software users is that HL
defaults to this and I'm sure that the software mode people have no idea how
to change this.  In CS:CZ we'll probably autodetect the user's video card
and try and set them up in OpenGL or Direct3D by default.

Scott Velasquez
Programmer
Gearbox Software (www.gearboxsoftware.com)
--
re·cur·sion n.: See Recursion.
--


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Tim Holt
Sent: Wednesday, April 24, 2002 3:07 PM
To: [EMAIL PROTECTED]
Subject: [hlcoders] Fun and games and amateur analysis of 1.1.0.9 update
hardware survey results...


--
[ Picked text/plain from multipart/alternative ]
Dunno of you all like to read the hardware survey results from the
1.1.0.9 update, but I do.  See http://valve.speakeasy.net/

Stuff I see that catches my eyes...

* People with fast connections get the patch first (hence the huge
  skew towards high speed with only 14,000 responces  :^)
* A lot of ppl are still using what you'd call "crappy" video cards.
   Voodoo 3 + TNT2 accounts for 10.4%. of all responses
* Most ppl have around 256 MB of RAM.  You'd think it would be more
  like 512 because it's cheap.
* Double peaked bell curve for processors.  Lots in the 800-900 mhz
  camp, and another bunch in the over 1 ghz range
* Most ppl run video at 1024x768, but there's a pretty surpising #
  at 800x600.  And who are these morons running 320x200? :D

So what's that make me think?  We (as game developers) need to be
careful we don't unconciously make our games unplayable by what we
consider the "fringe" of low end users - who are actually a pretty big
percentage.  Of course one can clearly decide "Minimum specs are Geforce
2, 512 MB of RAM, 1 gig processor" and go from there.

The other thing that comes to mind is this:  don't waste time
complaining about all those old vid card users, or ppl who don't upgrade
their RAM, because that isn't going to make them upgrade (unless you're
willing to pay).  It's not about how you think it should be, it's about
what it really is.

I know with DoD we kinda have been pushing the "minimum configuration"
limits, but not necessarily by planning.  DoD's next release (2.1) is
going to include a big revamp of all our maps with this in mind.  We
asked all the mappers to reduce their texture usage down to 5 meg or
less.  Testing shows us they run MUCH faster now on the "lower end"
video systems.  Made some mappers (ok, just one) really really mad, but
I think it was worth it for the players.

So anyone else have any observations/conclusions/etc. from the stats?

--
I think...I think it's in my basement. Let me go upstairs and check. -M.C.
Escher


--

___
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] SET_SIZE()

[Cortex]

Why don't you use the "SET_MODEL ( pev, your_model );" ? This links the
model into world and set automatically its size..

I think this should help you :)

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

- Original Message -
From: "Paul 'MoOg' Samways" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, April 24, 2002 5:42 PM
Subject: Re: [hlcoders] SET_SIZE()


*cough* english mailing list *cough*

- Original Message -
From: "Oskar 'Zoot' Lindgren" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, April 24, 2002 3:16 PM
Subject: Re: [hlcoders] SET_SIZE()


ser man på... en svensk till
- Original Message -
From: "Daniel Johansson" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, April 24, 2002 4:10 PM
Subject: [hlcoders] SET_SIZE()


> This is a multi-part message in MIME format.
> --
> [ Picked text/plain from multipart/alternative ]
> Hey all!
>
> Im playing around with models ingame, like spawning player models and then
make them play an animation.
> But now I have come to this little problem. I have an entity so the mapper
can choose what model to spawn
> and now when I spawn the model I dont know the size of it so I tried a
playermodel and set the size according
> to what was set in player.cpp spawn function. But now I was kinda
wondering if there is any way of getting the
> size of a model ie GET_SIZE (does not exist btw). Anyone care to enlighten
me on this if they can?
>
> Thanks
> Daniel Johansson
> [EMAIL PROTECTED]
>
> --
>
> ___
> 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

[hlcoders] Fun and games and amateur analysis of 1.1.0.9 update hardware surveyresults...

[Tim Holt]

--
[ Picked text/plain from multipart/alternative ]
Dunno of you all like to read the hardware survey results from the
1.1.0.9 update, but I do.  See http://valve.speakeasy.net/

Stuff I see that catches my eyes...

* People with fast connections get the patch first (hence the huge
  skew towards high speed with only 14,000 responces  :^)
* A lot of ppl are still using what you'd call "crappy" video cards.
   Voodoo 3 + TNT2 accounts for 10.4%. of all responses
* Most ppl have around 256 MB of RAM.  You'd think it would be more
  like 512 because it's cheap.
* Double peaked bell curve for processors.  Lots in the 800-900 mhz
  camp, and another bunch in the over 1 ghz range
* Most ppl run video at 1024x768, but there's a pretty surpising #
  at 800x600.  And who are these morons running 320x200? :D

So what's that make me think?  We (as game developers) need to be
careful we don't unconciously make our games unplayable by what we
consider the "fringe" of low end users - who are actually a pretty big
percentage.  Of course one can clearly decide "Minimum specs are Geforce
2, 512 MB of RAM, 1 gig processor" and go from there.

The other thing that comes to mind is this:  don't waste time
complaining about all those old vid card users, or ppl who don't upgrade
their RAM, because that isn't going to make them upgrade (unless you're
willing to pay).  It's not about how you think it should be, it's about
what it really is.

I know with DoD we kinda have been pushing the "minimum configuration"
limits, but not necessarily by planning.  DoD's next release (2.1) is
going to include a big revamp of all our maps with this in mind.  We
asked all the mappers to reduce their texture usage down to 5 meg or
less.  Testing shows us they run MUCH faster now on the "lower end"
video systems.  Made some mappers (ok, just one) really really mad, but
I think it was worth it for the players.

So anyone else have any observations/conclusions/etc. from the stats?

--
I think...I think it's in my basement. Let me go upstairs and check. -M.C. Escher


--

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

[hlcoders] Fog, sprites, and 1.1.0.9

[Tim Holt]

Anyone played with the "sprites in fog" fix in 1.1.0.9 to see how it works?

--
I think...I think it's in my basement. Let me go upstairs and check. -M.C. Escher



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

Re[2]: [hlcoders] Sprite problems

[Cruise]

I've not had the same problem with GetClassPtr...but I have noticed
the same problem when stepping through code...

The mod runs fine, but if I try to step through code, everything is
haywire...the stack trace is nonsense (function above has no reference
to the function I'm in), this pointers changing their value as I step
through a member function, memeber variables treated as out of scope.

Basically, really insane stuff...but the code is actually executing
fine...I can see the effects on screen. Basically it means I can't
step through the code at all...

All the latest service packs, etc. Very odd...


[ Cruise / www.casual-tempest.net ]



> Further troubles... I tried making this a non-static function, but that
> didn't work either. But here's the REALLY weird part. I was stepping
> through the new function in the debugger:

> CSprite* CStreetlamp::MakeSprite( const char* pSpriteName, const Vector
> &origin, BOOL animate  )
> {
> CSprite* pSprite = GetClassPtr( (CSprite *)NULL );
> pSprite->SpriteInit( pSpriteName, origin );
> pSprite->pev->classname = MAKE_STRING("env_sprite");
> pSprite->pev->solid = SOLID_NOT;
> pSprite->pev->movetype = MOVETYPE_NOCLIP;
> if ( animate )
> pSprite->TurnOn();

> return pSprite;
> }

> It has the exact same error as before. However, I noticed that as I step
> through the function that the value of this, i.e., the street lamp,
> changes three times. First it goes to some seemingly random memory
> location, then it changes to 1, then it goes back to its regular
> location. Is that CRAZY or what?

> Upon further inspection, I found that in addition to this calamity, the
> Keyvalue function for the entity is not being called at all. This, too,
> seems a bit odd. My suspicion was that somehow the game is stumbling
> over some of the fgd files and somehow, some way, that's messing up the
> files.

> However, I then dropped into the disassembler to check what the assembly
> had to say about it, and learned to my shock that CSprite* pSprite =
> GetClassPtr( (CSprite *)NULL ); has absolutely no assembly counterpart.
> In other words, the compiler is somehow skipping right the f**k over it.

> I have absolutely no clue. I'm going to try recompiling all the maps and
> the models involved in the hopes that somehow this will fix itself. Is
> there anyone who's had a similar problem with GetClassPtr? The rest of
> them seem to be compiling so I can't imagine it's a problem with the
> template implementation, but the problems like KeyValue suggest to me
> that it's a run-time problem of some sort, because the fact that
> GetClassPtr didn't compile shouldn't do anything to KeyValue...

> Persuter

>> -Original Message-
>> From: [EMAIL PROTECTED] [mailto:hlcoders-
>> [EMAIL PROTECTED]] On Behalf Of Persuter
>> Sent: Monday, April 22, 2002 6:42 PM
>> To: [EMAIL PROTECTED]
>> Subject: [hlcoders] Sprite problems
>>
>> Hey all, having a bit of a problem here:
>>
>> CSprite *CSprite::SpriteCreate( const char *pSpriteName, const Vector
>> &origin, BOOL animate )
>> {
>>   CSprite* pSprite = GetClassPtr( (CSprite *)NULL ); <-- This line
>>   pSprite->SpriteInit( pSpriteName, origin );
>>   pSprite->pev->classname = MAKE_STRING("env_sprite");
>>   pSprite->pev->solid = SOLID_NOT;
>>   pSprite->pev->movetype = MOVETYPE_NOCLIP;
>>   if ( animate )
>>   pSprite->TurnOn();
>>
>>   return pSprite;
>> }
>>
>> For some reason, when I execute the following code with
>> "sprites/glow01.spr", multiple times, the indicated line doesn't
> execute
>> at all except for one instance, the last that is tried. When I use the
>> debugger, it completely steps over the line, even when I try to step
>> into GetClassPtr. It's like the line doesn't exist... I try pleading
>> with the debugger, pointing at the line very insistently and so forth,
>> but to no avail.
>>
>> Anyway, so it doesn't execute the line, which means that pSprite does
>> not exist. This does not trouble the program, however, which happily
>> goes along executing the rest of the code, even while the debugger
> shows
>> that pSprite doesn't exist. If I step into the function and check the
>> value of this, I find that indeed it DOES have an address. But that
>> address is never returned, and the program proceeds as if nothing had
>> been returned from the function at all! It doesn't even throw errors.
>> It's very odd.
>>
>> Any ideas?
>>
>> Persuter
>>
>>
>> _
>> Do You Yahoo!?
>> Get your free @yahoo.com address at http://mail.yahoo.com
>>
>> ___
>> To unsubscribe, edit your list preferences, or view the list archives,
>> please visit:
>> http://list.valvesoftware.com/mailman/listinfo/hlcoders


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

RE: [hlcoders] Sprite problems

[Persuter]

Tried it. Numerous times. :)

Persuter

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:hlcoders-
> [EMAIL PROTECTED]] On Behalf Of Cortex
> Sent: Tuesday, April 23, 2002 5:28 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [hlcoders] Sprite problems
>
> Rebuild ALL ???
>
>   - Cortex : mapper & coder www.hlalbator.fr.st
>
> - Original Message -
> From: "Persuter" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, April 23, 2002 1:42 AM
> Subject: [hlcoders] Sprite problems
>
>
> > Hey all, having a bit of a problem here:
> >
> > CSprite *CSprite::SpriteCreate( const char *pSpriteName, const
Vector
> > &origin, BOOL animate )
> > {
> > CSprite* pSprite = GetClassPtr( (CSprite *)NULL ); <-- This line
> > pSprite->SpriteInit( pSpriteName, origin );
> > pSprite->pev->classname = MAKE_STRING("env_sprite");
> > pSprite->pev->solid = SOLID_NOT;
> > pSprite->pev->movetype = MOVETYPE_NOCLIP;
> > if ( animate )
> > pSprite->TurnOn();
> >
> > return pSprite;
> > }
> >
> > For some reason, when I execute the following code with
> > "sprites/glow01.spr", multiple times, the indicated line doesn't
execute
> > at all except for one instance, the last that is tried. When I use
the
> > debugger, it completely steps over the line, even when I try to step
> > into GetClassPtr. It's like the line doesn't exist... I try pleading
> > with the debugger, pointing at the line very insistently and so
forth,
> > but to no avail.
> >
> > Anyway, so it doesn't execute the line, which means that pSprite
does
> > not exist. This does not trouble the program, however, which happily
> > goes along executing the rest of the code, even while the debugger
shows
> > that pSprite doesn't exist. If I step into the function and check
the
> > value of this, I find that indeed it DOES have an address. But that
> > address is never returned, and the program proceeds as if nothing
had
> > been returned from the function at all! It doesn't even throw
errors.
> > It's very odd.
> >
> > Any ideas?
> >
> > Persuter
> >
> >
> > _
> > Do You Yahoo!?
> > Get your free @yahoo.com address at http://mail.yahoo.com
> >
> > ___
> > To unsubscribe, edit your list preferences, or view the list
archives,
> please visit:
> > http://list.valvesoftware.com/mailman/listinfo/hlcoders
> >
> >
>
>
> ___
> 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

[hlcoders] Re: hlcoders digest, Vol 1 #432 - 10 msgs

[Charlie Cleveland]

   Persuter,

   Whenever I see strange stuff like that, I have one solution I try first:
clean and rebuild all.  Using the Edit and Continue in MSVC 6 seems to work
fine for awhile, but then I'll start seeing issues like this.  I haven't
had these problems with other source, but using it with HL code has caused
me nothing but problems.  The crazy symptoms you are describing make me
think you're seeing the same thing.  Luckily, the fix is easy.

   If your machine is acting crazy, reboot.  If you're code is random and
nuts, rebuild all. :)  Woe, is the PC programmer's mentality...

   Let us know if this clears it up.

-Charlie

>Send hlcoders mailing list submissions to
> [EMAIL PROTECTED]
>
>To subscribe or unsubscribe via the World Wide Web, visit
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>or, via email, send a message with subject or body 'help' to
> [EMAIL PROTECTED]
>
>You can reach the person managing the list at
> [EMAIL PROTECTED]
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of hlcoders digest..."
>
>
>Today's Topics:
>
>1. RE: SITWFODF1D #1 (Ken Birdwell)
>2. Model sequencing woes - fixed :) (Jeff Fearn)
>3. RE: Sprite problems (Persuter)
>4. Re: 1000+ are nice? (Nathan Taylor)
>5. Entity indices (Georges Giroux)
>6. Re: Sprite problems (Cortex)
>7. RE: Sprite problems (Commando)
>8. SET_SIZE() (Daniel Johansson)
>9. Re: SET_SIZE() (Oskar 'Zoot' Lindgren)
>   10. Re: SET_SIZE() (Paul 'MoOg' Samways)
>
>--__--__--
>
>Message: 1
>From: Ken Birdwell <[EMAIL PROTECTED]>
>To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
>Subject: RE: [hlcoders] SITWFODF1D #1
>Date: Tue, 23 Apr 2002 13:41:52 -0700
>Reply-To: [EMAIL PROTECTED]
>
>Good advice.  The only hard limitations compilied into the engine are
>MAXSTUDIOBONES, MAXSTUDIOVERTS, and MAXSTUDIOCONTROLLERS.  The rest can be
>changed.
>
>-Original Message-
>From: Persuter [mailto:[EMAIL PROTECTED]]
>Sent: Tuesday, April 23, 2002 10:08 AM
>To: [EMAIL PROTECTED]
>Subject: RE: [hlcoders] SITWFODF1D #1
>
>
>I don't know if this is similar, but:
>
>On Hostile Intent, we had oodles and oodles of player animations, and
>eventually studiomdl started crapping out with amazing memory dump
>errors.
>
>The solution, however, was simple, we simply had to increase
>MAXSTUDIOSEQUENCES or MAXSTUDIOANIMATIONS, I forget which one, and
>recompile studiomdl and the game, then recompile all the models with the
>new studiomdl. I see in studio.h that there is a MAXSTUDIOSKINS variable
>as well, set to 100. Perhaps if you increased that to something higher
>and recompiled both studiomdl and the game?
>
>Again, it's a simple fix so you've probably already tried it, it just
>seemed similar in many ways to the problem we were having (Valve's code
>pooping out due to throwing way more at it than it was meant to handle).
>
>
>Persuter
>
>
>--__--__--
>
>Message: 2
>From: "Jeff Fearn" <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>
>Date: Wed, 24 Apr 2002 07:27:34 +1000
>Subject: [hlcoders] Model sequencing woes - fixed :)
>Reply-To: [EMAIL PROTECTED]
>
>As we seem to be sharing fixes for strange behavior, I thought I'd share
>my latest
>... "experience" with you.
>
>I have been having a problem where the incorrect animation would be
>displayed for
>a player, seemingly at random. So instead of running a player would swim,
>or it
>would say sequence 77 not in model hgrunt etc. Each class in our mod has
>it's own
>model, and each model only has animations for each of the weapons it uses,
>no more
>than 10 per class. I originally thought this was due to animations being
>incorrectly named in the model, however this would only explain problems
>displaying weapon animations, and should not have affected action
>animations, like
>swimming or running.
>
>The real problem was that, for some odd reason, g_ulModelIndexPlayer was being
>used to reset the players pev->modelindex at every spawn. This had the
>effect of
>making every player reference, but not display, the model for the class of the
>player that was spawned last. Thus if run, swim etc where in a different
>order in
>a model then the incorrect sequence would be displayed. Also as different
>classes
>had different weapons, which is almost always true, then it would fail to
>find the
>correct weapon sequence, even though it was in the players model. Needles
>to say
>this was a real pain in the ass to work out, especially as I had never
>used, or
>even noticed, g_ulModelIndexPlayer.
>
>The moral is that if you use models with different sequences, or different
>sequence order, then you should comment out references to
>g_ulModelIndexPlayer. I
>have commented them all out and have not seen any effects, other than the
>correct
>sequences being displayed :}
>
>Hope this saves someone a brain tumor ;)
>
>Jeff "DarthBobo" Fearn
>-
>Lead Coder, Web 

Re: [hlcoders] SET_SIZE()

[Paul 'MoOg' Samways]

*cough* english mailing list *cough*

- Original Message -
From: "Oskar 'Zoot' Lindgren" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, April 24, 2002 3:16 PM
Subject: Re: [hlcoders] SET_SIZE()


ser man på... en svensk till
- Original Message -
From: "Daniel Johansson" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, April 24, 2002 4:10 PM
Subject: [hlcoders] SET_SIZE()


> This is a multi-part message in MIME format.
> --
> [ Picked text/plain from multipart/alternative ]
> Hey all!
>
> Im playing around with models ingame, like spawning player models and then
make them play an animation.
> But now I have come to this little problem. I have an entity so the mapper
can choose what model to spawn
> and now when I spawn the model I dont know the size of it so I tried a
playermodel and set the size according
> to what was set in player.cpp spawn function. But now I was kinda
wondering if there is any way of getting the
> size of a model ie GET_SIZE (does not exist btw). Anyone care to enlighten
me on this if they can?
>
> Thanks
> Daniel Johansson
> [EMAIL PROTECTED]
>
> --
>
> ___
> 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] SET_SIZE()

[Oskar 'Zoot' Lindgren]

ser man på... en svensk till
- Original Message -
From: "Daniel Johansson" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, April 24, 2002 4:10 PM
Subject: [hlcoders] SET_SIZE()


> This is a multi-part message in MIME format.
> --
> [ Picked text/plain from multipart/alternative ]
> Hey all!
>
> Im playing around with models ingame, like spawning player models and then
make them play an animation.
> But now I have come to this little problem. I have an entity so the mapper
can choose what model to spawn
> and now when I spawn the model I dont know the size of it so I tried a
playermodel and set the size according
> to what was set in player.cpp spawn function. But now I was kinda
wondering if there is any way of getting the
> size of a model ie GET_SIZE (does not exist btw). Anyone care to enlighten
me on this if they can?
>
> Thanks
> Daniel Johansson
> [EMAIL PROTECTED]
>
> --
>
> ___
> 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] SET_SIZE()

[Daniel Johansson]

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

Im playing around with models ingame, like spawning player models and then make them 
play an animation.
But now I have come to this little problem. I have an entity so the mapper can choose 
what model to spawn
and now when I spawn the model I dont know the size of it so I tried a playermodel and 
set the size according
to what was set in player.cpp spawn function. But now I was kinda wondering if there 
is any way of getting the
size of a model ie GET_SIZE (does not exist btw). Anyone care to enlighten me on this 
if they can?

Thanks
Daniel Johansson
[EMAIL PROTECTED]

--

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