[hlcoders] Debug command line

[Eric Van Huss]

--
[ Picked text/plain from multipart/alternative ]
For debugging the orange box HL2 multiplayer, which hl2.exe should we specify 
in the debugger options? The only one that seems to work is the only located in 
the 'half-life 2 episode two' folder. But I'm not sure that's the right one to 
use.

Thanks
--

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

RE: [hlcoders] Beta SDK: Scratch SDK Bug Repository

[Eric Van Huss]

--
[ Picked text/plain from multipart/alternative ]
The fix with the server.dll and client.dll not appearing in the bin folder 
doesn't work with the hl2multiplayer.  The Custom Build Step->Command Line has 
...\bin  instead of  ...\bin\client.dll , client.pdb, etc.  Also compiling with 
the ...\bin creates a file in the mod directory named bin that prevents from 
compiling after I fixed the line.
In the same Custom Build Step->Outputs with the Release Client version it has 
two quotation marks around the ; in the middle of the line.  This prevents it 
from compiling the client as well.

The run_mod.bat doesn't work.  Gives error message Failed to load launcher dll. 
 The specified module could not be found.  I closed and reopened steam and saw 
the mod listed and it started up.

> From: [EMAIL PROTECTED]> To: hlcoders@list.valvesoftware.com> Subject: 
> [hlcoders] Beta SDK: Scratch SDK Bug Repository> Date: Fri, 25 Jan 2008 
> 20:19:30 -0500> > --> [ Picked text/plain from multipart/alternative ]> As I 
> don't know the common process for reporting issues with a beta SDK> release, 
> I thought I'd go ahead and start a new thread so that we can> consolidate 
> this. We all know of the issues regarding the iviewrender and> the gameid at 
> this point, so I'll post three issues regarding the Scratch> SDK that haven't 
> been mentioned as of yet.> > > 1. No matching RecvTable for SendTable 
> 'DT_WaterBullet'. Essentially> a new class was included in the server 
> project, CWaterBullet, but no> corresponding client implementation was added. 
> If a server attempts to> launch with CWaterBullet still present in the 
> project, the server will> immediately shutdown. Removal of this class removes 
> the error.> 2. No matching RecvTable for SendTable 'DT_WeaponCycler'. Same 
> issue> as above, save in this case the weapon cycler is buried in another 
> file with> a nice comment saying "FIXME: This has always been broken." 
> Removal of this> class fixes the error.> 3. One the two above issues are 
> solved, should a server attempt to> launch the included sdkvehicles map the 
> game will crash with the following> GameEngine error: UserMessageBegins: 
> Unregistered message 'Rumble'> > If anyone knows how to fix error 3 or knows 
> of any additional problems, feel> free to reply here.> > -Brackhar> --> > 
> ___> To unsubscribe, edit your 
> list preferences, or view the list archives, please visit:> 
> http://list.valvesoftware.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 SDK impossibly buggy.

[Eric Van Huss]

The page helped me a lot as well. Although there is one that doesn't seem to
work any more for the mp sdk or maybe it was just a fix for the single
player sdk?
http://developer.valvesoftware.com/wiki/SDK_Known_Issues_List#Server:_util.cpp_.28531.29_:_Assertion_Failed:_.21.22UTIL_GetLocalPlayer.22

I 'fixed' it but don't know if it's totally correct. Here's the changes:

