Re: [hlcoders] Threading

[Pat Magnan]

Is there a way in which I can spawn a thread in a cross-platform way?


AFAIK threads are inherently a platform specific device, and at one time
could not be counted on even being present on a platform (Linux has had a
few versions of 'threads' over the years, in fact, it hasn't always even
supported them, like about the time HL was released there were none IIRC).



Is it
possible to do this without #ifdef'ing code for Windows and Linux?


Yes, and the answer is related to the above, you don't need to use
conditional compilation all over the place to isolate platform differences,
but in one spot, you write three classes to perform the platform specific
things, one is a windows-only version of the code, one is a linux only
version of the code, and one is the abstraction layer (i.e. abstract base
class interface), then you have a single #if def to determine the platform
(or do something trickier at runtime, but really the ifdef is a reasonable
choice). You only have one instance of the three classes, a pointer to the
parent class, which is set equal to the sub classes depending on where
you're running -- windows/linux.

Wendy Jones has an article which shows off a simple technique in 'Game
Programming Tricks of the Trade', it more applies to things that run on
consoles and PC's, but the technique is useful in general for isolating
platform specific things. But the above would get someone started. Probably
one would make the thing a singleton, but the basic concept in no way
requires that.


--
Thanks,
Lachlan

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




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

Re: [hlcoders] Re: Hey Eric

[Pat Magnan]

Now we're comparing Valve to the borg?
Confused as ever,
Cale Dunlap wrote:
Those are Valve assimilated mods, not third party ones.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Imperio59
Sent: Friday, July 02, 2004 11:12 AM
To: [EMAIL PROTECTED]
Subject: [hlcoders] Re: Hey Eric
This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
DOD 1.2 has been released through steams, and CS updates are also being
released through steam, so it's already being done :)
--
___
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
--
Dupe, dupe, dupe, Dupe of Earl, dupe, dupe . . .{randomly inserted!}
___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] SDK 2.3 Observer

[Pat Magnan]

Hi Josh:
I've written about all the things I had to do to get the 2.3 spectator
modes to work in Tour of Duty, which has a gameplay mode exactly like
you describe. I had to ensure that the players remained in spectator
mode for the end of the round etc outside of this, but you may find this
helpful ensuring the 2.3 spectator modes work:
http://sluggo.org/tutorials.php
There's a bit of a rogue message about 'unsupported spectator mode' sent
to the console on join, but otherwise, that's how we did things.
Any 2.2, 2.0, 2.1 tutorial that documents the 'being spectators until
the round ends' bits work fine alongside the 2.3 spectator code. I
haven't looked at HL code for a long while now, but could dig into
specifics with you if one particular aspect is troubling you.
Josh Coyne wrote:
This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
Couldn't seem to find anything in the hl coders archive, so here goes:
It doesn't seem like the 2.3 code easily lets you make someone an observer. In The 
Wastes i want to add survival mode, where when you die you stay dead for the rest of 
the round, and you observe the other players. If I just use one of the 2.2 tutorials 
available online, I'll use it, I just thought that with the new SDK it was already 
coded in, but it seems like thats a false.
Also, if i use a 2.2 tutorial, what changes should I make to support the new 2.3 
spectator features, like PinP ? Any help on this would be greatly appreciated as well.
Regards,
Josh
--
___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders


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

Re: [hlcoders] compiling smdlexp

[Pat Magnan]

Those types of errors could mean either the code you're compiling is
just plain wrong, or that perhaps you have multiple copies of the same
hearders, and the declarations are slightly different (abstract vs.
non-abstract in this case (weird if that's true)).
You'll get similar results messing with DirectX if the DirectX headers
are in teh include path BELOW the platform SDK (which includes super old
DirectX stuffs).
Search for the files it's griping about (the .h's is my guess), and if
you have multiple copies, try rearranging the order for include files
(tools->options directories tab).
Otherwise, you get to try to make this plugin or sdk code valid :(.
Almost looks like the first one is because the constructor is pure
virtual (ie. declared = 0). Odd.
Vyacheslav Djura wrote:
But I still can't compile and and this time I guess I won't be able to
do anything without someone's advice :) When compiling I receive 2
strange error messages:
Configuration: smdlexp - Win32 Debug
Compiling...
smdlexp.cpp
c:\maxplugins\smdlexp\smedefs.h(96) : error C2259: 'SmdExportClass' : cannot 
instantiate abstract class due to following members:
c:\maxplugins\smdlexp\smedefs.h(24) : see declaration of 'SmdExportClass'




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

Re: [hlcoders] compiling smdlexp

[Pat Magnan]

Those types of errors could mean either the code you're compiling is
just plain wrong, or that perhaps you have multiple copies of the same
hearders, and the declarations are slightly different (abstract vs.
non-abstract in this case (weird if that's true)).
You'll get similar results messing with DirectX if the DirectX headers
are in teh include path BELOW the platform SDK (which includes super old
DirectX stuffs).
Search for the files it's griping about (the .h's is my guess), and if
you have multiple copies, try rearranging the order for include files
(tools->options directories tab).
Otherwise, you get to try to make this plugin or sdk code valid :(.
Almost looks like the first one is because the constructor is pure
virtual (ie. declared = 0). Odd.
Vyacheslav Djura wrote:
But I still can't compile and and this time I guess I won't be able to
do anything without someone's advice :) When compiling I receive 2
strange error messages:
Configuration: smdlexp - Win32 Debug
Compiling...
smdlexp.cpp
c:\maxplugins\smdlexp\smedefs.h(96) : error C2259: 'SmdExportClass' : cannot 
instantiate abstract class due to following members:
c:\maxplugins\smdlexp\smedefs.h(24) : see declaration of 'SmdExportClass'




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

Re: [hlcoders] voice and text comm.

[Pat Magnan]

It's not a very difficult problem, so I can see no tutorial being written,
say text is dealt with in client.cpp, Host_Say function. Something like
this should do:
CBasePlayer *pPlayer = (CBasePlayer *)CBaseEntity::Instance(
pEntity );
BOOL playerDead = ( FNullEnt( pPlayer->pev )  ||
FNullEnt(pPlayer->edict())||
FStrEq( STRING( pPlayer->pev->netname ), "" ) ||
!pPlayer->IsAlive()
  );
...
while ( ((client = (CBasePlayer*)UTIL_FindEntityByClassname(
client, "player" )) != NULL) && (!FNullEnt(client->edict())) )
{

// Dead players can't talk to alive ones
if ( playerDead && client->IsAlive() )
continue;


Just keeps the entity dll from forwarding the messages for dead players to
other non-dead players.. ;).
At 12:05 PM 10/20/2003 -0400, you wrote:
This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
hey guys i have another good question that i hope you can help me out
with. we have a multiplayer team based mod in development and one thing
that i dont like is that dead people in spectator mode can still talk
(voice comm and text) to any players that are alive in the game. basically
i wanna shut them up so they cant be giving away info (cheating) to there
team. how would i go about doing this? or even where would i start. ive
looked through the sdk and i cant seem to find anything... even the
internet doesnt have a tutorial on this subject. once i figure this out im
going to write one. thanks alot again!
--

___
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] TriAPI Question

[Pat Magnan]

Hmm, haven't played with D3D at all, is the problem you just can't get
reference to the surfaces/device context the engine uses i guess?
HL2 will be interesting to see if there is something available up in the
client code such that we can do our own D3D calls should we need to... ;).
At 12:56 AM 10/19/2003 -0400, you wrote:
Yes to the opengl, no to the d3d.



-omega
http://www.frontline2.com
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Keith
Jackson
Sent: October 19, 2003 12:34 AM
To: [EMAIL PROTECTED]
Subject: [hlcoders] TriAPI Question
This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
Alright, I've been researching the past few hours, my eyes hurt, and I'm
tired. I want to draw triangles without a texture. Just colors. Why
waste speed doing textures if I just want a flat color? Is this
possible? I cannot make it work at all. As soon as I take the TexCoord
calls out, it no longer works, regardless of me putting in Color() and
Brightness() calls.
So, is the TriAPI only for textured triangles? I can obviously get
around this by making a solid colored texture, but that seems like an
awful hack to me.
Also, where should I start looking to get 'deeper' into the drawing
code? Can I find if we are in OpenGL mode and just start making gl*
calls on my own? Or if we are in DX mode and start making DirectX calls?
Thanks ahead of time.

Keith

--

___
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] Open Letter To Hacker Community

[Pat Magnan]

Good point.. tei, I am trying to be as inoffensive as possible, but it's
not really possible here, if you're a merely a gamer, this is NOT the list
for you.
There are Quake I lists, and probably Halflife fans lists &c, if you want
to see what we talk about you're welcome to lurk, but a few of you new
folks on the list have been taking things WAY off topic. We don't give a
hoot what you can or can't do in Quake I, or any other engine, we ask each
other and the VALVe folks when they have time how you do stuff in Halflife.
Technical questions, if you've never looked at the SDK or done it yourself,
you're not really qualified to comment..
Now how do I retract my last post? :p

At 02:07 PM 10/10/2003 -0400, you wrote:
Keep in mind this is supposed to be a mailing list for people who WANT to
code for Half-life, not a place to get up on your high-horse and preach, or
a place to nitpick hacker definitions.
Let's get back on topic please.

-Charlie
--
Charlie Cleveland
Game programmer and designer
http://www.natural-selection.org
http://overmind.org
- Original Message -
From: "tei" <[EMAIL PROTECTED]>
To: "Phil" <[EMAIL PROTECTED]>
Sent: Friday, October 10, 2003 9:33 AM
Subject: Re[2]: [hlcoders] Open Letter To Hacker Community
> Hello Phil,
>
>
> P> Firstly, I would encourage you to get your definition of 'hacker'
correct
> P> before you start shaking your finger at them.
>
> "Open Letter to Hacker Community" was better than
>
> "Open Letter to Hacker, Cracker, ScriptKiddie, Virii, Troyan Makers
> etc... people".
>
> I know hacker mean a guy soo good at coding/system that can write
no-obvious
> workarounds for problems not-soluble other way.
>
> Hollywood is redefining hacker has "system cracker".
>
>
> >> I think Valve is triing to become the next Microsoft. The Steam tools
> >> is crappy, and damage users gameplay with delays and failures, and
> >> restrict singleplayer ability. Its the first step of a highly
> >> dangerous technology to damage freedom: DRM.
>
> P> How have they done any of that? That is just your personal experience.
It
> P> hasn't changed the way that authentication is done, it hasn't
introduced any
> P> new DRM, it hasn't restricted anything that you couldn't do before.
> P> All it is, is a new way to deliver Valve's content, authenticate to the
servers
> P> (which were WON until Steam) and update the games.
>
> I dont want to comments the negative points, but...
>
> Not true:
>
> You have to use the same tool (Steam), you can't use 3th party
> tools, better tools than Steam.  Bye Bye GameSpy, QTracker,...
>
> You can't still LAN or SP offline (will be fixed soon).
> You can't hack files into cache, but you can hack files into pak
> files. Ok, only power users and hackers care about, but the letter
> was address to this people...
>
> Everything is now imprisioned and buried inside Steam. The tool that
> access/able everything IF valve want Hopefully you can still
> directly access the hl.exe executable to lauch games :]
>
> This is somewhat like these TCPA .doc files. If Valve want to forbid
> "Mod Bart Simpson" can remake a new version that disable that mod, and
> "withouth consent" download to all users computers.
>
> This is not a problem for me, but I am not a hacker. But I think
> hacker will really disagree TCPA alike stuff...
>
> Maybe hackers will help to fix the Steam limitations.
>
> >> Valve as work dirty in the past. Unable Quake1 developpers to use
> >> both tools and some media into Quake1.
>
> P> When you take the Q1 engine, mix in stuff from Q2 and your own custom
> P> modifications, I'd love to see you do anything like backwards
compatability
> P> with Q1. Valve licensed the Q1 engine fair and square and had no
obligation,
> P> need or want to make it backwards compatable.
>
> Had not obligation other than be fair and make friends. Soo If you
> remove Q1 compatibility from Worldcraft... you gain enemys!.. not
> good. Ooops... maybe compatibility is droooped ? maybe... but is
> forbid at the license AND people as discovered a way to workaround
> (HACK HACK HACK) the problem to still use Worldcraft.  q1rad is a
> quake1 tool to light maps with rendersity... maybe a illegal tool, but
> exist. You can also make Q1 maps with Hammer, but Valve forbit it...
>
> I not like that, but I not blame Valve. I list stuff that hackers
> disagree and hate. This is a well know example.  Worldcraft, a Q1 map
> tool, generate BSP maps, Valve disable that (or drop) and forbid, also
> create is own "incompatible" BSP format. But this is also "fake" as is
> very easy to enable support for HL maps for Quake1. A lot of Q1
> engines support HL maps. Valve forbid *me*, to upload cs_siege.bsp to
> my homepage and share with other files with instructions to copy this
> file at /quake/cstrike-ish-mod/maps
>
> Maybe this was a bussines decision, made to have more profit. Cool!.
> But you gain more enemys. More people will become angry.
>
>
> >> Abducting good mods inside
> >> (like Counter-Stri

Re: [hlcoders] Re: Open Letter To Hacker Community

[Pat Magnan]

At 07:32 PM 10/10/2003 +0200, you wrote:

>>
>> Had not obligation other than be fair and make friends. Soo If you
>> remove Q1 compatibility from Worldcraft... you gain enemys!.. not
>> good. Ooops... maybe compatibility is droooped ? maybe... but is
>> forbid at the license AND people as discovered a way to workaround
>> (HACK HACK HACK) the problem to still use Worldcraft.  q1rad is a
>> quake1 tool to light maps with rendersity... maybe a illegal tool, but
>> exist. You can also make Q1 maps with Hammer, but Valve forbit it...
P> This is the first time i've seen ANYONE complain about HL2 not supporting
P> Quake1 maps (and i know alot of mappers). End of the day this is Valve's
P> product, so you either play by their rules or dont play at all. As was
P> mentioned they was under no obligation, moneytry or otherwise, to support a
P> game by another company in their product. Its a bit like complaining that
P> you cant make Quake1 map for UT, different products and different map
P> formats.
Nope.

Complains where about a license that ban tools, SDK source, maps,
textures... everything... to use with other engines. Like good old
Quake1.
Its legit, ok, but is annoying, so people may hate that. I really not
care soo much about.
But tei, those people are fools, plain and simple. That's like saying that
when you buy DukeNukem3D you are expecting to be able to use their CONTENT
or file formats to make a mod for Quake I , you bloody well can't, I
understand in your case, English is a second language, but you're pretty
fluent. Re-read the SDK license, it never ever said anything about doing
things for ANY engine but VALVes, nor should it.
It's not even logic these people are using, they're just 12 year olds
deciding VALVe is the enemy because they have a corporate name, they've
outstripped all the competition in the FPS and done something old ID fans
may not like, they licensed Quake's tech, made it way better than any Quake
or ID release since (apart from using new rendering techniques, which
Carmack is a leader at even if he makes the most dull games on the earth),
Quake III doesn't have skeletal animations, there's crap you can do in
Halflife you STILL can't do in Quake, or RTCW or any ID product.
This is all sour grapes. ID had their heyday, but fell from grace when they
didn't reorganize their code enough to use things like C++, which made
modding infinitetly more achievable for students, and professionals from
other fields as well.
And 'good ole quake I'.. people complain that the Halflife engine is dated,
quake I rendering with significant improvements in many areas like
networking, animation, etc etc (essentially what Halflife is), is surely
dated as well, if we need new BSP formats for HL2, it's about time. I'm
sick of hearing level designers bitching about being limited, and I think
the new BSP format will STILL be limiting, but hopefully not so severely
so. Hopefully enough so to give me a few months reprieve before the artists
start bitching all over again (because we all know they will... ).
We've tried every trick in the book to try to do believable jungles in
Halflife, it's just hard as pewp. Hopefully with a bit more improved
environment like HL2, we'll be able to pull it off more believably (well we
just finally stumbled on yet another technique to add some reality to
levels, and i'm sure it will carry over to HL2 ;)).
I am interested at HL2 only as gammer. Soo you will find 0 or none
references to hl2 in my messages.
Hehehehe

I am sorry for my english.

___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
Pat 'sluggo' Magnan
Tour of Duty mod
http://www.tourofdutymod.com


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

Re: [hlcoders] Re: ABUSE REPORT

[Pat Magnan]

I guess when I said stop feeding the troll, I didn't mention, unless it's
to the sharks :p.
gg ;).

At 09:22 PM 10/5/2003 -0700, you wrote:
Brian,

Glad i'm not the only one here with a distaste for this blatant abuse.  Good
job.
James

Brian A. Stumm writes:

Sorry forgot to add helpvalve to the list...

On Sun, 5 Oct 2003, Brian A. Stumm wrote:

On Sun, 5 Oct 2003, Brian A. Stumm wrote:

