Re: [hlcoders] Re: Problems with Hl1 SDK being built under VC Express

[Douglas Temple]

--
[ Picked text/plain from multipart/alternative ]
I probably will. I have to admit, it's a bit of a sloppy port and there are
a couple of warnings that I don't understand (I'll post them in a different
letter), but apart from that, you will need the header files from VC6
(that's how I cheated and cut the error list by about half).
If it's all legal (and if someone could tell me if it is) I'll put those up
as well, because you'll need to replace the VC Express header with these. If
someone wants to host the files for me, I think it would be better than just
shoving them on filefront.

Anyway, back to the salt mines (ie fixing one undeclared identifier that has
been annoying me for 7 hours).
--

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

Re: [hlcoders] Re: Problems with Hl1 SDK being built under VC Express

[Adam amckern Mckern]

Ok cool

I can host them if you want, just send me an off list
email for the details.

Adam

--- Douglas Temple [EMAIL PROTECTED] wrote:

 --
 [ Picked text/plain from multipart/alternative ]
 I probably will. I have to admit, it's a bit of a
 sloppy port and there are
 a couple of warnings that I don't understand (I'll
 post them in a different
 letter), but apart from that, you will need the
 header files from VC6
 (that's how I cheated and cut the error list by
 about half).
 If it's all legal (and if someone could tell me if
 it is) I'll put those up
 as well, because you'll need to replace the VC
 Express header with these. If
 someone wants to host the files for me, I think it
 would be better than just
 shoving them on filefront.

 Anyway, back to the salt mines (ie fixing one
 undeclared identifier that has
 been annoying me for 7 hours).
 --

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

http://list.valvesoftware.com/mailman/listinfo/hlcoders





Nigredo Studios http://www.nigredostudios.com

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

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

[hlcoders] player-child Touch causes player-self Touch

[bloodykenny]

I noticed in my mod, due to some asserts I had added, that under certain 
circumstances I don't fully understand, the vphysics engine would report a 
child object (ie, a weapon) touching a player, which when caused the player to 
touch itself.  I don't think Valve could've really intended this - anyone have 
any ideas on why it might ever have been a good thing to do?  Here's the fix if 
not...

--- mod/src/dlls/baseentity.cpp 26 Aug 2006 21:24:28 -  1.8
+++ mod/src/dlls/baseentity.cpp 7 Oct 2006 18:00:57 -
@@ -1787,8 +1787,9 @@
 void CBaseEntity::StartTouch( CBaseEntity *pOther )
 {
// notify parent
-   if ( m_pParent != NULL )
+   if ((m_pParent != NULL)  (m_pParent != pOther)) {
m_pParent-StartTouch( pOther );
+}
 }

 void CBaseEntity::Touch( CBaseEntity *pOther )
@@ -1797,15 +1798,15 @@
(this-*m_pfnTouch)( pOther );