else if ( pEvent->pObjects[index]->GetGameFlags() & FVPHYSICS_PLAYER_HELD )
{
// if the player is holding the object, use it's real mass 
(player holding
reduced the mass)
CBasePlayer *pPlayer = NULL, *temp_player = NULL;

temp_player = 
ToBasePlayer(pEvent->pEntities[index]->GetOwnerEntity());
if(temp_player && temp_player->edict()){
pPlayer = temp_player;
}
Assert(pPlayer && "object with FVPHYSICS_PLAYER_HELD but no 
player holding
it");

if (pPlayer)
{
float mass = pPlayer->GetHeldObjectMass( 
pEvent->pObjects[index] );
Assert((mass > 0) && "player was holding object so mass 
should be
non-zero");
if (mass > 0)
{
invMass = 1.0f / mass;
}
}
}





From: Jorge Rodriguez <[EMAIL PROTECTED]>
Reply-To: hlcoders@list.valvesoftware.com
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] New SDK impossibly buggy.
Date: Mon, 18 Dec 2006 13:35:15 +0900

[EMAIL PROTECTED] wrote:

Yeah I don't think Valve QA uses debug builds...  See
http://developer.valvesoftware.com/wiki/SDK_Known_Issues_List and the
bugzilla page for asserts.  Although I can't seem to find the first one
you mention at the moment.  I thought I'd filed it though so I'm holding
off on re-filing it.



Yes, I use that page to fix many of the problems in my SDK. I check it
semi regularly to fix the more recent ones. It's very helpful.

--
Jorge "Vino" Rodriguez


___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.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 materials

[Eric Van Huss]

Sorry have to reply to the broken long thread to finish this subthread off.

Anyway, there was nothing wrong at all...

I had accidently put my materials I was testing in mod/sprites instead of
mod/materials/sprites.  So now everything works, including unlitgenerics.

EJ



From: "Eric Van Huss" <[EMAIL PROTECTED]>
Reply-To: hlcoders@list.valvesoftware.com
To: hlcoders@list.valvesoftware.com
Subject: RE: [hlcoders] Question about materials
Date: Tue, 14 Nov 2006 07:13:58 -0700

Sorry for the e-mails... but I had misunderstanding about the code which
lead me to errors in testing and in my previous findings. I'll try to give
myself more time(sleep) before e-mailing about a problem again.
So disregard everything I said, except for the code. The code actually
works
if you need to set a rendermode for a material that's not suppose to be
opaque. Like the visual bug with the physics canon when you first start a
sdk hl2dm game.


EJ



From: "Eric Van Huss" <[EMAIL PROTECTED]>
Reply-To: hlcoders@list.valvesoftware.com
To: hlcoders@list.valvesoftware.com
Subject: RE: [hlcoders] Question about materials
Date: Mon, 13 Nov 2006 07:01:05 -0700

I stuck with a sprite instead of an unlitgeneric.  But I guess
$spriteRenderMode inside a vmt file doesn't work.  Checking the Int value
of
the IMaterialVar associated with $spriteRenderMode returns 0, when in the
vmt it's set to 3.  It can be done in code though, which I took from
Valve's
CEngineSprite::SetRenderMode. The problem was with creating a mesh(rpg
laser
dot,redglow1) with a material who's rendermode hadn't been set. I guess
you
should always set the rendermode for the material a mesh uses before it
draws? Anyway here's the code that makes it work, I got it from
CEngineSprite::SetRenderMode. (what seems weird that when a mesh is used,
it
could potentially use the material's render mode set by another entity if
you don't do this)

I included:  "materialsystem/imaterial.h" and
"materialsystem/imaterialvar.h"

//use CMaterialReference's operator method to store it's IMaterial pointer
inside testMaterial
IMaterial* testMaterial(m_hSomeCMaterialReference);
static unsigned int spriteRenderModeCache;
IMaterialVar* pTMaterialVar = testMaterial->FindVarFast(
"$spriteRenderMode", &spriteRenderModeCache );
if (pTMaterialVar)
{
 if(pTMaterialVar->GetIntValue() != kRenderGlow)
 {
  pTMaterialVar->SetIntValue( kRenderGlow );
  testMaterial->RecomputeStateSnapshots();
 }
}

This is also the reason when you first start up a fresh sdk MP game, your
physics cannon has opaque sprites in a couple of it's textures. I did a
quick fix with some code and the physics cannon was fixed. In my quick fix
I
used the same rendermode for all the textures so some of em looked a
little
wonky but it still worked. I just need to tweak it or maybe look again at
the texture's vmt file...
So are material's suppose to have a default rendermode based on what they
are (e.g. Sprite,unlitgeneric,etc.). Or is it always 0 unless set? Are
unlitgenerics suppose to use $spriteRenderMode?
Another strange thing happened when I called aMaterial->Refresh() during
testing. After that I called FindVarFast so I could look at the int value
of
$spriteRenderMode, it was set to a large int(792588). Whats weird is that
I
called FindVar right after and the int value was different. It was
(3,170,352) which is the first int, but just bit shifted to the left 2
times. 3,170,352 when looking at MaterialVarFlags_t seems to line up with
a
good default render setting bitmask. So is this how aMaterial->Refresh()
is
suppose to act? Using the code from above with out using Refresh() makes
them both return 3.

EJ



From: "Eric Van Huss" <[EMAIL PROTECTED]>
Reply-To: hlcoders@list.valvesoftware.com
To: hlcoders@list.valvesoftware.com
Subject: RE: [hlcoders] Question about materials
Date: Sun, 12 Nov 2006 14:32:52 -0700

[ Converted text/html to text/plain ]

Sorry should've mentioned that I had tried both sprite and unlitgeneric
and
have also tried $spriterendermode with the sprite. (tried 0 through 6 but
it
should be 3 I think)

I'll see if I can use IMaterialVar to get/set but any other suggestions
would
be appreciated.

Thanks,

EJ


--
From:  "Jay Stelly" <[EMAIL PROTECTED]>
Reply-To:  hlcoders@list.valvesoftware.com
To:  
Subject:  RE: [hlcoders] Question about materials
Date:  Sun, 12 Nov 2006 10:13:45 -0800

It can depend on the material.  In this case I'd guess you have a sprite
material and it's the rendermode key that's set to normal (which is not
transparent) and you change it to kRenderGlow (which is).

Jay


> -Original Message-
> From: [EMAIL PROTECTED]
&

RE: [hlcoders] Question about materials

[Eric Van Huss]

Sorry for the e-mails... but I had misunderstanding about the code which
lead me to errors in testing and in my previous findings. I'll try to give
myself more time(sleep) before e-mailing about a problem again.
So disregard everything I said, except for the code. The code actually works
if you need to set a rendermode for a material that's not suppose to be
opaque. Like the visual bug with the physics canon when you first start a
sdk hl2dm game.


EJ



From: "Eric Van Huss" <[EMAIL PROTECTED]>
Reply-To: hlcoders@list.valvesoftware.com
To: hlcoders@list.valvesoftware.com
Subject: RE: [hlcoders] Question about materials
Date: Mon, 13 Nov 2006 07:01:05 -0700

I stuck with a sprite instead of an unlitgeneric.  But I guess
$spriteRenderMode inside a vmt file doesn't work.  Checking the Int value
of
the IMaterialVar associated with $spriteRenderMode returns 0, when in the
vmt it's set to 3.  It can be done in code though, which I took from
Valve's
CEngineSprite::SetRenderMode. The problem was with creating a mesh(rpg
laser
dot,redglow1) with a material who's rendermode hadn't been set. I guess you
should always set the rendermode for the material a mesh uses before it
draws? Anyway here's the code that makes it work, I got it from
CEngineSprite::SetRenderMode. (what seems weird that when a mesh is used,
it
could potentially use the material's render mode set by another entity if
you don't do this)

I included:  "materialsystem/imaterial.h" and
"materialsystem/imaterialvar.h"

//use CMaterialReference's operator method to store it's IMaterial pointer
inside testMaterial
IMaterial* testMaterial(m_hSomeCMaterialReference);
static unsigned int spriteRenderModeCache;
IMaterialVar* pTMaterialVar = testMaterial->FindVarFast(
"$spriteRenderMode", &spriteRenderModeCache );
if (pTMaterialVar)
{
 if(pTMaterialVar->GetIntValue() != kRenderGlow)
 {
  pTMaterialVar->SetIntValue( kRenderGlow );
  testMaterial->RecomputeStateSnapshots();
 }
}

This is also the reason when you first start up a fresh sdk MP game, your
physics cannon has opaque sprites in a couple of it's textures. I did a
quick fix with some code and the physics cannon was fixed. In my quick fix
I
used the same rendermode for all the textures so some of em looked a little
wonky but it still worked. I just need to tweak it or maybe look again at
the texture's vmt file...
So are material's suppose to have a default rendermode based on what they
are (e.g. Sprite,unlitgeneric,etc.). Or is it always 0 unless set? Are
unlitgenerics suppose to use $spriteRenderMode?
Another strange thing happened when I called aMaterial->Refresh() during
testing. After that I called FindVarFast so I could look at the int value
of
$spriteRenderMode, it was set to a large int(792588). Whats weird is that I
called FindVar right after and the int value was different. It was
(3,170,352) which is the first int, but just bit shifted to the left 2
times. 3,170,352 when looking at MaterialVarFlags_t seems to line up with a
good default render setting bitmask. So is this how aMaterial->Refresh() is
suppose to act? Using the code from above with out using Refresh() makes
them both return 3.

EJ



From: "Eric Van Huss" <[EMAIL PROTECTED]>
Reply-To: hlcoders@list.valvesoftware.com
To: hlcoders@list.valvesoftware.com
Subject: RE: [hlcoders] Question about materials
Date: Sun, 12 Nov 2006 14:32:52 -0700

[ Converted text/html to text/plain ]

Sorry should've mentioned that I had tried both sprite and unlitgeneric
and
have also tried $spriterendermode with the sprite. (tried 0 through 6 but
it
should be 3 I think)

I'll see if I can use IMaterialVar to get/set but any other suggestions
would
be appreciated.

Thanks,

EJ


--
From:  "Jay Stelly" <[EMAIL PROTECTED]>
Reply-To:  hlcoders@list.valvesoftware.com
To:  
Subject:  RE: [hlcoders] Question about materials
Date:  Sun, 12 Nov 2006 10:13:45 -0800

It can depend on the material.  In this case I'd guess you have a sprite
material and it's the rendermode key that's set to normal (which is not
transparent) and you change it to kRenderGlow (which is).

Jay


> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Eric Van Huss
> Sent: Sunday, November 12, 2006 8:18 AM
> To: hlcoders@list.valvesoftware.com
> Subject: [hlcoders] Question about materials
>
> [ Converted text/html to text/plain ]
>
> Trying to fix a visual bug.
>
> What can you set in a .vmt file where
> aMaterial->IsTranslucent() would return True? I tried the
> obvious "$translucent" "1" but that didn't work(I've tried
> lots

RE: [hlcoders] Question about materials

[Eric Van Huss]

I stuck with a sprite instead of an unlitgeneric.  But I guess
$spriteRenderMode inside a vmt file doesn't work.  Checking the Int value of
the IMaterialVar associated with $spriteRenderMode returns 0, when in the
vmt it's set to 3.  It can be done in code though, which I took from Valve's
CEngineSprite::SetRenderMode. The problem was with creating a mesh(rpg laser
dot,redglow1) with a material who's rendermode hadn't been set. I guess you
should always set the rendermode for the material a mesh uses before it
draws? Anyway here's the code that makes it work, I got it from
CEngineSprite::SetRenderMode. (what seems weird that when a mesh is used, it
could potentially use the material's render mode set by another entity if
you don't do this)

I included:  "materialsystem/imaterial.h" and
"materialsystem/imaterialvar.h"

//use CMaterialReference's operator method to store it's IMaterial pointer
inside testMaterial
IMaterial* testMaterial(m_hSomeCMaterialReference);
static unsigned int spriteRenderModeCache;
IMaterialVar* pTMaterialVar = testMaterial->FindVarFast(
"$spriteRenderMode", &spriteRenderModeCache );
if (pTMaterialVar)
{
 if(pTMaterialVar->GetIntValue() != kRenderGlow)
 {
  pTMaterialVar->SetIntValue( kRenderGlow );
  testMaterial->RecomputeStateSnapshots();
 }
}

This is also the reason when you first start up a fresh sdk MP game, your
physics cannon has opaque sprites in a couple of it's textures. I did a
quick fix with some code and the physics cannon was fixed. In my quick fix I
used the same rendermode for all the textures so some of em looked a little
wonky but it still worked. I just need to tweak it or maybe look again at
the texture's vmt file...
So are material's suppose to have a default rendermode based on what they
are (e.g. Sprite,unlitgeneric,etc.). Or is it always 0 unless set? Are
unlitgenerics suppose to use $spriteRenderMode?
Another strange thing happened when I called aMaterial->Refresh() during
testing. After that I called FindVarFast so I could look at the int value of
$spriteRenderMode, it was set to a large int(792588). Whats weird is that I
called FindVar right after and the int value was different. It was
(3,170,352) which is the first int, but just bit shifted to the left 2
times. 3,170,352 when looking at MaterialVarFlags_t seems to line up with a
good default render setting bitmask. So is this how aMaterial->Refresh() is
suppose to act? Using the code from above with out using Refresh() makes
them both return 3.

EJ



From: "Eric Van Huss" <[EMAIL PROTECTED]>
Reply-To: hlcoders@list.valvesoftware.com
To: hlcoders@list.valvesoftware.com
Subject: RE: [hlcoders] Question about materials
Date: Sun, 12 Nov 2006 14:32:52 -0700

[ Converted text/html to text/plain ]

Sorry should've mentioned that I had tried both sprite and unlitgeneric and
have also tried $spriterendermode with the sprite. (tried 0 through 6 but
it
should be 3 I think)

I'll see if I can use IMaterialVar to get/set but any other suggestions
would
be appreciated.

Thanks,

EJ


--
From:  "Jay Stelly" <[EMAIL PROTECTED]>
Reply-To:  hlcoders@list.valvesoftware.com
To:  
Subject:  RE: [hlcoders] Question about materials
Date:  Sun, 12 Nov 2006 10:13:45 -0800

It can depend on the material.  In this case I'd guess you have a sprite
material and it's the rendermode key that's set to normal (which is not
transparent) and you change it to kRenderGlow (which is).

Jay


> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Eric Van Huss
> Sent: Sunday, November 12, 2006 8:18 AM
> To: hlcoders@list.valvesoftware.com
> Subject: [hlcoders] Question about materials
>
> [ Converted text/html to text/plain ]
>
> Trying to fix a visual bug.
>
> What can you set in a .vmt file where
> aMaterial->IsTranslucent() would return True? I tried the
> obvious "$translucent" "1" but that didn't work(I've tried
> lots of other stuff). Here's some more info.
>
> If a temp sprite ,using the same material, calls
> SetTransparency( kRenderGlow, 255, 255, 255, 200,
> kRenderFxNoDissipation ) then the material gets changed and
> aMaterial->IsTranslucent() returns True. If I call
> aMaterial->Refresh(),
> IsTranslucent() returns False and the visual bug returns. Which means
> Refresh() is working(I think). So I just need to know what
> settings in a .vmt file makes aMaterial->IsTranslucent() return True.
>
> EJ
>
> ___
> To unsubscribe, edit your list preferences, or view the list
> archives, please v

RE: [hlcoders] Question about materials

[Eric Van Huss]

[ Converted text/html to text/plain ]

Sorry should've mentioned that I had tried both sprite and unlitgeneric and
have also tried $spriterendermode with the sprite. (tried 0 through 6 but it
should be 3 I think)

I'll see if I can use IMaterialVar to get/set but any other suggestions would
be appreciated.

Thanks,

EJ


--
From:  "Jay Stelly" <[EMAIL PROTECTED]>
Reply-To:  hlcoders@list.valvesoftware.com
To:  
Subject:  RE: [hlcoders] Question about materials
Date:  Sun, 12 Nov 2006 10:13:45 -0800

It can depend on the material.  In this case I'd guess you have a sprite
material and it's the rendermode key that's set to normal (which is not
transparent) and you change it to kRenderGlow (which is).

Jay


> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Eric Van Huss
> Sent: Sunday, November 12, 2006 8:18 AM
> To: hlcoders@list.valvesoftware.com
> Subject: [hlcoders] Question about materials
>
> [ Converted text/html to text/plain ]
>
> Trying to fix a visual bug.
>
> What can you set in a .vmt file where
> aMaterial->IsTranslucent() would return True? I tried the
> obvious "$translucent" "1" but that didn't work(I've tried
> lots of other stuff). Here's some more info.
>
> If a temp sprite ,using the same material, calls
> SetTransparency( kRenderGlow, 255, 255, 255, 200,
> kRenderFxNoDissipation ) then the material gets changed and
> aMaterial->IsTranslucent() returns True. If I call
> aMaterial->Refresh(),
> IsTranslucent() returns False and the visual bug returns. Which means
> Refresh() is working(I think). So I just need to know what
> settings in a .vmt file makes aMaterial->IsTranslucent() return True.
>
> EJ
>
> ___
> To unsubscribe, edit your list preferences, or view the list
> archives, please visit:
> http://list.valvesoftware.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] Question about materials

[Eric Van Huss]

[ Converted text/html to text/plain ]

Trying to fix a visual bug.

What can you set in a .vmt file where aMaterial->IsTranslucent() would return
True? I tried the obvious "$translucent" "1" but that didn't work(I've tried
lots of other stuff). Here's some more info.

If a temp sprite ,using the same material, calls SetTransparency( kRenderGlow,
255, 255, 255, 200, kRenderFxNoDissipation ) then the material gets changed
and aMaterial->IsTranslucent() returns True. If I call aMaterial->Refresh(),
IsTranslucent() returns False and the visual bug returns. Which means
Refresh() is working(I think). So I just need to know what settings in a .vmt
file makes aMaterial->IsTranslucent() return True.

EJ

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

Re: [hlcoders] Still need this assert?

[Eric Van Huss]

[ Converted text/html to text/plain ]

I've been able to fix a few of the other asserts by using
http://developer.valvesoftware.com/wiki/SDK_Known_Issues_List[1] . Thanks to
all who contributed!

It was just this last one with Duck() that I was unsure about. Also I just
found out if you add a bot you get a bunch of asserts, so gonna look at that
too. A 'dumb' bot still appears despite the asserts. Didn't seem to respawn
after I killed em though.

EJ


--
From:  Nick <[EMAIL PROTECTED]>
Reply-To:  hlcoders@list.valvesoftware.com
To:  hlcoders@list.valvesoftware.com
Subject:  Re: [hlcoders] Still need this assert?
Date:  Wed, 8 Nov 2006 15:05:27 -0600

When I find any asserts i just comment them out.

On 11/8/06, Skillet <[EMAIL PROTECTED]> wrote:

--
[ Picked text/plain from multipart/alternative ]
It happens for me every time the duck key is released as well.
There's a
nearby comment that says it should rarely or never happen.  I
assume
something changed (or something that was supposed to change didn't)
between
when the assert was added and now.

Anyway, I doubt there's any harm in removing it.

On 11/7/06, Eric Van Huss <[EMAIL PROTECTED]> wrote:
>
> [ Converted text/html to text/plain ]
> This is for the recently released sdk update. I'm new and
playing around
> with
> the sdk so I'll probably sound as such. I'm using 2005 Express.
>
> At the end of CGameMovement::Duck there's a "hack" check to make
sure the
> viewoffset z value is correct. In the comments about this check
it says it
> might not be needed but it's there to make sure people know if a
certain
> bug
> is happening.
> I'm getting this assert after letting go of duck almost every
time. If I
> comment
> out 'SetDuckedEyeOffset(0.0f)' ,at the end of the assert check,
the code
> still
> works and the player's viewoffset z value gets changed to the
correct
> value on
> it's own(64.0).
>
> In case anyone wants to know...! FinishUnDuck() sets the
player's
> viewoffset(z
> = 64.0). It then goes back to engine.dll(which is a pain to
debug :) ).
> Engine.dll
> calls CHLClient::FrameStageNotify -> OnRenderStart(), which down
the line
> calls C_BaseEntity::Interp_Interpolate(). The for loop in this
method
> changes
> the z value of the player's viewoffset. Then Duck() gets called
again and
> the
> assert happens. I guess this check/assert is not letting
interpolation run
> its
> course?
>
> So do we still need this check/assert. Or maybe a better
conditional
> check?
>
> Thanks,
> EJ
> ___
> To unsubscribe, edit your list preferences, or view the list
archives,
> please visit:
> http://list.valvesoftware.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



===References:===
 1. http://developer.valvesoftware.com/wiki/SDK_Known_Issues_List

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

[hlcoders] Still need this assert?

[Eric Van Huss]

[ Converted text/html to text/plain ]
This is for the recently released sdk update. I'm new and playing around with
the sdk so I'll probably sound as such. I'm using 2005 Express.

At the end of CGameMovement::Duck there's a "hack" check to make sure the
viewoffset z value is correct. In the comments about this check it says it
might not be needed but it's there to make sure people know if a certain bug
is happening.
I'm getting this assert after letting go of duck almost every time. If I comment
out 'SetDuckedEyeOffset(0.0f)' ,at the end of the assert check, the code still
works and the player's viewoffset z value gets changed to the correct value on
it's own(64.0).

In case anyone wants to know...! FinishUnDuck() sets the player's viewoffset(z
= 64.0). It then goes back to engine.dll(which is a pain to debug :) ). 
Engine.dll
calls CHLClient::FrameStageNotify -> OnRenderStart(), which down the line
calls C_BaseEntity::Interp_Interpolate(). The for loop in this method changes
the z value of the player's viewoffset. Then Duck() gets called again and the
assert happens. I guess this check/assert is not letting interpolation run its
course?