>
>
> This mail is to notify you of illegal activity by your internet
> subscriber. Your customer has admitted repeatedly on
> list.valvesoftware.com to possessing stolen source code from the recent
> break in to valvesoftware.com where in source code to the highly
> anticipated half life 2 source code was stolen by illegal means. I
> encourage you to check your logs to see if a file entitled
hl2_src.rar was
> downloaded by your customer and implore you to report your findings to
> your local authorities, US FBI as well as valvesoftware.com.
>
> Your customer may feel that since this code was obtained through illegal
> manner that HE is permitted to download said code but that doesn't change
> anything. This is copywritted intellectual property that was obtained
> through illegal means. He feels that he has some "educational"
licenese to
> view said source but obtained no such license from the owner of said
> source code, valvesoftware.
>
> I implore you to take action, if you do not then I will take your lack of
> action as support for illegal activities by your customers. And will
> elevate this complaint further.
>
> Thank you for your immediate attention to this matter.
>
> 
> HEADERS:
> 
>
> Return-Path: <[EMAIL PROTECTED]>
> Received: from list.valvesoftware.com (mail.list.valvesoftware.com
> [207.173.176.202])
> by bs-linux.com (8.11.6/linuxconf) with ESMTP id h95JdXF05225
> for <[EMAIL PROTECTED]>; Sun, 5 Oct 2003 12:39:33 -0700
> Received: from localhost ([127.0.0.1] helo=list.valvesoftware.com)
> by list.valvesoftware.com with esmtp (Exim 3.35 #1 (Debian))
> id 1A6Eay-00014I-00; Sun, 05 Oct 2003 12:31:08 -0700
> Received: from [207.44.152.105] (helo=DD1.TheDryDock.Net)
> by list.valvesoftware.com with esmtp (Exim 3.35 #1 (Debian))
> id 1A6EaH-yD-00
> for <[EMAIL PROTECTED]>; Sun, 05 Oct 2003 12:30:25
> -0700
> X-ClientAddr: 80.3.177.6
> Received: from utserver (public1-fare1-3-cust6.cosh.broadband.ntl.com
> [80.3.177.6])
> (authenticated (0 bits))
> by DD1.TheDryDock.Net (8.11.6/8.11.6) with ESMTP id h95JVQN17416
> for <[EMAIL PROTECTED]>; Sun, 5 Oct 2003 14:31:28
> -0500
> Message-ID: <[EMAIL PROTECTED]>
> From: "Manip" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> References: <[EMAIL PROTECTED]>
> <[EMAIL PROTECTED]>
> Subject: Re: [hlcoders] Re: Re: Re: HL2 Source
> MIME-Version: 1.0
> X-Priority: 3
> X-MSMail-Priority: Normal
> X-Mailer: Microsoft Outlook Express 6.00.2800.1158
> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
> X-MailScanner-Information: Please contact the ISP for more information
> X-MailScanner: Found to be clean
> X-MailScanner-SpamCheck: not spam, SpamAssassin (score=0.9, required 8,
> OPPORTUNITY_2 1.26, QUOTED_EMAIL_TEXT -0.48,
> RCVD_IN_OSIRUSOFT_COM 0.55, REFERENCES -0.50)
> content-transfer-encoding: 7bit
> content-type: text/plain;
>  charset=iso-8859-1
> Sender: [EMAIL PROTECTED]
> Errors-To: [EMAIL PROTECTED]
> X-BeenThere: [EMAIL PROTECTED]
> X-Mailman-Version: 2.0.11
> Precedence: bulk
>
> -
> original message:
> -
>
> On Sun, 5 Oct 2003, Manip wrote:
>
> > > http://www.justinrossetti.com/albums/HalfLife2/hl2_death.jpg
> >
> > hahaha. I wouldn't want to work for valve right now either. Worse I
wouldn't
> > want to be the guy that got his
> > account broken into, if it was his fault or not. Just generally not
a good
> > day, and I don't think a few developers
> > talking openly about the source they know we have is going to make
things
> > worse. I'm not planning to develop
> > games with it but I am curious about how they did certain things so the
> > label 'for education use only' kind fits the
> > bill. Most developers that have blood going though their vanes
can't resist
> > information and something like this where
> > you have the unique opportunity to see how the pro's are doing it
is too
> > good to resist. I have nothing against valve and
> > don't plan on making a penny off of their hard work but me looking
over code
> > that is already public doesn't hurt anyone
> > so stop slamming me just because I'm open unlike all of you that
are looking
> > but don't want to talk about it.
> >
> > Please stop going on about IP, I am not selling it, I am not making
money
> > off of it, they can sue me for every penny
> > I have made off the half-life 2 source, duh.


___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoft

Re: [hlcoders] Re: HL2 Source

[Pat Magnan]

Folks, we're being trolled, and manipulated intentionally by someone who's
primary aim is to annoy this list, and make us fall for their little game.
Don't respond to anything they post or say, this person has contributed
nothing about Halflife coding, and I can't find any posts related to
Halflife mod coding, or any in fact before the HL2 source leak threads.
Don't feed this little troll. Just delete their posts, it's really the best
way. Nothing annoys a troll worse than being ignored.
At 12:13 PM 10/5/2003 +0100, you wrote:
Something like what ? I just got sent that so I stuck it on a web-server and
posted the link... freedome of information. It isn't illegal, that doc at
least because it isn't telling anyone to brake the law.. it doesn't provide
download  locations infact other than the title it could be about anything.
- Original Message -
From: "James Couzens" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, October 05, 2003 12:03 PM
Subject: [hlcoders] Re: HL2 Source
> Manip,
>
> What the FUCK is wrong with you?  How ignorant can you possibly be?  Show
> some god damn respect you son of a bitch!  Why would you post something
like
> that in this VALVE list?  You stupid cunt.
>
> James
>
>
> Manip writes:
>
> > http://www.thedrydock.net/adminspace/manip/Compile_Half_Life_2.txt
> > - Original Message -
> > From: "tei" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Sunday, October 05, 2003 10:28 AM
> > Subject: [hlcoders] Re: Re: HL2 Source
> >
> >
> >>
> >> Heee No one compile with warnings level 3?  ...debug mode?
> >> ...asserts?  ...logs?  ...batch tests?  #if 0 #else #endif?
> >>
> >>
> >>
> >> MC> Ha, I love that. You spend hours trying to fix a bug.  You put like
> > 100
> >> MC> lines of debug code before you find a glaring typo!!  You fix the
typo
> >> MC> and the bug is still there.
> >>
> >>
> >> MC> On Sun, 2003-10-05 at 04:44, Daniel Koppes wrote:
> >> >> Oh no, even better, you spend HOURS trying to fix a problem, only to
> >> >> discover it was your previously thought 100% perfect code elsewhere
> > that
> >> >> was causing the problem.
> >> >>
> >> >> At 09:31 5/10/2003, you wrote:
> >> >>
> >> >> >I absotively LOVE IT when that happens!
> >> >> >I also love it when you fix one bug, and find 2 more that were
hidden
> >> >> >BECAUSE of the one you fixed, and it ends up becoming a really
really
> >> >> >really long day trying to fix it :X!
> >> >> >
> >> >> >
> >> >> >-omega
> >> >> >http://www.frontline2.com
> >> >> >
> >> >> >
> >> >> >-Original Message-
> >> >> >From: [EMAIL PROTECTED]
> >> >> >[mailto:[EMAIL PROTECTED] On Behalf Of botman
> >> >> >Sent: October 4, 2003 3:17 PM
> >> >> >To: [EMAIL PROTECTED]
> >> >> >Subject: Re: [hlcoders] Re: HL2 Source
> >> >> >
> >> >> >Okay, I'm bored.  I've just rebuilt my code for the 83rd billionth
> > time
> >> >> >today and I everytime I fix a bug I seem to add 2 more.  I guess
it's
> >> >> >time
> >> >> >to go out and get completely WASTED and try again tomorrow!  :)
> >> >> >
> >> >> >Jeffrey "botman" Broome
> >> >> >
> >>
> >>
> >> ___
> >> To unsubscribe, edit your list preferences, or view the list archives,
> > please visit:
> >> http://list.valvesoftware.com/mailman/listinfo/hlcoders
> >>
> >
> >
> > ___
> > To unsubscribe, edit your list preferences, or view the list archives,
please visit:
> > http://list.valvesoftware.com/mailman/listinfo/hlcoders
> >
>
>
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders


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

Re: [hlcoders] Re: HL2 Source Leaked

[Pat Magnan]

Please think about this firstly, you're posting to a list owned and
operated by Valve... you're then suggesting that a bunch of 1337 h4x0rs can
somehow do a better job than they did with the dedicated server, as if
they're a bunch of amateurs..
I'm sorry, but you're being rude and displaying an utter lack of
consideration.. you were also warned politely about it.


At 04:55 PM 10/3/2003 +0100, you wrote:
How does making a dedicated server for valves software help valves down-fall
? I don't have the source but I would like to have it. All I am saying is in
certain area's of development this can be helpful to both half-life 2 (it
will have a kick-ass dedicated server, even if it is unofficial) and to all
the half-life admin's and players cause less lag etc :)
- Original Message -
From: "Stan Bubrouski" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, October 03, 2003 4:22 PM
Subject: Re: [hlcoders] Re: HL2 Source Leaked
> Manip wrote:
> > This is a multi-part message in MIME format.
> > --
> > [ Picked text/plain from multipart/alternative ]
> > I do feel sorry for valve and I can't even imagine what is going on in
the company right now. But from a development point of view I really hope
the HLDS source has been leaked, it will give us the opportunity to develop
the type of server we have always wanted but never had. It will allow us to
link into something better than Vac and to improve the half-life experience.
> > --
> >
>
> No it won't.  That source is stolen property of Valve
> Software L.L.C. and if you distribute it or modify
> and distribute it you are contributing to the downfall
> of Valve and of HL2.  And more than likely you will
> face civil and legal charges.  To clarify it is not
> ok to have the HL2 source at all, and frankly posting
> about having it is a bad idea.
>
> -sb
>
> >
> > ___
> > 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: [hlcoders] HL2 Source Leaked

[Pat Magnan]

I agree.. kinda like biting the hand that feeds you isn't it??

At 05:04 PM 10/2/2003 -0500, you wrote:
> Yes.  With a little setup, everything compiles.
>
> > On a side note... anyone know if the new Worldcraft can be compiled from
the leaked code?
> >
Wow.  C'mon guys, I know it's hard not to talk about HL2 source code issues
here, but give Valve a break.  It's bad enough people spreading the word
about how to build the HL2, TF2, CS2, etc. code from the leaked source, but
do you HAVE to do it on a list that's owned and operated BY VALVE???  Talk
about adding insult to injury!  :(
I would politely request that people on this list refrain from giving out
information to help other people gain from Valve's loss.  Have a heart guys.
Stop spreading this around any more than it already is.  I know it's like
trying to put the genie back in the bottle after you've let him out, but do
you have to do it on THIS e-mail list?
Just my $0.02 worth.

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

[hlcoders] Re: Re: [holdovers] HL2 Source Leaked

[Pat Magnan]

Therein lies the rub of 'telecommuting' and being able to work easily
sometimes. I know I've been in environments where the only option was to
turn off the 'real time' virus protection, because some products on the
market trigger while compiling (a lot of file access and it would check
each one), slowing the machines down beyond workability -- in our case our
800 MHz machines compiled code slower than 200 MHz machines are capable of.
Or other environments on the other end, where the programmers couldn't work
because they didn't have sufficient access on their machines to debug
processes they didn't start (really that was a misconfiguration I now know,
but most Windows programmers have been taught they need to be admin on the
local machine to work - that's not true but you do need some elevated
rights in some cases).
All of us know source code control is vital, and we back it up, but how
often do we consider how easy it would be to compromise from the outside?
What a crappy thing to have happened.. while I'd be less concerned about
serious competitors using the information (too easy to prove and end up
losing at court over), it's more disconcerting to see what use idiot script
kiddies and cheat 'h4x0rs' make of the information.. sigh.
At 05:35 PM 10/2/2003 -0500, you wrote:
> "1) Starting around 9/11 of this year, someone other than me was accessing
> my
> email account. This has been determined by looking at traffic on our email
> server versus my travel schedule."
>
> Im lost... Why did he not change his password?
Because hindsight is 20/20.  I would bet that Gabe only recently (today)
discovered that someone was using his e-mail account, otherwise he surely
would have changed his password and/or disabled his e-mail account until
things could be investigated further.
It's so commonplace today for people to expect their Windows computers to do
strange things and usually the first thought is "I have a virus".  Run a
virus scanner and if it doesn't detect anything, then your machine must not
be infected, right?  After all, how could you get a virus that no
body else knows about?
I'm sure with all the flurry of activity in the last couple of months for
Valve, and Gabe being on the road so much, that nobody really thought twice
about spending the time to throughly investigate why Gabe's computer was
acting weird.  Even worse, I would bet that the virus spread itself to other
machines, so that even if Gabe did reformat his machine and get it clean
again, as soon as he accessed one of the infected machines, it was back on
his machine again.  Sometimes those little buggers are REAL hard to get rid
of, especially in a corporate network environment.
I feel for the Valve guys and I know how difficult it can be to create
secure networks yet still allow internal people to access the external
resources that they need on a day-to-day basis.  Being a network
administrator is not an easy job and there's probably not much the network
admins could have done in this case anyway.
Perhaps Valve will restructure their internal network so that the "family
jewels" never sit on a machine that has any kind of external Internet
access.  It makes development tasks more of a pain, but in does help to
prevent security breaches.
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

[hlcoders] Problem testing HLDS Linux (yes it's mod coding related)

[Pat Magnan]

This is something I've been having difficulties with testing our Linux
dedicated server.
Anyway, I found this post on the STEAM forums:
http://steampowered.com/forums/showthread.php?s=9ba59de2554893f6d30c4bdbb783353c&threadid=19577
And it is the sort of problem I am having. I am wondering if this is
something we all see?
I have been constantly told that my USER ID ticket is invalid when I
connect to my HLDS/Linux server, yet the HLDS/Win32 servers I have in the
UK are working fine (sadly my host switched to Win32 only a while back).
I've connected with the released version of the mod to other steam servers,
that works fine, including one I know on Linux, but if we can't run a Linux
box on our local networks, that's going to make testing for third party mod
developers rather painful.
I believe the problem is that the client connects with a 192.168.x.x IP
address to the server, but it connected to the STEAM network with the
external IP..
Is there a solution for this? I haven't seen anything on hlds_linux that
states whether there is a solution for this yet.
Pat 'sluggo' Magnan
Tour of Duty mod
http://www.tourofdutymod.com


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

Re: [hlcoders] Another Steam bug

[Pat Magnan]

Sounds like a good post for the Steam support forums. This is a Halflife
Coders mailing list, not steam support.
Sorry to sound rude, but that's the facts, jack ;).

At 09:00 AM 9/26/2003 -0700, you wrote:
I have tried other forums but ave not had any luck in getting answers to
this problem yet, so here goes:
I have a rather basic system - Win2K, PIII 650, 192M Ram, 64MB video card,
and cable modem.
When steam is sitting idle, my CPU utilization is near 0, but I can't load
any programs or applications because the system is grinding my HD.
When loading CS through Steam, my committed Memory usage (in task manager)
goes from 90MB to well over 250MB, and sometimes peaks at over 300MB and
my Hard drive light stays lite constantly. When enterring a game, it tries
to load and verify server variable and times out consistantly but
occasionally actually loads the game. Forget loading DOD!!!
What are the system requirements (Steampoered.com has some listed, but
they can't be accurate)? Is there a memory leak of some sort? I installed
the full (750M) file and trying to access servers running standard maps
with low pings. I am not trying to do anything unusual, yet.
Any ideas? Do you need more info? Has anyone else seen this? Hey Valve,
what's up?
___
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] TriAPI fog missing under steam?

[Pat Magnan]

Hmm, that is interesting (didn't know it was a toggle), because we are
calling it multiple times then (every time TransTriangles is called).
Doesn't it start at a point 'near' the player and extend out to the end
distance in all directions? Wouldn't that have to update each frame as the
view origin moves through space? Well, I know you generally know what
you're talking about so perhaps that does make sense ;).
However, this was originally done in the same way DMC does fog (it's DMC
fog code, with some checks for if you're in a spectator inset and drawing a
map overview, etc added -- removing them is no help so no it's not them).
DMC calls it the exactly same way I am, does it work there? The levels I
tried under steam don't seem to have fog... in fact:
http://sluggo.org/upload/p_se_3.jpg
Doesn't have fog, yet if there's not supposed to be fog in this view, I'll
eat my hat... :p That's a shot of DMC running under steam (change the
extension to .bmp and get the original SS if you'd like).
I also took the fog code and put it into a clean SDK, and tried it, still
no fog... It still works just fine in standalone halflife with the same
code which is sort of disconcerting.
If anyone has it working with steam, I'd love to hear what I'm doing wrong,
and perhaps what DMC does wrong as well. I'll try your suggestion of only
calling it once (some sort of flag to toggle it once) omega, see what that
leads to..
At 09:45 PM 9/22/2003 -0400, you wrote:
I don't know if this has anything to do with it, but the only difference
between tri-api called fog, and direct opengl calls is that triapi is a
TOGGLE, don't call it multiple times, only when you turn it on or off;
but from within DrawTransTriangles.
-omega
http://www.frontline2.com
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Pat Magnan
Sent: September 22, 2003 9:27 PM
To: [EMAIL PROTECTED]
Subject: Re: [hlcoders] TriAPI fog missing under steam?


At 06:24 PM 9/22/2003 -0500, you wrote:
>Perhaps it's WHERE you are calling the TriAPI Fog function.  Where is
this
>call taking place in your client code (i.e. within what function)?
Could be, I call it from a function called by
HUD_DrawTransparentTriangles() just like several other things that are
still working.. very odd.
I'm going to try stripping out any check that could be causing a problem
for kicks, even though the one bool that says to draw fog or not is
always
1 when i print it just before calling the fog function.
I guess trying it in a plain old SDK alone would be instructive as well.

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


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


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


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

RE: [hlcoders] steamapp.cfg

[Pat Magnan]

I see the problem too when we use anything in the PAK0.PAK file (we had
some unused junk in our hud.txt referenced that I had to clean up).
When running from the debugger only that is, it worked fine copying the
directory to the steam directories and running it.
Are we all setting the path wrong such that hl.exe can't find the stuff in
the pak0.pak? or, do we need to copy that to the valve directory under
steam for it to work perhaps?
At 05:02 PM 9/22/2003 -0700, you wrote:
Can you try this without the "-game" command (that I assume you are using
to run your mod), and just see if you can launch HL in the debugger?
Also to make sure, you've set the debugger to use the HL dir as the
working directory?
Taylor

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Monday, September 22, 2003 4:16 PM
To: [EMAIL PROTECTED]
Subject: RE: [hlcoders] steamapp.cfg


Yeah I just figured that when it missed all of my break points.  Well i can
not
be the only one with this problem. If i add -steam, then i get about 234983
errors starting with Can not find gfx.wad and ending with the last file in
the
valve pak0 file. then after those errors, I get a number of illegal
operations
followed by some other shit.
this is what did

steam.dll into ...email/half-life/
created steamapp.cfg and placed it into ...email/half-life/
here is my config

SteamAppId=70
SteamAppVersionId=0
SteamInstallPath=c:\steam
SteamAppUser=my_steam_name
then i set up VS6.0 to copy the dll into the correct folder(this is
irrelavate
for debugging), then i linked to the correct dll under in the debug tab as
well
as set up all the correct paths for debugging
It will execute my mod fine WITHOUT the -steam
but as soon as i put it in there, well yeah... you know the rest.
I have looked over his instructions at least 6 times and I have checked them
all off. I can assure anyone they are done correctly.
Quoting Pat Magnan <[EMAIL PROTECTED]>:

> Yes, Alfred's instructions work perfectly, including the -steam. You
> won't
> be able to debug otherwise ( i forgot it first go around and nothing
> stopped at a breakpoint.. had to re-read to get that bit).
>
> At 03:39 PM 9/22/2003 -0700, you wrote:
> >You should need "-steam" in the command-line arguments for the debug
> >sequence
> >listed in Alfred's email to work.
> >
> >If you don't use "-steam", the game will launch but not inside your
> >debugger.
> >
> >Taylor
> >
> >-Original Message-
> >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> >Sent: Monday, September 22, 2003 3:25 PM
> >To: [EMAIL PROTECTED]
> >Subject: RE: [hlcoders] steamapp.cfg
> >
> >
> >
> >I found the problem, i had "-steam" in the command arguments inside
> VS6, i
> >thought it was supposed to be there, then i realized, hl.exe worked
> directly
> >with no -steam so i omitted it and it worked. Someone said to put it
> there,
> >i
> >don't know why really, perhaps i was confusing two different methods
> of
> >execution.
> >
> >
> >Quoting Taylor Sherman <[EMAIL PROTECTED]>:
> >
> > > You need to copy Steam.dll into the HL dir as well.
> > >
> > > SteamInstallPath should not include "\Steam.exe" - just the
> directory.
> > >
> > > Steam should be running when you do this.
> > >
> > > Hope that does the trick.
> > >
> > > Taylor
> > >
> > > -Original Message-
> > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> > > Sent: Sunday, September 21, 2003 7:12 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: [hlcoders] steamapp.cfg
> > >
> > >
> > >
> > > I followed directions and steam will not work
> > >
> > > "steamstartup failed with error 108: the local steam server is not
> > > running."
> > >
> > > I get that error any time i try to play a game with or without the
> > > debugger
> > > after i copy my steamapp.cfg into the half-life/ dir
> > >
> > > my steamapp.cfg looks like this
> > >
> > >
> > > SteamAppId=70
> > > SteamAppVersionId=0
> > > SteamInstallPath= c:\progra~1\Steam\Steam.exe
> > > SteamAppUser=myname
> > >
> > >
> > > sigh...
> > >
> > >
> > >
> > > ___
> > > To unsubscribe, edit your list preferences, or view the list
> archives,
> > > please visit:
> > > http://list.valvesoftware.com/mailman/listinfo/hlcoders
> > >
> > > 

Re: [hlcoders] TriAPI fog missing under steam?

[Pat Magnan]

At 06:24 PM 9/22/2003 -0500, you wrote:
Perhaps it's WHERE you are calling the TriAPI Fog function.  Where is this
call taking place in your client code (i.e. within what function)?
Could be, I call it from a function called by
HUD_DrawTransparentTriangles() just like several other things that are
still working.. very odd.
I'm going to try stripping out any check that could be causing a problem
for kicks, even though the one bool that says to draw fog or not is always
1 when i print it just before calling the fog function.
I guess trying it in a plain old SDK alone would be instructive as well.

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] steamapp.cfg

[Pat Magnan]

Yes, Alfred's instructions work perfectly, including the -steam. You won't
be able to debug otherwise ( i forgot it first go around and nothing
stopped at a breakpoint.. had to re-read to get that bit).
At 03:39 PM 9/22/2003 -0700, you wrote:
You should need "-steam" in the command-line arguments for the debug
sequence
listed in Alfred's email to work.
If you don't use "-steam", the game will launch but not inside your
debugger.
Taylor

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Monday, September 22, 2003 3:25 PM
To: [EMAIL PROTECTED]
Subject: RE: [hlcoders] steamapp.cfg


I found the problem, i had "-steam" in the command arguments inside VS6, i
thought it was supposed to be there, then i realized, hl.exe worked directly
with no -steam so i omitted it and it worked. Someone said to put it there,
i
don't know why really, perhaps i was confusing two different methods of
execution.
Quoting Taylor Sherman <[EMAIL PROTECTED]>:

> You need to copy Steam.dll into the HL dir as well.
>
> SteamInstallPath should not include "\Steam.exe" - just the directory.
>
> Steam should be running when you do this.
>
> Hope that does the trick.
>
> Taylor
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Sunday, September 21, 2003 7:12 PM
> To: [EMAIL PROTECTED]
> Subject: [hlcoders] steamapp.cfg
>
>
>
> I followed directions and steam will not work
>
> "steamstartup failed with error 108: the local steam server is not
> running."
>
> I get that error any time i try to play a game with or without the
> debugger
> after i copy my steamapp.cfg into the half-life/ dir
>
> my steamapp.cfg looks like this
>
>
> SteamAppId=70
> SteamAppVersionId=0
> SteamInstallPath= c:\progra~1\Steam\Steam.exe
> SteamAppUser=myname
>
>
> sigh...
>
>
>
> ___
> 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] TriAPI fog missing under steam?

[Pat Magnan]

I'm in open GL mode, our mod will kick you otherwise (because we had fog to
allow mappers to make bigger spaces and hide the rendering artifacts you
get if there's no fog blurring distant objects in HL) ;).
I just used opengl functions directly to render similar fog and it works
just fine. I still get no TriAPI fog under steam, and I can't figure out why.
Same build of my mod in regular halflife worked fine -- that is, I took
what was using TriAPI fog and rendering it, copied it to steam folders and
it produces no TriAPI fog, and yes i'm in OpenGL mode in both cases.
I suppose if it works for you Tony, then something else we're doing broke
the fog under steamHL, but we can just use the OpenGL stuff I suppose, it's
pretty much the same thing.
At 02:39 PM 9/22/2003 -0700, you wrote:
to follow up on Tony's email, fog will only work under OpenGL.

Tony "omega" Sergi wrote:
> Is it possible you could somehow not be in opengl mode? (I've not
> checked to see if fog works for me or not via tri-api, I shall do that
> and let you know my results when I finish what I'm working on at the
> moment)
>
>
> -omega
> http://www.frontline2.com
>
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Pat Magnan
> Sent: September 22, 2003 5:08 PM
> To: [EMAIL PROTECTED]
> Subject: [hlcoders] TriAPI fog missing under steam?
>
> I had to get things setup to debug under steam, to step through my
> code (I
> do a bunch of checks to see if I should render fog or not (i.e. are
> we in the spectator inset window in a map overview, etc), but all the
> checks work like they did before, but for whatever reason:
>
> gEngfuncs.pTriAPI->Fog ( g_iFogColor, g_iStartDist, g_iEndDist, bFog
> );
>
> Doesn't produce fog (bFog is true when debugging the code in
> question). Anyone else seeing this issue?
>
> It's possible it's timing too.. first pass through the above code my
> checks could be good, but later not so I'm going to get it to spew
> the values out now and see if  it's just on my end.
>
>
> Pat 'sluggo' Magnan
> Tour of Duty mod
> http://www.tourofdutymod.com
>
>
>
> ___
> To unsubscribe, edit your list preferences, or view the list
> archives, please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>
>
>
> ___
> To unsubscribe, edit your list preferences, or view the list
> archives, please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
___
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] TriAPI fog missing under steam?

[Pat Magnan]

I had to get things setup to debug under steam, to step through my code (I
do a bunch of checks to see if I should render fog or not (i.e. are we in
the spectator inset window in a map overview, etc), but all the checks work
like they did before, but for whatever reason:
gEngfuncs.pTriAPI->Fog ( g_iFogColor, g_iStartDist, g_iEndDist, bFog );

Doesn't produce fog (bFog is true when debugging the code in question).
Anyone else seeing this issue?
It's possible it's timing too.. first pass through the above code my checks
could be good, but later not so I'm going to get it to spew the values out
now and see if  it's just on my end.
Pat 'sluggo' Magnan
Tour of Duty mod
http://www.tourofdutymod.com


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

RE: [hlcoders] HWND of console? (steam bug?)

[Pat Magnan]

It's very much changed since Halflife with steam, as to whether it's a VGUI
window perhaps you're correct that it isn't, it has a title bar now, and
floats inside the Halflife window..
Anyhow, since condump doesn't work correctly in steam (it creates the
condump files, and claims to have dumped it's contents to them, but they're
all empty .txt files), I assumed that's what the original poster meant ;).
Just checked in a hex editor (trying to see why they weren't 0 byte files),
it appears to have written a whole pile of 0x20 (space) characters but
precious little else, with some 0x0D 0x0A's thrown in for good measure.
Guessing that's a bug, or a known issue that's being worked on ;).

At 02:44 AM 9/19/2003 -0500, you wrote:
I wouldn't think that the console would be a VGUI type window, VGUI
wasn't released until like, HL 1.1.0.8 or something around there. The
console has been in HL forever, and hasn't changed (that I've noticed).
I'd go with omega's first suggestion that's it a buffer of strings
rendered to the screen when needed.
-Cale

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tony "omega"
Sergi
Sent: Thursday, September 18, 2003 11:27 PM
To: [EMAIL PROTECTED]
Subject: RE: [hlcoders] HWND of console?
;)

