Re: [hlcoders] Jerky Movement when player is on moving lift/elevator.

2006-06-29 Thread Garry Newman

I think the basics are there - we just don't have the exposure entity.
I'm guessing that that  the exposure entity uses an interface.. so
unless we're real good at guessing we won't be able to do that
ourselves.

The bloom is just bloom, that's easy enough to do.


On 6/29/06, Teddy [EMAIL PROTECTED] wrote:

if you're talking about the hl2 mini-bloom mod (see
http://forum.neotokyohq.com/viewtopic.php?t=378) well it's not
selfillum textures. there's a whole lot of bloom in there.

strictly speaking, it's not the HDR technologoy valve have made, with
exposure and gathering on reflective surfaces, etc. we have the
compiled shaders for all that, but i don't think anyones figured out
how to implement it yet

On 6/29/06, Aaron Schiff [EMAIL PROTECTED] wrote:
 --
 [ Picked text/plain from multipart/alternative ]
 I think that mod just uses nice transparent selfillum textures

 --
 ts2do
 --

 ___
 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] Jerky Movement when player is on moving lift/elevator.

2006-06-29 Thread Matthew Lewis

I've been fighting that problem for a very long time. In fact, I'm
actually having to come back to it yet again. I think this issue has
appeared in the forums several times before with no resolution.

The jerkiness is quite real in the motion of the player. Entities placed
on plats jerk severely (even worse than players do). It looks awful.
I've looked at the code a number of times to get things to move smoothly
with no luck. It seems that the BaseVelocity code which is supposed to
help objects move on plats doesn't work very well. I'm not sure why.
I'll try the smoothstairs trick to hide the problem for now,  but I
would rather get to the root of the problem instead of just masking it.
It's interesting that the hl2mp seems to work ok. I haven't tried it
myself, but it wouldn't be the first thing that works properly in hl2mp
but not in the SDK. The weapon viewmodel skipping/jerkiness is another
example.

Incidently, it was suggested that the viewmodel problem be fixed by
making the viewmodel code client-side only. I actually started to do
this, but I then came to the conclusion that that solution was a major
hack -- especially when essentially the same code seems to work with
multiplayer version of the SDK, but not with the regular version of the
SDK. I still don't know what the multiplayer version is doing
differently to make the viewmodels work correctly.

Finally, I wish that Valve would roll back their changes to the SDK
tools. The latest version of the tools do not work properly. If you're
not going to fix them, then at least go back to a version that did work.
It's not nice doing unsolicited updates, installing broken code, then
just leaving it that way.




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



Re: [hlcoders] Jerky Movement when player is on moving lift/elevator.

2006-06-29 Thread Skillet
--
[ Picked text/plain from multipart/alternative ]
Could this be related to that old prediction error bug while moving along
walls that the KZMod guy kept bringing up?

NetworkOrigin jerks are exactly what happen there (looking at cl_pdump) and
that's another issue which dosen't happen in HL2DM but does in the SDK.

Couple of descriptions:
http://list.valvesoftware.com/mailman/private/hlcoders/2006-March/016988.html
http://list.valvesoftware.com/mailman/private/hlcoders/2006-April/017158.html