So do we still need this check/assert. Or maybe a better conditional check?

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

Re: [hlcoders] New SDK Update is Out As Beta

[Eric Van Huss]

[ Converted text/html to text/plain ]

Yep it's the free one. It compiles and runs HL2MP fine with debug and release
builds. You can even run it through the debugger.

There are still asserts and missing resources(mentioned previously in this
list). You can fix most of the resource bugs my transfering them from certain
gcf files.

EJ


--
From:  Adam Foster <[EMAIL PROTECTED]>
Reply-To:  hlcoders@list.valvesoftware.com
To:  hlcoders@list.valvesoftware.com
Subject:  Re: [hlcoders] New SDK Update is Out As Beta
Date:  Thu, 2 Nov 2006 11:54:54 +0100


On 2 Nov 2006, at 02:05, Eric Van Huss wrote:


Using C++ 2005 Express it wouldn't compile. It's a simple fix
though!


Visual C++ 2005 Express is the free-download one, isn't it?


Adam

--
Adam Foster - [EMAIL PROTECTED] - http://www.hylobatidae.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] New SDK Update is Out As Beta

[Eric Van Huss]

[ Converted text/html to text/plain ]

Sorry for the extra email but I forgot to say that it was the HLDM SDK. Don't
know about the others.

EJ