We can use that term from this point forward whenever someone does that
;)
I wanted to reply again but then I was like .. no.. come on, someone
else post.. I don't want to have 4 emails from me on the same subject in
a row!
"I pulled an 'omega' and spammed hlcoders inadvertently!"

-omega
http://www.frontline2.com
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Pat Magnan
Sent: September 19, 2003 12:15 AM
To: [EMAIL PROTECTED]
Subject: Re: [hlcoders] HWND of console?
Err, pulling an 'omega' here :p.

The other VGUI Surfaces do in fact have HWND's like friends, servers,
etc,
so it's possible the console does have one.. maybe.
You can't enumerate child windows of the mod window, because it seems to
have none, in fact all the VGUI Surfaces I see are not 'parented' by
anything in Spy++'s view at least.
You could try looking for all of the 'Surface' Windows with
FindWindow();
instead, but I'm not sure how simple it is to get the text of every
'Surface' that has "" for a window name parameter...
Sounds kind of dodgy to me anyhow.

At 11:53 PM 9/18/2003 -0400, you wrote:
>Could be a VGUI surface.. kinda looks like it is, but the 'title'
doesn't
>show up using SPY++. I can see all the other windows, mind you, lots of
>things were running, maybe I missed it.
>
>condump is autocompleted, and dumps a file out, but seems to not write
any
>text, maybe this is just a bug in steam at this point?
>
>I'm assuming you don't mean just highlight it all and copy ? That seems
to
>work ok, if you're just looking at some sort of console output now and
>again anyhow ;).
>
>At 04:29 AM 9/19/2003 +0100, you wrote:
>>I'd be VERY surprised if the console window was a windows window, its
>>probably just a buffer of strings which gets rendered to the screen
when
>>needs be and thats it
>>
>>- Original Message -
>>From: "Jupiter" <[EMAIL PROTECTED]>
>>To: <[EMAIL PROTECTED]>
>>Sent: Friday, September 19, 2003 3:53 AM
>>Subject: [hlcoders] HWND of console?
>>
>>
>> > Since the condump command no longer works (grr), I am attempting to
use
>> > API functions to get the text out of the console window and then
>> > save/copy it elsewhere.  The only problem is that I cannot
determine the
>> > HWND of the console window.   I tried the only way I know how --
using
>> > FindWindowEx() and following the child windows looking for
something
>> > that could be the console -- but no dice.
>> >
>> > Anyone have any insights they could share?
>> >
>> > --
>> > jupe
>> >
>> > How to ask smart questions:
>> > http://www.catb.org/~esr/faqs/smart-questions.html
>> >
>> >
>> > ___
>> > To unsubscribe, edit your list preferences, or view the list
archives,
>>please visit:
>> > http://list.valvesoftware.com/mailman/listinfo/hlcoders
>> >
>>
>>
>>___
>>To unsubscribe, edit your list preferences, or view the list archives,
>>please visit:
>>http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>Pat 'sluggo' Magnan
>Tour of Duty mod
>h

Re: [hlcoders] HWND of console?

[Pat Magnan]

Err, pulling an 'omega' here :p.

The other VGUI Surfaces do in fact have HWND's like friends, servers, etc,
so it's possible the console does have one.. maybe.
You can't enumerate child windows of the mod window, because it seems to
have none, in fact all the VGUI Surfaces I see are not 'parented' by
anything in Spy++'s view at least.
You could try looking for all of the 'Surface' Windows with FindWindow();
instead, but I'm not sure how simple it is to get the text of every
'Surface' that has "" for a window name parameter...
Sounds kind of dodgy to me anyhow.

At 11:53 PM 9/18/2003 -0400, you wrote:
Could be a VGUI surface.. kinda looks like it is, but the 'title' doesn't
show up using SPY++. I can see all the other windows, mind you, lots of
things were running, maybe I missed it.
condump is autocompleted, and dumps a file out, but seems to not write any
text, maybe this is just a bug in steam at this point?
I'm assuming you don't mean just highlight it all and copy ? That seems to
work ok, if you're just looking at some sort of console output now and
again anyhow ;).
At 04:29 AM 9/19/2003 +0100, you wrote:
I'd be VERY surprised if the console window was a windows window, its
probably just a buffer of strings which gets rendered to the screen when
needs be and thats it
- Original Message -
From: "Jupiter" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, September 19, 2003 3:53 AM
Subject: [hlcoders] HWND of console?
> Since the condump command no longer works (grr), I am attempting to use
> API functions to get the text out of the console window and then
> save/copy it elsewhere.  The only problem is that I cannot determine the
> HWND of the console window.   I tried the only way I know how -- using
> FindWindowEx() and following the child windows looking for something
> that could be the console -- but no dice.
>
> Anyone have any insights they could share?
>
> --
> jupe
>
> How to ask smart questions:
> http://www.catb.org/~esr/faqs/smart-questions.html
>
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
Pat 'sluggo' Magnan
Tour of Duty mod
http://www.tourofdutymod.com


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


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

Re: [hlcoders] HWND of console?

[Pat Magnan]

Could be a VGUI surface.. kinda looks like it is, but the 'title' doesn't
show up using SPY++. I can see all the other windows, mind you, lots of
things were running, maybe I missed it.
condump is autocompleted, and dumps a file out, but seems to not write any
text, maybe this is just a bug in steam at this point?
I'm assuming you don't mean just highlight it all and copy ? That seems to
work ok, if you're just looking at some sort of console output now and
again anyhow ;).
At 04:29 AM 9/19/2003 +0100, you wrote:
I'd be VERY surprised if the console window was a windows window, its
probably just a buffer of strings which gets rendered to the screen when
needs be and thats it
- Original Message -
From: "Jupiter" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, September 19, 2003 3:53 AM
Subject: [hlcoders] HWND of console?
> Since the condump command no longer works (grr), I am attempting to use
> API functions to get the text out of the console window and then
> save/copy it elsewhere.  The only problem is that I cannot determine the
> HWND of the console window.   I tried the only way I know how -- using
> FindWindowEx() and following the child windows looking for something
> that could be the console -- but no dice.
>
> Anyone have any insights they could share?
>
> --
> jupe
>
> How to ask smart questions:
> http://www.catb.org/~esr/faqs/smart-questions.html
>
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
Pat 'sluggo' Magnan
Tour of Duty mod
http://www.tourofdutymod.com


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

Re: [hlcoders] Won being retired -- how do we test non-valve mods?

[Pat Magnan]

Well no one is going to fix mods that didn't work already. There are 1000's
of mods listed, but not near that many that are in active development, or
are even publicly available.
I think by resolve issues, Alfred meant work out any issues that are due to
the mod that used to work not working on steam, if the issue is due to steam.
While I had some issues authenticating, beyond that an already working
Halflife mod should work on steam.. in theory. They just need to be sure
that's true (I think it should be, unless there's some problem or strange
workaround in the mod code it should run just fine).
What I'd really like to see resolved is the authentication issues:
User's ticket has expired
Failed to get valid content ticket
Timeouts and connection resets. - the Internet does this itself sometimes,
so we can't blame anyone totally :p.
Just trying to update 4 servers is taking a lot of my time, once it works
it's beautiful, I just can't seem to stay authenticated to do a whole
update, or manage to auth reliably when i try. I'm sure these issues are
being worked on, because like the last CS release, the system was showing
strain the first few days then worked flawlessly, I think it's just
capacity related, and it seems that's being beefed up constantly.


At 06:10 PM 9/16/2003 +0200, you wrote:


>> Can you give more details on the exact error message?
>>
>> WON will not be retired until we have resolved all the important
>> issues
>> with
>> 3rd party mods (i.e running and debugging them).
Hehehe... all?

I know a site that list 400 mods
http://mods.moddb.com/?mf=t&mf_gme=1&start=400
maybe half-life have more than 1000/2000 mods actually.

And suppose you fix 2320 mods. You will be stremly bored!

 - - -

G> Details on the auth protocol would be sufficient. Releasing the source
G> to won may have Copyright/DMCA/ issues
G> even if Valve were inclined to do so.
Maybe its not needed the won stuff, but the engine code itself *minus*
the won stuff. If you give me the HL engine source to the community as
GPL, these people will add:
 - a new sexy particle system (like Telejano)
 - bumpmaping (like Tenebreae)
 - per-vertex lighting (?)
 - terrain support
 - mvd demos, loc files, capture_avi, ... (zquake)
 - retexturing as 24b PNG + 24b luma
 - support for more than 10.000 entitys
 - support for better network
 - big maps
 - more sensitive control
 - a good model format to add ODE phisics
 - mix Quake2 and Half-Life clients
 - md3 model support
 - Quake2 maps support
Dream on!... half-life with doom3 lighting + terrain support + a sexy
particle engine for free!...
Give a broken toy to the community, and will return as a Ferrari.

Darkplaces
http://www.icculus.org/twilight/darkplaces/screenshots.html
Tenebrae
http://www.willihammes.com/tenebrae/tb-base_07.jpg
FTE
http://www.qexpo.com/booths.php?id=3
Telejano
http://telejano.berlios.de/wiki3/index.php/Screenshots%20v6.3
Others
http://wiki.quakesrc.org/index.php/The%20best%20of%202003%20Screenshots,%20by%20Tei
I dont want the "won" stuff, and will be dead stuff.. Ok? ... remove
all about "won" and release a older version.
___
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] Won being retired -- how do we test non-valve mods ?

[Pat Magnan]

Ok, now I feel foolish, but this was only the case for the last 36 hours or
something... it now appears to be working just fine. Sigh sorry, was up
trying this all night until 6 am, so I spoke too soon.
I can't recall precisely it is something like Invalid steam (player?) ID
ticket, in both the client and the server.. only after a client connected.
One useful question perhaps may be (i.e. for others as well), is it valid
to use the same account on your PC (client) and a dedicated server? Steam
would have a lot of accounts just for dedicated servers otherwise, but do
you detect/police multiple concurrent logins?
At 10:36 AM 9/15/2003 -0700, you wrote:
Can you give more details on the exact error message?

WON will not be retired until we have resolved all the important issues with
3rd party mods (i.e running and debugging them).
Pat Magnan wrote:
> I seem to be unable to run our mod's dedicated server and connect to
> it, it runs up, did all the update to steam, etc finally correctly.
> Whenever a player connects, I'm getting Invalid Steam ID ticket. It
> works on the same server if the game is 'valve', but not our mod.
>
> I initially created a new account for the server, and I've also tried
> using my steam client account as well.
>
> The only information I'm getting on the steampowered forums is that
> 'the system is overloaded right now'.
>
> Anyone else succeeding in this endeavor?. Hmm apologies if this is
> more appropriate for hlds list..
>
>
> Pat 'sluggo' Magnan
> Tour of Duty mod
> http://www.tourofdutymod.com
>
>
>
> ___
> To unsubscribe, edit your list preferences, or view the list
> archives, please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders


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

[hlcoders] Won being retired -- how do we test non-valve mods?

[Pat Magnan]

I seem to be unable to run our mod's dedicated server and connect to it, it
runs up, did all the update to steam, etc finally correctly. Whenever a
player connects, I'm getting Invalid Steam ID ticket. It works on the same
server if the game is 'valve', but not our mod.
I initially created a new account for the server, and I've also tried using
my steam client account as well.
The only information I'm getting on the steampowered forums is that 'the
system is overloaded right now'.
Anyone else succeeding in this endeavor?. Hmm apologies if this is more
appropriate for hlds list..
Pat 'sluggo' Magnan
Tour of Duty mod
http://www.tourofdutymod.com


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

Re: [hlcoders] Steam port collision.

[Pat Magnan]

Most videoboards deal poorly with two 3D apps running anyhow.. I'm not sure
I see this as an issue
At 04:17 AM 9/13/2003 +0200, you wrote:

"If you play half-life you need steam to authenticate yourself.

Apparently Steam uses the same port that QuakeWorld clients use (UDP 27001) .
This means you can't run both at the same time."
Read more here:
http://www.fuhquake.net/forum/viewtopic.php?t=1706
Seems like Valve is triing to cybersquatter the port 27001 :D

___
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] clientside weapon prediction

[Pat Magnan]

I was wrong.. it calls it several times if you're on a network game ;). So
i see your problem as well.
At 10:13 PM 9/11/2003 -0400, you wrote:
I don't think this is reproducible in a clean SDK when I did it (had to
keep setting the silly cl_lw cvar on for some reason, until it decided to
'stick'  -- third time's the charm.. ;)).
But, that line prints exactly once per primary attack. I made the
absolutely most minimal mod possible (dlls, liblist, 2 maps and that's it).
Didn't test over the network, just a lan game. Maybe that makes a difference?
At 02:44 AM 9/12/2003 +0200, you wrote:
hi,

when trying to do some advanced weapon coding i discovered a strange
behavior of the client weapon prediction.
I'm using a counter in PrimaryAttack(). On the server everything works
perfectly, but on client the counter is almost always wrong.
Now here's the problem: PrimaryAttack() gets called MANY times on client
when its just called once on the server.
m_flNextPrimaryAttack is set in PrimaryAttack(), but on next frame it
seems to be gone, m_flNextPrimaryAttack is still <0, and PrimaryAttack()
gets called again! That changes not until a few frames later (maybe when
the next server packet arrive?)
I reproduced this what i think is a bug with an clean version of SDK2.3.

Add this to hl_weapons.cpp before calling into PrimaryAttack():
gEngfuncs.Con_Printf("attack: %f\n", gEngfuncs.GetClientTime());
Take a pistol and fire once. You see many calls into PrimaryAttack().
Maybe there's something wrong with my HL? Can someone plz try to
reproduce this? If this is indeed a bug, it's very bad: it makes the
random_seed useless.
Rockefeller

___
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] clientside weapon prediction

[Pat Magnan]

I don't think this is reproducible in a clean SDK when I did it (had to
keep setting the silly cl_lw cvar on for some reason, until it decided to
'stick'  -- third time's the charm.. ;)).
But, that line prints exactly once per primary attack. I made the
absolutely most minimal mod possible (dlls, liblist, 2 maps and that's it).
Didn't test over the network, just a lan game. Maybe that makes a difference?
At 02:44 AM 9/12/2003 +0200, you wrote:
hi,

when trying to do some advanced weapon coding i discovered a strange
behavior of the client weapon prediction.
I'm using a counter in PrimaryAttack(). On the server everything works
perfectly, but on client the counter is almost always wrong.
Now here's the problem: PrimaryAttack() gets called MANY times on client
when its just called once on the server.
m_flNextPrimaryAttack is set in PrimaryAttack(), but on next frame it
seems to be gone, m_flNextPrimaryAttack is still <0, and PrimaryAttack()
gets called again! That changes not until a few frames later (maybe when
the next server packet arrive?)
I reproduced this what i think is a bug with an clean version of SDK2.3.

Add this to hl_weapons.cpp before calling into PrimaryAttack():
gEngfuncs.Con_Printf("attack: %f\n", gEngfuncs.GetClientTime());
Take a pistol and fire once. You see many calls into PrimaryAttack().
Maybe there's something wrong with my HL? Can someone plz try to
reproduce this? If this is indeed a bug, it's very bad: it makes the
random_seed useless.
Rockefeller

___
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] Visual Studio .net Question restated

[Pat Magnan]

Quake II includes the Engine source, are you sure you can mix and match
managed C++ with non-managed C++ code (the hl.exe, sw.dll, hw.dll and many
many other files we don't have source to in halflife).
Don't forget we have only source to the server and client dll's here, so
I'm not sure that you can just port those to be managed C++ code and have
it work at all.
Since the .NET runtime causes a market increase in runtime for applications
I've written with such 'managed' code, I wonder about the performance, but
that's just at startup I guess (dont' forget the .NET runtime is several MB
large, and is not loaded into memory continuously on many platforms). I
wrote a notepad like program in C#, it takes a minute or more to start up
if it hasn't run recently (the runtime hangs around it seems for a bit).
Oh, and you can't display a splash screen, because your runtime environment
isn't in existence... it's a lot like Java to me the whole thing.
On platforms with it built in, maybe it will be better (like windows server
2003 or whatever).
Sorry, strayed off topic a bit. The answer seems to be no one has done it
yet, and without knowing that you can run and call properly managed code
from unmanaged.. I'm not sure it's a good idea. (The engine expects exports
like you'd get from C code __cdecl extern "C" yadda yadda), not sure if HL
could even find the functions it needs if it were ported.
At 04:22 PM 9/4/2003 -1000, you wrote:
I just read over my question and the responeses I got back, and realized I
could have added more information. 8)
I an not sure how I found it, but Quake II was ported over to .net code, and
there is a White Paper that talks about it.
In the paper it talked about portint the code to a Managed C++ project and
all the benifits, with only a slight performance loss.  The information in
the paper is too large for me to relay, but it does talk about some good
stuff.
So this is what I had meant to ask about.

Starbreaker



___
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] Linux: Undefined object PM_Move

[Pat Magnan]

e/bits/string2.h:454: `__src4_4' undeclared (first use in
this functi
on)
/usr/include/bits/string2.h: At top level:
/usr/include/bits/string2.h:893: parse error before `__strcspn_c1'
/usr/include/bits/string2.h:895: parse error before `__strcspn_c1'
/usr/include/bits/string2.h: In function `__strcspn_c1':
/usr/include/bits/string2.h:897: syntax error before `__result'
/usr/include/bits/string2.h:898: `__result' undeclared (first use in
this functi
on)
/usr/include/bits/string2.h: At top level:
/usr/include/bits/string2.h:903: parse error before `__strcspn_c2'
/usr/include/bits/string2.h:906: parse error before `__strcspn_c2'
/usr/include/bits/string2.h: In function `__strcspn_c2':
/usr/include/bits/string2.h:908: syntax error before `__result'
/usr/include/bits/string2.h:909: `__result' undeclared (first use in
this functi
on)
/usr/include/bits/string2.h: At top level:
/usr/include/bits/string2.h:915: parse error before `__strcspn_c3'
/usr/include/bits/string2.h:918: parse error before `__strcspn_c3'
/usr/include/bits/string2.h: In function `__strcspn_c3':
/usr/include/bits/string2.h:921: syntax error before `__result'
/usr/include/bits/string2.h:922: `__result' undeclared (first use in
this functi
on)
/usr/include/bits/string2.h: At top level:
/usr/include/bits/string2.h:950: parse error before `__strspn_c1'
/usr/include/bits/string2.h:952: parse error before `__strspn_c1'
/usr/include/bits/string2.h: In function `__strspn_c1':
/usr/include/bits/string2.h:954: syntax error before `__result'
/usr/include/bits/string2.h:956: `__result' undeclared (first use in
this functi
on)
/usr/include/bits/string2.h: At top level:
/usr/include/bits/string2.h:961: parse error before `__strspn_c2'
/usr/include/bits/string2.h:964: parse error before `__strspn_c2'
/usr/include/bits/string2.h: In function `__strspn_c2':
/usr/include/bits/string2.h:966: syntax error before `__result'
/usr/include/bits/string2.h:968: `__result' undeclared (first use in
this functi
on)
/usr/include/bits/string2.h: At top level:
/usr/include/bits/string2.h:973: parse error before `__strspn_c3'
/usr/include/bits/string2.h:976: parse error before `__strspn_c3'
/usr/include/bits/string2.h: In function `__strspn_c3':
/usr/include/bits/string2.h:978: syntax error before `__result'
/usr/include/bits/string2.h:980: `__result' undeclared (first use in
this functi
on)
/usr/include/bits/string2.h: In function `__strpbrk_c2':
/usr/include/bits/string2.h:1015: void value not ignored as it ought to
be
/usr/include/bits/string2.h:1015: parse error before `__s'
/usr/include/bits/string2.h: In function `__strpbrk_c3':
/usr/include/bits/string2.h:1028: void value not ignored as it ought to
be
/usr/include/bits/string2.h:1028: parse error before `__s'
/usr/include/stdlib.h: At top level:
In file included from /usr/include/bits/string2.h:1185,
 from /usr/include/string.h:360,
 from ../pm_shared/pm_debug.c:24:
/usr/include/stdlib.h:527: parse error before `__size'
/usr/include/stdlib.h:529: parse error before `__nmemb'
In file included from /usr/include/string.h:360,
 from ../pm_shared/pm_debug.c:24:
/usr/include/bits/string2.h:1209: parse error before `size_t'
../pm_shared/pm_debug.c:29: parse error before `*'
../pm_shared/pm_debug.c: In function `PM_ParticleLine':
../pm_shared/pm_debug.c:128: request for member `PM_Particle' in
something not a
 structure or union
../pm_shared/pm_debug.c: In function `PM_DrawPhysEntBBox':
../pm_shared/pm_debug.c:164: request for member `numphysent' in
something not a
structure or union
../pm_shared/pm_debug.c:168: request for member `physents' in something
not a st
ructure or union
../pm_shared/pm_debug.c:174: request for member `PM_GetModelBounds' in
something
 not a structure or union
../pm_shared/pm_debug.c: In function `PM_ViewEntity':
../pm_shared/pm_debug.c:293: `pmtrace_t' undeclared (first use in this
function)
../pm_shared/pm_debug.c:293: parse error before `trace'
../pm_shared/pm_debug.c:302: request for member `angles' in something
not a stru
cture or union
../pm_shared/pm_debug.c:304: request for member `origin' in something
not a stru
cture or union
../pm_shared/pm_debug.c:304: request for member `origin' in something
not a stru
cture or union
../pm_shared/pm_debug.c:304: request for member `origin' in something
not a stru
cture or union
../pm_shared/pm_debug.c:306: request for member `player_mins' in
something not a
 structure or union
../pm_shared/pm_debug.c:306: request for member `usehull' in something
not a str
ucture or union
../pm_shared/pm_debug.c:306: request for member `player_maxs' in
something not a
 structure or union
../pm_shared/pm_debug.c:306: request for member `usehull' in somethi