// notify parent of touch
-   if ( m_pParent != NULL )
+if ((m_pParent != NULL)  (m_pParent != pOther)) {
m_pParent-Touch( pOther );
+}
 }

 void CBaseEntity::EndTouch( CBaseEntity *pOther )
 {
// notify parent
-   if ( m_pParent != NULL )
-   {
+   if ((m_pParent != NULL)  (m_pParent != pOther)) {
m_pParent-EndTouch( pOther );
}
 }
@@ -1825,8 +1826,7 @@
//
// Forward the blocked event to our parent, if any.
//
-   if ( m_pParent != NULL )
-   {
+   if ((m_pParent != NULL)  (m_pParent != pOther)) {
m_pParent-Blocked( pOther );
}
 }

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

Re: [hlcoders] player-child Touch causes player-self Touch

[Paul Peloski]

--
[ Picked text/plain from multipart/alternative ]
The subject of your message gave me a good laugh, and upon reading the
message I laughed even harder when I read .. caused the player to touch
itself.

Thanks,

Paul

On 10/7/06, [EMAIL PROTECTED] [EMAIL PROTECTED]
wrote:

 I noticed in my mod, due to some asserts I had added, that under certain
 circumstances I don't fully understand, the vphysics engine would report a
 child object (ie, a weapon) touching a player, which when caused the player
 to touch itself.  I don't think Valve could've really intended this - anyone
 have any ideas on why it might ever have been a good thing to do?  Here's
 the fix if not...

 --- mod/src/dlls/baseentity.cpp 26 Aug 2006 21:24:28 -  1.8
 +++ mod/src/dlls/baseentity.cpp 7 Oct 2006 18:00:57 -
 @@ -1787,8 +1787,9 @@
 void CBaseEntity::StartTouch( CBaseEntity *pOther )
 {
 // notify parent
 -   if ( m_pParent != NULL )
 +   if ((m_pParent != NULL)  (m_pParent != pOther)) {
 m_pParent-StartTouch( pOther );
 +}
 }

 void CBaseEntity::Touch( CBaseEntity *pOther )
 @@ -1797,15 +1798,15 @@
 (this-*m_pfnTouch)( pOther );

 // notify parent of touch
 -   if ( m_pParent != NULL )
 +if ((m_pParent != NULL)  (m_pParent != pOther)) {
 m_pParent-Touch( pOther );
 +}
 }

 void CBaseEntity::EndTouch( CBaseEntity *pOther )
 {
 // notify parent
 -   if ( m_pParent != NULL )
 -   {
 +   if ((m_pParent != NULL)  (m_pParent != pOther)) {
 m_pParent-EndTouch( pOther );
 }
 }
 @@ -1825,8 +1826,7 @@
 //
 // Forward the blocked event to our parent, if any.
 //
 -   if ( m_pParent != NULL )
 -   {
 +   if ((m_pParent != NULL)  (m_pParent != pOther)) {
 m_pParent-Blocked( pOther );
 }
 }

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


--

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

Re: [hlcoders] player-child Touch causes player-self Touch

[bloodykenny]

I went to great lengths to try to avoid that.  My original subject line was 
parent touching child causes parent to touch himself...

Anyway! ... any comments on the CODING part of the email?

At 2006/10/07 05:37 PM, John Sheu wrote:
On Saturday 07 October 2006 1:47 pm, Paul Peloski wrote:
 --
 [ Picked text/plain from multipart/alternative ]
 The subject of your message gave me a good laugh, and upon reading the
 message I laughed even harder when I read .. caused the player to touch
 itself.

 Thanks,

 Paul

Well, it had to happen sooner or later.  With all the effort that Valve put
into realistic characters, _somebody_ was going to start a porn mod...

-John Sheu

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.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] poorer prediction with new SDK?

[bloodykenny]

Well I've added back the lag compensation calls in player_command.cpp that the 
old SDK had.  Seemingly 100% of the players that were complaining before now 
agree that everything is much better (as it was prior to the SDK update).

At 2006/09/24 08:40 AM, Robbie Groenewoudt wrote:
--
[ Picked text/plain from multipart/alternative ]
Ah yes, you are right. Interpolation plays a roll.

Are there any other situations that needs lagcompensation? Also, if you do
it in player_command, player's physics position also gets updated with the
lagcompensated-position, which may give funny results...