--

From:  "Eric Van Huss" <[EMAIL PROTECTED]>
Reply-To:  hlcoders@list.valvesoftware.com
To:  hlcoders@list.valvesoftware.com
Subject:  RE: [hlcoders] New SDK Update is Out As Beta
Date:  Wed, 01 Nov 2006 18:05:41 -0700

[ Converted text/html to text/plain ]

Using C++ 2005 Express it wouldn't compile. It's a simple fix
though!

Change this for both debug and release. Check both server and client
as well.

Configuration Properties -> C/C++ -> Browse Information -> Browse
File

Change $(IntDir)\ to $(IntDir)/

After Doing this I was able to compile with a few warnings. I loaded
up the
release version on sdk_dm_lockdown and was able to run around and
shoot guns
for a little bit. Did notice a temp sprite stayed in the air after I
shot the
rocket launcher one time but I haven't tested much.

Debug version crashed when trying to load the map. One time it
actually did
let me in the map. It then crashed after firing the Pulse rifle.

I'll do more testing though to make sure it's not me.

EJ


--
From:  "Mike Durand" <[EMAIL PROTECTED]>
Reply-To:  hlcoders@list.valvesoftware.com
To:  
Subject:  [hlcoders] New SDK Update is Out As Beta
Date:  Wed, 1 Nov 2006 10:39:40 -0800

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