Re: [hlcoders] Linux: Undefined object PM_Move

[Pat Magnan]

Sounds like the pm_shared.c code is being compiled with g++ not gcc? CC
should normally be set to gcc in the makefile, and gcc is smart enough to
know to compile the cpp files as C++ code not C code. Your name decoration
(is that the term) would be horked if you compiled a .c module as C++ code,
and the engine couldn't find the C functions. Otherwise, you'd have to
declare the PM_Move function as extern "C", if you had converted the
pm_shared code to C++.
A guess off the top of my head anyhow.

At 05:39 PM 9/1/2003 -0500, you wrote:
This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
Hey guys, another Firearms problem (thank god this is scheduled to be
our last release). I'm trying to compile the linux server binary for FA.
I manage to get it compiled, but when executed, the server kills and
says it cannot get the API from fa_i386.so. The reason being:
'Undeclared object PM_Move' (or something like that, don't remember the
exact wording). Any ideas why?
The compile environment is:
Red Hat 7.2
EGCS 1.1.2
GCC 2.91.66
Any ideas?

-Cale 'Mazor' Dunlap
Firearms Programmer
http://www.firearmsmod.com/
--



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


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

Re: [hlcoders] (kinda OT) Steam to move to pay-as-play for HL2?

[Pat Magnan]

I think it's a rather obvious way to keep it all going (charging for
Steam). I mean, high as the sales of Halflife/CS were, I'm sure there were
times when it was uncertain in many people's minds how Valve made money on
an ongoing basis (hence the suggestions about deals with the devil and such).
I don't have the fear of monthly fees many gamers do, but that's unique to
my position in life, and if I had kids old enough, and I felt that the
environment was 'supervisable' enough, I'd gladly pay for them too.
The only thing Steam really doesn't seem to have that I'm aware of, is any
sort of recourse for truly nasty behaviour. Sure it's an FPS game, so
people are likely to be a little immature and testy (too much adrenaline
makes us all a little snappy), but I'm not sure about paying monthly if
real jerks or real sickos (stalkers, etc) can't be traced and banned
somehow (as MMORPGs all seem have facilities for).
Hmm, even more OT, how many of us make it to GDC every year? Might be cool
to have a modder's meet and greet there or something. I know geeks
socializing .. scary :p.
At 12:52 PM 9/1/2003 -0400, you wrote:
I've spoken to some of the marketing people at Valve recently and they
assured us that this was not for any products they themselves are releasing
soon. Rather, as a tool for other developers shipping through Steam do
charge fees that way.
On the other hand, I think it's just a matter of time for Valve to do so.
Recurring revenue is king.
- Original Message -
From: "mod man" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, September 01, 2003 12:48 PM
Subject: [hlcoders] Steam to move to pay-as-play for HL2?
> There are suggestions floating about that once Steam and HL2 get going
> that HL2 will move to a pay-as-you-play billing format for online play.
> I wouldn't have give this much thought, except that the slide show
> presentation at the Game Developers Conference in 2002 listed this as a
> feature of Steam. It seems a little unlikely that Valve would add the
> feature to Steam if there were no future plans to use it.
>
> Would someone at Valve like to clarify if this is in fact the case?
>
>
> ___
> 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] SDK release kaput?

[Pat Magnan]

But no one said nanny-nanny boo boo yet.. ;).

Ontopic: I'm not sure if it's the same position, but that job posting has
been on and off their site for about a year now. I don't know that means
the SDK has to be delayed per se. However, if the game is 'tight' it's
logical the SDK is going to be delayed a little. But let's wait and see.
At 01:46 PM 8/31/2003 -0400, you wrote:
And you and marco (and now this post) are promoting the list being a
kindergarten yourselves :P
-omega
Blackened Interactive - http://www.blackened-interactive.com
Omega Wing - http://owing.blackened-interactive.com
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Simon
Sent: August 31, 2003 11:01 AM
To: [EMAIL PROTECTED]
ok don't understand this joke, sorry for that.
Btw. do you know the heise comments?
This is sometimes a real kindergarten
- Original Message -
From: "Marco Leise" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, August 31, 2003 4:59 PM
Subject: Re: [hlcoders] SDK release kaput?
> > I mean kindergarten is a german word used in english language.
> > And as far as i know it's written like the german word: kindergarten
>
> I know what you meant ;), just tried to make a joke of it.
>
> ___
> 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] PM_PreventMegaBunnyJumping()

[Pat Magnan]

There's two sorts of bunny hopping.

What this code prevents is pogo sticking, jump jump jump (not touching the
ground, and also not running other movement logic - as the comments say).
That still allows what a CS player would think of as a bunny hop, jump,
land, jump in rapid succession. You'll still need to code logic to stop
that sort of jumping (using a stamina system ala DOD would work, I add
further penalties like you can't aim for beans after a jump, and if you
jump while firing an RPG or something you'll blow your .. err legs off).
At least that's always been my understanding.

You wouldn't want to clamp jumping to the normal forward speed of a player
as jumping is a gathering of kinetic/potential? energy in the
skeletal/muscular system and a release quickly to accelerate, it has to be
somewhat faster therefore than 1.0 times max speed. Why 1.7? I dunno, why
100 health? Just numbers chosen that 'felt right'? (well 100 health makes
math easy, but you know what i mean).
At 09:52 AM 8/23/2003 -0700, you wrote:

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

I understand this is to limit bunny hopping but why 1.7X the player max
speed? Is there a reason this was not set lower? Also why the .65 speed
reduction? 400 x 1.7 * 0.65 = 443 ???
I would like to further prevent bhoping and thought I would follow Valves
approach only with different multipliers but wonder why Valve didn't do
this originally. Was there some problem that prevented using a factor of
1.0 or 1.2 for example? Why was 1.7 chosen as the limit?
[code]

FROM VALVE SDK FILE: pm_shared.c

#define BUNNYJUMP_MAX_SPEED_FACTOR 1.7f

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


___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
Pat 'sluggo' Magnan
Tour of Duty mod
http://www.tourofdutymod.com
Monkeystrike mod
http://www.monkeystrike.com


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

Re: [hlcoders] Looking for a HLSTATS, SQLServer and ASP Coder

[Pat Magnan]

At 08:34 AM 8/16/2003 -0400, you wrote:
Regarding functionality of ASP versus PHP. Yes, if you know C++ you can
construct or use other libraries for functionality.  C# ships with most
common libraries standardized and integrated into the platform and includes
tools made to allow a small to a large development shop reuse the code and
(again) work as a standardized platform.  PHP standardization is
non-existant (except in the case of Zend which has a cost, yes?) .
PHP has a long way to go to be mature enough to be 'the only solution for
everything', and then I feel anyone who believes that to be foolish, every
language has a cost associated with using it.. I think PHP is more where
ASP used to be before .NET. I think with ASP.NET it's insane what you can
do (and probably the security holes you open up running it... )
It's also got a lot of weird problems... globals are unsafe, so there's no
longer such a thing if you set the options so that tainted data isn't just
allowed in?
Global variables should not require redeclaration inside the function
scope, that goes against the very concept of globals.
I think they need to rethink their solution to shoddy PHP programmers a bit
there. (the real problem was people with no programming expertise unsafely
using globals).
My last complaint is database support.  MYSql isn't truly an option for a
large development platform as, while it does improve, it lacks much of the
needed functionality that more robust and developed platforms provide
(dynamic stored procedures, row level locking, foreign key constraint and
trickle, object clustering).  On Linux, you have to use Sybase or Oracle (I
believe?)  or DB2.  All of these options cost money (in the case of Oracle,
quite an exorbitant amount). I consider Sybase a very good database, but MS
Sql Server is comparable (seeing as how it's roots exist in Sybase10x).
Actually, it depends on how many connections to Oracle you need, you can
get Oracle (fully functional legal versions, etc) for about 30 dollars a
month -- that's for like 5 connections or something.. so that's obviously
too few for web stuff, but it's nowhere near as expensive as one may think,
and it's pretty comparable with SQL Server for similar sized operations.
Coupled with better speed and stability, I can't see a reason to use SQL
server unless you want the database on the application server, but that's
just wrong to me.
Sybase and SQL server have forked pretty widely.. not sure they're all that
related any longer, at least talking to someone who worked with both, he
preferred sybase.
MySQL is perfect for dynamic unimportant data, like news pages, blogs and
such drivel. Without transactions (sure coming, but how buggy will the new
feature be) and the like, it's not a real database, they're working on all
this, but I suspect they'll just screw up what was a great option for small
scale data (i.e non-financial stuff that isn't being updated nearly as much
as retreived).
Actually, PHP works with any databases you want it to nearly, I use it with
an access database (ugh don't ask crappy web host).
I'd say use PostGresSQL if MySQL doesn't meet your needs, it's free, and
has most of the features of the big boys (transactions, locking, yadda
yadda), minus the cost.
I'd just not want to put an IIS server on the net myself. ASP on Apache
maybe then... ;).
Just my thoughts! I'm a die-hard ./ fan and *nix geek as well.

Shane
PHXX.net
p.s. ASP can be run off chilsoft! platform on Apache as well.

- Original Message -
From: "jc" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, August 16, 2003 5:07 AM
Subject: Re: [hlcoders] Looking for a HLSTATS, SQLServer and ASP Coder
> The point is you have the *choice*. With mircro$haft you have freedoms
> taken away. oh how much does it cost to set up a legal ASP box? And how
> much for a legal PHP/Apache box :o?? I personally dont trust anything
> from a company that large. Having read about how ms manipulated and held
> back netscape i am convinced they should be kicked squarely in the nuts.
>
> Of course if you like expensive software from the bloat king who am I to
> try an change your mind. Myself, well I will be returning to my Linux
> box to play with my backend PHP library code. Which was so easy to write
> its untrue. If you can figure out C++ then I challenge you not to find
> PHP the most easy language on the planet.
>
> jc
>
>
> Daniel Koppes wrote:
>
> > True... but PHP can run on IIS too :)
> >
> > At 17:46 16/08/03, you wrote:
> >
> >> ASP only runs on Micro$haft IIS -- the most remotely hacked web
> >> server on
> >> earth.
> >>
> >> Flexible in terms of the number of ways you can be "0wn3ed", maybe.
> >>
> >> At 09:18 PM 8/15/2003 -0400, you wrote:
> >>
> >>> You are obviously biased.  ;)
> >>>
> >>> With 14 years of professional development experience I can say hands
> >>> down I
> >>> find ASP (and more so .net) far more flexible and capable the PHP
> >>> any day.
> >>> However, it, like Perl, awk, 

Re: [hlcoders] weapon prediction bug

[Pat Magnan]

Right, cl_lw is a CVAR that turns off prediction.

Both we and as I understand it DOD had a problem due to the assumption it
would always be on with some weapons not recoiling at all (we do some
punchangle adjustments client and an identical client/server calc based on
current 'accuracy', I guess they did too).
For our weapons to work correctly at all, I just had to set this every
frame to 1.
You seem to have the opposite problem where the prediction is mucked. I
noticed also that checking cl_lw, the value seems to intermittently change
(tried to print to console based on it's value, and it seems to decide to
reset itself at random).
It seems like somewhere this value is getting munged, as well checks for it
don't work correctly at all. I lean to the idea there is a bug in the
engine and the value is getting stomped.
Hmm, wait, HUD_WeaponsPostThink is called when cl_lw is true is that not
correct?
At 11:15 AM 8/6/2003 -0400, you wrote:
This is something that has been going on for a long time, and I had thought
I'd fixed it, but now it seems like its really an engine bug. Here's the
lowdown:
For a long time, people have been complaining about "weapon jamming" (as
they call it) long before I started working on FLF; So I began re-writing
the weapon code completely. Locally it seems to work perfectly now, but over
the internet it randomly stops predicting. And that's the keyword, I can't
re-produce it, it just at random times "jams" (or more specifically,
HUD_WeaponsPostThink is not called at ALL anymore.) cl_lw 0 seems to fix it,
which if my understanding is correct, tells the engine to not call
HUD_WeaponsPostThink and then the server will not skip the event playback
from FEV_NOTHOST. Correct?
The problem is; now all weapon prediction features are lost, just to make
the weapons not "jam". This is a pain in the ass, and the fact that I can't
reproduce it to even debug and see if it is something messed up in the
weapons code, or if it's in the engine for sure it leaves me in a pickle jar
with no fork to pull myself out.
I was wondering mostly if anyone else has experienced this, and if they can
confirm or deny if it really is an engine problem, or something that can be
fixed in weapons code :/
I'm getting ready to rip my hair out again (and to think. It just grew back
from last time I was fixing weapons!)
-omega
Blackened Interactive - http://www.blackened-interactive.com
Omega Wing - http://owing.blackened-interactive.com
___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders


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

RE: [hlcoders] weapon prediction bug

[Pat Magnan]

Hmm, ok guess that shouldn't be too random then :).

I did find it strange that changing this code:
if ( cl_lw && cl_lw->value )
{
HUD_WeaponsPostThink( from, to, cmd, time, random_seed );
}
so there's no check for cl_lw (i.e. the conditional was changed to if ( 1
)), seemed to have no effect - that is, HUD_WeaponsPostThink was never
called if someone types cl_lw 0, since I draw something on the screen from
that function continuously -- well based on a value only ever set there,
and it stops working as soon as someone types cl_lw 0 in the console I can
see that it was not being called.
I guess that means the only way to disable a client's ability to turn
prediction off is to set it to 1 right before the check?
I guess I'd have to say other than this cl_lw stuff, I have no issues with
the prediction not working or HUD_WeaponsPostThink not being called because
we draw based on that value and I've never heard of it randomly not working...
Oh for your problem omega, setting cl_lw to zero guarantees that
HUD_WeaponsPostThink is NOT ever called... so it shouldn't fix it not being
called.. at least that's what that code above says to me :p, maybe some
other check for it, the only 'default' other check is this, and one in the
gauss code I think...:
int CHud::MsgFunc_SetFOV(const char *pszName,  int iSize, void *pbuf)
{
.. snip ...
if ( cl_lw && cl_lw->value )
return 1;
So, if you rely on FOV at all, then you'd need a zero in cl_lw for your
weapons to work correctly perhaps? Comment that check out, and see if the
predicted weapons work correctly now?. No idea on the randomness of it..
At 10:40 AM 8/6/2003 -0700, you wrote:

> You seem to have the opposite problem where the prediction is mucked.
> I noticed also that checking cl_lw, the value seems to intermittently
> change (tried to print to console based on it's value, and it seems
> to decide to reset itself at random).
>
There is only one place in the engine where cl_lw is reset to 0, here is the
code for it:
if (cl_funcs.pPostRunCmd )
{
cl_funcs.pPostRunCmd( from, to, cmd, runfuncs, time,
random_seed );
}
else
{
extern cvar_t cl_lw;
if ( cl_lw.value != 0 )
{
Cvar_SetValue( "cl_lw", 0.0 );
}
}
obviously this should never be called as long as your client dll exports the
HUD_PostRunCmd function.


> It seems like somewhere this value is getting munged, as well checks
> for it don't work correctly at all. I lean to the idea there is a bug
> in the engine and the value is getting stomped.
>
> Hmm, wait, HUD_WeaponsPostThink is called when cl_lw is true is that
> not correct?
>
> At 11:15 AM 8/6/2003 -0400, you wrote:
>> This is something that has been going on for a long time, and I had
>> thought I'd fixed it, but now it seems like its really an engine
>> bug. Here's the lowdown:
>>
>> For a long time, people have been complaining about "weapon jamming"
>> (as they call it) long before I started working on FLF; So I began
>> re-writing the weapon code completely. Locally it seems to work
>> perfectly now, but over the internet it randomly stops predicting.
>> And that's the keyword, I can't re-produce it, it just at random
>> times "jams" (or more specifically, HUD_WeaponsPostThink is not
>> called at ALL anymore.) cl_lw 0 seems to fix it, which if my
>> understanding is correct, tells the engine to not call
>> HUD_WeaponsPostThink and then the server will not skip the event
>> playback from FEV_NOTHOST. Correct?
>>
>> The problem is; now all weapon prediction features are lost, just to
>> make the weapons not "jam". This is a pain in the ass, and the fact
>> that I can't reproduce it to even debug and see if it is something
>> messed up in the weapons code, or if it's in the engine for sure it
>> leaves me in a pickle jar with no fork to pull myself out.
>>
>> I was wondering mostly if anyone else has experienced this, and if
>> they can confirm or deny if it really is an engine problem, or
>> something that can be fixed in weapons code :/
>>
>> I'm getting ready to rip my hair out again (and to think. It just
>> grew back from last time I was fixing weapons!)
>>
>> -omega
>> Blackened Interactive - http://www.blackened-interactive.com
>> Omega Wing - http://owing.blackened-interactive.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] (no subject)

[Pat Magnan]

Yeah, really would have rocked to have no dedicated server for linux..
thank goodness they are thinking (Delphi for Linux is only what 2 years
old, and does it still cost money?).
I've said it before and I'll say it again, languages != programming. If we
can't put aside our personal preference for language x, we're like a
carpenter who only knows how to use a saw. Choose the tool that fits the
job, don't make the job fit the tool... ;).
At 04:59 AM 8/3/2003 +1200, you wrote:
Ok... perhaps I was wrong about Pascal then (I've never used pre-Delphi
pascal), but Delphi is still good :)
At 04:33 03/08/03, you wrote:
Hallo,

Saturday, August 2, 2003, 18:27,
Daniel Koppes <[EMAIL PROTECTED]> wrote:
> I've found Delphi just as compentant as C++
> Normal Pascal is no worse than C really.
Then you might want to read this one:
http://www.lysator.liu.se/c/bwk-on-pascal.html
--
Sebastian Steinlechner <[EMAIL PROTECTED]>//www.resourcecode.de
"In the beginning the Universe was created. This had made a lot of
people very angry and been widely regarded as a bad move."
   - Douglas Adams
___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders


--
Programmer and Modeller for The
Pokemod
--

___
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] Java and Half-Life

[Pat Magnan]

Or if you're a GUI freak, right click view dependencies , or open the thing
in Dependency Walker (visual studio tool - that may require enterprise
edition, not sure).
Nice little treeview of all the .dlls yours is dependent on, plus you can
peek into what functions a dll exports, etc..
At 12:08 PM 8/1/2003 -0500, you wrote:
> Maybe you need some library or dll for the java stuff which windows can't
> find upon loading your code. Then hl can't get a handle to your dll and
> bails out with the error.
True.

"dumpbin /dependents client.dll" on the MS-DOS command line will show the
DLL dependencies of an executable so you can verify that the required DLLs
are in the Half-Life folder (where the .exe file is) or in the
Windows\System32 folder.
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] FW: Half-Life: fun with MODs

[Pat Magnan]

Oi I'm sorry, I hpe you don't think I was calling you anything mate,
talking about the 'researcher' :).
At 10:25 AM 7/30/2003 +0200, you wrote:
I mean that informing people about fact that  mods could have a malicious
code is stupid (i got this message from bugtraq).
Bodek

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Pat Magnan
> Sent: Wednesday, July 30, 2003 12:36 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [hlcoders] FW: Half-Life: fun with MODs
>
>
> OMG you mean a mod could contain malicious code? What an arse.
>
> The overrun in liblist.gam is a bit of an issue, however.
>
> At 12:16 AM 7/30/2003 +0200, you wrote:
> >HI,
> >
> >Look at this, very interesting (liblist.gam) but not dangerous in my
> >opinion, and very silly. Maybe commonly known (DLLs with
> malicious code hehe
> >who creates mods with trojans or other dnagerous things ?!?)
> >
> >Bodek
> >
> >-Original Message-
> >From: Auriemma Luigi [mailto:[EMAIL PROTECTED]
> >Sent: Tuesday, July 29, 2003 8:33 PM
> >To: undisclosed-recipients:
> >Subject: Half-Life: fun with MODs
> >
> >
> >##
> >
> >Applications: Half-Life (http://half-life.sierra.com) MODs.
> >Versions: 1.1.1.0
> >Platforms:Windows
> >Bugs: Buffer overflow in liblist.gam and arbitrary code
> >   execution through customized DLL files
> >Risk: High
> >Author:   Auriemma Luigi
> >   Senior Security Researcher, PivX Solutions, LLC
> >   e-mail: [EMAIL PROTECTED]
> >   web:http://www.pivx.com/luigi/
> >
> >
> >##
> >
> >
> >1) Introduction
> >2) Bug
> >3) The Code
> >4) Fix
> >5) Philosophy
> >
> >
> >##
> >
> >===
> >1) Introduction
> >===
> >
> >
> >Valve's Half-Life was released in 1998 but still remains as the worlds
> >most popular FPS game.
> >
> >The success of the game is largely due to the overwhelming community
> >support, which has spawned a range of MODs for the game - including
> >the popular Counter-Strike MOD and Day Of Defeat.
> >
> >The cause of these problems are MODs.
> >One of these problems is an inherent flaw in the basic structure of
> >Half-Life and cannot be fixed without fundamental changes.
> >
> >
> >
> >##
> >
> >==
> >2) Bug
> >==
> >
> >
> >The 2 bugs are:
> >
> >
> >-
> >[A] Buffer-overflow in liblist.gam
> >-
> >
> >Liblist.gam is a text file present in every MOD. The problem is a
> >buffer overflow caused by long values.
> >
> >The following liblist.gam demonstrate the problem:
> >
> >---liblist.gam---
> >
> >game
> >"
> aa
> >a
> aa
> >a
> aa
> >EIPx"
> >gamedll "what you want"
> >
> >-
> >
> >
> >The buffer-overflow happens when there is a value of 276 bytes and
> >only when the gamedll parameter is specified.
> >
> >NOTE: The important and "strange" thing to see is that the stored
> >return address is overwritten by the 4 bytes at offset 260 of the
> >value.
> >We need to add another 12 bytes after it to cause the buffer-overflow
> >and successfully overwriting the stored EIP.
> >
> >
> >
> >--
> >[B] Do you know the DLL files in MODs?
> >--
> >
> >
> >A lot of MODs are distributed with custom DLL files that are contained
> >in the folders "dlls" and "cl_dlls".
> >
> >The problem is easily explained:
> >
> >The DLL files used by MODs are real binary libraries that can contain
> >all the code you want!
> >Which means that I can create a malicious DLL that I distribute with
> >a MOD and everyone that use it wi