On 9/23/06, Paul Peloski [EMAIL PROTECTED] wrote:

 --
 [ Picked text/plain from multipart/alternative ]
 I have to disagree. Right in the StartLagCompensation function you will
 see
 that the amount of time to back track the enemy player is calculated like
 this:

 back track time = cmd transit time (net. latency) + cl_interp value

 Check the first 10-15 lines of StartLagCompensation to see that in action
 (note that player-m_fLerpTime is elswhere set to the player's value for
 cl_interp.) cl_interp is the determining factor in how far behind the
 client
 renders an entity vs. the servers position data.

 The amount the player is moved back is not simply the players ping, its a
 composite of how far behind their rendering is (cl_interp) and how long it
 took for their ucmd to reach the server.

 And yes, like I said you can do it in FireBullets if you use IsPlayer and
 cast the entity to CBasePlayer, but you can also do it in RunCommand and
 catch other situations where you use tracelines but are not necessarily
 calling FireBullets.

 On 9/23/06, Robbie Groenewoudt [EMAIL PROTECTED] wrote:
 
  --
  [ Picked text/plain from multipart/alternative ]
  In fact, I already moved it to CBaseEntity::FireBullets and I tested it
  and
  it works. player_command.cpp sets the last usercmd in the player class,
  which you can get via CBasePlayer::GetLastUserCommand(). Also, func_tank
  gives the player as an argument to FireBullets() so in the class itself
 I
  do
  a pAttacker-IsPlayer() check, which works for everything.
 
  You are forgetting something. It's ping. And if you have a ping of
 250ms,
  you don't hit anything because the location of players are different
 250ms
  ago. Lagcompensation fixes this by moving all other players, that the
  player
  could shoot, back in time (amount is equivalent to the player's ping )
 and
  then execute the tracelines to check if a bullet has hit someone.
  Interpolation has nothing to do with lagcompensation.
 
  On 9/23/06, Paul Peloski [EMAIL PROTECTED] wrote:
  
   --
   [ Picked text/plain from multipart/alternative ]
   What Teddy said is probably the best place. CBaseEntity::FireBullets
 is
   probably not good because StartLagCompensation takes CBasePlayer and
   CUserCmd as parameters so passing the this pointer from within
   CBaseEntity::FireBullets won't compile, you'd have to wrap it in
   IsPlayer(),
   so there's no benefit to func_tank.
  
   Garry's right, the lag compensation moves the player back to match
 what
   the
   client would have been shooting at since the client is behind the
  server.
   Client rendering is always kept (cl_interp 0.1, ~100 ms) behind the
  server
   so that the client can keep enough data ahead of the actual rendering
 to
   smoothly interpolate movement.
  
   You can get a really good idea what's going on by adding a bot,
 turning
  on
  
   sv_showhitboxes 2
   sv_showlagcompensation 1
   host_timescale 0.1
  
   Now you should see some colorful hitboxes that are the servers
 position,
   the
   rendered enemy player is the clients which lags behind those hitboxes
   because of cl_interp, and when you shoot at the bot, you should see a
   bunch
   of blue hitboxes which are the lag compensated hitboxes that are
  actually
   used when tracing your shots. In slowmo you can see that the blue
 boxes
   overlap the client-rendered player pretty well.
  
   Hope that helps, BK  Robbie.
  
   On 9/23/06, Robbie Groenewoudt [EMAIL PROTECTED] wrote:
   
--
[ Picked text/plain from multipart/alternative ]
Let me rephrase that last. Maybe the best place to lagcompensate
 would
   be
CBaseEntity:FireBullets(). Then you are sure no other things get
  messed
up... (there's some other stuff in CBasePlayer::PostThink that may
 not
like
changing positions).
   
Also, it's possible that the func_tank has no lagcompensation at the
moment
(I'm not sure) so moving it to FireBullets() would do
 lagcompensation
   for
everything that fires bullets ;) I doubt that it's called more then
  once
in
a frame so moving it shouldn't be harmfull.
   
Just thinking out loud here... Please tell me if I am wrong :)
   
On 9/23/06, Robbie Groenewoudt [EMAIL PROTECTED] wrote:

 FX_FireBullets() calls CSDKPlayer::FireBullet() and that's where
 the
 bullet-code is done.

 However, with mods based 

[hlcoders] HldsUpdate Tool weird Error

[Matthew poo]

--
[ Picked text/plain from multipart/alternative ]
i get this error after following your instructions...

[IMG]http://i89.photobucket.com/albums/k239/MattMccomb/HLdsUpdateToolError.jpg[/IMG]

This URL = 
http://i89.photobucket.com/albums/k239/MattMccomb/HLdsUpdateToolError.jpg
_
Be one of the first to try Windows Live Mail.
http://ideas.live.com/programpage.aspx?versionId=5d21c51a-b161-4314-9b0e-4911fb2b2e6d
--

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