An updated SDK has been released as beta. You can get access to
this
beta by adding the '-beta sdk1031'  command line option to your
shortcut
to steam.exe.

Here are the highlights of this update:
New Features

- Visual Studio 2005 Support for SDK Code

- Spectate Mode Added to HL2 Deathmatch

Bug fixes

- Faceposer Crashes When When Trying to Extract or Add a .txt File

- Lag compensation added back into HL2MP


The full release notes are here, as always:
http://developer.valvesoftware.com/wiki/Source_SDK_Release_Notes
<http://developer.valvesoftware.com/wiki/Source_SDK_Release_Notes>


I'm planning to beta this update for a week and then make it the
active
SDK on 10/8. I plan to make all SDK releases as beta for the first
week
so that teams that are in critical parts of their development cycle
don't get surprised.

Please let me know directly if you run into any "show-stopper"
issues
with the new SDK update. Minor bugs should go into Bugzilla.

-Thanks,
 Mike
--

___
To unsubscribe, edit your list preferences, or view the list
archives, please

visit:

http://list.valvesoftware.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 SDK Update is Out As Beta

[Eric Van Huss]

[ Converted text/html to text/plain ]

Using C++ 2005 Express it wouldn't compile. It's a simple fix though!

Change this for both debug and release. Check both server and client as well.

