Re: [hlcoders] Jerky Movement when player is on moving lift/elevator.
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.
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.
-- [ 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.
-- [ 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.
*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
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
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.
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??
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
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
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