Re: [hlcoders] FW: Half-Life: fun with MODs

[Pat Magnan]

Darn internet, still no undo feature.. umm wait, that's a local exploit
anyhow, you'd have to crack the gameserver, modify the liblist.gam, then
insert malicious code, not the world's biggest threat, I think? Should
prolly be patched anyhow, but still not a big deal. I repeat, what an arse. :)
At 12:16 AM 7/30/2003 +0200, you wrote:
HI,

Look at this, very interesting (liblist.gam) but not dangerous in my
opinion, and very silly. Maybe commonly known (DLLs with malicious code hehe
who creates mods with trojans or other dnagerous things ?!?)
Bodek

-Original Message-
From: Auriemma Luigi [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 29, 2003 8:33 PM
To: undisclosed-recipients:
Subject: Half-Life: fun with MODs
##

Applications: Half-Life (http://half-life.sierra.com) MODs.
Versions: 1.1.1.0
Platforms:Windows
Bugs: Buffer overflow in liblist.gam and arbitrary code
  execution through customized DLL files
Risk: High
Author:   Auriemma Luigi
  Senior Security Researcher, PivX Solutions, LLC
  e-mail: [EMAIL PROTECTED]
  web:http://www.pivx.com/luigi/
##

1) Introduction
2) Bug
3) The Code
4) Fix
5) Philosophy
##

===
1) Introduction
===
Valve's Half-Life was released in 1998 but still remains as the worlds
most popular FPS game.
The success of the game is largely due to the overwhelming community
support, which has spawned a range of MODs for the game - including
the popular Counter-Strike MOD and Day Of Defeat.
The cause of these problems are MODs.
One of these problems is an inherent flaw in the basic structure of
Half-Life and cannot be fixed without fundamental changes.


##

==
2) Bug
==
The 2 bugs are:

-
[A] Buffer-overflow in liblist.gam
-
Liblist.gam is a text file present in every MOD. The problem is a
buffer overflow caused by long values.
The following liblist.gam demonstrate the problem:

---liblist.gam---

game
"aa
aaa
aaa
EIPx"
gamedll "what you want"
-

The buffer-overflow happens when there is a value of 276 bytes and
only when the gamedll parameter is specified.
NOTE: The important and "strange" thing to see is that the stored
return address is overwritten by the 4 bytes at offset 260 of the
value.
We need to add another 12 bytes after it to cause the buffer-overflow
and successfully overwriting the stored EIP.


--
[B] Do you know the DLL files in MODs?
--
A lot of MODs are distributed with custom DLL files that are contained
in the folders "dlls" and "cl_dlls".
The problem is easily explained:

The DLL files used by MODs are real binary libraries that can contain
all the code you want!
Which means that I can create a malicious DLL that I distribute with
a MOD and everyone that use it will run my malicious code.
[Bodek]Really ??? I can't believe !!! :)

This problem "CANNOT" be fixed by Valve, so be careful when you use an
unknown MOD or you download a MOD from an non-trusted site.


##

===
3) The Code
===
-
[A] Buffer-overflow in liblist.gam
-
---liblist.gam---

game
"aa
aaa
aaa
EIPx"
gamedll "what you want"
-



--
[B] Do you know the DLL files in MODs?
--
Create a Half-Life DLL or add any malicious code in a existent DLL.



###

==
4) Fix
==
Valve was notified of this vulnerability on April 14 2003, and replied
that they were working to patch these bugs.
Since that last point of contact, Valve and it's representatives have
been contacted on multiple occasions for a status update on the patch,
without any replies.


###

==
5) Researcher's Philosophy
==
Be free.
The researchers' community needs your reversing, yo

Re: [hlcoders] FW: Half-Life: fun with MODs

[Pat Magnan]

OMG you mean a mod could contain malicious code? What an arse.

The overrun in liblist.gam is a bit of an issue, however.

At 12:16 AM 7/30/2003 +0200, you wrote:
HI,

Look at this, very interesting (liblist.gam) but not dangerous in my
opinion, and very silly. Maybe commonly known (DLLs with malicious code hehe
who creates mods with trojans or other dnagerous things ?!?)
Bodek

-Original Message-
From: Auriemma Luigi [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 29, 2003 8:33 PM
To: undisclosed-recipients:
Subject: Half-Life: fun with MODs
##

Applications: Half-Life (http://half-life.sierra.com) MODs.
Versions: 1.1.1.0
Platforms:Windows
Bugs: Buffer overflow in liblist.gam and arbitrary code
  execution through customized DLL files
Risk: High
Author:   Auriemma Luigi
  Senior Security Researcher, PivX Solutions, LLC
  e-mail: [EMAIL PROTECTED]
  web:http://www.pivx.com/luigi/
##

1) Introduction
2) Bug
3) The Code
4) Fix
5) Philosophy
##

===
1) Introduction
===
Valve's Half-Life was released in 1998 but still remains as the worlds
most popular FPS game.
The success of the game is largely due to the overwhelming community
support, which has spawned a range of MODs for the game - including
the popular Counter-Strike MOD and Day Of Defeat.
The cause of these problems are MODs.
One of these problems is an inherent flaw in the basic structure of
Half-Life and cannot be fixed without fundamental changes.


##

==
2) Bug
==
The 2 bugs are:

-
[A] Buffer-overflow in liblist.gam
-
Liblist.gam is a text file present in every MOD. The problem is a
buffer overflow caused by long values.
The following liblist.gam demonstrate the problem:

---liblist.gam---

game
"aa
aaa
aaa
EIPx"
gamedll "what you want"
-

The buffer-overflow happens when there is a value of 276 bytes and
only when the gamedll parameter is specified.
NOTE: The important and "strange" thing to see is that the stored
return address is overwritten by the 4 bytes at offset 260 of the
value.
We need to add another 12 bytes after it to cause the buffer-overflow
and successfully overwriting the stored EIP.


--
[B] Do you know the DLL files in MODs?
--
A lot of MODs are distributed with custom DLL files that are contained
in the folders "dlls" and "cl_dlls".
The problem is easily explained:

The DLL files used by MODs are real binary libraries that can contain
all the code you want!
Which means that I can create a malicious DLL that I distribute with
a MOD and everyone that use it will run my malicious code.
[Bodek]Really ??? I can't believe !!! :)

This problem "CANNOT" be fixed by Valve, so be careful when you use an
unknown MOD or you download a MOD from an non-trusted site.


##

===
3) The Code
===
-
[A] Buffer-overflow in liblist.gam
-
---liblist.gam---

game
"aa
aaa
aaa
EIPx"
gamedll "what you want"
-



--
[B] Do you know the DLL files in MODs?
--
Create a Half-Life DLL or add any malicious code in a existent DLL.



###

==
4) Fix
==
Valve was notified of this vulnerability on April 14 2003, and replied
that they were working to patch these bugs.
Since that last point of contact, Valve and it's representatives have
been contacted on multiple occasions for a status update on the patch,
without any replies.


###

==
5) Researcher's Philosophy
==
Be free.
The researchers' community needs your reversing, your programs, and
your research. Never let your passion die and don't stop your work!
Disclosure:
Full and responsible disclosure can lead to a quick fix, and prevent a
prob

Re: [hlcoders] Using a TRIAPI, flipped sprite

[Pat Magnan]

What do you mean 'flipped' ? The coordinates are represented pretty much
like most graphics APIs, 0,0 being the upper left corner of the screen,
IIRC, so you perhaps are drawing it upside down if it's oriented incorrectly.
At 04:37 PM 7/5/2003 +0200, you wrote:
Hello,
Why a sprite is flipped on the screen, when it's drew using TRIAPI ?
Bodek

http://www.bodek.kicks-ass.org/mod
___
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] Linux compilation problem

[Pat Magnan]

http://www.thewavelength.net/forums/index.php?act=ST&f=13&t=8382&s=5a32ae43713bc6b242369bbb911d2af1

That thread may be helpful, you're having similar problems, using g++, you
get into name mangling issues. I also think since you're copying libs
about, something strange happened when you installed a compiler/library.
The correct symlinks to libblah.so.x are setup if things are installed
correctly, or your ld.so.conf is not updated properly.
PM_Move is C code, so compiling with g++, you get a mangled name, and the
engine won't find it.
At 05:00 PM 6/20/2003 +0200, you wrote:
mmh :(
Doesn't work either... HLDS asks for : "VecBModelOrigin__FP9entvars_s".
Please !! Why do I have so many problems with linux :p ?

Cortex.

D. Hofer wrote:
> For me it works only when i compile it with gcc and link it with
> g++... so
> set gcc as the compiler, run the makefile then change the compiler to
> g++ (in the makefile) and run it again.
>
> cya Spin
>
> On Fri, 20 Jun 2003 15:05:10 +0200, Cortex <[EMAIL PROTECTED]> wrote:
>
>> Hi,
>>
>> The solution of Botman didn't work (-lstdc++).
>>
>> I tried the brut way... I have copied the libstdc++[bla].so.2 to my
>> /lib directory, and now, hlds finds it.
>>
>> However, now, it doesn't find HL SDK symbols :( RGGG
>>
>> If I compile with g++, it doesn't find "PM_Move".
>> If I compile with egcc, it doesn't find BModelSize (or something like
>> that,
>> with a horrible mangled name). HLDS doesn't seem to find the mangled
>> name...
>> Have I to change the mangling name version of the compilator ?
>>
>> (Rest of the answer below).
>>
>> Florian Zschocke wrote:
 I think my problem comes from the fact I use _snprintf and some
 STL...
>>>
>>> What is _snprintf? Usually that _something is M$ stuff (like
>>> _strnicmp(). God knows why they have to prefix them with an
>>> underscore). Using STL should be no problem, we use deques from the
>>> STL in Admin Mod
>>> and can link with libstd++ fine.
>>
>> _snprintf is a function I used to remplace ALL the sprintf in the
>> SDK...
>> Indeed, I had a memory problem and thought it was a buffer overrun
>> caused
>> by
>> a too long sprintf. It didn't come from sprintf, but I let the
>> _snprintf.
>>
>> But now, this problem is resolved if I place the libstdc++ in /lib.
>>
 When
 I put the "-static" option instead of "-shared" and when I compile
 with egcc, it doesn't find these symbols...
>>>
>>> Uhm, you don't want to use -static. YOu want to produce a dynamic
>>> shared object, a .so, so you will need to link with -shared which
>>> tell the
>>> linker that you want a DSO created.
>>
>> OK.
>>
 So, how could I link statically to libstdc++ so that the .so
 "contains" the libstdc++[bla].so ?
>>>
>>> You cannot. The libstdc++[bla].so is just that, a DSO. You cannot
>>> link statically against a DSO. If you want to link statically
>>> against a
>>> library you need to use the static version of the library, the
>>> archive.
>>> You need to link against libstdc++[bla].a <--
>>
>> OK, I think I'll let the libstdc++ thing, and distribute
>> libstdc++[Bla].so.2
>> with my mod... Crappy, but if it solves the pb, it's good ;)
>>
>> Thx for your helps
>>
>> Cortex.
>>
>>
>> ___
>> 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] Net problems: choke

[Pat Magnan]

- Excessive messages are a logical starting point
- Including player data in the entity updates and having a lot of moving
entities (like we do with helicopters and APCs) is another thing to check
(if you added things to delta.lst or use that for significant amount of
client updates as we do). I made this mistake once.
Don't know of any articles, and finding these things was for us a very
manual process. Also, be wary of sending messages to all players in loops
and such, particularly at initialization, we were flooding clients with
that at one time).
If you have a 'zone' type entity, don't send messages for in/out of the
zone, use something in a delta instead (much more efficient, you send bits
rather than bytes).
Hope those are some places to look for evilness in your code. You could try
disabling some of the changes you've made. Testing early and often helps,
but it's often hard to manage with a really rough product and volunteer
testers who have more polished mods to play :).
Good luck!

At 12:13 AM 6/20/2003 -0400, you wrote:
This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
Has anyone else had any seemingly rare problems where their mod gave some
people an unusually high choke?
In one server on the first map, My choke was nearing 100 and It was as if
i lagged out but had 40ms ping, next map it was on 2 other people, but my
choke was 80-90 yet it was very smooth for me.
If there are any articles code related to HL choke as possible causes (I'm
thinking MESSAGE_BEGIN/ENDs...) I would be much obliged
--
___
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] Linux compilation problem

[Pat Magnan]

t 10:37 PM 6/19/2003 +0200, you wrote:
> I think my problem comes from the fact I use _snprintf and some STL...

What is _snprintf? Usually that _something is M$ stuff (like
_strnicmp().
Yup, appears to be another Microsoft abomination... it is used only in
cl_dll code however, in the default SDK, so the Microsoft version will
work, but, if you're using it in your server code at all, then look at
extdll.h:
#define _vsnprintf(a,b,c,d) vsnprintf(a,b,c,d)

And add a similar macro for the mangled version of snprintf ;). The
parameter order and types are the same between M$'s docs and the man page,
so the preprocessor can do your work for you.
M$ likes to try to suggest these are deprecated in favor of CString/MFC
crap, ANSI compliant my 0x0A$$.. ;)
--
Want to produce professional emails and Usenet postings?
http://www.netmeister.org/news/learn2quote.html
___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders


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

Re: [hlcoders] Half-life resources

[Pat Magnan]

I think a direct specific question would be much simpler to answer. :).

A good source of general information would be to start at
http://www.thewavelength.net and read their 'links' section in the coding
forums. There's a general overview of the way the SDK is organized at a
site call 'the fixxxer', or botman's MOD FAQ, otherwise, experience and
asking targetted questions are the best ways to learn.
Good luck.

At 01:59 PM 5/29/2003 -0400, you wrote:
I've noticed lots of tutorials on the net about various mod techniques like
adding weapons,
hud updates, vgui etc.
I'm looking for higher level information.  Is there any resource out there
that explains the
higher-level structure of HL?  I'm looking for "the big picture".
Thanks,
Jamie
___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders


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

RE: [hlcoders] default.cfg

[Pat Magnan]

Hmm that's likely it, what do you want to set to 'defaults' that isn't this?

kb_def.lst works fine for setting up the default keybindings, and is about
all that default.cfg really contains... it may not be being exec'd anymore
(default.cfg) since it's essentially redundant.
We don't ship out a default.cfg, but have default keybindings (if
config.cfg is deleted) in that file.
At 01:40 PM 4/12/2003 -0700, you wrote:
 If what you want is set default keys when a config file is not found, the
values are in the kb_def.lst file under /gfx.
-Original Message-
From: Kyle [mailto:[EMAIL PROTECTED]
Sent: Saturday, April 12, 2003 12:37 PM
To: [EMAIL PROTECTED]
Subject: RE: [hlcoders] default.cfg
Yes, when config is deleted, I want to exec from the mod/pak0.pac file
"default.cfg" exactly like valve does
I thought all you had to do was place the default.cfg in the pac. I did
notice another file called valve.rc within it there was a line commented
out //exec default.cfg  im not sure if that matters tho. I tried
uncommenting that line but it did not seem to help.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Friday, April 11, 2003 2:05 AM
To: [EMAIL PROTECTED]
Subject: RE: [hlcoders] default.cfg
I'm not 100% sure what you want...

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

-Original Message-
Wrom: LBDXRQBGJSNBOHMKHJYFMYXOEAIJJPHSCRTNH
[mailto:[EMAIL PROTECTED] On Behalf Of Kyle
Sent: Thursday, April 10, 2003 11:42 PM
To: [EMAIL PROTECTED]
Subject: RE: [hlcoders] default.cfg
??? Is this a tuff question, I did not think it was

-Original Message-
Wrom: GSWZIDREXCAXZOWCONEUQZAAFXISHJEXXIMQZ
[mailto:[EMAIL PROTECTED] On Behalf Of Kyle
Sent: Friday, April 04, 2003 3:55 PM
To: [EMAIL PROTECTED]
Subject: [hlcoders] default.cfg
This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
>From what I understand this file gets exec'ed if there is no config
file? I guess im wrong because that doest work. It always reverts back
to the valve/default.cfg
How can I make a default.cfg specific to my mod that gets set when the
config gets deleted?
--

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


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

Re: [hlcoders] new to the list

[Pat Magnan]

Search around counter-server, your linux server isn't setup functionally,
libhlwon.so needs to be somewhere it can be found (added to
LD_LIBRARY_PATH), or add /whatever/games/hlds_l to ld.so.conf and run ldconfig.
At 08:53 PM 4/1/2003 -0800, you wrote:
these links are great, thanx.  One problem I've been having is getting a
compiled hl_i386.so to work right.  The server complains about not being
able to find various .so files(libhlwon.so,
libSteamValidateUserIDTickets.so, etc...).  any help?
Andrew

- Original Message -
From: "Jonathas Costa" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, March 30, 2003 3:28 PM
Subject: Re: [hlcoders] new to the list
> Have a good look at botman's article at
> http://www.planethalflife.com/botman/MOD_FAQ.shtml
>
> A thousand links there.
>
> Jonathas
>
> - Original Message -
> From: "Andrew" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Sunday, March 30, 2003 8:03 PM
> Subject: [hlcoders] new to the list
>
>
> This is a multi-part message in MIME format.
> --
> [ Picked text/plain from multipart/alternative ]
> ello folks, I'm looking for a good intro to the sdk.  Something covering
> what, when, and why functions are called, objects are created, etc...  I
> have absolutely no idea how the underlying quake1 engine works or how it
> uses the server library(i'm fairly uninterested in the client library).
> Links to good tutorials anyone?
>
> Andrew
> --
>
> ___
> 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] new to the list

[Pat Magnan]

That is the case, metamod.org has a doxygen SDK, we had more grandiose
plans (like usage coments, etc), but life got in the way somehow.



> Persuter wrote:
> >
> > sluggo and I were going to do something like this recently, he put a
> > Doxygenated SDK up on his site, but it really never materialized.
>
> There was (is) a Doxygen docu of the SDK at metamod.org (whenever that
> will be back), IIRC.
>
> Florian.
>
> --
> Want to produce professional emails and Usenet postings?
> http://www.netmeister.org/news/learn2quote.html
> ___
> To unsubscribe, edit your list preferences, or view the list
archives, please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>

---
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

Re: [hlcoders] Problem porting to SDK 2.3

[Pat Magnan]

Someone posted solutions to this at:
http://www.thewavelength.net/forums

Search for 'rocket crowbar'. I believe the problem related to the code that
is run when you 'miss' all entities either not delaying something properly
(not setting the 'next primary attack' value correctly).

At 11:31 PM 2/13/2003 -0500, you wrote:

Was attempting to port a mod from a very old SDK to 2.3 by inserting the
additions from the 2.3 SDK [using WinDiff].

Everything went pretty well, except for multiple 'weapon prediction' bugs.

Example: When I "fire" the crowbar, it basically has no delay that I can
see. It hits the wall as fast as it can so after holding it down for a few
secs I might have 100 holes in the wall =D.

Did I forget something?

___
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] Triggering a door from the client

[Pat Magnan]

At 10:01 PM 2/2/2003 +1100, you wrote:

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

Just after some conceptual help here on how you'd go about triggering an
entity (in most if not all instances a door) to open from the client
side.

I'm recoding the func_door to open a VGUI menu for the user to enter a
pin code.  If the pin is correct the door should open if not then it
should remain closed.

Ideally this should be able to be done so that the player can't emulate
it via console commands etc.


I'd think that if the server doesn't somehow validate the code, it is
exposed to being comprimised.

I'm not sure how else you can transmit something from a menu to the server
that can't be emulated by a client.

Windows has a cryptographic API, which works on all versions from Windows
95 OSR 2 and up, if I recall correctly (my MSDN is broken right now and I
can't check).

You could take the code, and use one of those crypto functions to encrypt
it, and send that, but that can still be 'emulated' by a clever enough
client. Also, the encryption function you use would have to be available on
windows and linux for the server (or the results of the encrypted secrets
would have to be available on all servers somehow).

The door knows the client 'used' it or however the VGUI is triggered right?
Set a flag so the door remembers if it was triggered to look for the
password, if so it accepts the thing coming from the client, otherwise the
player is 'faking it' by typing the password without triggering the door.

I can't think of a way to make it not be able to be emulted in the console,
I just protect the server from receiving it when it doesn't want to myself.
Like dead players can't send voice commands, even though they can die with
a VGUI menu open, I just don't play the command from the server, regardless
of what the client sends me.

Not what you wanted exactly, but it may stop the casual hacker...



Anyway, looking forward to your ideas,

Thanks,

Michael Shimmins 
Sesechial Software

___
Important - This email and any attachments may be confidential. If
received in error, please contact us and delete all copies. Before
opening or using attachments, check them for viruses and defects.
Regardless of any loss, damage or consequence, whether caused by the
negligence of the sender or not, resulting directly or indirectly from
the use of any attached files our liability is limited to resupplying
any affected attachments. Any representations or opinions expressed are
those of the individual sender, and not necessarily those of Sesechial
Software.

--

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


Pat 'sluggo' Magnan
Tour of Duty mod
http://www.tourofdutymod.com


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

Re: [hlcoders] Models and memory management

[Pat Magnan]

At 01:40 PM 1/28/2003 -0600, you wrote:

So what's the deal with Valve and Evil?  :)


well, a slight re-arrangement of 'valve' could yield
evalV ... close to evilV...

and i and a differ by 8 positions.. in numerology one possible
interpretation of the number 8 is 'power-seeking, high-material goals.'

Any questions? :P

(bad humour courtesy of second cup of coffee not kicking in)

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

Re: [hlcoders] OT: Dlls and C++

[Pat Magnan]

At 03:41 PM 1/22/2003 -0600, you wrote:

  The only problem you would run into
is if you changed the 'class Foo', rebuild the DLL, but forgot to rebuild
the application that loads the DLL.  In this case you might want to make a
Delete() function so that you are freeing up the same size object that was
allocated (of course, if the sizes were different, you'd have other crashing
problems as well).


This latter problem is potentially addressed by instead using COM, in that
once you have a stable library, you don't have to rebuild the applications
that use the class, because rather than using the .lib and headers, you use
the binary object, and things like instantiating/freeing/functions are all
done via vtable lookup and the COM mechanisms (CoCreateInstance/Release
rather than new and delete). Mind you, COM specifications say you shouldn't
change the interface, just the implementation, or create new interfaces if
you need to revise the interface somehow. Don Box thinks COM is more OO
than C++, because of the binary compatibility (where C++ abstracts
interface from implementation on a source code level if I read him right).

But learning COM isn't necessarily for the faint of heart, and is of course
pretty platform specific, if it's just a small library for your own use,
then just remember to rebuild everything if you change the size of the
object in the library.

Probably simpler to add your own internal Delete function now that I think
about it :).



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] Adding fog to my mods...

[Pat Magnan]

The fog from DMC works in OpenGL mode only sadly. I believe the spirit fog
is the same, but you could try putting it in or contacting spirit's author
about it.



At 06:01 AM 1/15/2003 -0500, you wrote:

I've been trying to add fog to a couple of mods that I'm working on, but I
haven't had any success.  Actually, I've only tried one thing.  I looked
through the DMC code, and tried to do what was done there.  I think I did
everything in the code that needed to be done.  I made a map with an env_fog
entity, but there was no fog when I ran the test map.  I went back and tried
all sorts of things code-wise, but still no fog.

I've been noticing lots of mods with fog in them, so it made me wonder if
there's a way to have fog that's easy, and I'm just not seeing it.  It might
be in Half-Life now, and I just completely missed it.  Even if it's not easy
to implement, I would still like to know how it's being done.

Now that I think about it, I think I've asked how to get fog in HL twice
before on this list.  But now there actually are mods with fog, so I guess
everyone knows how to do it.  I feel like I missed out on some great stuff.

Maybe I just need to check out the fog in the Spirit source code...?

Jonathan Day
www.trepid.net


___
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] Bugtraq: hl exploits