Configuration Properties -> C/C++ -> Browse Information -> Browse File

Change $(IntDir)\ to $(IntDir)/

After Doing this I was able to compile with a few warnings. I loaded up the
release version on sdk_dm_lockdown and was able to run around and shoot guns
for a little bit. Did notice a temp sprite stayed in the air after I shot the
rocket launcher one time but I haven't tested much.

Debug version crashed when trying to load the map. One time it actually did
let me in the map. It then crashed after firing the Pulse rifle.

I'll do more testing though to make sure it's not me.

EJ


--
From:  "Mike Durand" <[EMAIL PROTECTED]>
Reply-To:  hlcoders@list.valvesoftware.com
To:  
Subject:  [hlcoders] New SDK Update is Out As Beta
Date:  Wed, 1 Nov 2006 10:39:40 -0800

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

An updated SDK has been released as beta. You can get access to this
beta by adding the '-beta sdk1031'  command line option to your shortcut
to steam.exe.

Here are the highlights of this update:
New Features

- Visual Studio 2005 Support for SDK Code

- Spectate Mode Added to HL2 Deathmatch

Bug fixes

- Faceposer Crashes When When Trying to Extract or Add a .txt File

- Lag compensation added back into HL2MP


The full release notes are here, as always:
http://developer.valvesoftware.com/wiki/Source_SDK_Release_Notes