On 6/27/06, Teddy [EMAIL PROTECTED] wrote:

 I just did a test on an elevator in Dystopia using smoothstairs 0,
 unfortunately the problem still persists.

 I noticed when this jerking is taking place there's prediction errors,
 further investigation shows it's getting a pred error in
 C_BaseEntity::m_vecNetworkOrigin, so I've been looking through the
 movement code for answers, to no avail.

 On 6/28/06, Jay Stelly [EMAIL PROTECTED] wrote:
  When you say, In hl2dm, it's smooth regardless of the smoothstairs
  setting. It sounds like you misunderstand what I'm trying to say.
 
  HL2DM is running the code from episode 1 that I pasted below.
  smoothstairs is already disabled when you're on an elevator in HL2DM -
  so testing HL2DM isn't going to prove whether this change is the fix or
  not - you have to test a mod based on the current SDK code release.
 
 
   -Original Message-
   From: [EMAIL PROTECTED]
   [mailto:[EMAIL PROTECTED] On Behalf Of
   Spencer 'voogru' MacDonald
   Sent: Tuesday, June 27, 2006 7:07 PM
   To: hlcoders@list.valvesoftware.com
   Subject: RE: [hlcoders] Jerky Movement when player is on
   moving lift/elevator.
  
   That only masks the problem apparently. In hl2dm, it's smooth
   regardless of the smoothstairs setting.
  
   -Original Message-
   From: Jay Stelly [mailto:[EMAIL PROTECTED]
   Sent: Tuesday, June 27, 2006 9:30 PM
   To: hlcoders@list.valvesoftware.com
   Subject: RE: [hlcoders] Jerky Movement when player is on
   moving lift/elevator.
  
   I'm not sure if it's the issue or not, but I remember a bug
   like this in episode 1.  If it's the same issue, then setting
   smoothstairs to zero will fix it (but cause other problems).
   If that's the case then you need to add some logic to disable
   stair smoothing when the player is on an elevator.
  
   Here's the code from ep1
   baseplayer_shared.cpp:
  
   static ConVar smoothstairs( smoothstairs, 1,
   FCVAR_REPLICATED, Smooth player eye z coordinate when
   traversing stairs. );
  
   //
   --
   ---
   // Handle view smoothing when going up or down stairs
   //
   --
   ---
   void CBasePlayer::SmoothViewOnStairs( Vector eyeOrigin ) {
 CBaseEntity *pGroundEntity = GetGroundEntity();
 float flCurrentPlayerZ = GetLocalOrigin().z;
 float flCurrentPlayerViewOffsetZ = GetViewOffset().z;
  
 // Smooth out stair step ups
 // NOTE: Don't want to do this when the ground entity
   is moving the player
 if ( ( pGroundEntity != NULL 
   pGroundEntity-GetMoveType() == MOVETYPE_NONE )  (
   flCurrentPlayerZ != m_flOldPlayerZ ) 
   smoothstairs.GetBool() 
  m_flOldPlayerViewOffsetZ == flCurrentPlayerViewOffsetZ
   )
 {
 int dir = ( flCurrentPlayerZ  m_flOldPlayerZ ) ? 1 :
   -1;
  
 float steptime = gpGlobals-frametime;
 if (steptime  0)
 {
 steptime = 0;
 }
  
 m_flOldPlayerZ += steptime * 150 * dir;
  
 const float stepSize = 18.0f;
  
 if ( dir  0 )
 {
 if (m_flOldPlayerZ  flCurrentPlayerZ)
 {
 m_flOldPlayerZ = flCurrentPlayerZ;
 }
 if (flCurrentPlayerZ - m_flOldPlayerZ 
   stepSize)
 {
 m_flOldPlayerZ = flCurrentPlayerZ -
   stepSize;
 }
 }
 else
 {
 if (m_flOldPlayerZ  flCurrentPlayerZ)
 {
 m_flOldPlayerZ = flCurrentPlayerZ;
 }
 if (flCurrentPlayerZ - m_flOldPlayerZ 
   -stepSize)
 {
 m_flOldPlayerZ = flCurrentPlayerZ +
   stepSize;
 }
 }
  
 eyeOrigin[2] += m_flOldPlayerZ - flCurrentPlayerZ;
 }
 else
 {
 m_flOldPlayerZ = flCurrentPlayerZ;
 m_flOldPlayerViewOffsetZ = flCurrentPlayerViewOffsetZ;
 }
  
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On 

Re: [hlcoders] Jerky Movement when player is on moving lift/elevator.

2006-06-29 Thread Aaron Schiff
--
[ Picked text/plain from multipart/alternative ]
Their issue didn't consist of entity movement. The issue there was about the
client moving too far into geometry.

This issue has to do with the server changing the environment and the server
moving entities around so they don't get stuck.

--
ts2do
--

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



RE: [hlcoders] Jerky Movement when player is on moving lift/elevator.

2006-06-29 Thread Spencer 'voogru' MacDonald
*Crickets*

-Original Message-
From: Aaron Schiff [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 29, 2006 3:09 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] Jerky Movement when player is on moving
lift/elevator.

--
[ Picked text/plain from multipart/alternative ]
Their issue didn't consist of entity movement. The issue there was about the
client moving too far into geometry.

This issue has to do with the server changing the environment and the server
moving entities around so they don't get stuck.

--
ts2do
--

___
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] physics shadow

2006-06-29 Thread Tony \omega\ Sergi
Anyone know what these affect yet? I'm trying to do something with the
players shadow, to make it function a little differently, but still retain
the same basic functionality, but I cant figure out exactly what these do.

Valve?

m_pPhysicsController-SetPushMassLimit( 350.0f );
m_pPhysicsController-SetPushSpeedLimit( 50.0f );

--
-- omega
Heroes of Excelsior
http://www.heroesofexcelsior.com
Blackened Interactive
http://www.blackened-interactive.com



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



Re: [hlcoders] physics shadow

2006-06-29 Thread Adam \amckern\ Mckern
Shot an email to Wrayth, he had a very complex looking
yet easy to programm player shadow in a few builds
ago, untill we worked out that the 'gorden' model in
sp has no animations.

Adam

--- Tony \omega\ Sergi
[EMAIL PROTECTED] wrote:

 Anyone know what these affect yet? I'm trying to do
 something with the
 players shadow, to make it function a little
 differently, but still retain
 the same basic functionality, but I cant figure out
 exactly what these do.

 Valve?

   m_pPhysicsController-SetPushMassLimit( 350.0f );
   m_pPhysicsController-SetPushSpeedLimit( 50.0f );

 --
 -- omega
 Heroes of Excelsior
 http://www.heroesofexcelsior.com
 Blackened Interactive
 http://www.blackened-interactive.com



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

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





My Website http://www.ammahls.com
   Lead Programer NightFall http://www.nightfallmod.net
  Developer of CST and ZHLT 3.0 http://www.zhlt.info
 Team Lead - Prime - 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



Re: [hlcoders] Jerky Movement when player is on moving lift/elevator.

2006-06-29 Thread bloodykenny

Finally, I wish that Valve would roll back their changes to the SDK
tools. The latest version of the tools do not work properly. If you're
not going to fix them, then at least go back to a version that did work.
It's not nice doing unsolicited updates, installing broken code, then
just leaving it that way.

Yea it'd be nice if Steam would say Update XX? (y/n) ... then the community 
could maintain a wiki or something as to which version was the stable release.

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



Re: [hlcoders] Physical Mayhem bug again! Death by Touch considered harmful??

2006-06-29 Thread bloodykenny
Apparently what's bad is doing damage while vphysics.dll has done a callback 
for one of its ShouldCollide things or something.  Inside the 
CBaseEntity::TakeDamage there is this code:

if (PhysIsInCallback()) {
PhysCallbackDamage(this, inputInfo);
} else  {
... actually do the damage...
}

So as far as I can tell damage inside a Touch should be legal as far as the 
physics is concerned.  Can Valve please confirm?

However as a test I've changed my code inside the touch function to do a 
PhysCallbackDamage() ... will see if it makes a difference.

At 2006/06/25 01:52 PM, [EMAIL PROTECTED] wrote:
After a month or so without the commonplace Physical Mayhem bug that repros in 
HL2DM, I have now managed to create a new Physical Mayhem bug that's possibly 
unique to my mod, or at least to mods with similar features.  This one is a 
bit harder to repro - I've only seen it twice in the last week or so.

It seems to be tied to a recent code change (or is otherwise a great 
coincidence) that allows for high-speed players to do damage to each other 
when they collide.  So what I'm suspicious of is this: is there some 
undocumented bug/feature in vphysics.dll that could cause Physical Mayhem if 
players died or fragged while in the CHL2MP_Player::Touch(CBaseEntity *pOther) 
function?

I could theoretically add a delay mechanism to take note of the damage and 
come back and apply the damage later.  I'm extra suspicious this may be 
required because CCollisionEvent::AddDamageEvent seems to be doing just that 
sort of thing.

___
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] physics shadow

2006-06-29 Thread John Sheu
On Thursday 29 June 2006 8:51 pm, Tony omega Sergi wrote:
   m_pPhysicsController-SetPushMassLimit( 350.0f );
   m_pPhysicsController-SetPushSpeedLimit( 50.0f );

Limits the mass of objects which the player's shadow controller can push, and
the maximum speed to push it away with, I would think.

-John Sheu

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



RE: [hlcoders] physics shadow

2006-06-29 Thread Jay Stelly
These limits apply to the impulses a player can exert through his
contact points.

The mass limit is the limit at which the player controller stops pushing
through the contact.  So with the code below the player will not push
against the contact normal with any object  350kg.

The speed limit actually controls the impulse you can apply but limiting
the velocity again through the contact.  So the player won't be able to
apply an impulse greater than (50 * playermass) against the contact
normal of any contact.

There is also a general speed limit that controls the overall velocity.
So these limits explicitly deal with contacts.  The basic idea is to
allow the player to accelerate to max velocity quickly without giving
the player the ability to push really massive objects out of his way as
a result.  Without the extra term increasing the acceleration rate
increases the mass a player can push.

Jay


 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of John Sheu
 Sent: Thursday, June 29, 2006 9:26 PM
 To: hlcoders@list.valvesoftware.com
 Subject: Re: [hlcoders] physics shadow

 On Thursday 29 June 2006 8:51 pm, Tony omega Sergi wrote:
  m_pPhysicsController-SetPushMassLimit( 350.0f );
  m_pPhysicsController-SetPushSpeedLimit( 50.0f );

 Limits the mass of objects which the player's shadow
 controller can push, and the maximum speed to push it away
 with, I would think.

 -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