[Pat Magnan]

At 04:16 AM 1/13/2003 -0500, you wrote:

>I'm also concerned after reviewing the site, I'm not sure if their hat
>colour is black, white, or maybe 'grey'.

Bugtraq is a community of Security Analysts not hackers. They normally
do not post exploits until the vendor is ready with a patch to fix the
exploit. In cases where the vendor ignores the security concern or fails


I wasn't referrring to bugtraq, I know who they are.. I was refering to
void.at ? or whoever posted the issue to bugtraq, guess I should have made
that more clear. ;)

void.at.whatever has 'hacking mysql' articles.. I know what colour
bugtraq's hat is, just wonder about those other guys, and if they've been
testing the exploit in the field for a while then decided to inform bugtraq
(and the world) :).

Pat 'sluggo' Magnan
Tour of Duty mod
http://www.tourofdutymod.com

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

Re: [hlcoders] Bugtraq: hl exploits

[Pat Magnan]

Cortex wrote:

Thx for the explanation :)

But, I wonder if the hacker can hack the program without its source code...
It looks quite hard if he hasnt the source code, because he wouldn't know
where there is a risk of buffer overflow, does he ?


I think that's a fallacy -- that open source code leads to more
exploits. The  ability to execute arbitrary code has been proven against
many closed (and open too) source products in the past.

Once they figure out there is an overflow (by sending arbitrarily long
input and seing the program crash), it's then just a matter of them
figuring out how to construct another program that takes advantage of it.

It's just a matter of understanding C's fundamental weakness (and also a
strength in terms of speed) -- a lack of runtime bounds checking for
arrays and the fact that strings are char arrays.

Don't forget, I don't have to know your fuction name to know you're
taking a string into it as a parameter, and since i'm passing a bunch of
garbage, i just tack on a few extra bytes, which is the return address
(in memory) of my nasty code. It probably takes some experimentation to
work out where to stick it. Or, they just pass the address for 128 bytes
or so (because that's a valid string), and blam.

I'm doing QA right now. One of the things I do is test for something
like that (field length validation), I don't always bother looking up in
the database schema how long the field is supposed to be, I just paste
in 10 character blocks until it cracks -- or gives me an error message.
I can then work out at what byte/character it blew up. Crackers would
likely follow a similar procedure.

Hope this isn't too off-topic for this list.. :D.

--


Pat 'sluggo' Magnan
Tour of Duty mod
http://www.tourofdutymod.com

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

Re: [hlcoders] Bugtraq: hl exploits

[Pat Magnan]

At 09:26 PM 1/10/2003 +0100, you wrote:

Well, explain it only if it can't give enough info about making hack for HL


Sorry, one more point. If we as programmers don't understand what hackers
do, how can we write secure code? :D. We should never be afraid to
understand how they work, such information doesn't necessarily lead to
cheats/hacks, it allows us collectively to eliminate them from our code.
It's certain they're (the black hats) educating each other, it's only fair
that we try to educate ourselves being the white hats we are (personally,
I'm more of a redhat) :).

Even with a cursory understanding that I'm currently getting for these
issues (pick up 'Writing Secure Code' from Microsoft Press -- it's not bad,
and the issues they talk about aren't totally Windows specific), i'm at
least taking a step that too many programmers tend to put off until later
-- thinking about writing the code securely from the get go. You don't have
to be a genius to not make a buffer overflow, you just have to think about
them when dealing with user input, and have a few 'standard tricks' in your
arsenal to avoid them. ;).

/me gets off soapbox



Pat 'sluggo' Magnan
Tour of Duty mod
http://www.tourofdutymod.com

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

Re: [hlcoders] Bugtraq: hl exploits

[Pat Magnan]

I'll try, i've just been reading my first book about how this works.

I'm a somewhat junior programmer so my understanding is somewhat lacking. I
believe that it is possible because of the way things are represented in
memory, when you're taking in input from a user, so something like this:

void somefunc(char * someNastyUserspaceStrings)
{
 char mybuf[32] = someNastyUserspaceStrings;
 ...
}

The attacker sends a longer than 32 byte string into that 'untrusted user
input',  putting code which overwrites the return address of the function
that should be in memory at or near? the end of the buffer, with the
address of a function call of your choice. Someone else can probably
explain that part better.

So rather than executing what you've specified when the function returns,
it proceeds to the attacker's nasty code.

If hlds_l is running as root, that can be pretty bad. Because the attacker
can setup any arbitrary code to run, they could say start a shell on port
17000, change root's password to what they want, connect to it, and be root
on your system.

There's many reasons why services that are known to run as root have been
attacked over the years, if the service runs as root and i can overflow a
buffer, I become root (hence the term 'rooted') with the right script.



At 09:26 PM 1/10/2003 +0100, you wrote:

Sebastian Steinlechner wrote:
> Actually, this advisory isn't researched to the end. The main problem
> lies in cl_dll's text_message.cpp. Looking at
> CHudTextMessage::MsgFunc_TextMsg() it's clear to see that there are
> MANY potential buffer overflows. e.g., READ_STRING is able to return
> a char array as long as 2048 chars, however, MsgFunc_TextMsg() does
> only declare an array of 128 chars, where the string returned by
> READ_STRING is copied into via strcpy without any checks.

And ? What can be done if a buffer overflows ? It's perhaps a basic
question, but I really don't know anything about *hacking*. And I'm sure I'm
not the only one there :)

Well, explain it only if it can't give enough info about making hack for HL
!

  - Cortex : HL ALBATOR coder & mapper
  - [EMAIL PROTECTED] & ICQ : 71548738


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


Pat 'sluggo' Magnan
Tour of Duty mod
http://www.tourofdutymod.com

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

Re: [hlcoders] Bugtraq: hl exploits

[Pat Magnan]

At 01:44 PM 1/10/2003 -0600, you wrote:

> Bugtraq (a security related mailing list) just posted 3 advisories
> concerning Half-Life (HLTV, ClanMod, Adminmod). I highly recommend to any
> coder and/or sysadmin to check these out (I'm not going to reproduce them
> here, bugtraq has an excellent archive). Although there's no fix available
> yet, you should at least know about the possible dangers.
>
> Just to clearify things: I'm in NO way related to those who found the
> vulnerabilities, I'm just telling you that these exist so you know what
> you'll have to deal with sooner or later.

Here's the URL's for those of you that are not bugtraq savy...

http://online.securityfocus.com/archive/1/306122/2003-01-07/2003-01-13/0

http://online.securityfocus.com/archive/1/306120/2003-01-07/2003-01-13/0

http://online.securityfocus.com/archive/1/306117/2003-01-07/2003-01-13/0

The AdminMOD and ClanMod exploits REQUIRE knowledge of the rcon password.


In theory the rcon password could be sniffed, as I believe they're plain
text? :(

I'm also concerned after reviewing the site, I'm not sure if their hat
colour is black, white, or maybe 'grey'.

There are several articles on 'attacking MySQL servers' or various other
things. There is a disclaimer about study purposes, etc.. for what's it's
worth.

The good news is that the potential seems limited for those not running
their servers as root, in the case of the clanmod one.



Pat 'sluggo' Magnan
Tour of Duty mod
http://www.tourofdutymod.com

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

Re: [hlcoders] Trains

[Pat Magnan]

botman wrote:

This was brought up a while ago, but nothing much was said on the topic.

Has


anyone gotten any deeper with the block problem for trains?

Trains have a limit of 6 or something (I haven't a clue the exact number)


of


players before it stops functioning and gibs someone or such. This is a


real


problem for multiplayer games that use trains for primary transportation..
And in large groups, sheesh it gets ugly.

Wondering if this might be fixed in the next patch as well or something.
Though my guess is no.



I don't think there is a limit on the number of entities.  I think it
depends on where they are physically (i.e. 6 may work fine as long as no one
is blocking anyone else, 2 may cause the second person to gib if they are
blocking the first person).

The problem with trains is that the moving brush tries to push players out
of the way so that it can move forward.  If a player is blocked from moving
(by another player?), the player will get gibbed.  What you really want to
do is implement a function similar to what Monsters have for pushing others
out of the way.  See the DispatchBlocked() function that monsters use to
tell each other they want someone to get out of the way.



Hmm, I'll have to take a look at that, what we ended up doing was
possibly similar, we just make the players push each other away a
certain distance..fun tweaking that code, we initially put a velocity of
like 600 on the players, and they went flying out of the helicopter
(CFuncTracktrain) :).

I guess the reason the players touching blocks the train is that the
brush is sliding, exerting a 'friction' on the player's feet, which is
fine until they touch, then there's too much friction, calling the
blocked() function for the tracktrain.. something like that anyway.


This is more of an SDK issue than it is an engine issue, therefore, an
engine patch won't do anything to fix this.

Jeffrey "botman" Broome

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




--


Pat 'sluggo' Magnan
Tour of Duty mod
http://www.tourofdutymod.com

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

Re: [hlcoders] models flickering

[Pat Magnan]

At 07:46 PM 1/9/2003 +, you wrote:

I'd suggest you pick up the Spirit of HL source code as this was solved by
Laurie.


Not really, trust me, the movewith stuff doesn't work too well on Network
games. We incorporated it, and things just don't work right. Client side
prediction may actually make it viable however.


- Original Message -
From: botman <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, January 09, 2003 7:03 PM
Subject: Re: [hlcoders] models flickering


> > Everyone knows that monster models will "flicker" if monster is moving
> > on train or platform. In BShift this is somehow fixed...
> >
> > Does anyone know how it can be fixed?
>
> If you are talking about monsters positions rapidly jumping, that's due to
> network "lag" between the server and the client (even in single player).
> The monster entities all exist on the server and they have to be sent to
the
> client in order for them to be rendered.  Each time the position changes,
a
> packet with the new position must be sent to the client (even in single
> player).  The faster the monster is moving, the faster his position is
> changing and the greater the jumping effect will be (moving from old
> position to new position).
>
> You could make the monster's positions predicted similar to the way player
> positions are predicted in multiplayer network games.
>
> Jeffrey "botman" Broome
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>

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


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

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

[Pat Magnan]

Sniper wrote:

A lot of people I know have the PS2 versions of the monster models as
replacements for the HD Pack. Not sure why the PS2 version is more detailed
than the HD Pack's. That doesn't make sense... since the PS2 doesn't have
near as much power as a goliath high-end PC has. Anyhow...



How many people buy a 'goliath high-end PC', and a budget gfx card? Too
many, or don't know how to use Hardware rendering? The answer is sadly
far too many. Or, don't bother to install drivers regularly... etc.

My point is that just because the specs may seem higher (I forget the
CPU an xbox has for example, but it's not a 2.4 GHz), the thing is, you
don't have the interoperability issues on consoles you have on PC,
meaning you can push poly limits far harder. If it runs on PS2, it's a
captive platform, so it runs on EVERY PS2. But if it runs on the highest
of the highest end PC, you can't ship something necessarily, because
you've got to ensure that it also runs on the 'average' PC.

At least, that would be my guess looking at some of the new console
games vs. new PC games.

--

Pat 'sluggo' Magnan
Tour of Duty mod
http://www.tourofdutymod.com

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

Re: [hlcoders] need help on CBaseMonster

[Pat Magnan]

Vyacheslav Djura wrote:

S> You should really use tasks and schedules to do something like this.

I've never worked with that :( Can you give me please link to some good
tutorial?



http://www.planethalflife.com/hlsdk2

Has a good _explanation_ of how they work (as well as good info on a
number of subjects).



Best regards,
 Vyacheslav "Hoaxer" Djura


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

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




--
--

Pat 'sluggo' Magnan
Tour of Duty mod
http://www.tourofdutymod.com

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

Re: [hlcoders] pev->sequence, pev->gaitsequence

[Pat Magnan]

> Can anyone go into how these work exactly, and how they work with the
> models. i.e Does gaitsequence control the leg animations only? If so

Not 'exactly', but you have the correct idea, pev->sequence is the
upper torso (shoot/hold weapon, etc), and pev->gaitsequence is the
legs. I found the code in player.cpp (setanimation() function I
believe) to be easy enough to modify for our needs.

how
> does the engine know which are the leg animations and which are the
torso
> animations?

Just a sort of guess, but it probably plays the sequence animation from
the pelvis bone (bip_01 I think is the name) 'up', and the pev-
>gaitsequence from there down, blending the two.

For example, if the player is holding a shotgun (pev->sequence is set
to 'ref_aim_shotgun'), and running (pev->gaitsequence is set to 'run'),
then the upper torso does whatever animation (if any) is in that
sequence, and all bones lower down are acted on by the run sequence.

How it actually works isn't required to successfully use the interface,
so I have yet to trace through any implementation details that we have
available, if any :).

>
> thanks,
>
> Rob.
>
> ___
> 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] SetThink() [hard question #1]

[Pat Magnan]

Bonus question:
#ifdef _DEBUG
#define SetThink( a ) ThinkSet( static_cast 
(a), #a )
#else

What's the difference for this debug version?



Specifically, the debug version expands to this:
ThinkSet ((CBaseEntity::*)(FnName), "FnName")

Hmm, ok, maybe I didn't expand perfectly the C++ bits, but the
'stringize' preprocessor operator gives you the function name as a
quoted string literal. ThinkSet having a declaration similar to:
 ThinkSet( void *, const char * );

 is the immaterial in this case return type ;)

The quoted literal is used to report a lack of EXPORT declaration in
debug mode (if it fails to find the EXPORT declaration). (it's passed to
the FunctionCheck function (say that ten times fast :P)) in debug builds
only.


--

Pat 'sluggo' Magnan
Tour of Duty mod
http://www.tourofdutymod.com

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

Re: Re[2]: [hlcoders] testing hlcoders

[Pat Magnan]

  Even the toilets are made of solid gold!


As a Canadian (cold winters and all), I've never understood why any SANE
person would want a gold (or any metal) toilet. Come visit Canada in
February in a house where the heat gets turned down at night you'll
figure out why this is a BAD idea :P




Pat 'sluggo' Magnan
Tour of Duty mod
http://www.tourofdutymod.com

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

Re: [hlcoders] say and say_team

[Pat Magnan]

Mikael Lindmark wrote:

This is a multi-part message in MIME format.
--
Has anyone made a small plugin that sole function is to prevent
says in game ?

example,

say 0
team_say 1
say_dead 1
team_say_dead 1

--  use would be great for alot of public servers


I didn't find a reference on metamod's site http://www.metamod.org, but
that doesn't mean someone's not working on this. I was going to come out
with a snarky comment about what would be better ( a 1337 H4x0r filter
), but apparently someone's already done that :P

It shouldn't be too hard to write something like that, if there isn't
one ;).

--

Pat 'sluggo' Magnan
Tour of Duty mod
http://www.tourofdutymod.com

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

Re: [hlcoders] VAC

[Pat Magnan]

Eric Smith wrote:

Mods using the VAC security modules will *not* need to have Valve "buy them
out".

-Eric



I think you're supposed to let people get all excited and THINK they
were bought out first aren't ya? :P

Glad to see, we've been getting the odd query about it also ;).

--

Pat 'sluggo' Magnan
Tour of Duty mod
http://www.tourofdutymod.com

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

Re: [hlcoders] woo

[Pat Magnan]

It's not that they're not sorted. Every reasonable mail client can sort.

They actually  _arrive_ in random order..

At 10:36 AM 11/28/2002 -0500, you wrote:

I use Mozilla, works wonderfully

-av

Florian Zschocke wrote:


Daniel Koppes wrote:


I get mine like that, in any old random order, questions and replies all
mooshed together :(


What is your sort order?

Florian.


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

[Pat Magnan]

Ok, so I'm not insane.. someone else I know on the list says he gets them
in order.. maybe my mail server is just being a turd, but I have the same
problem (getting replies before answers more often than not) ;).

At 06:45 PM 11/26/2002 -0500, you wrote:

This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
I love how this list likes to send us emails in a jumbled up order, so
stuff doesn't make sense, or is missing ;x





-omega

Blackened Interactive - http://blackened-interactive.com

Front Line Force - http://www.flfmod.com



--

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


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

Re: [hlcoders] grah

[Pat Magnan]

I think the server executes a SpectatorConnect type function, or there is
one somewhere. You could probably send them a timer update there?

Or, in the ClientPutInServer/InitHUD, send it if FL_PROXY is set?

Or, in the client, in the initialization of that panel, if
g_Engfuncs.IsSpecateOnly() returns true, request a timer update?

DRC_COMMAND_START should be a director event fired when the server signals
proxies that something has occured... ok that's a couple vague ideas that
could be bogus.

Hopefully someone who knows what the hell they're talking about tells me
I'm on crack and tells you the right way to do it :).

At 01:01 PM 11/24/2002 -0500, you wrote:

If I keep spamming the list, im sorry, outlook is being retarded. It
keeps telling me I can't send to the list for some reason so I don't
know if it's going out or not (and it's not the list telling me that)

What I'm trying to post--->
Hrm, well I'm scratching my head on this one..


Any of you know if there's a way to have a client connecting to the
proxy, make the proxy send a message to the server? I've tried placing a
servercmd and clientcmd inside DRC_CMD_START, to see if it would have
the proxy execute it, but to no success.



I need to update certain data (clock, etc) whenever a spectator connects
to the proxy. If a client is already watching the game, and the round
starts over, and whatnot, the normal clock update that's sent to all
clients works, however I can't seem to find a way to update hltv
spectators with any data that I need upon connection.

Help would be appreciated.

Thanks

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


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


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

Re: [hlcoders] FGD's and coding

[Pat Magnan]

Well, a couple things. If you've removed every halflife entity, and are
going to code all your own from scratch,  then NOT starting with a stock
Halflife one is a good idea. ;)

Otherwise, start there. Learn a bit about mapping (the use of entities),
and you'll start to connect the dots as far as the things that are in the
FGD relate to what Hammer's UI shows the mapper. I think to code entities
for Halflife, you HAVE to be able to build a boxy room and make a couple
entities work. Otherwise, your entities will be too hard to use for most
mappers, as you won't be conforming to standard idioms of entity use possibly.

An FGD is simply a way of customizing entity properties in Hammer's UI, and
linking between your entity's code (Look at the KeyValue function to see
how the code deals with the properties), and the compiled .bsp.

Otherwise, an FGD is pretty much a C++ object's data members, or, depending
on your COM experience, it's like an IDL file -- not C++, but ways to
document what a C++ class exposes as methods and data types (in this case
more like a struct), it's an intermediate language.

The data types are pretty simple (number or string), why everyone says
start with Halflife's is that it will become self documenting once you
spend enough time reading it (yes, that's the hard part.. cause it looks
like gibberish the first go). @SolidClass or @PointClass just means 'is it
a brush based or point entity'. That is, does the mapper drop in a brush,
and convert it to an entity, or do they pick a point. Again, a basic level
of mapping will help here.

The rest is just a bunch of data stuff. If you can write a C++ struct, you
can pretty much write a description of your entity in the FGD file, by
looking at other entities for the 'data types' and/or UI features you want
to expose.

For example:

@SolidClass base(SomeBaseClass) = MyEntityName : "Mappers Pretty Name"
[
  myvalue (choices) : "Mappers Pretty Name" :  =
  [
  0 : "choice 0"
  1 : "choice 1"
  ]
]

Things that the names may not make obvious:
(choices) - gives the mapper a dropdown (or combo box), the value is an int
in code
0 - the int value when mapper picks this
: "choice 0" - what mapper sees

MyEntityName - You'll use this in code in the LINK_ENTITY_TO_CLASS macro

In general, if it's quoted, then the mapper will see that value (there's
probably an exception I'm forgetting).

Copying and pasting is like inheritance is to C++ in my opinion. Wisely
used, it saves work and brain power for more important logic problems.
Poorly used, it's just a bloody mess.