I'm planning to beta this update for a week and then make it the active
SDK on 10/8. I plan to make all SDK releases as beta for the first week
so that teams that are in critical parts of their development cycle
don't get surprised.

Please let me know directly if you run into any "show-stopper" issues
with the new SDK update. Minor bugs should go into Bugzilla.

-Thanks,
 Mike
--

___
To unsubscribe, edit your list preferences, or view the list archives, please

visit:

http://list.valvesoftware.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] Launching Mod from Steam doesn't work

[Eric Van Huss]

[ Converted text/html to text/plain ]

-allowdebug doesn't seem to work for me in steam.

Make sure you run your source game in a window to see any error message. Won't
see it in fullscreen.

Running debug mode through the debugger does work though as said before.

Eric


--
From:  "Jay Stelly" <[EMAIL PROTECTED]>
Reply-To:  hlcoders@list.valvesoftware.com
To:  
Subject:  RE: [hlcoders] Launching Mod from Steam doesn't work
Date:  Sun, 6 Aug 2006 18:13:06 -0700

For a debug build you either need to be in a debugger or running with
the -allowdebug commandline argument.  Otherwise the engine is supposed
to validate that none of the binaries are debug builds.  It's not
supposed to crash, however; you should get a message box with an error.

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Paul Peloski
> Sent: Sunday, August 06, 2006 4:25 PM
> To: hlcoders@list.valvesoftware.com
> Subject: [hlcoders] Launching Mod from Steam doesn't work
>
> --
> [ Picked text/plain from multipart/alternative ] I've got the
> same problem as Steve, hl2.exe crashes (with no error)
> immediately after playing the Valve intro video (about the
> time it would load my mod DLLs). Here's some more
> information, hopefully it will help solve our problem..
>
> The mod will launch and not crash from Steam OR Visual Studio
> ONLY if I attach a debugger (ie, windbg or manually attaching
> VS.net while the game is loading). It seems hl2.exe doesn't
> want to load the mod DLLs unless a debugger is attached.
>
> This crash dump was made in my half-life 2 deathmatch folder:
> http://hl2ctf.net/~sinbad/Steam__2803__2006_8_6T23_11_47C14656.mdmp
>
> I'm using appid 320, not 215, because HL2CTF shares a lot with HL2DM.
>
> I'm using the latest (Aug 04) SDK code as a base for the mod.
>
> Thank you,
>
> Paul.
> --
>
> ___
> To unsubscribe, edit your list preferences, or view the list
> archives, please visit:
> http://list.valvesoftware.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] Source SDK Update Is Released

[Eric Van Huss]

[ Converted text/html to text/plain ]

It was shutting down at start because it was a debug build(-allowdebug wasn't
working). Though debug build does work through the debugger so it's all good.
Release works as well.

One other question. I used the Creat a Mod->Modify Half-Life 2 Multiplayer.
When I started up the game I had no maps like the previous sdk would give you.
I was able to copy a map from a previously run sdk release though. It loaded
and I was able to run/drive around.

No maps must have something to do with this new 215 base sdk?

Thanks,

Eric


--
From:  "Eric Van Huss" <[EMAIL PROTECTED]>
Reply-To:  hlcoders@list.valvesoftware.com
To:  hlcoders@list.valvesoftware.com
Subject:  RE: [hlcoders] Source SDK Update Is Released
Date:  Sat, 05 Aug 2006 13:27:22 -0700

[ Converted text/html to text/plain ]

There's probably some easy way to read library files I'm not aware
of. I'll
research that though :)

Anyway I used your info and created the static library. Did get some
errors
when trying to compile the static library. Though I just had to cast
a bunch
of string constants to const tchar*

I was able to compile and run the sdk after that. Using run_mode.bat
I was
able to start HL2 and it loaded. Am finding a 'start partway then
shutdown'
error though, will tackle that when I'm not as sleepy. Probably has
to do with
my video settings, but we'll see.

Thanks for the info!

Eric


--
From:  "Yahn Bernier" <[EMAIL PROTECTED]>
Reply-To:  hlcoders@list.valvesoftware.com
To:  
Subject:  RE: [hlcoders] Source SDK Update Is Released
Date:  Sat, 5 Aug 2006 09:56:16 -0700

Yeah, we'll get that out to you guys.

FWIW, it's just a convenience static lib that includes
game_shared/choreoactor.cpp, choreochannel.cpp, choreoevent.cpp and
choreoscene.cpp and not much else, so you might be able to create
your
own version trivially.

Yahn




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

RE: [hlcoders] Source SDK Update Is Released

[Eric Van Huss]

[ Converted text/html to text/plain ]

There's probably some easy way to read library files I'm not aware of. I'll
research that though :)

Anyway I used your info and created the static library. Did get some errors
when trying to compile the static library. Though I just had to cast a bunch
of string constants to const tchar*

I was able to compile and run the sdk after that. Using run_mode.bat I was
able to start HL2 and it loaded. Am finding a 'start partway then shutdown'
error though, will tackle that when I'm not as sleepy. Probably has to do with
my video settings, but we'll see.

Thanks for the info!

Eric


--
From:  "Yahn Bernier" <[EMAIL PROTECTED]>
Reply-To:  hlcoders@list.valvesoftware.com
To:  
Subject:  RE: [hlcoders] Source SDK Update Is Released
Date:  Sat, 5 Aug 2006 09:56:16 -0700

Yeah, we'll get that out to you guys.

FWIW, it's just a convenience static lib that includes
game_shared/choreoactor.cpp, choreochannel.cpp, choreoevent.cpp and
choreoscene.cpp and not much else, so you might be able to create your
own version trivially.

Yahn

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Eric Van
Huss
Sent: Saturday, August 05, 2006 7:23 AM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] Source SDK Update Is Released

[ Converted text/html to text/plain ]

Any chance of getting the source code for choreoobject.lib?

 Compiling HL2MP wont work any more with 2005 express because this
library is
compiled with older referenced libraries. Would need to get the source
code to
choreoobjects to recompile under newer libraries.

I've fixed all the other new/old bugs otherwise.

Here's the error: xran and xlen using __thiscall

choreoobjects.lib(choreoevent.obj) : error LNK2019: unresolved external
symbol
"public: void __thiscall ...

choreoobjects.lib(choreoevent.obj) : error LNK2019: unresolved external
symbol
"public: void __thiscall ...

Thanks,

Eric


--

From:  Wraiyth <[EMAIL PROTECTED]>
Reply-To:  hlcoders@list.valvesoftware.com
To:  hlcoders@list.valvesoftware.com
Subject:  Re: [hlcoders] Source SDK Update Is Released
Date:  Sat, 5 Aug 2006 20:55:07 +1000
>--
>[ Picked text/plain from multipart/alternative ]
>Bah, its alright, false


___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.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] Source SDK Update Is Released

[Eric Van Huss]

[ Converted text/html to text/plain ]

Any chance of getting the source code for choreoobject.lib?

Compiling HL2MP wont work any more with 2005 express because this library is
compiled with older referenced libraries. Would need to get the source code to
choreoobjects to recompile under newer libraries.

I've fixed all the other new/old bugs otherwise.

Here's the error: xran and xlen using __thiscall

choreoobjects.lib(choreoevent.obj) : error LNK2019: unresolved external symbol
"public: void __thiscall ...

choreoobjects.lib(choreoevent.obj) : error LNK2019: unresolved external symbol
"public: void __thiscall ...

Thanks,

Eric

--

From:  Wraiyth <[EMAIL PROTECTED]>
Reply-To:  hlcoders@list.valvesoftware.com
To:  hlcoders@list.valvesoftware.com
Subject:  Re: [hlcoders] Source SDK Update Is Released
Date:  Sat, 5 Aug 2006 20:55:07 +1000

--
[ Picked text/plain from multipart/alternative ]
Bah, its alright, false



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