That's about all I can think of that wasn't clear to me after mucking about
with it a bit.. and I don't know of any documentation per se.
http://www.planethalflife.com/hlsdk2 has something on creating an entity,
and he may go into the FGD there?

At 01:45 AM 11/24/2002 -0800, you wrote:

Howdy, I'm really interested in how FGD's work and such, I want to know the
real deal, is their some design documents, or
tutorials that are written on them, because I know everyone always says its
not hard just look at other peoples stuff,
but that just means cut and paste a stock halflife fgd if you aint got an
idea wth your doing, I have no idea how to
associate this stuff codewise, things like,
--stock fgd--
@SolidClass base(Door) = momentary_door : "Momentary/Continuous door"
--end of stock fgd--
means bloody nothing to me, how am i suppost to read this and just figure it
out ? see where im getting at ?
anyways it would be of so much help if theirs some sort of tutorials or
guides on writing fgd's (i.e. keys, syntax,
usage, etc) and hopefully, writing the code required portions and
everything, because i honestly don't feel right in
 giving out my mapmakers something i truly don't understand, which i want to
udnerstand myself.

Thanks ahead of time,
Paul


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


Pat 'sluggo' Magnan
Tour of Duty mod
http://www.tourofdutymod.com

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

RE: [hlcoders] water gone screwy :(

[Pat Magnan]

And I was just going to respond telling you that some of us have been
TRYING to but there was an error in the registration page.. fixed now.. so
never mind :)

At 09:45 AM 11/21/2002 -0800, you wrote:

If you want a place to post tutorials... *cough*
http://collective.valve-erc.com/ :)

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of omega
Sent: Thursday, November 21, 2002 9:27 AM
To: [EMAIL PROTECTED]
Subject: RE: [hlcoders] water gone screwy :(


Hrm, if I starless would fix my login on nofadz I could update that
tutorial a bit.. but anyway..

The rescale shouldn't physically affect the water, it doesn't rescale
brushes. So maybe you're just seeing something funny when you're in the
water due to the fact that those hulls don't work with zhlt, unless you
modify hlcsg.exe so that it'll read in the qcsg formatted hulls.txt
(which is what I used when I wrote that thing) as for being tied to
water, that's simply so it can move up/down (ie: like un undertow, when
you hit the button the water fills up) and to allow it to be rendered
transparent.

Now back to the hulls again, since you're using zhlt, zoner used a
different format on the hulls.txt . it just takes the positive values
and mirrors it exactly on the opposite. The old way you specified the
top and the bottom (you could make non-perfect boxes, the old way, so
you could in essence have the origin not in the exact center) which is
probably the problem here. So, you'll have to make new hulls and change
the code to use em.

There's also some other things missing from that tut to make it work
perfectly, too.


-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 jc
Sent: November 20, 2002 2:21 PM
To: [EMAIL PROTECTED]
Subject: [hlcoders] water gone screwy :(

all of a sudden the water in my mod has stopped working properly (in
doesnt
extend down fully any more - there is space under the water !!). the
water
was working before and im clueless as to what could be causing this.

i first noticed the problem after rescaling using this tut:
http://www.nofadz.com/blackened/hltuts/rescale.html

the maps are compiled with a modified hull file using ZHLT

has anyone had any problems like this before and can anyone suggest how
i
can fix this? i look at func_water in the sdk and its linked to a door
so im
even more clueless..

jc

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

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

___
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] Re: [hlcoders] Re: [hlcoders] Valve´s programmers need more sleep?

[Pat Magnan]

Valve's programmers need more sheep?


Ya, c'mon we all know that just because the luser knows about the bug it's
good enough to fix it right? Why do any programmers need sleep? :P

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

Re: [hlcoders] Re: [hlcoders] RE: [hlcoders] Valve´s programmers need more sleep?

[Pat Magnan]

Perhaps we all need more sleep then Mazor, I bought it too. :X

Thanks for showing us all up there Persuter :P

At 05:10 AM 11/8/2002 +, you wrote:

Heh, I didn't know it was a vec... oops. I thought it was just a z value for
a vector. I guess I'm off I was just thinking along the lines of
"anything times zero = zero"

-Mazor



From: Persuter <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [hlcoders] Re: [hlcoders] RE: [hlcoders] Valve´s  programmers need
more sleep?
Date: Thu, 07 Nov 2002 22:06:11 -0500

???

vec3_t  view_ofs;   // eye position

How does pev->view_ofs = 0 work? Sounds suspiciously like you just set
view_ofs to NULL.

Anyway, the difference is three floating-point multiplications. Not a huge
problem in a Think function. :)

Persuter

At 04:44 PM 11/7/2002 -0600, you wrote:

HAHA

*changes the line in the Firearms code to read:
pev->view_ofs = 0;
*

THANK YOU!

-Original Message-
From: [EMAIL PROTECTED]
[mailto:hlcoders-admin@;list.valvesoftware.com] On Behalf Of Oskar 'Zoot'
Lindgren
Sent: Thursday, November 07, 2002 3:37 PM
To: [EMAIL PROTECTED]
Subject: [hlcoders] Valve´s programmers need more sleep?


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

I found a funny thing:

"pev->view_ofs = pev->view_ofs * 0.0;" from trigger.cpp line 859


It can be done better... and you will get about
0.0008027% higher FPS, i have tested.

/ A bored Zoot


--

___
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



_
Help STOP SPAM with the new MSN 8 and get 2 months FREE*
http://join.msn.com/?page=features/junkmail

___
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] Re: [hlcoders] RE: [hlcoders] Valve´s programmers need more sleep?

[Pat Magnan]

Hmm... /me hides with tail between legs duh!

At 04:44 PM 11/7/2002 -0600, you wrote:

HAHA

*changes the line in the Firearms code to read:
pev->view_ofs = 0;
*

THANK YOU!

-Original Message-
From: [EMAIL PROTECTED]
[mailto:hlcoders-admin@;list.valvesoftware.com] On Behalf Of Oskar 'Zoot'
Lindgren
Sent: Thursday, November 07, 2002 3:37 PM
To: [EMAIL PROTECTED]
Subject: [hlcoders] Valve´s programmers need more sleep?


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

I found a funny thing:

"pev->view_ofs = pev->view_ofs * 0.0;" from trigger.cpp line 859


It can be done better... and you will get about
0.0008027% higher FPS, i have tested.

/ A bored Zoot


--

___
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


Pat 'sluggo' Magnan
Tour of Duty mod
http://www.tourofdutymod.com

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

[hlcoders] Re: [hlcoders] Valve´s programmers need more sleep?

[Pat Magnan]

Heh,

Are you suggesting *= will make that much difference? I think it's one or
two less opcodes that it compiles to or something, but I think i'd need to
see AT LEAST 0.0088027% difference to be
convinced of it's utility :)

At 10:37 PM 11/7/2002 +0100, you wrote:

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

I found a funny thing:

"pev->view_ofs = pev->view_ofs * 0.0;" from trigger.cpp line 859


It can be done better... and you will get about
0.0008027% higher FPS, i have tested.

/ A bored Zoot


--

___
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] Problem with client-side events

[Pat Magnan]

I think that A is the crux of the thing not working in one sense. If you're
sending a message on the entities' spawn (or playing an event), the event
is sent to clients far before they are in a state to 'play the event'.

Why not cache the values you need from your entity in member variables in
your keyvalue function, and then send them in InitHUD (just search by
classname, and xmit the data to the clients as they connect).

At least anything I've done that involves some map entity that is relevant
to the client (I render mine with yummy triAPI), I took that approach and
once I realised it was probably good to free the memory for it (big oops in
an internal build), it's been flawless.

One message isn't too costly, paticularly if it's just an 'on/off' type
(one byte).

Cheers,

Pat 'sluggo' Magnan
Tour of Duty mod
http://www.tourofdutymod.com

At 08:16 AM 10/27/2002 -0600, you wrote:

Just taking a swing here at this. But 2 problems I see right off with this
system is the fact that

A.) With a entity being in the map (your grate to emit steam) its spawn
function is called generally when the map is still loading (your not in the
map yet). So wouldnt sending a playevent while your not fully in the game,
b\c the server is still loading, pretty much void that call ?

B.) If this is a multiplayer mod then the other clients would not get this
event b\c its only called on map load. So clients connecting after that load
would never get the msg.

Thats the 2 possible problem areas Im seeing right off.

-Brandon "Axis" Russell
Programmer for
Day of Defeat



-Original Message-
From: [EMAIL PROTECTED]
[mailto:hlcoders-admin@;list.valvesoftware.com]On Behalf Of Persuter
Sent: Sunday, October 27, 2002 1:25 AM
To: [EMAIL PROTECTED]
Subject: [hlcoders] Problem with client-side events


Hey folks.

I have a question about client-side events. I'm trying to program something
simple here: an entity that sends a message to the client-side telling it
to start a particle system when it spawns, i.e., a grate from which dynamic
steam emits, or something similar.

I have the following code:

void CParticleEmitter::Spawn( void )
{
Precache();
PLAYBACK_EVENT_FULL( FEV_GLOBAL | FEV_UPDATE, edict(),
m_usStartParticle,
0.0, (float *)&g_vecZero, (float *)&g_vecZero, 0.0, 0.0, type, 0, 0, 0 );
}

void CParticleEmitter::Precache( void )
{
m_usStartParticle = PRECACHE_EVENT( 1, "events/particle.sc" );
}

(type, by the way, is the type of system to add)

Now, this all works fine and dandy, the event gets precached, the playback
function goes through fine, the problem is that on the client side the
corresponding function never gets called. On the client-side dll, I've
added the function declaration in both ev_hldm.cpp and hl_events.cpp, and
I've added the HookEvent in hl_events.cpp as well. I dunno, I'm perfectly
able to do weapons but for some reason this one has me at a loss, and the
one client-side non-weapon event in the SDK isn't much help. Am I missing
something required in the spawn function or on the client side that is
simply part of the weapons code?

Thanks for any help.

Persuter

___
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] Question about decreasing clipping rectangle

[Pat Magnan]

Maybe I'll shutup and go play halflife again :P I only recalled the
flashlight :X...

Anyway, the point is there is code there you can use that's what someone
was trying to say, I'm just not sure where it is anymore.. ;)

At 10:32 PM 10/24/2002 +0100, you wrote:

>>Halflife has no sprites for either health OR armor. They used
>>numbers for
>both.
>>
>>You may be however, thinking of the flashlight perhaps? Because
>>that is precisely what was done for the flashlight's battery
>>status.
>
>
>There is a suit icon, filling and unfilling as health (maybe only
>armor?) goes up and down...

Yeah, I meant the armour :P

It's just been a long time since I played the original HL, rather
than never :P


___
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] Question about decreasing clipping rectangle

[Pat Magnan]

I'm guessing that not enough people in the mod community ever played
Halflife. :)

Halflife has no sprites for either health OR armor. They used numbers for both.

You may be however, thinking of the flashlight perhaps? Because that is
precisely what was done for the flashlight's battery status.

At 12:01 PM 10/24/2002 +0100, you wrote:

>am
>wondering if the wise all experienced members of this list could
enlighten
>me on their opinion of which one to use, or
>another method at all.

Isn't this exactly what the original health HUD did? The "full"
healthsprite is shown over the top of the "empty" sprite, and
progressively draw less of the "full" sprite as you loose health.

Can't you just change the sprites in that code?

[ cruise / casual-tempest.net / transference.org ]


___
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] Question about decreasing clipping rectangle

[Pat Magnan]

At 05:56 PM 10/23/2002 -0700, you wrote:

>I've got another question, I'm interested in using 2 sprite graphics, one is
>a picture of a full health bar,
>and the other is a picture of an empty health bar, the empty bar has the
>full bar copied on top of it*layered over*

... snip ..

One way to do this is to:
- get the rectangle for the sprite (in vidinit, stored in some member variable)
- I used a temporary RECT, which is initialized to that dereferenced pointer
- I calculate the height (rect.bottom - rect.top) --> see below *
- I calculate an offset (height - (height * health / 100)
- Add this offset to the rect.top (+=) --> again, explained below *
- Set the sprite
- draw the sprite, passing this modified local variable rect as the fourth
parameter to SPR_Draw, and using the stored offset to determine where to
draw the top (y+offset).

* Ok, why was I adding rather than subtracting? 0, 0 is the top left corner
of the screen (like Windows GDI graphics), so to move stuff lower, you need
to add, not subtract. So the height of things is rect.bottom - rect.top
(not the other way about, mind you you might be able to add that way since
you'd get -ve numbers
-- but I much prefer to add or subtract rather than adding negatives, also
you'd have no clue they were negative values in the code, so you could mess
up changing it later).

So what you're seeing is as it should be, if you subtract, you'll move it
UP the screen. And you need to not only shorten your bar, you need to move
it down the screen as it gets smaller (in effect you're moving the top down
the screen, not just making the top closer to the bottom).

You can also use scissoring to do this, I'm not sure the precise approach,
but I imagine it is somewhat similar.

Hope that makes sense :)


Pat 'sluggo' Magnan
Tour of Duty mod
http://www.tourofdutymod.com

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

RE: [hlcoders] More hud difficulties

[Pat Magnan]

No, the problem isn't a bug in the 2.3 SDK, if it shows one of your hud
items, what possible bug would cause it not to run other ones that are
correctly coded? Doesn't make sense, ergo it's just your code.

My experience with hud elements is its generally always caused by a silly
little mistake i've made (i spent 4 hours working out that i did a =
instead of an == once :P). BTW, great trick for that -- write the test the
other way around, your code won't compile anymore... (e.g. don't do if (x
== 1), do if (1 == x), forget an equals sign and the compiler will stop you).

If you're having trouble debugging, i suggest you resolve that first and
foremost. www.thewavelength.net in the old site area, there's info on
setting up to debug your .dlls.

It sounds as if your init function isn't getting called at all. Step
through the init code in CHud, and when you get to this line:
m_Scouter.Init(); //<---My new hud piece

press F11 rather than F10, and you'll go into your function.

Or,  copy your new scouter thingy's files elsewhere, and start over. Do an
empty shell for everything, then just have vidinit and draw do minimal
things, like draw one of the halflife sprites, once you've succeeded there,
put your stuff back in slowly.

Could just be the rect is whacked or the sprite itself. Double check that
you added lines to the hud.txt at the top, or you'll pull your hair out for
hours for nothing.

At 03:57 PM 10/22/2002 -0700, you wrote:


>Make sure you have added a member variable for your new hud element to CHud
>and call Init() in CHud::Init() and VidInit() in CHud:VidInit();

Yup done that.

>If that is done, make sure that it is not your drawing code.  Comment out
>anything that might turn it off (or whatever you have that turns it on and
>then turn it on in VidInit().  Does it display now?  Then it is your
>communication code that is broken.

Nope still doesn't display, and it can't be the communication code because
none of that
is involved with activating/displaying the hud anymore because i moved it to
vidinit

>Put a breakpoint in Init() and VidInit().  Are they getting called?  Walk
>through VidInit() and make sure the sprite is getting loaded (just because
>it works elsewhere, doesn't mean you don't have an invisible typo here ;) )
>
>If it is getting loaded, put a breakpoint in the Draw and walk through
>it.  Are the x and y coords right?  (might be drawn off screen)  Are you
>getting to the actual drawing code?  Is the size of your rectangle that you
>pass into the draw valid?  Is the sprite NULL?

I can't seem to get it to run in the debugger
I set my debugging executable as hl.exe in my sierra/halflife folder
but It has no debugging symbols and when i try to go into mod viewer and
load
up my mod, it only finds 3 mods that I have to click refresh list to find
and wont even
let me activate those. I even tried specifying my program arguments to load
my mod directly
and It loads up the splash and all, but when you try to create a game, It
simply tries to create
a halflife game instead. I dunno I really believe theirs something buggy
with this sucker because,
I even through in a real quick failing assert in my new hud's init that
would guarantee to fail,
and it Didn't . I mean, It's not even calling the function.
And I dunno about anyone else but,
--hud.cpp--
..
m_flTime = 1.0;

m_Ammo.Init();
m_Health.Init();
m_Scouter.Init(); //<---My new hud piece
..
--End of hud.cpp--
It should at least call my init function, (it does call init, vidinit, and
display for my health hud just not my scouter)
Now, I'm using the new sdk 2.3, and I already heard their was one bug in it,
would this be another possible one ?





___
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] little bug in the SDK 2.3 ?

[Pat Magnan]

!! seems sort of obtuse, however, there are situations in which you'd want
to use it.

It says ! ( ! (something) ).

Truth table:

something ! something !!something
true   0 1
false  1 0

Why would we want to do this? If you've got an int, that's either 0 or
non-zero, and you want to return it to a bool type, you can get warnings
back from the compiler if you just pass one to the other.

A lot of beginning programmers mistakenly believe that 'true' expressions
== 1, this is not the case, 'truth' in C is simply non-zero. bool C++ data
types must always act as if they are 0 or 1, so !!something where something
is an int, behaves correctly as a bool (it's either 0 or 1 as demonstrated
above).

Lookup the C4800 compiler warning for more information on why passing ints
to bools can be bad.

Returning the value of a comparison operation is hard on the brain first
time you see it, it's an old trick, and part of the language. You can
return the results of a computation right? This is the same thing, we're
just not adding, we're using logical operators on it.

If you don't like it, or the code isn't self evident to you, declare this
on a few more lines, and don't worry about it.

However, it's no different than this perfectly valid syntax:

int MyAdd(int a, int b)
{
   return a + b;
}

Or this:

bool MyTest( int c )
{
 return (!!c);   // 0 or 1 depending on c's 'trueness'
}

Why we don't go through extra assignments is just a matter of a small
optimization in memory we're utilizing. You could allocate temporary values
in your functions, and unless you're calling them 5 bizzillion times in a
loop, write your functions that way if it is more clear to you.

Just because it CAN be written more optimally, doesn't mean it has to be,
because programmer efficiency is important too (I mean, not writing code
that's so nifty that in 3 months you don't have the foggiest idea what you
were getting at).

Pat 'sluggo' Magnan
Tour of Duty mod
http://www.tourofdutymod.com

At 01:05 PM 10/17/2002 -0400, you wrote:


Sorry for the newbie C++ coder question, but wouldn't it be wrong to use a
comparison on a return statement like was suggested? Is the !! an operator?
I haven't seen it before. From this thread I'm guessing that it converts any
>0 value to a 1 and any <0 value to 0, making the return perform an
assignment before returning? Just a guess. I know this is a little OT I
guess, so feel free to answer me off-list if you know. Thanks! =)

-Nick


-Original Message-
From: [EMAIL PROTECTED]
[mailto:hlcoders-admin@;list.valvesoftware.com]On Behalf Of Mark Gornall
Sent: Thursday, October 17, 2002 12:43 PM
To: '[EMAIL PROTECTED]'
Subject: RE: [hlcoders] little bug in the SDK 2.3 ?


valve use '!!' a few times in the sdk so it's probably deliberate.


-Original Message-
From: Cortex [mailto:cort@;meloo.com]
Sent: 17 October 2002 16:51
To: [EMAIL PROTECTED]
Subject: Re: [hlcoders] little bug in the SDK 2.3 ?


Oh yes, it could be a good explanation.
But, why wouldn't it be :
return (gEngfuncs.GetPlayerUniqueID( iPlayer, playerID ) != 0);

? It's much more concise... And it doesn't look as a mistake :p

 - Cortex : HL Albator coder and mapper ( www.hlalbator.fr.st )
 - email : [EMAIL PROTECTED]  &  ICQ : 71548738

David Flor <[EMAIL PROTECTED]> nous disait :

> Don't know if it's meant to be that way, but the "!!" convention
> ensures that the value is ALWAYS either a one or a zero.
>

__
This mail has been scanned for all known viruses by UUNET
delivered through the MessageLabs Virus Control Centre.
___
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] Config vars for improved graphics?

[Pat Magnan]

I believe the precise verbiage from the Modelling for Halflife document
states that 'textures may be no more than 1024 pixels in any direction'.

Textures most assuredly can be 512 x 512, no configuration value
needed. They compile with studiomdl or they don't, it will tell you if
it's 'too big'. There's no default, just a limit on what studiomdl
allows. By the way, 1024 x 1024 textures are about a meg of texture
memory, if you only have 3 models on screen at any one time, that's a
reasonable amount of memory to consume. Otherwise, I think you're just
wasting texture memory for nothing.

We've sized down weapon textures in photoshop, and found very little
difference between a 512 x 512 texture and a 256 x 256 one, if it's
done correctly. Don't forget, they're being applied to objects that are
only 200 pixels large on screen, if that.

Or are you talking about map textures? I'd suggest:
http://www.valve-erc.com/resources/?page=zhlt

I haven't found anything there that deals specifically with increasing
the dimensions, just the max texture memory. As I understand it, DOD
pushed this a little too hard in one release, and then scaled back,
limiting mappers after that experience.

Halflife may be old, but modern gfx systems, while stunning compared to
what we had in 98, are still lacking to throw away texture memory
frivilously. I'd spend it where it matters, i.e. on your 'main'
weapons, or frequently seen models, etc. If your artists can't work in
those constraints, maybe they should consider another profession ;),
tell them they should be happy not to be working with 4 bit palettes :)

Maybe I'm confused, but I don't know what config file you are asking
about either ;).

Pat 'sluggo' Magnan
Tour of Duty mod
http://www.tourofdutymod.com

At 01:49 AM 10/17/2002 -0400, you wrote:
This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
I remember hearing somewhere that there were 2 or more config vars you
could set to improve the graphics resolution of the HL engine over
the "default" values.  I think one had to do with raising Texture sizes
from 256 to 512 or 1024, and there were one or two others.

Can anyone tell me what the correct config file command line syntax
would be to set those, and what those variable names were?  If you have
a good URL that explains that would be great.

Thanks.

--

___
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] SDK 2.3 spectator modes

[Pat Magnan]

Make sure that iuser1 is 3 bits in delta.lst. The old spectator mode
had you specify it at 2 (so you can only have 4 possible values, you
need a couple more as the values go up to 6 with new spec modes).

Stupid high level languages making us forget the basics *grumble*
*grumble* :)

Once I worked that out, mine started working.

Pat 'sluggo' Magnan
Tour of Duty Mod
http://www.tourofdutymod.com

At 08:37 PM 10/16/2002 -0500, you wrote:
This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
How do I get the spectator modes to work? The only ones I can get to
work on the old ones from before... chase cam, locked chase, free look

-Mazor
___
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] First Person Spectator mode

[Pat Magnan]

Ok Mark, since we're both working at the same problem in paralell, the
V_FindViewModelByWeaponModel made sense and I sort of figured that out
before seeing Brandon's reply.

I just got the view setup correctly and the view models showing by changing
this:

(in V_CalcSpectatorRefdef, about line 1496-ish)

// predict missing client data and set weapon model ( in HLTV mode or inset
in eye mode )
if ( gEngfuncs.IsSpectateOnly() )
{
 V_GetInEyePos( g_iUser2, pparams->simorg, pparams->cl_viewangles );
(..  a few lines later, the code that looks up
V_FindViewModelByWeaponModel(), and sets the
 view model ), etc.

So it doesn't check for IsSpectateOnly() .. (initially i did 'la ugly hack'
and changed it to if (1) but, i'll just comment out the if and else blocks.

I'm not sure if this is a bad idea or not. Can anyone think of why that is
a bad idea?



Pat 'sluggo' Magnan
Tour of Duty mod
http://www.tourofdutymod.com

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

RE: [hlcoders] First Person Deadcam

[Pat Magnan]

I am also wondering about this. I think that you need to get
the 'observer targets' view model, and have that rendered, rather than
the spectating player's (which is probably why the pointer is null, she
doesn't have a weapon view model).

The view is positioned at the target's origin == pelvis bone for player
models, for me also (i.e. I don't think its the feet).

There are a couple of things that the SDK seems to omit (one of them
is 'forwarding' the spec_mode command to the server as is done
with 'follownext' when IsSpecatateOnly() is false).

This was the next little issue I was going to tackle, I will let
everyone know what I find out (I think its just a matter of adding some
code for the case where IsSpectateOnly is not true), adjusting the
spectating player's origin up to the eye level of the target, and
getting the target's view model rendered.



Pat 'sluggo' Magnan
Tour of Duty mod
http://www.tourofdutymod.com


At 10:32 AM 10/8/2002 +0100, you wrote:
Sorry, I wasn't clear enough. You become a spectator when you are dead
in my
mod (like CS) and I was talking about the 'First Person Cam' in the
spectator mode when you are looking through a 'living' players view so
his
p_model and v_model would be intact (I don't use p_models in my mod
anyway).

 My problem is the camera seems to be tracking the player correctly but
it
is at their feet not their 'eyes' and the view->model pointer is null.

Thanks,
Mark.

-Original Message-
From: Brandon "Axis" Russell [mailto:[EMAIL PROTECTED]]
Sent: 08 October 2002 00:50
To: [EMAIL PROTECTED]
Subject: RE: [hlcoders] First Person Deadcam


B\c I believe at the point of death (death animation being played) the
p_models are not shown b\c all items are removed from the player.
Player is
just a stripped entity that is doing a death animation then his model
is not
drawn till you spawn() again. If you wanted the p_model to stay longer
you
would have to store off the current p_model at point of death and keep
the
pev->weaponmodel set during death animation I would think.

Hope that helps,
-Brandon
Programmer for
Day of Defeat

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Mark Gornall
Sent: Monday, October 07, 2002 4:26 AM
To: '[EMAIL PROTECTED]'
Subject: [hlcoders] First Person Deadcam


Hi,
  I merged with SDK2.3 and got it all running. The first person deadcam
works but there is no weapon model displayed. Any idea why? or where I
should be looking?

Thanks,
Mark.
www.planethalflife.com/vampire
www.planethalflife.com/ios




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

RE: [hlcoders] How do you guys deal with players harrasing other players?

[Pat Magnan]

We've also learned that the worst thing you can do in playtesting is
discourage them from finding exploits.. oops (They kind of get carried away
with them sometimes and it is annoying, but the playtesters are volunteers
and i guess they deserve to have some fun too ).

However, thanks to everyone's ideas, we've decided not to do anything
impulsively that we'll regret, and we've just gone and tightened up what we
can. I still think there is a way they are causing floods, but it's tough
to tell (only some server operators updated their machines).

Cheers all,

At 10:44 AM 9/30/2002 -0500, you wrote:
>The best plan is to code with the assumption that every thing your adding in
>will be used as an exploit. You also have to program in the mind of a
>cheater. As your writing your new systems think "If I was a cheater how
>could I break this". Its a sad world, but the best way to win is to be one
>step ahead of the cheaters. If someone is blocking a door leading from a
>spawn area. Then this doesnt mean you have to program stuff to combat it. It
>just means you and your mapper needs to rethink the paths from a spawn area.
>In Day of Defeat we was hit with this one alot. So we took out the "spawn in
>a room with 1 exit door" train of thought and randomly spawned people in a
>area with multiple exits out if possible.
>
>Thats probably the best advice to take and  use in this situation. Just
>program with the mind set of how can I break this.
>
>-Brandon "Axis" Russell
>Programmer for Day of Defeat
>
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED]]On Behalf Of Ryan
>"Professional Victim" Desgroseilliers
>Sent: Wednesday, September 18, 2002 5:51 PM
>To: [EMAIL PROTECTED]
>Subject: Re: [hlcoders] How do you guys deal with players harrasing
>other players?
>
>
>Permanant bans should really not be added for any kind of arbitrary
>decision.  This kind of feature relies too heavily in the "perfect world"
>assumption -- more often than not, players will simply vote "yes" when
>unaware of the circumstances of the vote just to get that annoying prompt
>off the screen.  Not to mention the arbitrary bans handed out on many
>style-obsessed servers for using tactics the server doesn't approve of, and
>the general "ban first, instruct later" mentality many players have towards
>newbies unaware of the server rules.  IMO, it's much more effective to work
>to remove the possible venues of abuse than to add features encouraging what
>is essentially vigilante justice.
>
>
>- Original Message -
>From: "botman" <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>
>Sent: Wednesday, September 18, 2002 7:09 AM
>Subject: Re: [hlcoders] How do you guys deal with players harrasing other
>players?
>
>
> > > build some vote features into your mod (vote_cheater, vote_lamer,
> > > vote_spammer). not a console based one, but an onscreen one.
> > >
> > > if more than 50% of the users vote to ban someone, the server does it,
>and
> > > then sends a notice to the server your mod's page is hosted on, (with a
> > > small reciever program running) that takes the ban notice, and applys
>the
> > > wonID to a global banlist. Each server sends a message to this main
> > server,
> > > and syncs up it's global banlist (with options to sync lists like:
>cheater
> > > list, lamer list, and spamer list available) on a regular basis.
> >
> > ...and like I said, you'd have a server with 8 players on it (5 of them
> > being from myg0t) and the myg0t players would start banning everyone else
> > left and right (since they comprise more than 50% of the players).
> >
> > Bad idea, IMHO.  Also global ban lists are a bad idea unless you are
>99.997%
> > sure the player is cheating or constantly disruptive (i.e. has been
> > disruptive on more than one occasion).
> >
> > Jeffrey "botman" Broome
> >
> >
> > ___
> > To unsubscribe, edit your list preferences, or view the list archives,
>please visit:
> > http://list.valvesoftware.com/mailman/listinfo/hlcoders
> >
> >
> >
>
>___
>To unsubscribe, edit your list preferences, or view the list archives,
>please visit:
>http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>
>
>
>___
>To unsubscribe, edit your list preferences, or view the list archives,
>please visit:
>http://list.valvesoftware.com/mailman/listinfo/hlcoders

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

[hlcoders] How do you guys deal with players harrasing other players?

[Pat Magnan]

I know this sounds OT for a coding forum, bear with me for a sec.

We've been publically released for a very very short time, and most of
our servers seem to have been targetted by a group of annoying little
players that call themselves 'myg0t'. http://www.myg0t.com if you want
to see more about these annoying children.

I'm sure we're not the first mod to experience this, but if we were as
big as CS or something, they would get lost in all the noise.

Do you guys recommend implementing things in your codebase to cause
them havoc back? Has anyone learned little things to watch out for in
terms of exploits they commonly use that we can all benefit from?

I know we learned a couple things the hard way, and we now have to put
things like 'spam control' on our voice comm, so that these idiots
can't overflow all the players on their team and disconnect them. That
was possibly just poor design on our part, we forgot that all gamers
aren't nice,  well adjusted people, who just want to have fun. :(

I know some of this is the server admin's realm, but if we can give
them tools to make it easier, then we will.

Can we formally request a 'format annoying little punks hard drive'
engine command from valve? :P

Also, does anyone know if that exploit that allowed players in the CS
beta 4 days to constantly reconnect (avoiding the round timer when
dead) still works (they're using it on us, so it seems to work in an
unmodified SDK)? Am I missing a fix that I should be using when clients
reconnect, that breaks that exploit? How does it work anyway.. etc.

I guess we're just feeling a little harrassed by these guys, and if all
of us can benefit from sharing 'tips' to avoid letting any one player
be annoying, so much the better.

Cheers,



Pat 'sluggo' Magnan
Tour of Duty mod
http://www.tourofdutymod.com
___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] hl.exe bug report ?

[Pat Magnan]

Change the working directory in the C program. I forget the function
call that does this, but there should be a Win32 function that does it
for you.

Mind you, that would involve querying the registry to find the halflife
directory. Why would you want to do that? Why not just make a shortcut
like everyone else, and save yourself the hassle :P

> Well, but how can I get the execl function working with hl.exe -game
albator
> ??
>
>  - Cortex : HL Albator coder and mapper ( www.hlalbator.fr.st )
>  - email : [EMAIL PROTECTED]  &  ICQ : 71548738
>
> - Original Message -
> From: "Cortex" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Sunday, June 09, 2002 9:32 PM
> Subject: Re: [hlcoders] hl.exe bug report ?
>
>
> | wow... thx :) I understand now the "Change directory" command of
> | Worldcraft/Hammer.
> |
> | All works fine now :) It was "quite easy" :)
> |
> |  - Cortex : HL Albator coder and mapper ( www.hlalbator.fr.st )
> |  - email : [EMAIL PROTECTED]  &  ICQ : 71548738
> |
> | - Original Message -
> | From: "Kuja" <[EMAIL PROTECTED]>
> | To: <[EMAIL PROTECTED]>
> | Sent: Sunday, June 09, 2002 9:20 AM
> | Subject: RE: [hlcoders] hl.exe bug report ?
> |
> |
> | | Yeah, the shortcut has to "start in" the hl directory, or it
doesnt know
> | how
> | | to find your mods.
> | |
> | | -Original Message-
> | | From: [EMAIL PROTECTED]
> | | [mailto:[EMAIL PROTECTED]]On Behalf Of Cortex
> | | Sent: Sunday, June 09, 2002 2:02 AM
> | | To: [EMAIL PROTECTED]
> | | Subject: [hlcoders] hl.exe bug report ?
> | |
> | |
> | | Hi,
> | |
> | | a month ago, I distributed the first private release of my mod to
a few
> | | players, to get them test it. In the install procedure, a link is
added
> to
> | | the start menu, with arguments : -game albator. When the testers
have
> ran
> | | the mod by this link, in the "LAN/Create game" menu, the maps of
HL
> | Classic,
> | | instead of mines, were displayed. Really annoying... I really
don't know
> | | what happen, since when I use "Start menu/Run... -> ...\hl.exe -
game
> | | albator", all works fine...
> | |
> | | Recently, for the need of my mod, I made a little DOS app which
use
> execl
> | to
> | | launch hl.exe. Here is the line which launches HL :
> | |
> | | _execl(hlpath, hlpath, "-console", "-game Albator", "-dev", 0);
> | |
> | | The bug which was reported by the beta-testers happens when I use
the
> DOS
> | | app... So, it's very weird, because all "my" new game (btns_main,
> etc...)
> | | interface is loaded !
> | |
> | | The other thing which amazes me is that FLF, FA, CS (etc...) uses
simple
> | | links like the one I use. They work fine for them... So, it'd be a
> single
> | | problem with MY mod or something else has already ran into
this ???
> | |
> | | Thx in advance for any answer...
> | |
> | |  - Cortex : HL Albator coder and mapper (
www.hlalbator.fr.st )
> | |  - email : [EMAIL PROTECTED]  &  ICQ : 71548738
> | |
> | |
> | | ___
> | | 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
>
>

---
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

Re: [hlcoders] string to #define

[Pat Magnan]

Cool, just find that 'holy grail' for someone else, and it's all good...

At least, that's my theory... :)

Cheers,

Pat 'sluggo' Magnan
Tour of Duty Mod
http://www.tourofdutymod.com

- Original Message -
From: "Mugsy _" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, May 29, 2002 8:13 PM
Subject: Re: [hlcoders] string to #define


>
> Yes! I had given up on this idea, but I guess I didn't imagine it after
all
> :) This is exactly what I was thinking of.
>
> Thanks for finding this
>
> Mugsy
>
> >From: "Pat Magnan" <[EMAIL PROTECTED]>
> >Reply-To: [EMAIL PROTECTED]
> >To: <[EMAIL PROTECTED]>
> >Subject: Re: [hlcoders] string to #define
> >Date: Tue, 28 May 2002 22:21:35 -0500
> >
> >Hey Mugsy:
> >
> >Did you ever figure this out? I was browsing the comp.lang.c newsgroup
FAQ
> >(ok, somebody needs a life :P), and found this:
> >Question 11.17
> >I'm trying to use the ANSI ``stringizing'' preprocessing operator `#' to
> >insert the value of a symbolic constant into a message, but it keeps
> >stringizing the macro's name rather than its value.
> >
> >-
> >
> >You can use something like the following two-step procedure to force a
> >macro
> >to be expanded as well as stringized:
> >
> > #define Str(x) #x
> > #define Xstr(x) Str(x)
> > #define OP plus
> > char *opname = Xstr(OP);
> >
> >This code sets opname to "plus" rather than "OP".
> >
> >An equivalent circumlocution is necessary with the token-pasting operator
> >##
> >when the values (rather than the names) of two macros are to be
> >concatenated.
> >
> >References: ANSI Sec. 3.8.3.2, Sec. 3.8.3.5 example
> >ISO Sec. 6.8.3.2, Sec. 6.8.3.5
> >
> >
> >http://www.eskimo.com/~scs/C-faq/q11.17.html
> >
> >I think you were trying to get the preprocessor to expand and then
> >'stringize' your #define'd constant, passing it's value as the arg to
your
> >func, which is what that code appears to do.
> >
> >
> >
> >Pat 'sluggo' Magnan
> >Tour of Duty Mod
> >http://www.tourofdutymod.com
> >
> >
> >
> >
> >- Original Message -
> >From: "Mugsy _" <[EMAIL PROTECTED]>
> >To: <[EMAIL PROTECTED]>
> >Sent: Tuesday, May 07, 2002 2:29 AM
> >Subject: Re: [hlcoders] string to #define
> >
> >
> > > > > > > > > > The pre-processors scan through source files replacing
the
> > > >define
> > > > > >with
> > > > > > > > > > the value.
> > > > > > > > > >
> > > > > > > > > > I'm not 100% sure, but about 95% that it looks in
strings
> >as
> > > >well,
> > > > > >so
> > > > > > > > > >
> > > > > > > > > > someFuncThatTakesAString("WEAPON_GARAND");
> > > > > > > > > >
> > > > > > > > > > will get changed to
> > > > > > > > > >
> > > > > > > > > > someFuncThatTakesAString("2"); file://constant string
2\0
> > > > > > > > > >
> > > > > > > > > > before its compiled.
> >
> >
> >___
> >To unsubscribe, edit your list preferences, or view the list archives,
> >please visit:
> >http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
>
> _
> Get your FREE download of MSN Explorer at
http://explorer.msn.com/intl.asp.
>
> ___
> 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] string to #define

[Pat Magnan]

Hey Mugsy:

Did you ever figure this out? I was browsing the comp.lang.c newsgroup FAQ
(ok, somebody needs a life :P), and found this:
Question 11.17
I'm trying to use the ANSI ``stringizing'' preprocessing operator `#' to
insert the value of a symbolic constant into a message, but it keeps
stringizing the macro's name rather than its value.

-

You can use something like the following two-step procedure to force a macro
to be expanded as well as stringized:

#define Str(x) #x
#define Xstr(x) Str(x)
#define OP plus
char *opname = Xstr(OP);

This code sets opname to "plus" rather than "OP".

An equivalent circumlocution is necessary with the token-pasting operator ##
when the values (rather than the names) of two macros are to be
concatenated.

References: ANSI Sec. 3.8.3.2, Sec. 3.8.3.5 example
ISO Sec. 6.8.3.2, Sec. 6.8.3.5


http://www.eskimo.com/~scs/C-faq/q11.17.html

I think you were trying to get the preprocessor to expand and then
'stringize' your #define'd constant, passing it's value as the arg to your
func, which is what that code appears to do.



Pat 'sluggo' Magnan
Tour of Duty Mod
http://www.tourofdutymod.com




- Original Message -
From: "Mugsy _" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, May 07, 2002 2:29 AM
Subject: Re: [hlcoders] string to #define


> > > > > > > > The pre-processors scan through source files replacing the
> >define
> > > >with
> > > > > > > > the value.
> > > > > > > >
> > > > > > > > I'm not 100% sure, but about 95% that it looks in strings as
> >well,
> > > >so
> > > > > > > >
> > > > > > > > someFuncThatTakesAString("WEAPON_GARAND");
> > > > > > > >
> > > > > > > > will get changed to
> > > > > > > >
> > > > > > > > someFuncThatTakesAString("2"); file://constant string 2\0
> > > > > > > >
> > > > > > > > before its compiled.


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

Re: [hlcoders] DEM

[Pat Magnan]

That's right, there's no format.. they use some kinda random algorythm (sp)
on both ends to figure out how to play it .. :P

I think botman was suggesting that it is an _undocumented_ format. ;) At
least that would be my guess, but then, maybe Occam was wrong .. :)


Pat 'sluggo' Magnan
Tour of Duty Mod
http://www.tourofdutymod.com

- Original Message -
From: "Tim Holt" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, May 24, 2002 12:08 PM
Subject: Re: [hlcoders] DEM


> --
> [ Picked text/plain from multipart/alternative ]
> There isn't a description, or it has no format? :^)
> botman wrote:
>
> >>sorry if i'm using the wrong list.
> >>Does anybody know where i can get a DEM-File Format Description ?
> >>
> >>
> >
> >There isn't one for the Half-Life demo file format.
> >
> >Jeffrey "botman" Broome
> >
> >___
> >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] (no subject)

[Pat Magnan]

This may not be a strictly code question ;)

You can have the player models show up and available by placing them into
the directory structure as follows:
yourmod/models/player/modelname/modelname.mdl

Depending on whether the model selection is done by the player in the
advanced options screen or not, then you would need to add no code, as I
understand it.

Otherwise, you can use this type of code to select models for the players:
g_engfuncs.pfnSetClientKeyValue(entindex(),
g_engfuncs.pfnGetInfoKeyBuffer(edict()), "model", "usmc-regenlistee");

Note, that you may have scoping issues, entindex() and edict() are
CBasePlayer (not totally correct*) function, and we happen to set player
models in a function in that class, otherwise, if you already have a pointer
to a CBasePlayer kicking around, then call it like pWhatever->edict()

"usmc-regenlistee" would be your model name - .mdl (still need same
directory structure for game to load it).

To my knowledge, player models are not precached, at least we don't, and we
have no troubles.

Cheers,


Pat 'sluggo' Magnan
Tour of Duty mod
http://www.tourofdutymod.com

* I believe that they are CBaseEntity member functions as well, but anyway,
you get my point :P
- Original Message -
From: "Brandon Robertson" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, May 12, 2002 1:56 PM
Subject: [hlcoders] (no subject)


> Where is the code for placing player models in my game? I already have the
> models made, i just wanna know how to get them in my mod.
>
>
> _
> Join the world's largest e-mail service with MSN Hotmail.
> http://www.hotmail.com
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders

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

Re: [hlcoders] CS Retail support

[Pat Magnan]

> wondering if people know what needs doing to a mod to support CS
retail.
>


We're busily testing our mod out with a handful of beta testers, some
of whom run CS Retail.

Apart from the general things like providing all the needed content
that differs between CS Retail's PAK and the valve/PAK0.PAK (which
isn't an issue, if all our models are our own), the only issue I ran
into was with the installer.

Unfortunately, I'm at work and don't have the installSheild version I
need to look at it, but the normal registry keys that you need to check
for Halflife, won't find CS retail. There's a couple different keys to
that you have to query to get the path to CS Retail/Halflife.

Depending on whether you'll eventually be replacing the stuff in the
Halflife PAK in the future or not, you might just want to pull the
missing artwork from the PAK0.PAK and put it into your mod's dir now.
That means one installer for CS Retail and Halflife.

At least we've managed to get away with one until now ;)

If someone else can't come up with the registry keys here in a day or
two, send me an email, and I'll send you the specifics.

Cheers,

Pat 'sluggo' Magnan
Tour of Duty mod
http://www.tourofdutymod.com
___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders

Re: [hlcoders] CS Retail support

[Pat Magnan]

> wondering if people know what needs doing to a mod to support CS
retail.
>


We're busily testing our mod out with a handful of beta testers, some
of whom run CS Retail.

Apart from the general things like providing all the needed content
that differs between CS Retail's PAK and the valve/PAK0.PAK (which
isn't an issue, if all our models are our own), the only issue I ran
into was with the installer.

Unfortunately, I'm at work and don't have the installSheild version I
need to look at it, but the normal registry keys that you need to check
for Halflife, won't find CS retail. There's a couple different keys to
that you have to query to get the path to CS Retail/Halflife.

Depending on whether you'll eventually be replacing the stuff in the
Halflife PAK in the future or not, you might just want to pull the
missing artwork from the PAK0.PAK and put it into your mod's dir now.
That means one installer for CS Retail and Halflife.

At least we've managed to get away with one until now ;)

If someone else can't come up with the registry keys here in a day or
two, send me an email, and I'll send you the specifics.

Cheers,

Pat 'sluggo' Magnan
Tour of Duty mod
http://www.tourofdutymod.com
___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders