Re: [hlcoders] Any ideas on how to get thought bubbles to appear above character heads?
Just look at the code that shows something above the player's head for voice communication. We copied that for speech bubbles when typing for instance. On 26/04/2011 19:38, Saul Rennison wrote: You'd be best off creating a sprite (CSpriteOriented) at player creation, then making it visible when you want to show it, and then hiding it a few seconds later. All that's server-side, by the way. Thanks, - Saul On 26 April 2011 17:54, Secretive Loon secretivel...@gmail.com mailto:secretivel...@gmail.com wrote: Apologies if this is posted more than once. I was unsubscribed from this list for some reason. I'm going to make characters that have little thought bubbles like how characters do in The Sims. I know that I'm probably going to use billboards (so the thought image always faces the camera) but I have no idea where to start. Could anyone give me any advice as to how I might have an image that appears in game (the thought) and then disappears a few seconds later? Perhaps I create a wall, set the image as the wallpaper, billboard it and stick on a timer? What classes do you think could help me? Thanks in advance. ___ 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] CUtlVector crash ( screenshake )
Orangebox. Yeah, my next move was online debug play, hope I get lucky :)
On 2/04/2011 21:16, Psy_Commando wrote:
You could test the game online compiled in debug, you should get a
more precise error or assertion. Remove any breakpoints before :)
You can also put a breakpoint before the purge of that particular
vector, and try to see if it crashes at the same position in the
vector. Also, check what is actually contained at that particular
position in the vector, and in the container object if the pointer's
not null. That should give a few more hints.
What version of the codebase are you using by the way ?
On Fri, Apr 1, 2011 at 12:26 AM, joshua simmons simmons...@gmail.com
mailto:simmons...@gmail.com wrote:
Just a note that memcpy_s doesn't do much other than make your
code non-portable. You're better off avoiding malloc in the first
place than using a slightly slower version of it that's just as
unsafe.
On Fri, Apr 1, 2011 at 3:14 PM, Maarten De Meyer
maar...@off-limits.be mailto:maar...@off-limits.be wrote:
No, both windows and linux. I suspected it was a valid
construction. Still, that leaves me out of ideas :P
From: Adam amckern McKern
Sent: vrijdag 1 april 2011 3:25
To: Discussion of Half-Life Programming
Subject: Re: [hlcoders] CUtlVector crash ( screenshake )
You might want to upgrade to memcpy_s if your windows server
only (GCC has a dislike to microsoft non ISO code).
Owner Nigredo Studios http://www.nigredostudios.com
http://www.nigredostudios.com/
--- On *Fri, 1/4/11, Tony omega Sergi /omegal...@gmail.com
mailto:omegal...@gmail.com/* wrote:
From: Tony omega Sergi omegal...@gmail.com
mailto:omegal...@gmail.com
Subject: Re: [hlcoders] CUtlVector crash ( screenshake )
To: Discussion of Half-Life Programming
hlcoders@list.valvesoftware.com
mailto:hlcoders@list.valvesoftware.com
Cc: Tony Paloma drunkenf...@hotmail.com
mailto:drunkenf...@hotmail.com
Received: Friday, 1 April, 2011, 12:10 PM
It's destructing the container the pointer to your object
is stored in, not the object itself.
PurgeAndDelete on the other hand will destroy the object
itself as well.
On Fri, Apr 1, 2011 at 4:02 AM, Tony Paloma
drunkenf...@hotmail.com
http://au.mc335.mail.yahoo.com/mc/compose?to=drunkenf...@hotmail.com
wrote:
Your point about #3 does indeed look fishy. I'm not
sure why they're calling
the destructor on their own anyways.
Try this:
// Retire this shake.
void *shake = m_ShakeList.Element( nShake );
m_ShakeList.FastRemove( nShake );
delete shake;
continue;
-Original Message-
From: hlcoders-boun...@list.valvesoftware.com
http://au.mc335.mail.yahoo.com/mc/compose?to=hlcoders-boun...@list.valvesoftware.com
[mailto:hlcoders-boun...@list.valvesoftware.com
http://au.mc335.mail.yahoo.com/mc/compose?to=hlcoders-boun...@list.valvesoftware.com]
On Behalf Of Maarten De
Meyer
Sent: Thursday, March 31, 2011 11:38 AM
To: Discussion of Half-Life Programming
Subject: [hlcoders] CUtlVector crash ( screenshake )
Hi List!
So, we're finally out there in closed beta. One of the
most annyoing issues
is a client side crash. The call stack doesn't say all
that much, but still:
it always happens in the Purge command in the
destructor of
CUtlVector:
template typename T, class A
inline CUtlVectorT, A::~CUtlVector()
{
Purge();
}
more precisely, in the CUtlVector screenshake_t * .
[ There's only one of
those, in CViewEffects ].
Now, some questions:
1) any idea why this happens? [ had to ask :D ]
2) if no, any idea on how to debug?
3) Is the following normal? :
// Retire this shake.
delete m_ShakeList.Element( nShake );
m_ShakeList.FastRemove( nShake );
continue;
where:
template typename T, class A
void CUtlVectorT, A::FastRemove( int elem ) {
Assert( IsValidIndex(elem) );
Destruct( Element(elem
[hlcoders] CUtlVector crash ( screenshake )
Hi List!
So, we're finally out there in closed beta. One of the most annyoing
issues is a client side crash. The call stack doesn't say all that much,
but still: it always happens in the Purge command in the destructor of
CUtlVector:
template typename T, class A
inline CUtlVectorT, A::~CUtlVector()
{
Purge();
}
more precisely, in the CUtlVector screenshake_t * . [ There's only
one of those, in CViewEffects ].
Now, some questions:
1) any idea why this happens? [ had to ask :D ]
2) if no, any idea on how to debug?
3) Is the following normal? :
// Retire this shake.
delete m_ShakeList.Element( nShake );
m_ShakeList.FastRemove( nShake );
continue;
where:
template typename T, class A
void CUtlVectorT, A::FastRemove( int elem )
{
Assert( IsValidIndex(elem) );
Destruct( Element(elem) );
if (m_Size 0)
{
memcpy( Element(elem), Element(m_Size-1), sizeof(T) );
--m_Size;
}
}
and
template class T
inline void Destruct( T* pMemory )
{
pMemory-~T();
#ifdef _DEBUG
memset( pMemory, 0xDD, sizeof(T) );
#endif
}
Concretely: how come it is allowed to first delete a pointer, and
afterwards still call the destructor on it? Is that not dangerous? [
Probably a c++ finesse I'm missing ]
Shake works fine most of the time though ( I tried with the console
cheat command ), so it's not a reproducible crash yet - but happens very
often in online games.
Thanks in advance for any lights shed in the darkness!
-- Maarten
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] CUtlVector crash ( screenshake )
No, both windows and linux. I suspected it was a valid construction. Still,
that leaves me out of ideas :P
-Original Message-
From: Adam amckern McKern
Sent: vrijdag 1 april 2011 3:25
To: Discussion of Half-Life Programming
Subject: Re: [hlcoders] CUtlVector crash ( screenshake )
You might want to upgrade to memcpy_s if your windows server only (GCC has a
dislike to microsoft non ISO code).
Owner Nigredo Studios http://www.nigredostudios.com
--- On Fri, 1/4/11, Tony omega Sergi omegal...@gmail.com wrote:
From: Tony omega Sergi omegal...@gmail.com
Subject: Re: [hlcoders] CUtlVector crash ( screenshake )
To: Discussion of Half-Life Programming hlcoders@list.valvesoftware.com
Cc: Tony Paloma drunkenf...@hotmail.com
Received: Friday, 1 April, 2011, 12:10 PM
It's destructing the container the pointer to your object is stored in, not the
object itself.
PurgeAndDelete on the other hand will destroy the object itself as well.
On Fri, Apr 1, 2011 at 4:02 AM, Tony Paloma drunkenf...@hotmail.com wrote:
Your point about #3 does indeed look fishy. I'm not sure why they're calling
the destructor on their own anyways.
Try this:
// Retire this shake.
void *shake = m_ShakeList.Element( nShake );
m_ShakeList.FastRemove( nShake );
delete shake;
continue;
-Original Message-
From: hlcoders-boun...@list.valvesoftware.com
[mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of Maarten De
Meyer
Sent: Thursday, March 31, 2011 11:38 AM
To: Discussion of Half-Life Programming
Subject: [hlcoders] CUtlVector crash ( screenshake )
Hi List!
So, we're finally out there in closed beta. One of the most annyoing issues
is a client side crash. The call stack doesn't say all that much, but still:
it always happens in the Purge command in the destructor of
CUtlVector:
template typename T, class A
inline CUtlVectorT, A::~CUtlVector()
{
Purge();
}
more precisely, in the CUtlVector screenshake_t * . [ There's only one of
those, in CViewEffects ].
Now, some questions:
1) any idea why this happens? [ had to ask :D ]
2) if no, any idea on how to debug?
3) Is the following normal? :
// Retire this shake.
delete m_ShakeList.Element( nShake );
m_ShakeList.FastRemove( nShake );
continue;
where:
template typename T, class A
void CUtlVectorT, A::FastRemove( int elem ) {
Assert( IsValidIndex(elem) );
Destruct( Element(elem) );
if (m_Size 0)
{
memcpy( Element(elem), Element(m_Size-1), sizeof(T) );
--m_Size;
}
}
and
template class T
inline void Destruct( T* pMemory )
{
pMemory-~T();
#ifdef _DEBUG
memset( pMemory, 0xDD, sizeof(T) ); #endif }
Concretely: how come it is allowed to first delete a pointer, and afterwards
still call the destructor on it? Is that not dangerous? [ Probably a c++
finesse I'm missing ] Shake works fine most of the time though ( I tried
with the console cheat command ), so it's not a reproducible crash yet - but
happens very often in online games.
Thanks in advance for any lights shed in the darkness!
-- Maarten
___
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
--
-Tony
-Inline Attachment Follows-
___
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] Linux vphysics infinite NaN m_vecAbsVelocity IS_NAN grenade PhysicsToss PhysicsCheckVelocity grrr
there, that should do it as far as keywords go for future generations, might save someone a good night's sleep. FYI: The IS_NAN macro doesn't work on all platforms. Or the extern const int nanmask; is. Or it's wrong somewhere. But don't depend on IS_NAN on linux, it gives false positives. If anyone has an intelligent explanation on this, it'd be nice. My hypothesis is that the internal representation of floating points may differ on different platforms? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] View model transform @ mouselook
Hi list, As a fix for a previously posted issue we seriously scaled down all our view models. As a consequence i've had to change quite a few things in code ( eg muzzle flashes, sprint bob code,...) One thing still escapes me: when turning around quickly using the mouse, the view model gets distorted. I assume this is a voluntary effect in source somewhere to make looking around more dynamic. Problem is, with the new weapon scales this deformation is way too big so I'd need to modify it, and I have no idea where in the code this effect is applied. Anyone know where to look? Maarten___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] View model transform @ mouselook
Thanks. Bob I know too well, it's sway I was looking for :) -Original Message- From: Garry Newman Sent: donderdag 3 maart 2011 11:06 To: Discussion of Half-Life Programming Subject: Re: [hlcoders] View model transform @ mouselook It's called view bob and view sway. That should help you find it :) garry On Thu, Mar 3, 2011 at 9:56 AM, Maarten De Meyer maar...@off-limits.be wrote: Hi list, As a fix for a previously posted issue we seriously scaled down all our view models. As a consequence i've had to change quite a few things in code ( eg muzzle flashes, sprint bob code,...) One thing still escapes me: when turning around quickly using the mouse, the view model gets distorted. I assume this is a voluntary effect in source somewhere to make looking around more dynamic. Problem is, with the new weapon scales this deformation is way too big so I'd need to modify it, and I have no idea where in the code this effect is applied. Anyone know where to look? Maarten ___ 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] Overriding materials, especially while rendering world (BSP) geometry
It depends what you put in your part of the combo and what you keep. We wanted to keep the existing shader behavior and add a desaturation at the end that can be dynamically toggled on and off. Desaturation is not very costly, it's only a few instructions, but adding those already pushed us over the limit of a lot of combos. Since I didnt want to increase the shader model I cut out a few combos - left out some variables we didn't use anyway in our maps, until the lot compiled. Depending on what you want in your vision you won't have a problem - if it's very stylised you don't need to keep all the existing shader code and you won't have a problem. -- Maarten On 25/02/2011 19:37, Zach Brockway wrote: Good info. Tony also suggested using a material proxy on #hlcoders. I'll hopefully have time to look into it some this weekend. However, your mention of instruction limits is cause for concern. If the alternate vision mode behavior is controlled by a combo variable, wouldn't the compiler optimization of the static branching prevent the normal behavior of the shader from eating up instruction limit? I'll also look into replacing the materials, but that sounds even harder to implement cleanly. Thanks. On Tue, Feb 22, 2011 at 9:23 PM, Maarten De Meyer maar...@off-limits.be mailto:maar...@off-limits.be wrote: Wasnt there a replacematerial method? I remember something like that. For our alternate vision i ended up making a custom version of all the stock shaders with a material proxy allowing me to switch between vision modes in the shader itself. Advantages there are the switch is immediate and you can change the effects outcome per material, contrary to a postprocess. Disadvantages are that you have to be able to do it in a shader ofcourse, and that the stock shaders leave very little room for modification before you hit the limits of the shader model. From: Zach Brockway Sent: woensdag 23 februari 2011 0:23 To: hlcoders@list.valvesoftware.com mailto:hlcoders@list.valvesoftware.com Subject: [hlcoders] Overriding materials, especially while rendering world (BSP) geometry Hi list, I've been investigating the possibility of being able to do across-the-board material overriding. Motivated by an idea for implementing an alternate vision mode, it would also entail a few other things like rendering alternate view setups into render targets; however, all of that seems to be well-supported and you even get the benefit of examples of how to do it. The part that I'm really stuck on is the fact that there doesn't seem to be a way to affect the material used for rendering BSP geometry, since it's all blackboxed away in the engine. Things I've tried: 1. Calling ForcedMaterialOverride on modelrender, studiorender, and g_pStudioRender, before render-DrawWorldLists is called. This had no effect. 2. Installing an IBrushRenderer using render-InstallBrushSurfaceRenderer. My implementation of RenderBrushModelSurface was never called, so I suspect this only affects brush-based entities. Of course, I still have to worry about how to handle the rendering of *everything else* if I manage to figure this out, but this particular problem struck me as the biggest stretch for the engine. Thanks in advance for any advice. -- They've penetrated our code walls. They're stealing the Internet! We'll need to hack all IPs simultaneously. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- They've penetrated our code walls. They're stealing the Internet! We'll need to hack all IPs simultaneously. ___ 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] Overriding materials, especially while rendering world (BSP) geometry
oh, you smartass [ not a bad quality in a programmer ;) ] I know, but I also tweak brightness/contrast and some other minor things in the shader, so I needed 'a few' :p On 25/02/2011 20:36, Zach Brockway wrote: That makes sense. Thanks again for the quick reply. (As an aside, it seems like desaturation could be done in one instruction, e.g. color.rgb = dot(color.rgb, float3(0.2126, 0.7152, 0.0722)); :) On Fri, Feb 25, 2011 at 11:13 AM, Maarten De Meyer maar...@off-limits.be mailto:maar...@off-limits.be wrote: It depends what you put in your part of the combo and what you keep. We wanted to keep the existing shader behavior and add a desaturation at the end that can be dynamically toggled on and off. Desaturation is not very costly, it's only a few instructions, but adding those already pushed us over the limit of a lot of combos. Since I didnt want to increase the shader model I cut out a few combos - left out some variables we didn't use anyway in our maps, until the lot compiled. Depending on what you want in your vision you won't have a problem - if it's very stylised you don't need to keep all the existing shader code and you won't have a problem. -- Maarten On 25/02/2011 19:37, Zach Brockway wrote: Good info. Tony also suggested using a material proxy on #hlcoders. I'll hopefully have time to look into it some this weekend. However, your mention of instruction limits is cause for concern. If the alternate vision mode behavior is controlled by a combo variable, wouldn't the compiler optimization of the static branching prevent the normal behavior of the shader from eating up instruction limit? I'll also look into replacing the materials, but that sounds even harder to implement cleanly. Thanks. On Tue, Feb 22, 2011 at 9:23 PM, Maarten De Meyer maar...@off-limits.be mailto:maar...@off-limits.be wrote: Wasnt there a replacematerial method? I remember something like that. For our alternate vision i ended up making a custom version of all the stock shaders with a material proxy allowing me to switch between vision modes in the shader itself. Advantages there are the switch is immediate and you can change the effects outcome per material, contrary to a postprocess. Disadvantages are that you have to be able to do it in a shader ofcourse, and that the stock shaders leave very little room for modification before you hit the limits of the shader model. From: Zach Brockway Sent: woensdag 23 februari 2011 0:23 To: hlcoders@list.valvesoftware.com mailto:hlcoders@list.valvesoftware.com Subject: [hlcoders] Overriding materials, especially while rendering world (BSP) geometry Hi list, I've been investigating the possibility of being able to do across-the-board material overriding. Motivated by an idea for implementing an alternate vision mode, it would also entail a few other things like rendering alternate view setups into render targets; however, all of that seems to be well-supported and you even get the benefit of examples of how to do it. The part that I'm really stuck on is the fact that there doesn't seem to be a way to affect the material used for rendering BSP geometry, since it's all blackboxed away in the engine. Things I've tried: 1. Calling ForcedMaterialOverride on modelrender, studiorender, and g_pStudioRender, before render-DrawWorldLists is called. This had no effect. 2. Installing an IBrushRenderer using render-InstallBrushSurfaceRenderer. My implementation of RenderBrushModelSurface was never called, so I suspect this only affects brush-based entities. Of course, I still have to worry about how to handle the rendering of *everything else* if I manage to figure this out, but this particular problem struck me as the biggest stretch for the engine. Thanks in advance for any advice. -- They've penetrated our code walls. They're stealing the Internet! We'll need to hack all IPs simultaneously. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- They've penetrated our code walls. They're stealing the Internet! We'll need to hack all IPs simultaneously. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http
Re: [hlcoders] Shell eject issue
Scale does seem to be the issue alright, our view models are big. But indeed, scaling them wont be straightforward, and we have a lot of weapons to process. Anyone know of a fast method? -Original Message- From: Adam amckern McKern Sent: dinsdag 22 februari 2011 7:30 To: Discussion of Half-Life Programming Subject: Re: [hlcoders] Shell eject issue $scale never seemed to work for me, it would only go to a lesser size of 0.5 - i had to manually adjust my view model in max, and then realign it, and export again. Owner Nigredo Studios http://www.nigredostudios.com --- On Tue, 22/2/11, Stephen Micheals stephen.miche...@gmail.com wrote: From: Stephen Micheals stephen.miche...@gmail.com Subject: Re: [hlcoders] Shell eject issue To: Discussion of Half-Life Programming hlcoders@list.valvesoftware.com Received: Tuesday, 22 February, 2011, 1:24 PM being a view model it can be created at any size, the way it looks from the players viewpoint is what matters, but it seems that lighting and other items may be applied to the viewmodel relative to the worldspace coordinates. i applied a small hack by adding $scale to the viewmodels qc and that brought them within range of the hl2 sp/mp viewmodels in size/scale. this is one of the viewmodels as it was originally. http://freelancenerd.com/blog/wp-content/uploads/2011/02/aks_before.jpg after it was scaled down to hl2 viewmodel size: http://freelancenerd.com/blog/wp-content/uploads/2011/02/aks_normal.jpg On Mon, Feb 21, 2011 at 1:42 PM, Maarten De Meyer maar...@off-limits.be wrote: hmm, any idea what the standard scale is ? ___ 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] Overriding materials, especially while rendering world (BSP) geometry
Wasnt there a replacematerial method? I remember something like that. For our alternate vision i ended up making a custom version of all the stock shaders with a material proxy allowing me to switch between vision modes in the shader itself. Advantages there are the switch is immediate and you can change the effects outcome per material, contrary to a postprocess. Disadvantages are that you have to be able to do it in a shader ofcourse, and that the stock shaders leave very little room for modification before you hit the limits of the shader model. -Original Message- From: Zach Brockway Sent: woensdag 23 februari 2011 0:23 To: hlcoders@list.valvesoftware.com Subject: [hlcoders] Overriding materials, especially while rendering world (BSP) geometry Hi list, I've been investigating the possibility of being able to do across-the-board material overriding. Motivated by an idea for implementing an alternate vision mode, it would also entail a few other things like rendering alternate view setups into render targets; however, all of that seems to be well-supported and you even get the benefit of examples of how to do it. The part that I'm really stuck on is the fact that there doesn't seem to be a way to affect the material used for rendering BSP geometry, since it's all blackboxed away in the engine. Things I've tried: 1. Calling ForcedMaterialOverride on modelrender, studiorender, and g_pStudioRender, before render-DrawWorldLists is called. This had no effect. 2. Installing an IBrushRenderer using render-InstallBrushSurfaceRenderer. My implementation of RenderBrushModelSurface was never called, so I suspect this only affects brush-based entities. Of course, I still have to worry about how to handle the rendering of *everything else* if I manage to figure this out, but this particular problem struck me as the biggest stretch for the engine. Thanks in advance for any advice. -- They've penetrated our code walls. They're stealing the Internet! We'll need to hack all IPs simultaneously. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Physics props 90° angle snap issue - (linux?)
For future reference: turns out it *was* the linux build. Source doesn't seem to like gcc 4.2.4 - built fine, but with a few vphysics quirks as said below. I rebuilt with gcc 4.1.2 and the 90° snap issue was gone. Makes me fear though what other kind of bugs are due to the gcc version, and what gcc version finally is the way to go, if there is any :) On 20/02/2011 16:04, Maarten De Meyer wrote: No no, I'm fairly sure it's not me :D I beyond-compare'd anything between prop_physics and the engine, no relevant changes on my side. I still think it'll turn out to be an issue with the linux build - eg gcc version can be a factor too, although we're on 4.2.4 so we should be good. If I end up not finding it at all I'll compile a clean OB mod on my linux machine or something and work from there, but hope that won't be necessary. On 20/02/2011 15:39, Tobias Kammersgaard wrote: Sounds like you need to check previous revisions of your code to be honest. - ScarT On 20 February 2011 14:18, Maarten De Meyer maar...@off-limits.be mailto:maar...@off-limits.be wrote: Found out another piece of interesting information. When we drop weapons, we give them the direction of the player to make the drop look realistic. This has always worked decently. On our linux server, the dropped weapons - also physics objects ofcourse - always have orientation 0 0 0, irrespective of the player orientation. On 19/02/2011 15:01, Tom Edwards wrote: Without knowing how the debug code works it's hard to say what that means. But it's still definitely a networking problem rather than something that's happening on the server. What happens when a predicted player walks around the affected object, hugging it tightly? *From:* Maarten De Meyer maar...@off-limits.be mailto:maar...@off-limits.be *To:* hlcoders@list.valvesoftware.com mailto:hlcoders@list.valvesoftware.com *Sent:* Saturday, 19 February, 2011 11:14:39 *Subject:* Re: [hlcoders] Physics props 90° angle snap issue - (linux?) vcollide_wireframe moves together with the mesh I'm afraid. On 19/02/2011 11:52, Tom Edwards wrote: If you look closely, the collision model doesn't change. It's only the visual, client-side mesh that's out of place. Try using vcollide_wireframe to see what's really going on.|| *From:* Jonathan Murphy nuclearfri...@gmail.com mailto:nuclearfri...@gmail.com *To:* Discussion of Half-Life Programming hlcoders@list.valvesoftware.com mailto:hlcoders@list.valvesoftware.com *Sent:* Saturday, 19 February, 2011 10:41:28 *Subject:* Re: [hlcoders] Physics props 90° angle snap issue - (linux?) In my experience it is unlikely to be a Linux specific issue, and more of a prediction issue. Try introducing fake lag on a listen server (net_fakelag 200) and seeing if the issue is reproducable. That should make it much easier to debug. On Sat, Feb 19, 2011 at 9:33 PM, Maarten De Meyer maar...@off-limits.be mailto:maar...@off-limits.be wrote: Yes, they are. From: Jonathan Murphy Sent: zaterdag 19 februari 2011 11:02 To: Discussion of Half-Life Programming Subject: Re: [hlcoders] Physics props 90° angle snap issue - (linux?) Would be a interesting clue to know if all players are seeing exactly the same thing? On Sat, Feb 19, 2011 at 7:42 PM, Joel R. joelru...@gmail.com mailto:joelru...@gmail.com wrote: Have you tested it on a windows dedicated server? Listenservers don't act entirely the same as dedicated servers. It appears like the angle of the physics object is updating a bad networked angle value. On Sat, Feb 19, 2011 at 2:22 AM, Maarten De Meyer maar...@off-limits.be mailto:maar...@off-limits.be wrote: As great as Noir Desir's song is, obviously it's not what I wanted to show :D Here's the real vid with the issue: *http://www.youtube.com/watch?v=QhmrP6eSAek* sorry for that. On 19/02/2011 9:15, Maarten De Meyer wrote: Hi list, we're facing an issue I don't immediately know where to start to debug. Basically, in all of our maps, some physics props have an issue where the orientation of their model snaps at 90° angles instantaneously. This is not only with props, but also eg with our vehicles, so I'm looking suspicously at vphysics :). In addition, this only seems
Re: [hlcoders] Shell eject issue
Thanks a lot list!! Problem solved. I can confirm that $scale works, byt indeed only you do it before the SMD references ( if not it screws up the model ), and that my problems with shell eject muzzle flash were due to viewmodel size. /me happy, 2 bugs to go :) On 22/02/2011 12:52, Tom Edwards wrote: $scale *is* the method. In theory you should be able to apply the same value for each weapon. Just remember to define it before any SMD references. On 22/02/2011 11:33, Maarten De Meyer wrote: Scale does seem to be the issue alright, our view models are big. But indeed, scaling them wont be straightforward, and we have a lot of weapons to process. Anyone know of a fast method? From: Adam amckern McKern Sent: dinsdag 22 februari 2011 7:30 To: Discussion of Half-Life Programming Subject: Re: [hlcoders] Shell eject issue $scale never seemed to work for me, it would only go to a lesser size of 0.5 - i had to manually adjust my view model in max, and then realign it, and export again. Owner Nigredo Studios http://www.nigredostudios.com --- On *Tue, 22/2/11, Stephen Micheals /stephen.miche...@gmail.com/* wrote: From: Stephen Micheals stephen.miche...@gmail.com Subject: Re: [hlcoders] Shell eject issue To: Discussion of Half-Life Programming hlcoders@list.valvesoftware.com Received: Tuesday, 22 February, 2011, 1:24 PM being a view model it can be created at any size, the way it looks from the players viewpoint is what matters, but it seems that lighting and other items may be applied to the viewmodel relative to the worldspace coordinates. i applied a small hack by adding $scale to the viewmodels qc and that brought them within range of the hl2 sp/mp viewmodels in size/scale. this is one of the viewmodels as it was originally. http://freelancenerd.com/blog/wp-content/uploads/2011/02/aks_before.jpg after it was scaled down to hl2 viewmodel size: http://freelancenerd.com/blog/wp-content/uploads/2011/02/aks_normal.jpg On Mon, Feb 21, 2011 at 1:42 PM, Maarten De Meyer maar...@off-limits.be /mc/compose?to=maar...@off-limits.be wrote: hmm, any idea what the standard scale is ? ___ 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] Shell eject issue
hmm, any idea what the standard scale is ? On 21/02/2011 22:28, Stephen Micheals wrote: with the old mod i worked on i noticed issues with the location of effects attached to the view models as well as awkward lighting on the viewmodels themselves. as it turned out the viewmodels were created at a much larger scale then the standard scale most viewmodels were made at and that was causing problems. On Sun, Feb 20, 2011 at 3:40 AM, Maarten De Meyermaar...@off-limits.be wrote: Hi list! I have a problem that I think is a common one. Some effects, like muzzle flash and shell eject, take an attachment's position in view model space, transform it to world space and act upon it. I have some issues with that: if you are looking down ( even a little bit under the straight forward pose ), these effects don't play - I guess because the attachment position is actually *below* the world surface when transformed. For the muzzle flashes I can work around this by rendering the flash anyway, after the world has been rendered. But for shell eject I'm not sure what the best solution is - right now my shell ejection only works when looking up. Is this a common problem? Or is it maybe related to the way our view models are created ( eg, we place them at 0 0 0, is that correct or do they have to be at eye-height in max, corrected with $origin in the .qc or something? ) -- Maarten ___ 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] Shell eject issue
Hi list! I have a problem that I think is a common one. Some effects, like muzzle flash and shell eject, take an attachment's position in view model space, transform it to world space and act upon it. I have some issues with that: if you are looking down ( even a little bit under the straight forward pose ), these effects don't play - I guess because the attachment position is actually *below* the world surface when transformed. For the muzzle flashes I can work around this by rendering the flash anyway, after the world has been rendered. But for shell eject I'm not sure what the best solution is - right now my shell ejection only works when looking up. Is this a common problem? Or is it maybe related to the way our view models are created ( eg, we place them at 0 0 0, is that correct or do they have to be at eye-height in max, corrected with $origin in the .qc or something? ) -- Maarten ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Physics props 90° angle snap issue - (linux?)
Found out another piece of interesting information. When we drop weapons, we give them the direction of the player to make the drop look realistic. This has always worked decently. On our linux server, the dropped weapons - also physics objects ofcourse - always have orientation 0 0 0, irrespective of the player orientation. On 19/02/2011 15:01, Tom Edwards wrote: Without knowing how the debug code works it's hard to say what that means. But it's still definitely a networking problem rather than something that's happening on the server. What happens when a predicted player walks around the affected object, hugging it tightly? *From:* Maarten De Meyer maar...@off-limits.be *To:* hlcoders@list.valvesoftware.com *Sent:* Saturday, 19 February, 2011 11:14:39 *Subject:* Re: [hlcoders] Physics props 90° angle snap issue - (linux?) vcollide_wireframe moves together with the mesh I'm afraid. On 19/02/2011 11:52, Tom Edwards wrote: If you look closely, the collision model doesn't change. It's only the visual, client-side mesh that's out of place. Try using vcollide_wireframe to see what's really going on.|| *From:* Jonathan Murphy nuclearfri...@gmail.com *To:* Discussion of Half-Life Programming hlcoders@list.valvesoftware.com *Sent:* Saturday, 19 February, 2011 10:41:28 *Subject:* Re: [hlcoders] Physics props 90° angle snap issue - (linux?) In my experience it is unlikely to be a Linux specific issue, and more of a prediction issue. Try introducing fake lag on a listen server (net_fakelag 200) and seeing if the issue is reproducable. That should make it much easier to debug. On Sat, Feb 19, 2011 at 9:33 PM, Maarten De Meyer maar...@off-limits.be mailto:maar...@off-limits.be wrote: Yes, they are. From: Jonathan Murphy Sent: zaterdag 19 februari 2011 11:02 To: Discussion of Half-Life Programming Subject: Re: [hlcoders] Physics props 90° angle snap issue - (linux?) Would be a interesting clue to know if all players are seeing exactly the same thing? On Sat, Feb 19, 2011 at 7:42 PM, Joel R. joelru...@gmail.com mailto:joelru...@gmail.com wrote: Have you tested it on a windows dedicated server? Listenservers don't act entirely the same as dedicated servers. It appears like the angle of the physics object is updating a bad networked angle value. On Sat, Feb 19, 2011 at 2:22 AM, Maarten De Meyer maar...@off-limits.be mailto:maar...@off-limits.be wrote: As great as Noir Desir's song is, obviously it's not what I wanted to show :D Here's the real vid with the issue: *http://www.youtube.com/watch?v=QhmrP6eSAek* sorry for that. On 19/02/2011 9:15, Maarten De Meyer wrote: Hi list, we're facing an issue I don't immediately know where to start to debug. Basically, in all of our maps, some physics props have an issue where the orientation of their model snaps at 90° angles instantaneously. This is not only with props, but also eg with our vehicles, so I'm looking suspicously at vphysics :). In addition, this only seems to happen on our linux server. Not 100% sure, since it does not happen consistently on all props, but we've tried reproducing it a lot on a windows listenserver without success, and on our linux dedicated server it happens frequently. Here's a video of the issue: *http://www.youtube.com/watch?v=NrgcRvBJYBE* At one point we had a vehicle that stood still with a driver in it, and it did a 'snap' at nearly fixed intervals of several seconds. Player got out, it went away, player stepped in, it was back ( another reason for me to look at vphysics with the evil eye ). I'm hoping someone has hit this issue before, or can at least point me in the right direction, or, a method for debugging this. Since I'm not sure if it's related to vphysics linux internals, the linux build machine/settings, networking tolerances, ... I'm not sure where to start looking. Thanks for any feedback ( or sympathy :D ), Maarten ___ 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
Re: [hlcoders] Physics props 90° angle snap issue - (linux?)
No no, I'm fairly sure it's not me :D I beyond-compare'd anything between prop_physics and the engine, no relevant changes on my side. I still think it'll turn out to be an issue with the linux build - eg gcc version can be a factor too, although we're on 4.2.4 so we should be good. If I end up not finding it at all I'll compile a clean OB mod on my linux machine or something and work from there, but hope that won't be necessary. On 20/02/2011 15:39, Tobias Kammersgaard wrote: Sounds like you need to check previous revisions of your code to be honest. - ScarT On 20 February 2011 14:18, Maarten De Meyer maar...@off-limits.be mailto:maar...@off-limits.be wrote: Found out another piece of interesting information. When we drop weapons, we give them the direction of the player to make the drop look realistic. This has always worked decently. On our linux server, the dropped weapons - also physics objects ofcourse - always have orientation 0 0 0, irrespective of the player orientation. On 19/02/2011 15:01, Tom Edwards wrote: Without knowing how the debug code works it's hard to say what that means. But it's still definitely a networking problem rather than something that's happening on the server. What happens when a predicted player walks around the affected object, hugging it tightly? *From:* Maarten De Meyer maar...@off-limits.be mailto:maar...@off-limits.be *To:* hlcoders@list.valvesoftware.com mailto:hlcoders@list.valvesoftware.com *Sent:* Saturday, 19 February, 2011 11:14:39 *Subject:* Re: [hlcoders] Physics props 90° angle snap issue - (linux?) vcollide_wireframe moves together with the mesh I'm afraid. On 19/02/2011 11:52, Tom Edwards wrote: If you look closely, the collision model doesn't change. It's only the visual, client-side mesh that's out of place. Try using vcollide_wireframe to see what's really going on.|| *From:* Jonathan Murphy nuclearfri...@gmail.com mailto:nuclearfri...@gmail.com *To:* Discussion of Half-Life Programming hlcoders@list.valvesoftware.com mailto:hlcoders@list.valvesoftware.com *Sent:* Saturday, 19 February, 2011 10:41:28 *Subject:* Re: [hlcoders] Physics props 90° angle snap issue - (linux?) In my experience it is unlikely to be a Linux specific issue, and more of a prediction issue. Try introducing fake lag on a listen server (net_fakelag 200) and seeing if the issue is reproducable. That should make it much easier to debug. On Sat, Feb 19, 2011 at 9:33 PM, Maarten De Meyer maar...@off-limits.be mailto:maar...@off-limits.be wrote: Yes, they are. From: Jonathan Murphy Sent: zaterdag 19 februari 2011 11:02 To: Discussion of Half-Life Programming Subject: Re: [hlcoders] Physics props 90° angle snap issue - (linux?) Would be a interesting clue to know if all players are seeing exactly the same thing? On Sat, Feb 19, 2011 at 7:42 PM, Joel R. joelru...@gmail.com mailto:joelru...@gmail.com wrote: Have you tested it on a windows dedicated server? Listenservers don't act entirely the same as dedicated servers. It appears like the angle of the physics object is updating a bad networked angle value. On Sat, Feb 19, 2011 at 2:22 AM, Maarten De Meyer maar...@off-limits.be mailto:maar...@off-limits.be wrote: As great as Noir Desir's song is, obviously it's not what I wanted to show :D Here's the real vid with the issue: *http://www.youtube.com/watch?v=QhmrP6eSAek* sorry for that. On 19/02/2011 9:15, Maarten De Meyer wrote: Hi list, we're facing an issue I don't immediately know where to start to debug. Basically, in all of our maps, some physics props have an issue where the orientation of their model snaps at 90° angles instantaneously. This is not only with props, but also eg with our vehicles, so I'm looking suspicously at vphysics :). In addition, this only seems to happen on our linux server. Not 100% sure, since it does not happen consistently on all props, but we've tried reproducing it a lot on a windows listenserver without success, and on our linux dedicated server it happens frequently. Here's a video of the issue: *http://www.youtube.com/watch?v=NrgcRvBJYBE
[hlcoders] Physics props 90° angle snap issue - (linux?)
Hi list, we're facing an issue I don't immediately know where to start to debug. Basically, in all of our maps, some physics props have an issue where the orientation of their model snaps at 90° angles instantaneously. This is not only with props, but also eg with our vehicles, so I'm looking suspicously at vphysics :). In addition, this only seems to happen on our linux server. Not 100% sure, since it does not happen consistently on all props, but we've tried reproducing it a lot on a windows listenserver without success, and on our linux dedicated server it happens frequently. Here's a video of the issue: *http://www.youtube.com/watch?v=NrgcRvBJYBE* At one point we had a vehicle that stood still with a driver in it, and it did a 'snap' at nearly fixed intervals of several seconds. Player got out, it went away, player stepped in, it was back ( another reason for me to look at vphysics with the evil eye ). I'm hoping someone has hit this issue before, or can at least point me in the right direction, or, a method for debugging this. Since I'm not sure if it's related to vphysics linux internals, the linux build machine/settings, networking tolerances, ... I'm not sure where to start looking. Thanks for any feedback ( or sympathy :D ), Maarten ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Physics props 90° angle snap issue - (linux?)
As great as Noir Desir's song is, obviously it's not what I wanted to show :D Here's the real vid with the issue: *http://www.youtube.com/watch?v=QhmrP6eSAek* sorry for that. On 19/02/2011 9:15, Maarten De Meyer wrote: Hi list, we're facing an issue I don't immediately know where to start to debug. Basically, in all of our maps, some physics props have an issue where the orientation of their model snaps at 90° angles instantaneously. This is not only with props, but also eg with our vehicles, so I'm looking suspicously at vphysics :). In addition, this only seems to happen on our linux server. Not 100% sure, since it does not happen consistently on all props, but we've tried reproducing it a lot on a windows listenserver without success, and on our linux dedicated server it happens frequently. Here's a video of the issue: *http://www.youtube.com/watch?v=NrgcRvBJYBE* At one point we had a vehicle that stood still with a driver in it, and it did a 'snap' at nearly fixed intervals of several seconds. Player got out, it went away, player stepped in, it was back ( another reason for me to look at vphysics with the evil eye ). I'm hoping someone has hit this issue before, or can at least point me in the right direction, or, a method for debugging this. Since I'm not sure if it's related to vphysics linux internals, the linux build machine/settings, networking tolerances, ... I'm not sure where to start looking. Thanks for any feedback ( or sympathy :D ), Maarten ___ 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: Physics props 90° angle snap issue - (linux?)
Yes, they are. -Original Message- From: Jonathan Murphy Sent: zaterdag 19 februari 2011 11:02 To: Discussion of Half-Life Programming Subject: Re: [hlcoders] Physics props 90° angle snap issue - (linux?) Would be a interesting clue to know if all players are seeing exactly the same thing? On Sat, Feb 19, 2011 at 7:42 PM, Joel R. joelru...@gmail.com wrote: Have you tested it on a windows dedicated server? Listenservers don't act entirely the same as dedicated servers. It appears like the angle of the physics object is updating a bad networked angle value. On Sat, Feb 19, 2011 at 2:22 AM, Maarten De Meyer maar...@off-limits.bewrote: As great as Noir Desir's song is, obviously it's not what I wanted to show :D Here's the real vid with the issue: *http://www.youtube.com/watch?v=QhmrP6eSAek* sorry for that. On 19/02/2011 9:15, Maarten De Meyer wrote: Hi list, we're facing an issue I don't immediately know where to start to debug. Basically, in all of our maps, some physics props have an issue where the orientation of their model snaps at 90° angles instantaneously. This is not only with props, but also eg with our vehicles, so I'm looking suspicously at vphysics :). In addition, this only seems to happen on our linux server. Not 100% sure, since it does not happen consistently on all props, but we've tried reproducing it a lot on a windows listenserver without success, and on our linux dedicated server it happens frequently. Here's a video of the issue: *http://www.youtube.com/watch?v=NrgcRvBJYBE* At one point we had a vehicle that stood still with a driver in it, and it did a 'snap' at nearly fixed intervals of several seconds. Player got out, it went away, player stepped in, it was back ( another reason for me to look at vphysics with the evil eye ). I'm hoping someone has hit this issue before, or can at least point me in the right direction, or, a method for debugging this. Since I'm not sure if it's related to vphysics linux internals, the linux build machine/settings, networking tolerances, ... I'm not sure where to start looking. Thanks for any feedback ( or sympathy :D ), Maarten ___ 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] Physics props 90° angle snap issue - (linux?)
vcollide_wireframe moves together with the mesh I'm afraid. On 19/02/2011 11:52, Tom Edwards wrote: If you look closely, the collision model doesn't change. It's only the visual, client-side mesh that's out of place. Try using vcollide_wireframe to see what's really going on.|| *From:* Jonathan Murphy nuclearfri...@gmail.com *To:* Discussion of Half-Life Programming hlcoders@list.valvesoftware.com *Sent:* Saturday, 19 February, 2011 10:41:28 *Subject:* Re: [hlcoders] Physics props 90° angle snap issue - (linux?) In my experience it is unlikely to be a Linux specific issue, and more of a prediction issue. Try introducing fake lag on a listen server (net_fakelag 200) and seeing if the issue is reproducable. That should make it much easier to debug. On Sat, Feb 19, 2011 at 9:33 PM, Maarten De Meyer maar...@off-limits.be mailto:maar...@off-limits.be wrote: Yes, they are. From: Jonathan Murphy Sent: zaterdag 19 februari 2011 11:02 To: Discussion of Half-Life Programming Subject: Re: [hlcoders] Physics props 90° angle snap issue - (linux?) Would be a interesting clue to know if all players are seeing exactly the same thing? On Sat, Feb 19, 2011 at 7:42 PM, Joel R. joelru...@gmail.com mailto:joelru...@gmail.com wrote: Have you tested it on a windows dedicated server? Listenservers don't act entirely the same as dedicated servers. It appears like the angle of the physics object is updating a bad networked angle value. On Sat, Feb 19, 2011 at 2:22 AM, Maarten De Meyer maar...@off-limits.be mailto:maar...@off-limits.be wrote: As great as Noir Desir's song is, obviously it's not what I wanted to show :D Here's the real vid with the issue: *http://www.youtube.com/watch?v=QhmrP6eSAek* sorry for that. On 19/02/2011 9:15, Maarten De Meyer wrote: Hi list, we're facing an issue I don't immediately know where to start to debug. Basically, in all of our maps, some physics props have an issue where the orientation of their model snaps at 90° angles instantaneously. This is not only with props, but also eg with our vehicles, so I'm looking suspicously at vphysics :). In addition, this only seems to happen on our linux server. Not 100% sure, since it does not happen consistently on all props, but we've tried reproducing it a lot on a windows listenserver without success, and on our linux dedicated server it happens frequently. Here's a video of the issue: *http://www.youtube.com/watch?v=NrgcRvBJYBE* At one point we had a vehicle that stood still with a driver in it, and it did a 'snap' at nearly fixed intervals of several seconds. Player got out, it went away, player stepped in, it was back ( another reason for me to look at vphysics with the evil eye ). I'm hoping someone has hit this issue before, or can at least point me in the right direction, or, a method for debugging this. Since I'm not sure if it's related to vphysics linux internals, the linux build machine/settings, networking tolerances, ... I'm not sure where to start looking. Thanks for any feedback ( or sympathy :D ), Maarten ___ 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] Physics props 90° angle snap issue - (linux?)
That was my first try, but I can't reproduce it with net_fakelag. On 19/02/2011 11:41, Jonathan Murphy wrote: In my experience it is unlikely to be a Linux specific issue, and more of a prediction issue. Try introducing fake lag on a listen server (net_fakelag 200) and seeing if the issue is reproducable. That should make it much easier to debug. On Sat, Feb 19, 2011 at 9:33 PM, Maarten De Meyer maar...@off-limits.be mailto:maar...@off-limits.be wrote: Yes, they are. From: Jonathan Murphy Sent: zaterdag 19 februari 2011 11:02 To: Discussion of Half-Life Programming Subject: Re: [hlcoders] Physics props 90° angle snap issue - (linux?) Would be a interesting clue to know if all players are seeing exactly the same thing? On Sat, Feb 19, 2011 at 7:42 PM, Joel R. joelru...@gmail.com mailto:joelru...@gmail.com wrote: Have you tested it on a windows dedicated server? Listenservers don't act entirely the same as dedicated servers. It appears like the angle of the physics object is updating a bad networked angle value. On Sat, Feb 19, 2011 at 2:22 AM, Maarten De Meyer maar...@off-limits.be mailto:maar...@off-limits.be wrote: As great as Noir Desir's song is, obviously it's not what I wanted to show :D Here's the real vid with the issue: *http://www.youtube.com/watch?v=QhmrP6eSAek* sorry for that. On 19/02/2011 9:15, Maarten De Meyer wrote: Hi list, we're facing an issue I don't immediately know where to start to debug. Basically, in all of our maps, some physics props have an issue where the orientation of their model snaps at 90° angles instantaneously. This is not only with props, but also eg with our vehicles, so I'm looking suspicously at vphysics :). In addition, this only seems to happen on our linux server. Not 100% sure, since it does not happen consistently on all props, but we've tried reproducing it a lot on a windows listenserver without success, and on our linux dedicated server it happens frequently. Here's a video of the issue: *http://www.youtube.com/watch?v=NrgcRvBJYBE* At one point we had a vehicle that stood still with a driver in it, and it did a 'snap' at nearly fixed intervals of several seconds. Player got out, it went away, player stepped in, it was back ( another reason for me to look at vphysics with the evil eye ). I'm hoping someone has hit this issue before, or can at least point me in the right direction, or, a method for debugging this. Since I'm not sure if it's related to vphysics linux internals, the linux build machine/settings, networking tolerances, ... I'm not sure where to start looking. Thanks for any feedback ( or sympathy :D ), Maarten ___ 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] Physics props 90° angle snap issue - (linux?)
Well, I just tried playing with cl_predict 0, and it still happens, so I guess it's not prediction then. On 19/02/2011 12:33, Tobias Kammersgaard wrote: I'd say its related to the prediction. You say it doesn't happy with all props? Have you tried checking the difference between props that does it, and props that don't? - ScarT On 19 February 2011 12:17, Jonathan Murphy nuclearfri...@gmail.com mailto:nuclearfri...@gmail.com wrote: How unusual.. I'm starting to feel for you. Hopefully someone can come on here and shine some real light on the problem. :( On Sat, Feb 19, 2011 at 10:15 PM, Maarten De Meyer maar...@off-limits.be mailto:maar...@off-limits.be wrote: That was my first try, but I can't reproduce it with net_fakelag. On 19/02/2011 11:41, Jonathan Murphy wrote: In my experience it is unlikely to be a Linux specific issue, and more of a prediction issue. Try introducing fake lag on a listen server (net_fakelag 200) and seeing if the issue is reproducable. That should make it much easier to debug. On Sat, Feb 19, 2011 at 9:33 PM, Maarten De Meyer maar...@off-limits.be mailto:maar...@off-limits.be wrote: Yes, they are. From: Jonathan Murphy Sent: zaterdag 19 februari 2011 11:02 To: Discussion of Half-Life Programming Subject: Re: [hlcoders] Physics props 90° angle snap issue - (linux?) Would be a interesting clue to know if all players are seeing exactly the same thing? On Sat, Feb 19, 2011 at 7:42 PM, Joel R. joelru...@gmail.com mailto:joelru...@gmail.com wrote: Have you tested it on a windows dedicated server? Listenservers don't act entirely the same as dedicated servers. It appears like the angle of the physics object is updating a bad networked angle value. On Sat, Feb 19, 2011 at 2:22 AM, Maarten De Meyer maar...@off-limits.be mailto:maar...@off-limits.be wrote: As great as Noir Desir's song is, obviously it's not what I wanted to show :D Here's the real vid with the issue: *http://www.youtube.com/watch?v=QhmrP6eSAek* sorry for that. On 19/02/2011 9:15, Maarten De Meyer wrote: Hi list, we're facing an issue I don't immediately know where to start to debug. Basically, in all of our maps, some physics props have an issue where the orientation of their model snaps at 90° angles instantaneously. This is not only with props, but also eg with our vehicles, so I'm looking suspicously at vphysics :). In addition, this only seems to happen on our linux server. Not 100% sure, since it does not happen consistently on all props, but we've tried reproducing it a lot on a windows listenserver without success, and on our linux dedicated server it happens frequently. Here's a video of the issue: *http://www.youtube.com/watch?v=NrgcRvBJYBE* At one point we had a vehicle that stood still with a driver in it, and it did a 'snap' at nearly fixed intervals of several seconds. Player got out, it went away, player stepped in, it was back ( another reason for me to look at vphysics with the evil eye ). I'm hoping someone has hit this issue before, or can at least point me in the right direction, or, a method for debugging this. Since I'm not sure if it's related to vphysics linux internals, the linux build machine/settings, networking tolerances, ... I'm not sure where to start looking. Thanks for any feedback ( or sympathy :D ), Maarten ___ 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 build prediction? issues
I did some checking, and you are right. My issue is unrelated to the linux build, it just didn't show on windows or listenserver cause the connection was way better. It is a generic prediction issue ( net_fakelag 50 causes it to show up on listenserver, cl_prediction 0 and it's gone ) I've also searched this list's archive, I think there is several threads on similar problems already. A suggestion by Yahn a short valve-time ago I think is relevant here. Basically, depending on network conditions, it is normal that a frame gets predicted several times, causing the same events to be re-fired clientside. If I grasped it correctly, putting this construction #if defined( CLIENT_DLL ) if ( prediction-InPrediction() !prediction-IsFirstTimePredicted() ) return; #endif before anything that shouldn't happen twice ( muzzle flashes, SendWeaponAnim, ... ) is a way to deal with this problem: the multiple predictions will still happen as should be the case, but the impact on what the client sees is minimised. I guess that leaves me with the question: is this really what I'm hitting, and more importantly, is the above m.o. the way to go? Do I need to meticulously filter out things I want to be re-predicted and things I don't everywhere and if() with the above statement? Anyone else went through this? I'm no prediction expert, would like to hear from those that are :) -- Maarten On 24/01/2011 1:25, Andrew Ritchie wrote: I had similar experiences with our port to orange box. I had originally thought that it might be my own fault for handling a lot of our free look and weapon aiming client side but we even tracked the same issues in the base SDK on listen servers under fake ping. I can't say it's identical since you mentioned only getting it under linux, we could recreate it on listen servers as well, but the symptoms are the same. I tracked that prediction was rerunning the frames without ever indicating that it was actually a rerun frame, the frame counter would just drop X into he past and run from there. This was the biggest give away that either I'd botched up or something was a lower level had an issue that needed a fix beyond a check to make sure you don't repeat beyond the first prediction frame. I was never able to figure out a real solution to the issue beyond client side absolute platform time checks, which didn't solve anything more than superficially. I'd be interested in hearing if you find anything or anyone else has this and found a solution, as it essentially brought everything to a grinding halt over a year ago, since online play become unmanageable for a lot of players. On Sun, Jan 23, 2011 at 7:07 PM, Maarten De Meyer maar...@off-limits.be mailto:maar...@off-limits.be wrote: Hi list, I've recently built our OB mod's linux server after a loong time working windows only. I got it to compile run fine, but there's a serious general issue with the way the game acts when playing on the linux server. It runs OK, but some things are clearly off, like sprint behavior/animations, shoot animations etc. E.g., one particular, reproducible issue is that if you click to shoot, the shot goes well, but if you hold your mouse down for a while and release it, a second shoot anim/muzzle flash happens, ammo gets decremented, but immediately after that reincremented and that second shot does not register on the server. I think that means that client side is predicting a lot more than it should. I also get some prediction errors wtih cl_showerrors 1. I don't get any of this behavior with the same client, but on the windows server [Which I find a bit odd, since prediction is client-side only, no?]. Anyone has any clue in what direction to look or has had similar experiences? Thanks in advance, Maarten ___ 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] Linux build prediction? issues
Hi list, I've recently built our OB mod's linux server after a loong time working windows only. I got it to compile run fine, but there's a serious general issue with the way the game acts when playing on the linux server. It runs OK, but some things are clearly off, like sprint behavior/animations, shoot animations etc. E.g., one particular, reproducible issue is that if you click to shoot, the shot goes well, but if you hold your mouse down for a while and release it, a second shoot anim/muzzle flash happens, ammo gets decremented, but immediately after that reincremented and that second shot does not register on the server. I think that means that client side is predicting a lot more than it should. I also get some prediction errors wtih cl_showerrors 1. I don't get any of this behavior with the same client, but on the windows server [Which I find a bit odd, since prediction is client-side only, no?]. Anyone has any clue in what direction to look or has had similar experiences? Thanks in advance, Maarten ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] SMG model affects player rendercolor
God, I hope I'm not the only one left here that's still actually modding HL2 :) On 27/12/2010 19:45, drgreen2003 wrote: Its some sort of reverse Valve-Time (http://developer.valvesoftware.com/wiki/Valve_Time). Valve managed it to make the world spin in wrong direction (Must be related to the good christmas holiday sales). So we got back 3 years were we all still subscribed hlcoders :D - /me starts playing HL2 again - *Von:*hlcoders-boun...@list.valvesoftware.com [mailto:hlcoders-boun...@list.valvesoftware.com] *Im Auftrag von *Jamie Femia *Gesendet:* Montag, 27. Dezember 2010 01:47 *An:* Discussion of Half-Life Programming *Betreff:* Re: [hlcoders] SMG model affects player rendercolor What I find stranger is that having also unsubscribed, that this email is getting through but no others are! Surely this can't be the only mail going through the hlcoders servers! On 26 December 2010 23:09, Richard Hough richard.r.ho...@gmail.com mailto:richard.r.ho...@gmail.com wrote: Same here, except my unsubscription was from about 3 years ago. If they restored it from a backup that's an old backup. On Sun, Dec 26, 2010 at 4:27 PM, Jorge Rodriguez bs.v...@gmail.com mailto:bs.v...@gmail.com wrote: Valve probably just restored their single old mailing list server from a backup or some other shenanigans. Just like old times eh fellas? -- 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 ___ 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)
About 5 more and I'm gonna follow the OP I think. AFAIK the longest thread is What MSVC version do you use/have? by Alfred Reynolds, with 91 responses. That's 50 more to go :) 2009/3/6 John Standish vold...@gmail.com Sir, I think that is happening. So this one time, at band camp.oh wait wrong thread :-P On Fri, Mar 6, 2009 at 10:25 AM, Saul Rennison saul.renni...@gmail.com wrote: *anufa digital signature* Maybe we could make this thread an everlasting random thread? 2009/3/6 John Standish vold...@gmail.com - Show quoted text - *digital signature* On Fri, Mar 6, 2009 at 10:18 AM, Saul Rennison saul.renni...@gmail.com wrote: Never! Petition against locking? 2009/3/6 Jorge Rodriguez bs.v...@gmail.com - Show quoted text - I wish I could lock this thread. -- Jorge Vino Rodriguez ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- Thanks, - Saul. - Show quoted text - ___ 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 -- Thanks, - Saul. ___ 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] Multi-Pass Shaders?
http://pastebin.com/m5d914966 Well, thanks you Maarten's help, I've found the appropriate functions for changing the render target. I just have one other problem: The shader needs to know how big a pixel is texture coordinates so that it can grab the adjacent pixels and blend them. The only way I have figured out to do this so far is to call materials-GetRenderTargetDimensions() from within the shader's .cpp file, then pass them into the shader registers as constants. Unfortunately, this wont work without adding tier2.lib to the link libraries, and it seems like kind of a hack. Is there a better/prettier way to do this that doesn't involve adding in extra link libraries to the stdshader project? I've looked around, but I can't seem to find any appropriate examples. I expect I'm just looking in the wrong places. Maarten De Meyer wrote: I can give you some samples of my multipass post-process shaders, both code shader-side, when I get home tonight, if you still need them. They're fairly easy to understand examples. -- Maarten Thanks! I'll take another look at it. Tony Sergi wrote: Core is multipass. -Original Message- From: hlcoders-boun...@list.valvesoftware.com [mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of Walter Gray Sent: January-16-09 3:13 AM To: Discussion of Half-Life Programming Subject: [hlcoders] Multi-Pass Shaders? I'm trying to add a Kuwahara post-process shader into an ep1 mod, but sadly I'm a bit new to shader programming to be undertaking such a task and I've gotten a bit lost. For a Kuwahara shader, or at least the sample implementation of it I've found, you need to have 5 passes, 4 of which render to intermediate buffers, and a 5th one that combines the 4 buffers and renders to the screen. Unfortunately, I haven't been able to find any examples of a multi-pass shader in the SDK, or even any reference to functions that might enable that kind of behavior. Does anyone have any hints on how to do this or places to look for examples? Even knowing if multiple render targets like this are supported would be a big help, as I suspect there may also a way to do it in a single pass. ___ 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] Multi-Pass Shaders?
I can give you some samples of my multipass post-process shaders, both code shader-side, when I get home tonight, if you still need them. They're fairly easy to understand examples. -- Maarten Thanks! I'll take another look at it. Tony Sergi wrote: Core is multipass. -Original Message- From: hlcoders-boun...@list.valvesoftware.com [mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of Walter Gray Sent: January-16-09 3:13 AM To: Discussion of Half-Life Programming Subject: [hlcoders] Multi-Pass Shaders? I'm trying to add a Kuwahara post-process shader into an ep1 mod, but sadly I'm a bit new to shader programming to be undertaking such a task and I've gotten a bit lost. For a Kuwahara shader, or at least the sample implementation of it I've found, you need to have 5 passes, 4 of which render to intermediate buffers, and a 5th one that combines the 4 buffers and renders to the screen. Unfortunately, I haven't been able to find any examples of a multi-pass shader in the SDK, or even any reference to functions that might enable that kind of behavior. Does anyone have any hints on how to do this or places to look for examples? Even knowing if multiple render targets like this are supported would be a big help, as I suspect there may also a way to do it in a single pass. ___ 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] Round Restart wiki tutorial soundscapes
Hi list! I followed the tutorial at http://developer.valvesoftware.com/wiki/Resetting_Maps_and_Entities to do round restarts. [ This code preserves certain entities, among which env_soundscape, on restart ] It specified the use of an event, and clientside, adds this to the handler of the restart event: enginesound-StopAllSounds( true ); Soundscape_OnStopAllSounds(); // Tell the soundscape system. Those lines cause all my soundscapes to die, and they don't play at all anymore after round restart. If I take them out of the handler, at first glance it works OK, but I wonder if I'm not introducing any other bugs that way like permanently looping sounds etc - I'll still remember as_oilrig's elevator for that when I'm old and dying I think :) Anyone here hit that particular bump know the proper way to preserve soundscapes ? Thanks, Maarten ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Simple question ? on mouse key bindings
As said, I'm trying to close the spectator menu. By default it closes with the duck button, but doesnt work if duck is a mouse button. So I capture mouse events in the specgui and see the user hit the right mouse button. So then I need to check if that maps to duck. Tada. This seems like a very strange question.What are you trying to achieve with this? -Skyler Clark On Fri, Dec 26, 2008 at 6:57 AM, Maarten De Meyer maar...@off-limits.bewrote: Update I found out engine-Key_LookupBinding(duck); is returning MOUSE2, but only if it's the first bound key. I don't understand why this function doesn't return an array of strings, since a binding can map to any number of keys? Or at least supply an inverse function, which would allow you to access all information. Maarten Hi, How can I check if e.g. my right mouse button is bound to e.g. duck ? I'm trying to close the spectator menu. My duck is bound to F and right mouse button. I can catch the mousepressed, and see in the vgui::MouseCode it's right mouse button, but how can I find the mapping between a mousekey and it's bind? Thanks, Maarten ___ 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] Simple question ? on mouse key bindings
Hi, How can I check if e.g. my right mouse button is bound to e.g. duck ? I'm trying to close the spectator menu. My duck is bound to F and right mouse button. I can catch the mousepressed, and see in the vgui::MouseCode it's right mouse button, but how can I find the mapping between a mousekey and it's bind? Thanks, Maarten ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Simple question ? on mouse key bindings
Update I found out engine-Key_LookupBinding(duck); is returning MOUSE2, but only if it's the first bound key. I don't understand why this function doesn't return an array of strings, since a binding can map to any number of keys? Or at least supply an inverse function, which would allow you to access all information. Maarten Hi, How can I check if e.g. my right mouse button is bound to e.g. duck ? I'm trying to close the spectator menu. My duck is bound to F and right mouse button. I can catch the mousepressed, and see in the vgui::MouseCode it's right mouse button, but how can I find the mapping between a mousekey and it's bind? Thanks, Maarten ___ 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] rounds not ending and scoreboard?
Debug. Set a breakpoint. Press F10 repeatedly. Use watches. See what's not
how you expect it.
No offense but it is a bug in your own gameplay code probably. Just step
into it see what doesn't happen the way you want it and take it from
there. If there's something about Source that doesn't happen the way you'd
expect it and you want clarification or help on that, ok, post here with a
specific question, but if you write a bunch of nested if statements and
they don't work the way you expect, it is the kind of problem you need to
learn how to debug yourself.
Do not take this the wrong way, I'm a helpful guy really, but there's some
basic techniques you need to master yourself if you plan to make any kind
of modification, and debugging this kind of code is one of them.
Ok since it was around christmass when I asked this I guess not too many
people read this so I'm bringing it back up, see below! It's about
rounds not ending when they should now and then, they're supposed to end
when only 1 or less players left alive, but they dont and I don't see
the problem
Also second question below the quote.
Yorg Kuijs wrote:
alright here's how it continues after counting players:
if ( iRounds 0 )
{
if( IsTeamplay() == true )
{
if ( combinecountertotal= 1 rebelcountertotal= 1
combinecounter = 1 rebelcounter = 0 )
{
GoToIntermission2();
UTIL_ClientPrintAll( HUD_PRINTCENTER, Combine Wins);
UTIL_ClientPrintAll( HUD_PRINTCONSOLE, Combine won the
round );
return;
}
else if ( combinecountertotal= 1 rebelcountertotal= 1
combinecounter = 0 rebelcounter = 1 )
{
GoToIntermission2();
UTIL_ClientPrintAll( HUD_PRINTCENTER, Rebels Win);
UTIL_ClientPrintAll( HUD_PRINTCONSOLE, Rebels won the
round );
return;
}
else if ( combinecountertotal= 1 rebelcountertotal= 1
combinecounter = 0 rebelcounter = 0 )
{
GoToIntermission2();
UTIL_ClientPrintAll( HUD_PRINTCENTER, The round is a
draw);
UTIL_ClientPrintAll( HUD_PRINTCONSOLE, The round was a
draw );
return;
}
}
else // not teamplay
{
if ( playercountertotal=2 playercounter == 1 )
{
GoToIntermission2();
UTIL_ClientPrintAll( HUD_PRINTCENTER, Player X Wins);
UTIL_ClientPrintAll( HUD_PRINTCONSOLE, Player X Won );
return;
}
else if ( playercountertotal=2 playercounter = 0 )
{
GoToIntermission2();
UTIL_ClientPrintAll( HUD_PRINTCENTER, The round is a
draw);
UTIL_ClientPrintAll( HUD_PRINTCONSOLE, The round was a
draw );
return;
}
}
}
else
{
GoToIntermission();
}
cheeseh-bu wrote:
I think we'd also need to see what you do with the counter variables
afater
finding them, as I don't see much wrong with that code just looking at
it.
hope i can help with it..
Secondly: How does the scoreboard gets it values? I don't understand how
it does, does anyone know a tutorial on the multiplayer scoreboard of hl2?
___
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] Hud elements / specgui Z ordering
Hi list! I think last year I swore it'd be my last christmas developing on Source. Har har, how time flies. I guess I'll add it to my list of recurring new year resolutions. I'm trying to have some of my hud elements render before ( before in z space, not in render order ) my specgui. I first tinkered with SetZPos, but that apparently only works between siblings in the render hierarchy. I tried setting the specgui's parent to the same as the hud elements, but didn't succeed. Any other ideas? I can make a hud element and copy parts of the specgui in there, but that's so much of a hack, there must be a cleaner way? Merry Xmas, Maarten ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] specating bug and rounds not ending
I fixed mine with
http://forums.thewavelength.net/index.php?showtopic=11140st=15
hth
Hey list,
my previous attemts at making a windnade turned out good :D
so I'm now going back to fixing some bugs
First bug is been in for a while and I've seen other mods that have it
too:
Now and then spectate is bugged, when you free view into a wall it will
constantly fall down into the map and you can't stop it, or you are
stuck on your dead body, though you can get loose if u try hard enough
but then if u go into a wall again you are back to your own body.
A long time ago I posted this problem and was told to set
mp_forcerespawn to 1, which was already on 1 and to have the mapper add
some entity to the map which was done as well, the problem has remained
since and it wasn't too bad while the mod used deathmatch, but now my
gametypes are last man standing and last team standing, when a player
runs out of lives they are now forced to spectate and so they are
confronted often with the bug, other spectate views work fine until you
free view into a wall.
Second bug is that rounds aren't ending sometimes, today I happened to
notice that the last 2 guys alive died at the same time, though I'm not
100% sure that's the problem, but the round is supposed to end when
there's 2 or more players and 1 alive, or if 0 alive then its a draw and
it ends the round as well.
However like I said sometimes it doesn't do it.
Players are counted like this:
int playercountertotal = 0;
int playercounter = 0;
int rebelcountertotal = 0;
int rebelcounter = 0;
int combinecountertotal = 0;
int combinecounter = 0;
for ( int i = 1; i = gpGlobals-maxClients; i++ )
{
CHL2MP_Player *pPlayer = (CHL2MP_Player*) UTIL_PlayerByIndex( i );
if ( !pPlayer || pPlayer-GetTeamNumber() == TEAM_SPECTATOR )
continue;
if( IsTeamplay() == true )
{
if( pPlayer pPlayer-GetTeamNumber() == TEAM_COMBINE )
combinecountertotal++;
if( pPlayer pPlayer-GetTeamNumber() == TEAM_REBELS )
rebelcountertotal++;
if( pPlayer pPlayer-GetTeamNumber() == TEAM_COMBINE
ToHL2MPPlayer(pPlayer)-GetTeamPlayerLives()0 )
combinecounter++;
if( pPlayer pPlayer-GetTeamNumber() == TEAM_REBELS
ToHL2MPPlayer(pPlayer)-GetTeamPlayerLives()0 )
rebelcounter++;
}
else
{
if ( pPlayer )
{
//Total players
playercountertotal++;
//Alive players
if( ToHL2MPPlayer(pPlayer)-GetPlayerLives()0)
playercounter++;
}
}
}
any idea on how to fix these 2 things?
___
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] Push Gun
If by push you mean blown back in a single blow, VelocityPunch? I would like to create a weapon that when fired pushes the other player backwards how would I go about applying a force to a player? ___ 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] .fxc Shaders not found
Are you sure your environment settings are correct for your mod? He's not copying the files to another directory? I've recently attempted to run through the shader tutorials on the wiki and on wraith's website, and I seem to be running into an error in both. I'm using the episode one engine, and I followed the tutorials to the letter as far as I can tell. The Buildsdkshaders.bat seems to run with no problem, however i can find no reference at all to any of the shaders that are defined in .fxc files in my mod's shader directory when it completes, and I get a could not find shader error for them if they are used anywhere in a map. This includes not just the post_sepia effect that I created following wraith's tutorial, but also some of the SDK shaders. I recieve a message that looks like this: Couldn't load pixel shader sdk_lightmappedgeneric_ps20 Couldn't load vertex shader sdk_lightmappedgeneric_vs20 Couldn't load vertex shader SDK_lightmappedgeneric_flashlight_vs20 Couldn't load pixel shader SDK_flashlight_ps20 Am I missing something here? There are .fxc files for all of these, but the compiler just seems to generate .inc files for them and nothing else. What's going on? ___ 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] Custom shaders in hammer?
Hi list, We've created custom shaders for our mod as a replacement for e.g. VertexLitGeneric, LightmappedGeneric etc. However, Hammer doesn't seem to like that change, and our mapper needs to revert his version to the materials before the change to be able to develop compile. How can I let hammer the compilation tools (if necessary) make use of our own custom shader_dll's and shaders ? Thanks for any help, Maarten ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] EmitSound not always emitting sound
You don't have to use two different sounds. You can put the loop in the same sound with the windup, just set the cue points at the loopin part. It will play the start, and then loop the rest. That's a cool mechanism, I didn't know it worked that way, but since I want to switch between two sounds after the first part is done I still need to do the timing myself - but I've already added code to take care of that. One main question remains: how does this class network? I have a soundenvelopecontroller driven by my own statemachine without issues, but entirely clientside at the moment. Consequently sounds are only played to the local client. Can I just put this code serverside? I fear the timings of the sounds over a network will introduce serious lag, I'm not sure what the idea is. I could use this system client-side and a separate one to play only a subset of the sounds to other players too, I'm not sure what the best approach is? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Maarten De Meyer Sent: November-01-08 8:14 AM To: Discussion of Half-Life Programming Subject: Re: [hlcoders] EmitSound not always emitting sound I'm passing through the soundenvelopecontroller's createsound/play/shutdown now. Alternating seems to work better, but how do I determine when a sound is finished? The IsPlaying seems only to track status of whether or not the play/shutdown has been called, not of the actual sound duration. I need to transition from the end of my spinup sound to the looping or firing sound. Also, how should I use the SoundEnvelopeController class? I want smooth, immediate glitchfree transitions between sounds and no influence by lag. At the moment I'm using it completely client-side only, is that the way to go? Will it also emit sounds to other players or do I have to create a separate mechanism for that? Thanks in advance for some clarification - documentation on soundenvelope's is very sparse, or I'm missing it completely. Maarten Use a sound envelope for that sort of thing, instead of using emitsound. Do everything else you already did for maintaining it's state though. -Tony -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Maarten De Meyer Sent: Wednesday, October 29, 2008 2:47 PM To: Discussion of Half-Life Programming Subject: Re: [hlcoders] EmitSound not always emitting sound If no-one has any idea why EmitSound can be unreliable, is there another/better way to emit sounds? Anyone here implemented a minigun with alternating, looping sounds being played in sequence? Hi list, *if this is a duplicate mail, ignore it, I'm having mailhost problems* I'm doing sound for a minigun which requires a bit more effort than an average weapon since we have spinup /spindown / loop loopfire sounds which have to transition seamlessly. I've done this by adding a little state machine clientside in ItemPostFrame that updates the weapon's soundstate depending on its actual state. That works fine, in that my states properly update. When I change state, I do a StopSound on the sounds that need to be stopped ( for the looping sounds ), and a WeaponSound on the weaponsound for the new state. Problem is, when I switch alternatingly between the loop_spin and loop_spin_fire states/sounds, occasionally the spinning sound does not play when I EmitSound() it. [Both sounds are mutually exclusive, I don't mix a shooting sound on top of the spinning sound, that's done in the wave. Both sounds I switch between that give issues are looping sounds with a cuepoint at the start and end]. The next time I switch states it's playing again, just every once in a while it doesn't play, and it really bothers. Things I've done to debug so far: - I've enabled sound emitter tracing ingame, and can see clearly that StopSound and EmitSound always do get called for the proper sounds, and StopSound is always before EmitSound. Just sometimes the sound in the last EmitSound is not audible. - I've done several experiments with the channels, but haven't found any combination that solves my issue ( although admittedly I don't know all about those channels, documentation is sparse/incomplete ). - I've called MakeReliable() on the filters in the WeaponSound function, that didn't help. Any ideas what the issue could be or how I could make sure my sounds are always played when they're EmitSound()'ed ? -- Maarten ___ 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
Re: [hlcoders] EmitSound not always emitting sound
I'm passing through the soundenvelopecontroller's createsound/play/shutdown now. Alternating seems to work better, but how do I determine when a sound is finished? The IsPlaying seems only to track status of whether or not the play/shutdown has been called, not of the actual sound duration. I need to transition from the end of my spinup sound to the looping or firing sound. Also, how should I use the SoundEnvelopeController class? I want smooth, immediate glitchfree transitions between sounds and no influence by lag. At the moment I'm using it completely client-side only, is that the way to go? Will it also emit sounds to other players or do I have to create a separate mechanism for that? Thanks in advance for some clarification - documentation on soundenvelope's is very sparse, or I'm missing it completely. Maarten Use a sound envelope for that sort of thing, instead of using emitsound. Do everything else you already did for maintaining it's state though. -Tony -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Maarten De Meyer Sent: Wednesday, October 29, 2008 2:47 PM To: Discussion of Half-Life Programming Subject: Re: [hlcoders] EmitSound not always emitting sound If no-one has any idea why EmitSound can be unreliable, is there another/better way to emit sounds? Anyone here implemented a minigun with alternating, looping sounds being played in sequence? Hi list, *if this is a duplicate mail, ignore it, I'm having mailhost problems* I'm doing sound for a minigun which requires a bit more effort than an average weapon since we have spinup /spindown / loop loopfire sounds which have to transition seamlessly. I've done this by adding a little state machine clientside in ItemPostFrame that updates the weapon's soundstate depending on its actual state. That works fine, in that my states properly update. When I change state, I do a StopSound on the sounds that need to be stopped ( for the looping sounds ), and a WeaponSound on the weaponsound for the new state. Problem is, when I switch alternatingly between the loop_spin and loop_spin_fire states/sounds, occasionally the spinning sound does not play when I EmitSound() it. [Both sounds are mutually exclusive, I don't mix a shooting sound on top of the spinning sound, that's done in the wave. Both sounds I switch between that give issues are looping sounds with a cuepoint at the start and end]. The next time I switch states it's playing again, just every once in a while it doesn't play, and it really bothers. Things I've done to debug so far: - I've enabled sound emitter tracing ingame, and can see clearly that StopSound and EmitSound always do get called for the proper sounds, and StopSound is always before EmitSound. Just sometimes the sound in the last EmitSound is not audible. - I've done several experiments with the channels, but haven't found any combination that solves my issue ( although admittedly I don't know all about those channels, documentation is sparse/incomplete ). - I've called MakeReliable() on the filters in the WeaponSound function, that didn't help. Any ideas what the issue could be or how I could make sure my sounds are always played when they're EmitSound()'ed ? -- Maarten ___ 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] EmitSound not always emitting sound
If no-one has any idea why EmitSound can be unreliable, is there another/better way to emit sounds? Anyone here implemented a minigun with alternating, looping sounds being played in sequence? Hi list, *if this is a duplicate mail, ignore it, I'm having mailhost problems* I'm doing sound for a minigun which requires a bit more effort than an average weapon since we have spinup /spindown / loop loopfire sounds which have to transition seamlessly. I've done this by adding a little state machine clientside in ItemPostFrame that updates the weapon's soundstate depending on its actual state. That works fine, in that my states properly update. When I change state, I do a StopSound on the sounds that need to be stopped ( for the looping sounds ), and a WeaponSound on the weaponsound for the new state. Problem is, when I switch alternatingly between the loop_spin and loop_spin_fire states/sounds, occasionally the spinning sound does not play when I EmitSound() it. [Both sounds are mutually exclusive, I don't mix a shooting sound on top of the spinning sound, that's done in the wave. Both sounds I switch between that give issues are looping sounds with a cuepoint at the start and end]. The next time I switch states it's playing again, just every once in a while it doesn't play, and it really bothers. Things I've done to debug so far: - I've enabled sound emitter tracing ingame, and can see clearly that StopSound and EmitSound always do get called for the proper sounds, and StopSound is always before EmitSound. Just sometimes the sound in the last EmitSound is not audible. - I've done several experiments with the channels, but haven't found any combination that solves my issue ( although admittedly I don't know all about those channels, documentation is sparse/incomplete ). - I've called MakeReliable() on the filters in the WeaponSound function, that didn't help. Any ideas what the issue could be or how I could make sure my sounds are always played when they're EmitSound()'ed ? -- Maarten ___ 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] EmitSound not always emitting sound
no, it's even on the same spot, it randomly doesn't play. Well EmitSound is unreliable for me when played from the viewmodel of grenades, another dev who helps test said it's because the map I was testing on uses looping ambient_generic sounds and the problem might go away. But from what I read the first time you mailed I didn't think it applies on what you're trying to cause it only happened in certain area's. I'm assuming you were shooting the gun on one place and it randomly didnt play? If it's only certain parts of the map then it may be the above problem... Maarten De Meyer wrote: If no-one has any idea why EmitSound can be unreliable, is there another/better way to emit sounds? Anyone here implemented a minigun with alternating, looping sounds being played in sequence? ___ 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] background01_widescreen.vtf and 16:10 resolutions
Hi list, since this seems basic to me, I risk asking a FAQ, but google didn't help, so here goes. Apparently, people playing in 16:10 ( tested on 1920*1200 ) get the background01.vtf image in the main menu in stead of the background01_widescreen.vtf image. 16:9 reso's display background01_widescreen properly. Any ideas/help to link 16:10 to a widescreen image? -- Maarten ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Scrolling Textures
What I would *expect* logically is
LightmappedGeneric
{
$basetexture test/basewatertexture01
$basetexture2 base/basewavetexture01
$surfaceprop metal
Proxies
{
TextureScroll
{
textureScrollVar $basetexture2transform
textureScrollAngle 90
textureScrollRate 10
}
}
}
Can't verify it now though, I'm at work. If you don't have it up and
running when I'm at home I'll take a look.
-- Maarten
Well yeah I know about the model with the animation, but I don't want to
have to have two copies of the waves (and render 2x the triangles) with
the
top layer being foam.
How would you overlay an animated material ontop of a $basetexture?
On Sun, Oct 12, 2008 at 7:08 PM, Josh Hollander [EMAIL PROTECTED]
wrote:
The puddle should be easy enough to do, but I'm not so sure about the
water... Model with animation could be best, if you're up to it.
On Sun, Oct 12, 2008 at 9:12 PM, Matt Hoffman
[EMAIL PROTECTED]wrote:
Well what I'm trying to do is re-create Wetwork from COD4. (First
level
really, with the cargoship, etc)
I'm trying to re-create the water, which appears to be a moving plane
(animated vertexes) with a base water texture, then an animated
'wave/foam'
texture on top.
I'm also trying to re-create the puddles on the deck plating. This I
think
could be done with a base texture, and then an animated (water droplet
animation) refract texture, which is overlayed onto the deckplating
material.
On Sun, Oct 12, 2008 at 6:07 PM, Josh Hollander [EMAIL PROTECTED]
wrote:
I believe so... I'm not quite sure as to what you are trying to
achieve,
but
if it's just a single texture I got mine working with Maarten's
help.
On Sun, Oct 12, 2008 at 8:53 PM, Matt Hoffman
[EMAIL PROTECTED]wrote:
All I know is the code I posted doesn't do anything. :P
Would I remove $basetexture2 (at the start of the vmt) and replace
it
with
$basetexturetransform?
On Sun, Oct 12, 2008 at 5:49 PM, Josh Hollander
[EMAIL PROTECTED]
wrote:
I believe you have to change the line
textureScrollVar $basetexture2
to
textureScrollVar $baseTextureTransform
Although I'm not sure if you're going for a different effect
from
scrolling.
Josh
On Sun, Oct 12, 2008 at 2:46 PM, Matt Hoffman
[EMAIL PROTECTED]wrote:
Whoops that won't work, that's animated texture.
I meant to say:
LightmappedGeneric
{
$basetexture test/basewatertexture01
$basetexture base/basewavetexture01
$surfaceprop metal
Proxies
{
TextureScroll
{
textureScrollVar $basetexture2
textureScrollAngle 90
textureScrollRate 10
}
}
}
On Sun, Oct 12, 2008 at 11:25 AM, Matt Hoffman
[EMAIL PROTECTED]wrote:
What would my code look like, something like this? (Typed
off
memory,
so
the commands may be iffy)
LightmappedGeneric
{
$basetexture base/basetexture1
$basetexture base/basetexture1overlay
$surfaceprop metal
$surfaceprop2 water //Does source support
SurfaceProp2?
Proxies
{
AnimatedTexture
{
animatedTextureVar $basetexture2
animatedTextureFrameNumVar $frame
animatedTextureFrameRate 10
}
}
$frame 2
}
Would that work? Or where do I put $basetexture2transform.
On Sun, Oct 12, 2008 at 11:08 AM, Maarten De Meyer
[EMAIL PROTECTED]wrote:
Proxies operate on variables, I see no reason why the
$basetexture2transform should be any different. What you
want
should
be
possible, yes.
In a related question, can you have your $basetexture2
scroll?
I
wish
to
have a basetexture, then a scrolling material overlayed
ontop
of
this.
Is
this possible?
On Sun, Oct 12, 2008 at 8:54 AM, Maarten De Meyer
[EMAIL PROTECTED]wrote:
try using $bumptransform in stead of
$baseTextureTransform
as
texturescrollvar. That help?
-- Maarten
I'd like to know why my texture wont scroll. It
refracts
beautifully,
but...
well, it looks utterly fake. Can anybody figure out
what
I've
done
wrong
here?
VMT CODE:
Refract
{
$normalmap dvlstx/forcefield_normal
$surfaceprop glass
$bluramount 1
$refractamount .100
$scale [1 1]
$envmap env_cubemap
$envmaptint [.7 .7
Re: [hlcoders] Scrolling Textures
try using $bumptransform in stead of $baseTextureTransform as
texturescrollvar. That help?
-- Maarten
I'd like to know why my texture wont scroll. It refracts beautifully,
but...
well, it looks utterly fake. Can anybody figure out what I've done wrong
here?
VMT CODE:
Refract
{
$normalmap dvlstx/forcefield_normal
$surfaceprop glass
$bluramount 1
$refractamount .100
$scale [1 1]
$envmap env_cubemap
$envmaptint [.7 .7 .7]
$REFRACTTINTTEXTURE dvlstx/forcefield_a
Proxies
{
TextureScroll
{
texturescrollvar $baseTextureTransform
texturescrollrate 0.1
texturescrollangle 30.00
}
}
}
I've indented with TAB where needed, (ie, after brackets) but have no idea
what is wrong!! Somebody please help!
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] Scrolling Textures
Proxies operate on variables, I see no reason why the
$basetexture2transform should be any different. What you want should be
possible, yes.
In a related question, can you have your $basetexture2 scroll? I wish to
have a basetexture, then a scrolling material overlayed ontop of this. Is
this possible?
On Sun, Oct 12, 2008 at 8:54 AM, Maarten De Meyer
[EMAIL PROTECTED]wrote:
try using $bumptransform in stead of $baseTextureTransform as
texturescrollvar. That help?
-- Maarten
I'd like to know why my texture wont scroll. It refracts beautifully,
but...
well, it looks utterly fake. Can anybody figure out what I've done
wrong
here?
VMT CODE:
Refract
{
$normalmap dvlstx/forcefield_normal
$surfaceprop glass
$bluramount 1
$refractamount .100
$scale [1 1]
$envmap env_cubemap
$envmaptint [.7 .7 .7]
$REFRACTTINTTEXTURE dvlstx/forcefield_a
Proxies
{
TextureScroll
{
texturescrollvar $baseTextureTransform
texturescrollrate 0.1
texturescrollangle 30.00
}
}
}
I've indented with TAB where needed, (ie, after brackets) but have no
idea
what is wrong!! Somebody please help!
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
___
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] Vector Math Wallwalking problem
Yup, that's why I changed the input reference. I'll mail you the relevant parts of my code tonight when I get access. -- Maarten Hey, thanks for your response. I have tried implementing the mouse movement change so that all movement when on the wall is from the right reference. I am having problems with Yaw'ing the mouse though, I am not sure how to actually adjust the yaw value properly because it 'rolls' (when you are on the wall) the camera around, instead of swiveling parallel to the surface of the wall like it does when your walking normally. I would love to see the math you used in your approach or any other help :) Mitchel On Sun, Oct 5, 2008 at 5:52 PM, Maarten De Meyer [EMAIL PROTECTED]wrote: Hi Mitchel, I implemented fully functional wallwalking about two years ago for the first implementation of our gameplay, when we still had an alien. I'm not sure which part you're referring to though. Personally, when players in my mod jumped to or walked over a new surface, I kept the current camera orientation, since changing your camera angle at that time gives a shocky experience and can be very disorienting. What I rather did, is modify the input classes so all mouse movement from that point on happened in the reference frame of the new surface ( with some interpolation over time to smooth things out ). This felt very natural and worked very well. I also touched problems that sound a lot like yours, I'm not sure if they're the same, but I can give you the math for my approach if you want. One word of caution though. I don't know your game's pitch, so for all I know you won't have this problem, but we eventually stepped away from wallwalking since you cannot do it properly (i.e. fully equivalent to upright walking ) without an oriented box shapecast, which Source doesn't support. I had something pretty decent using several points that I transformed ourselves, but this kind approach always has edge cases with certain geometry. One concession you can make to still have it working decently, is e.g. limiting the orientation and complexity of the surfaces you can walk on, but that was a sacrifice we chose not to make. Hope that helped a bit. Feel free to contact me on- or off-list if you want more info or parts of my code. -- Maarten Hi Everyone, Making a mod with a few others that has walkwalking - the actual physical walking along walls part has been implemented. Basically it uses the normal of the surface you are walking on and the viewing direction of the player to construct the correct 'right' and 'forward' unit vectors, so that the players movement is constrained to the surface (using the cross product). The problem I am having now is that I want to change the camera angle to face the forward direction of the surface. I have hooked up the server-client code so that I can directly change the camera angle however my vector cross product calculations screw up because I am now changing the camera viewing angle and then using it to make a calculation which changes it again - e.g. circular madness. Thus I am sure it is possible because you see it done all of the time - but is there a way to construct at least one right angled vector from just one vector? The cross product requires 2 vectors, so I played with arbitrary vectors and rotations to the original direction of the normal to the surface - however I get problems where one wall's normal will eventually be co-linear to the vector I have chosen (which results in a zero vector). So I am not sure I really explained the problem all that well - I can go into more detail if anyone doesn't understand. Thanks Mitchel ___ 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] Vector Math Wallwalking problem
Hi Mitchel, I implemented fully functional wallwalking about two years ago for the first implementation of our gameplay, when we still had an alien. I'm not sure which part you're referring to though. Personally, when players in my mod jumped to or walked over a new surface, I kept the current camera orientation, since changing your camera angle at that time gives a shocky experience and can be very disorienting. What I rather did, is modify the input classes so all mouse movement from that point on happened in the reference frame of the new surface ( with some interpolation over time to smooth things out ). This felt very natural and worked very well. I also touched problems that sound a lot like yours, I'm not sure if they're the same, but I can give you the math for my approach if you want. One word of caution though. I don't know your game's pitch, so for all I know you won't have this problem, but we eventually stepped away from wallwalking since you cannot do it properly (i.e. fully equivalent to upright walking ) without an oriented box shapecast, which Source doesn't support. I had something pretty decent using several points that I transformed ourselves, but this kind approach always has edge cases with certain geometry. One concession you can make to still have it working decently, is e.g. limiting the orientation and complexity of the surfaces you can walk on, but that was a sacrifice we chose not to make. Hope that helped a bit. Feel free to contact me on- or off-list if you want more info or parts of my code. -- Maarten Hi Everyone, Making a mod with a few others that has walkwalking - the actual physical walking along walls part has been implemented. Basically it uses the normal of the surface you are walking on and the viewing direction of the player to construct the correct 'right' and 'forward' unit vectors, so that the players movement is constrained to the surface (using the cross product). The problem I am having now is that I want to change the camera angle to face the forward direction of the surface. I have hooked up the server-client code so that I can directly change the camera angle however my vector cross product calculations screw up because I am now changing the camera viewing angle and then using it to make a calculation which changes it again - e.g. circular madness. Thus I am sure it is possible because you see it done all of the time - but is there a way to construct at least one right angled vector from just one vector? The cross product requires 2 vectors, so I played with arbitrary vectors and rotations to the original direction of the normal to the surface - however I get problems where one wall's normal will eventually be co-linear to the vector I have chosen (which results in a zero vector). So I am not sure I really explained the problem all that well - I can go into more detail if anyone doesn't understand. Thanks Mitchel ___ 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] Predicted variable override
Hi list! I'm using a client-side concommand to directly set the value of a variable that's predicted. My problem is that the prediction immediately overrides this value. [ I've already used a recvproxy to disable network updates to override this value, which works decently ]. How can I either invalidate the current prediction, or update the value the prediction uses, so that my value is not re-overwritten (all clientside ofcourse)? Thanks for any insight, Maarten ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Which are the other 3 mods that get access to the steamworks sdk?
Personally, as far as my mod is concerned, we want to get something releaseworthy first, after that I'm probably gonna ask valve to do a little playtest with us and give us some feedback. But I think prerequisite one is releasing a public beta and get noticed. [ Which is an art in itself. We're one of the few serious mods that have never ever been mentioned in Steam news, but we're patient - our day will come :p ] How do mods get invovled with this? Who do we have to bribe to be included? bFriday, September 26, 2008/bbr br br br img src=http://storefront.steampowered.com/Steam/Marketing/message/1843/img/5mods.jpg; alt= class=img_tag border=0br br As a part of our continuing efforts to support the MOD community, we will begin hosting selected MODs directly on Steam starting next week. The first five MODs to ship on steam will be Age of Chivalry, D.I.P.R.I.P., Insurgency, Synergy, and Zombie Panic. As always, owners of a href=steam://openurl/http://store.steampowered.com/search/?category2=16; target=_blankany Source game/a will be able to download and play all of these MODs for free.br br Once installed, these MODs will appear in your My Games list and will receive automatic updates just like other games on Steam. Also, these MODs now take advantage of Steamworks, which provides stat tracking and tighter integration with the Steam community.br br We're excited to see MOD developers get wider recognition for the hard work they have done, and we hope to support more MOD teams in the future. Watch for the official release next week! On Mon, Aug 11, 2008 at 6:20 PM, Jonathan Murphy [EMAIL PROTECTED] wrote: I remember quite some time ago I was invited to a discussion on doing this (on a forum somewhere, can't remember where :( but Valve was involved). The questions were along the lines of What would you like Steam to do for mods? and someone from Valve said they were planning on a system to allow mods to release through Steam, so I guess Steamworks is a continuation of that idea. There was also talk of possibly allowing mods to charge people to download, wonder if that will ever come to fruition. It wasn't really a popular idea at the time but yeah, would certainly make things interesting. :p On Tue, Aug 12, 2008 at 7:47 AM, Adam amckern McKern [EMAIL PROTECTED]wrote: They where going to do SvenCoop back in the day, but never did, so i spose it will never happen, unless the mod goes retail. Owner Nigredo Studios http://www.nigredostudios.com --- On Tue, 8/12/08, Wiktor Deresz [EMAIL PROTECTED] wrote: From: Wiktor Deresz [EMAIL PROTECTED] Subject: Re: [hlcoders] Which are the other 3 mods that get access to the steamworks sdk? To: Discussion of Half-Life Programming hlcoders@list.valvesoftware.com Date: Tuesday, August 12, 2008, 4:09 AM On Mon, Aug 11, 2008 at 7:47 PM, 1nsane [EMAIL PROTECTED] wrote: Zombie Panic Source and Age of Chivalry? It would be nice if Valve finally started distributing mods for ?free? over Steam... that would make updating much easier for everyone and less random disconnects when the versions differ. On Mon, Aug 11, 2008 at 9:52 AM, Wiktor Deresz [EMAIL PROTECTED] wrote: On Mon, Aug 11, 2008 at 8:54 AM, [EMAIL PROTECTED] wrote: I noticed that Synergy is one of the first 4 mods that get access to the steamworks sdk, so im wondering which are the other 3 mods that get access, and if its possible that more mods will get access to the steamworks sdk in the near future, as this would be a great benefit for the source modders out there. -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders Zombie Panic Source! ___ 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 http://forums.steampowered.com/forums/showpost.php?p=7985973postcount=9 ___ 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:
[hlcoders] WorldVertexTransition shader
Hi list, I'm wrapping up some modifications to all the standard shaders for my mod ( LightmappedGeneric, VertexLitGeneric ). Works a charm so far ( thx for the help Tony ), only thing is for my modifications to make sense I need to apply them to the WorldVertexTransition shader as well, and I'm not sure if it's a shader in itself, or an alias for another one, or where the source code for that shader is located. I see references to WorldVertexTransition in the flashlight shaders, but I don't see the WorldVertexTransition shader used for displacements, or which pixel shader is used so I can modify it. Anyone have any clues on this? I hope to god the answer isn't that we just don't get access to that particular shader's source - I'd hate to have to re-write it from scratch. Thanks! -- Maarten ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] problems with dedicated server and mod start (frontiers)
Do you have a steam.inf file in your mod directory? I didn't have the same
problem but related ones, see the thread at
http://www.mail-archive.com/hlcoders@list.valvesoftware.com/msg23714.html
hi,
got here some problem with a source dedicated server(windows).
The mod is called Frontiers.
(1)
The Frontiers-Gameserver is not listed in the Serverwindow in Steam.
Using the filter for Frontiers and it says, no servers out there.
Can add the IP in my favorites and join him.
If i use no filters in the Steam Server window i can see the server. By
game (sorted with the arrows on the top) it says Frontiers.
(2)
Second Problem is that when i join the Frontiers-Gameserver it launches
hl2dm. But only says that it launches it.
It shows the inrto of hl2dm. After the intro i am in Frontiers and not in
hl2dm. The Task says it is the Mod-Game too.
If i start my Mod via Steam it will only start the Mod. Not hl2dm.
(1 additional infos)
Installed with hldsupdatetool Hl2DM-Server (required for the mod).
Installed the frontiers files in a new Folder called frontiers in the
root directory of the gameserver.
Started scrds with e:\Gameserver\Test1\srcds.exe -game frontiers
-applaunch 215 +map ceuta_beta_02a -maxplayers 16 -port 26015 -autoupdate
Server cfg i reduced to the minimum now. hostname,rcon_password,
sv_password, sv_lan 0, sv_region 3
The Server console says that it is adding the server to the master server
72.165.61.189:27011 and 69.28.151.162:27011.
Server is started and vac is active.
The server.dll is coded for Frontiers and is new. Server is updated to the
newest version.
The game dll files are the same version at client and server.
The server ip is: 87.118.120.171:26015 and is running atm.
(2 additional infos)
The game dll files are the same version at client and server.
The Gameinfo.txt is:
GameInfo
{
gamefrontiers
typemultiplayer_only
nomodels 0
nohimodel 1
nocrosshair 1
hidden_maps
{
test_speakers 1
test_hardware 1
}
developer Gold Extra
developer_url http://www.frontiers-game.com;
manualhttp://www.frontiers-game.com/about.html;
icon frontiers
FileSystem
{
SteamAppId 215
ToolsAppId 211
{
Game|gameinfo_path|.
Gamehl2mp
Gamehl2
}
}
}
best regards jens
_
In 5 Schritten zur eigenen Homepage. Jetzt Domain sichern und gestalten!
Nur 3,99 EUR/Monat! http://www.maildomain.web.de/?mc=021114
___
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] How to do things
I'm very sorry but I can't help saying it: Welcome to Source development. I've only just got into the plug-in scene but I've got several years experience in C++, C# and Java. Thing that I'm confused about, is if I'm missing something. I was looking at in-game menus and saw a tutorial on sdk source wiki site. It uses the user message ShowMenu. It works fine but how did the person figure it out when there's no example of it being used in the source code. In trying to figure it out I looked up UserMessageBegin function only to find that there's no code for the function. Instead I find a interface class for a DLL. So I can't see a working example (where the functions used) and I can't see the functions code, so how on earth does anyone figure out how to use the function? I was also looking at colouring in user messages. I think UTIL_SayText2Filter does that but it uses the user message SayText2. That hasn't been declared in the source although because there's SayText it might not matter. I across a forum where they figured out you can use escape characters like \1 for yellow and \2 for green. Once again there's doesn't seem to any example of that in the source code. What I want is to be able to create in-game menus and user messages with colouring (like in mani plug-in) but from what I see, I can't see how you can figure that out. When you don't have access to the complete code (you get a bunch of interfaces with no explanation). Am I missing something that big, please tell me I am? ___ 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] Networking Game Rules
Unless if I'm really very mistaken, I'm using just basic CNetworkVar's in my gamerules class without any problem. I'm on the latst ep1 SDK btw, created a mod from scratch if that's relevant. I read somewhere in the archive that rules arn't networked. They said it could be done (obviously or valve wouldnt have written the CTeamplayRoundBasedRules class to use client variables). I'm just wondering if anyone else has any ideas HOW to do it. 2008/9/16 Marek Sieradzki [EMAIL PROTECTED] Just a hint not really related to networking: you have to remember that VS can show random values in debugger for Release build if the variable was optimized out. ___ 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] Networking Game Rules
Yeah, but that should be transparent, no? since the send/recv table from the proxy is referencing the one in gamerules: BEGIN_SEND_TABLE( COffLGameRulesProxy, DT_OffLGameRulesProxy ) SendPropDataTable( offl_gamerules_data, 0, REFERENCE_SEND_TABLE( DT_OffLGameRules ), SendProxy_OffLGameRules ) END_SEND_TABLE() Which leads me to ask; Olly, did you forget to add your variables to the send/receive tables of DT_SDKGameRules ? The rules themselves aren't networked. That's why there's a gamerules proxy. In hl2mp: LINK_ENTITY_TO_CLASS( hl2mp_gamerules, CHL2MPGameRulesProxy ); in 'scratch': LINK_ENTITY_TO_CLASS( sdk_gamerules, CSDKGameRulesProxy ); Etc. -Tony -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Olly Sent: September-16-08 10:27 AM To: Discussion of Half-Life Programming Subject: Re: [hlcoders] Networking Game Rules I read somewhere in the archive that rules arn't networked. They said it could be done (obviously or valve wouldnt have written the CTeamplayRoundBasedRules class to use client variables). I'm just wondering if anyone else has any ideas HOW to do it. 2008/9/16 Marek Sieradzki [EMAIL PROTECTED] Just a hint not really related to networking: you have to remember that VS can show random values in debugger for Release build if the variable was optimized out. ___ 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] Networking Game Rules
Weird, imo it should work then. You can try to add a receiveproxy to one of the variables, change the variable server-side and see if the receiveproxy hits clientside to check if you have basic networking functionality or not, that should help you narrow down the problem. The values are added to the Data Table of the parent base rules class: CTeamplayRoundBasedRules ( game/shared/teamplayroundbased_gamerules.cpp/.h if anyone is interested ) 2008/9/16 Maarten De Meyer [EMAIL PROTECTED] Yeah, but that should be transparent, no? since the send/recv table from the proxy is referencing the one in gamerules: BEGIN_SEND_TABLE( COffLGameRulesProxy, DT_OffLGameRulesProxy ) SendPropDataTable( offl_gamerules_data, 0, REFERENCE_SEND_TABLE( DT_OffLGameRules ), SendProxy_OffLGameRules ) END_SEND_TABLE() Which leads me to ask; Olly, did you forget to add your variables to the send/receive tables of DT_SDKGameRules ? The rules themselves aren't networked. That's why there's a gamerules proxy. In hl2mp: LINK_ENTITY_TO_CLASS( hl2mp_gamerules, CHL2MPGameRulesProxy ); in 'scratch': LINK_ENTITY_TO_CLASS( sdk_gamerules, CSDKGameRulesProxy ); Etc. -Tony -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Olly Sent: September-16-08 10:27 AM To: Discussion of Half-Life Programming Subject: Re: [hlcoders] Networking Game Rules I read somewhere in the archive that rules arn't networked. They said it could be done (obviously or valve wouldnt have written the CTeamplayRoundBasedRules class to use client variables). I'm just wondering if anyone else has any ideas HOW to do it. 2008/9/16 Marek Sieradzki [EMAIL PROTECTED] Just a hint not really related to networking: you have to remember that VS can show random values in debugger for Release build if the variable was optimized out. ___ 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] Basic HDR question
Yup, looks a lot like what I'm trying to do. I'm already rendering the glowing models in a separate render target for my own techniques, I'll try applying the modified HDR pass like you did in stead of my own glows/blurs to see which one looks best. Id have loved to have combined the glow for the HDR and those for the glowing objects in one pass ( we did a similar thing in an engine I worked on ) since blurs are costly, but I'll definately try this, thanks! -- Maarten For reference, this is what it looked like. I meant to link this in the previous email, I'm having a very weird day. http://www.project-valkyrie.com/images/stories/ingame/glowpreview.jpg Is that the kind of thing you're trying to achieve? -Tony On Thu, Sep 4, 2008 at 4:03 PM, Tony omega Sergi [EMAIL PROTECTED]wrote: What I did in project valkyrie, was render all models that glow in a secondary pass (which rendered all the glowy bits), and then call a modified version of the HDR pass on that rendertarget, and then overlayed it all ontop in post process. I had some other minor things like using pixelvisibility and whatnot to determine if a model should render, it's not perfect, and at some angles big things will glow 'through' walls (ie: if you're looking through a doorway and someone is partially exposed, I didn't do any blocking with world geometry, only other players and the view model will block, so I used the pixelvisibility as a quick test, from the first normal render pass. There are probably some much better ways to do it, but that's how I did it anyway. -Tony ___ 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] Basic HDR question
Hi list! (tm) I'm wondering about something. HDR causes light areas to glow, with bloomy edges and all. I'm looking for a way to have the same effect applied to one of my dynamic models ( a specific model ). I've already implemented my own post-process glow using custom blurs that does the trick, but I wondered if there isn't a way to somehow use the HDR for this to economise the extra blur ( there should already be a blurring pass in the HDR if I'm not mistaken ), to make it seem as though a dynamic model emits light with glow and everything ( mind you, I'm not talking about a dynamic light that lights up the environment, just a glow from a player's viewpoint ). Ugh. Sorry for my ( lack of decent ) punctuation. So basically, can I use a heavy HDR bloom on one specific, dynamic model using the built-in hdr techniques? -- Maarten ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Graphical Debugging
This mail is intended more for valve employees than the list I guess, but you never know. Simple question, as usual: is there a way to do some graphical debugging in Source, similar to eg nvperfhud or the likes? [ where you can see contents of rendertargets per drawcall etc ]? I assume not, or at least not for us modders, but you never know :) Maarten ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Graphical Debugging
/me hits myself in the head. Should've thought of that myself, I didn't think it'd work out of the box with a random directx application. [ Although I have a habit of looking down on pix for windows, it's absolute horror compared to the xbox version :p ] Thanks! Maarten De Meyer wrote: This mail is intended more for valve employees than the list I guess, but you never know. Simple question, as usual: is there a way to do some graphical debugging in Source, similar to eg nvperfhud or the likes? [ where you can see contents of rendertargets per drawcall etc ]? I assume not, or at least not for us modders, but you never know :) PIX?... http://msdn.microsoft.com/en-us/library/bb173088(VS.85).aspx -- 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] grenade code
I haven't followed the discussion from the beginning, so I don't know
where you are in the code, but you seem to be talking about grenades, so
typically if you want to wait until the end of an animation you do sth
like:
SetWeaponIdleTime( gpGlobals-curtime + SequenceDuration() );
or
m_fNextTimeToDoWhateverYouWant = gpGlobals-curtime + SequenceDuration();
SequenceDuration() gives you the duration of the current selected
animation, so call this after you just set that animation.
hth
ok back again and found out a bit more
I'm thinking I was initially wrong when I thought only NPC's use Events
but I think its actually so that Activities are linked to Events and in
the events the coder can then specifiy specific code stuff that a
modeller can't do with it.
so I think I have to be here:
case EVENT_WEAPON_SEQUENCE_FINISHED:
m_fDrawbackFinished = true;
break;
in the qc file its determined what event is linked to the activity(the
animation name that the code uses to find the animation name from the
model files)
event 3900 is EVENT_WEAPON_SEQUENCE_FINISHED as seen above and is this
as Nauz specified in the qc file
1) $sequence drawbackhigh watermelon_drawhigh activity
ACT_VM_PULLBACK_HIGH 1 fps 24 { frames 0 35 } { event 3900 4 }
so animation name = watermelon_drawhigh but the activity is called
ACT_VM_PULLBACK_HIGH(which is what the code uses) and it uses the event
3900 which is EVENT_WEAPON_SEQUENCE_FINISHED
so it seems that as soon as animation drawhigh starts it counts the
grenade ready to throw(cause it then reads DrawBackFinished = true which
means its ready to throw, therefore you can throw the grenade because it
doesnt tell it to wait for the end of the animation!
so now I need a way to tell it in the code to say: HEY WAIT UNTIL IT
ENDS then DrawbackFinished = true
rather then hey animation starts, drawbackfinished = true oh lol you can
throw now even though you havent pulled the pin yet ..
yeah im rambling. but I think i'm close now! just have no idea how to
tell it to wait for the end of the animation..
___
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] grenade code
probably cause you're using a hl2 mod or something, I have a from scratch mod ( ep1 based ), and my code uses base projectile grenades :) still haven't got it working the base projectile grenade was useless, it wasnt even included in the project and seems part of the sdk code? or whatever.. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] grenade code
http://www.mail-archive.com/hlcoders@list.valvesoftware.com/ but impact grenades should be peanuts. Check out void CBaseGrenadeProjectile::ResolveFlyCollisionCustom( trace_t trace, Vector vecVelocity ) hth Alright back with a new problem, been working on a grenade that explodes on impact and used so far molotov or rpg code(tried both) but haven't been able to get it work yet, all I got to work is that it explodes on physic entities, npcs and players but other then that it just bounces off anything else then lies on the floor floating or in the ground. Now I remember more then a month back someone on this list posed a question about impact grenades and I believed he also later stated the solution he found for it, if anyone can help me find that post that would be great, I have been manually scanning over thread names for past 3 months, but if its there its not under a name that will make it easy to find. I believe the list also has a search function but I can't find 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
Re: [hlcoders] TF2 style player collisions
Well I've managed to disable collisions based on team in the meantime, but don't have the soft physics push. Mind you I'm still in the ep1 engine. Basically, I had already added a custom filter to the TracePlayerBBox in gamemovement.cpp to filter gamemovement for my mod ( players can walk through forcefields, but only belonging to their team ). I just added the condition for players of the same team to that filter. So they're not blocking eachother anymore when casting rays for their movement. VPhysics has not been an issue at all for me, there's no collision. I'm looking for the same check the Player collisions, enemies vs friendlies. thread for more details. I still haven't found a fix to the prediction issues (if you have any insight, let me know). On Tue, Aug 12, 2008 at 5:43 AM, Maarten De Meyer [EMAIL PROTECTED] wrote: Hi list, In my mod by default players collide ( hard ) against eachother. For obvious reasons I want to disable this for teammates and rather have a soft collision/physics push like in TF2, where you still have the option to clip through a teammate if you want to, but you do get a slight physics resistance when you do. I know this isn't that hard, just wondering if someone had done it before and could point me in the right direction for the soft push part, I'm not too at home in Source's physics. -- Maarten ___ 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] [ep1] Stencil Buffer availability
Hi list, I'd like to use the stencil buffer to store a mask during my main render pass so I can use it in a postprocess effect. My question is simple: is the main stencil available and preserved during the main render loop or is it used by something already? The only use of stencil I see is in mat_tonemapping_occlusion_use_stencil, but I'm not sure where in the pipeline this operates on the stencil buffer. Maarten ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] TF2 style player collisions
Hi list, In my mod by default players collide ( hard ) against eachother. For obvious reasons I want to disable this for teammates and rather have a soft collision/physics push like in TF2, where you still have the option to clip through a teammate if you want to, but you do get a slight physics resistance when you do. I know this isn't that hard, just wondering if someone had done it before and could point me in the right direction for the soft push part, I'm not too at home in Source's physics. -- Maarten ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Per non local player client side simulation code - where do I put it ?
Hi list! Simple question really, I want to simulate a part of a certain weapon's behavior on the client, since it's visual and I don't want the visual aspects networked ( not necessary and makes things laggy ). I usually put stuff like that in ItemPostFrame, but I'm discovering that only the local player's ItemPostFrame functions are called on the client. Is this normal, and if so, is there an interface already for what I'm trying to do or do I just hook C_BasePlayer::PhysicsSimulate or something ( where the difference between local and non local players is made ) ? Thanks, Maarten ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Per non local player client side simulation code - where do I put it ?
The first will do just fine, thanks a lot. Don't know what's worse, the fact that I used it before, or the fact that it was 10 lines below the ugly hack I did now in stead. Lack of sleep is bad for coding, loads of caffeine not a substitute. UpdateClientSideAnimation or ClientThink perhaps? On Tue, Jul 29, 2008 at 5:41 PM, Maarten De Meyer [EMAIL PROTECTED]wrote: Hi list! Simple question really, I want to simulate a part of a certain weapon's behavior on the client, since it's visual and I don't want the visual aspects networked ( not necessary and makes things laggy ). I usually put stuff like that in ItemPostFrame, but I'm discovering that only the local player's ItemPostFrame functions are called on the client. Is this normal, and if so, is there an interface already for what I'm trying to do or do I just hook C_BasePlayer::PhysicsSimulate or something ( where the difference between local and non local players is made ) ? Thanks, Maarten ___ 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] Character Animation Blending problem
Hi list! I'm trying to understand a blending problem. Simple question: http://i336.photobucket.com/albums/n330/jfkeats/problem.jpg In this setup, run_lower only affects the legs ( so the upper pose is Jesus, weightlists are at 0 for upper body ). run_upper_minigun and walk_upper_minigun are both a simple, correct pose ( correct being with the hand on the front handle ). Why is that, if they're both blended with weight 0.50, and the run_lower should have a weight of 0 for the upper body, I still have a gap/incorrect pose ( caused by some of the 'Jesus' pose still being blended in )? If the sum of their weights is 1.0, shouldn't the pose be exact? Ingame this translates in glitches when we start/stop running, other than that it's fine. Thanks for any insight, Maarten ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Character Animation Blending problem
The bottom one is probably at 0.6, but to eliminate all doubt: http://i336.photobucket.com/albums/n330/jfkeats/ol_testmap0041.jpg idle_, walk_ and lower_ are identical, the sum of their weights is 1, and still the blend is not 'complete', there's a part of jesus in there which causes the gap. It doesn't look like the two sliders are both on 0.5: the top one is further to the left than the bottom one. Maarten De Meyer wrote: Hi list! I'm trying to understand a blending problem. Simple question: http://i336.photobucket.com/albums/n330/jfkeats/problem.jpg In this setup, run_lower only affects the legs ( so the upper pose is Jesus, weightlists are at 0 for upper body ). run_upper_minigun and walk_upper_minigun are both a simple, correct pose ( correct being with the hand on the front handle ). Why is that, if they're both blended with weight 0.50, and the run_lower should have a weight of 0 for the upper body, I still have a gap/incorrect pose ( caused by some of the 'Jesus' pose still being blended in )? If the sum of their weights is 1.0, shouldn't the pose be exact? Ingame this translates in glitches when we start/stop running, other than that it's fine. Thanks for any insight, Maarten ___ 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] Character Animation Blending problem
I've discovered this while debugging: if you're blending between two sequences that are the exact same pose, you will not attain that pose unless at least one of the two blendfactors is at one ( feel free to try that in hlmv ). Can anyone tell me how the blending works, and if it's possible to have it working the way I'd expect ( e.g. 0.5 * sequence a + 0.5 * a sequence identical to a = a. ). Any insight in the animation blending process is appreciated. Maarten The bottom one is probably at 0.6, but to eliminate all doubt: http://i336.photobucket.com/albums/n330/jfkeats/ol_testmap0041.jpg idle_, walk_ and lower_ are identical, the sum of their weights is 1, and still the blend is not 'complete', there's a part of jesus in there which causes the gap. It doesn't look like the two sliders are both on 0.5: the top one is further to the left than the bottom one. Maarten De Meyer wrote: Hi list! I'm trying to understand a blending problem. Simple question: http://i336.photobucket.com/albums/n330/jfkeats/problem.jpg In this setup, run_lower only affects the legs ( so the upper pose is Jesus, weightlists are at 0 for upper body ). run_upper_minigun and walk_upper_minigun are both a simple, correct pose ( correct being with the hand on the front handle ). Why is that, if they're both blended with weight 0.50, and the run_lower should have a weight of 0 for the upper body, I still have a gap/incorrect pose ( caused by some of the 'Jesus' pose still being blended in )? If the sum of their weights is 1.0, shouldn't the pose be exact? Ingame this translates in glitches when we start/stop running, other than that it's fine. Thanks for any insight, Maarten ___ 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] Character Animation Blending problem
Last entry in what seems to be my monologue: well, I fixed it. Used only one sequence for idle_, walk_ and run_ upper, since they were identical, but more importantly, disabled the piece of code in the if ( ShouldBlendAimSequenceToIdle() ) loop in CBasePlayerAnimState::ComputeAimSequence(). That piece of code apparently should prevent the player getting all jiggly at slow speeds, but for me, it does the exact opposite; commenting it out fixes my issues. Hope this helps anyone. If anyone understands why this is a fix, feel free to teach me :) I've discovered this while debugging: if you're blending between two sequences that are the exact same pose, you will not attain that pose unless at least one of the two blendfactors is at one ( feel free to try that in hlmv ). Can anyone tell me how the blending works, and if it's possible to have it working the way I'd expect ( e.g. 0.5 * sequence a + 0.5 * a sequence identical to a = a. ). Any insight in the animation blending process is appreciated. Maarten The bottom one is probably at 0.6, but to eliminate all doubt: http://i336.photobucket.com/albums/n330/jfkeats/ol_testmap0041.jpg idle_, walk_ and lower_ are identical, the sum of their weights is 1, and still the blend is not 'complete', there's a part of jesus in there which causes the gap. It doesn't look like the two sliders are both on 0.5: the top one is further to the left than the bottom one. Maarten De Meyer wrote: Hi list! I'm trying to understand a blending problem. Simple question: http://i336.photobucket.com/albums/n330/jfkeats/problem.jpg In this setup, run_lower only affects the legs ( so the upper pose is Jesus, weightlists are at 0 for upper body ). run_upper_minigun and walk_upper_minigun are both a simple, correct pose ( correct being with the hand on the front handle ). Why is that, if they're both blended with weight 0.50, and the run_lower should have a weight of 0 for the upper body, I still have a gap/incorrect pose ( caused by some of the 'Jesus' pose still being blended in )? If the sum of their weights is 1.0, shouldn't the pose be exact? Ingame this translates in glitches when we start/stop running, other than that it's fine. Thanks for any insight, Maarten ___ 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] Character Animation Blending problem
Thanks for the explanation! I figured the root pose was still in there, I just hoped the weightlist was taken into account at this level, causing the root pose to be left out of the equation for the upper body. But I guess the weightlist is just earlier. Thanks for the insight! I pinged Ken and here is what he had to say: Blending sequence B on sequence A is: Result = A * (1.0 - blend_factor) + B * blend_factor Each blend accumulates on the previous pose, so what they're doing is blending two sequences on top of the root pose like this: result = (root_pose * (1.0 - 0.5) + sequence_a * 0.5 ) * (1.0 - 0.5) + sequence_a * 0.5) The final result will be: result = 0.25 * root_pose + 0.75 * sequence_a Blending isn't the same as addition, it's an accumulation on top of the previous operation. There is addition, flagging an animation as a delta animation will get that, but that'll be true addition, which means they'd need to subtract the root_pose from each in order to made adding make sense, which probably isn't what they want to do. Yahn -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Maarten De Meyer Sent: Saturday, July 12, 2008 7:09 AM To: Discussion of Half-Life Programming Subject: Re: [hlcoders] Character Animation Blending problem I've discovered this while debugging: if you're blending between two sequences that are the exact same pose, you will not attain that pose unless at least one of the two blendfactors is at one ( feel free to try that in hlmv ). Can anyone tell me how the blending works, and if it's possible to have it working the way I'd expect ( e.g. 0.5 * sequence a + 0.5 * a sequence identical to a = a. ). Any insight in the animation blending process is appreciated. Maarten The bottom one is probably at 0.6, but to eliminate all doubt: http://i336.photobucket.com/albums/n330/jfkeats/ol_testmap0041.jpg idle_, walk_ and lower_ are identical, the sum of their weights is 1, and still the blend is not 'complete', there's a part of jesus in there which causes the gap. It doesn't look like the two sliders are both on 0.5: the top one is further to the left than the bottom one. Maarten De Meyer wrote: Hi list! I'm trying to understand a blending problem. Simple question: http://i336.photobucket.com/albums/n330/jfkeats/problem.jpg In this setup, run_lower only affects the legs ( so the upper pose is Jesus, weightlists are at 0 for upper body ). run_upper_minigun and walk_upper_minigun are both a simple, correct pose ( correct being with the hand on the front handle ). Why is that, if they're both blended with weight 0.50, and the run_lower should have a weight of 0 for the upper body, I still have a gap/incorrect pose ( caused by some of the 'Jesus' pose still being blended in )? If the sum of their weights is 1.0, shouldn't the pose be exact? Ingame this translates in glitches when we start/stop running, other than that it's fine. Thanks for any insight, Maarten ___ 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] [ep1] CLocalSpaceEmitter vs CSimpleEmitter
The saga continues! The problem basically is that a certain flag for effects, which forces it to get rendered just before the view model and out of the leaf system ( FLAGS_DRAW_BEFORE_VIEW_MODEL ), is not working properly. There's a function CParticleMgr::DrawBeforeViewModelEffects that is not called at all in my pipeline. I see it's called from ViewDrawScene_Intro which calls DrawWorldAndEntities, but my pipeline passes through the function WaterDrawWorldAndEntities where this thing is not called. Did I break the pipeline somewhere or is it a bug? I can add the function somewhere in my pipeline, and then my muzzle flashes work properly, but they still get rendered in the main loop when it's not culled which triggers an assert. I can fix that easily, just wondering where it or I went wrong what caused the bug in the first place. -- Maarten Just a quick update, to maybe still ring a bell somewhere: apparently my muzzle flash for my view model has a bounding box that is being tested against world geometry, if I turn on the debug I clearly see the muzzle flash disappearing the moment the bounding box is completely in the world geometry somewhere ( floors, walls, ceilings ). I assume it shouldn't, or at the very least, the bounding box in view space is obviously inconsistent with the world test. Gonna try to prevent that somehow, but if anyone knows this problem, or what might cause it, feel free to share :) -- maarten Hi list! I'm debugging an issue with our muzzle flashes and wanted to check if one of you could give me an answer faster than I can debug it myself. Basically, our muzzle flash particles are invisible when you look down when you're on the ground or when you look up near a ceiling. I thought maybe some bounding box issue ( the particles are appearing/disappearing while you look up down, eg when I set the lifetime to 10 seconds I can easily test this ). I've used some logging to debug the difference between both, and one difference is that, when the muzzle flash is created when looking down, it's calling CSimpleEmitter::SimulateParticles which decides it should remove certain particles when their lifetime has touched something between 0.25 and 1 sec. Lifetime of my muzzle flash particles is 10 sec, so I'm not even sure if these particles are the same, but even so, this does not happen at all when I fire the gun in a straight angle ( in this case the particles are removed properly by CLocalSpaceEmitter when their lifetime hits 10 seconds ). Does this ring any bells? Anyone properly understand how CLocalSpaceEmitter and CSimpleEmitter interact/function and why the visibility of such particles can be position/angle dependent? Thanks in advance, maarten ___ 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] [ep1] CLocalSpaceEmitter vs CSimpleEmitter
Just a quick update, to maybe still ring a bell somewhere: apparently my muzzle flash for my view model has a bounding box that is being tested against world geometry, if I turn on the debug I clearly see the muzzle flash disappearing the moment the bounding box is completely in the world geometry somewhere ( floors, walls, ceilings ). I assume it shouldn't, or at the very least, the bounding box in view space is obviously inconsistent with the world test. Gonna try to prevent that somehow, but if anyone knows this problem, or what might cause it, feel free to share :) -- maarten Hi list! I'm debugging an issue with our muzzle flashes and wanted to check if one of you could give me an answer faster than I can debug it myself. Basically, our muzzle flash particles are invisible when you look down when you're on the ground or when you look up near a ceiling. I thought maybe some bounding box issue ( the particles are appearing/disappearing while you look up down, eg when I set the lifetime to 10 seconds I can easily test this ). I've used some logging to debug the difference between both, and one difference is that, when the muzzle flash is created when looking down, it's calling CSimpleEmitter::SimulateParticles which decides it should remove certain particles when their lifetime has touched something between 0.25 and 1 sec. Lifetime of my muzzle flash particles is 10 sec, so I'm not even sure if these particles are the same, but even so, this does not happen at all when I fire the gun in a straight angle ( in this case the particles are removed properly by CLocalSpaceEmitter when their lifetime hits 10 seconds ). Does this ring any bells? Anyone properly understand how CLocalSpaceEmitter and CSimpleEmitter interact/function and why the visibility of such particles can be position/angle dependent? Thanks in advance, maarten ___ 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] [ep1] CLocalSpaceEmitter vs CSimpleEmitter
Hi list! I'm debugging an issue with our muzzle flashes and wanted to check if one of you could give me an answer faster than I can debug it myself. Basically, our muzzle flash particles are invisible when you look down when you're on the ground or when you look up near a ceiling. I thought maybe some bounding box issue ( the particles are appearing/disappearing while you look up down, eg when I set the lifetime to 10 seconds I can easily test this ). I've used some logging to debug the difference between both, and one difference is that, when the muzzle flash is created when looking down, it's calling CSimpleEmitter::SimulateParticles which decides it should remove certain particles when their lifetime has touched something between 0.25 and 1 sec. Lifetime of my muzzle flash particles is 10 sec, so I'm not even sure if these particles are the same, but even so, this does not happen at all when I fire the gun in a straight angle ( in this case the particles are removed properly by CLocalSpaceEmitter when their lifetime hits 10 seconds ). Does this ring any bells? Anyone properly understand how CLocalSpaceEmitter and CSimpleEmitter interact/function and why the visibility of such particles can be position/angle dependent? Thanks in advance, maarten ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Performance : OB engine vs ep1 engine
That reply only makes sense if the OB engine has some serious features added that require these performances. If you want the same functionality on a more modern engine, the performance should stay the same or increase, not decrease. I don't know what they added in the OB engine that justifies a performance drop ( didn't even know there was one ), I'm perfectly happy with my ep1 functionality performance, just saying that you shouldn't take for granted that developers need a bigger hardware budget each time unless it's justified. Not to mention they're supporting a console which has at least a 5 year lifespan with a fixed performance budget. Nick wrote: I am really shocked about this massive performance difference. I read about this nowhere else, I had no idea this would happen. I am only very thankful that I didn't bother upgrading to OB sdk. Does anyone know if/when these performance issues will be resolved Probably never. Next-gen games require next-gen hardware. You're not going to be able to run more recent games with your '386 computer and your GeForce2 graphics card. :) Seriously, game developers will keep pushing the top-end hardware just as far as it can go. If you don't keep upgrading your hardware every few years, you will be unable to run the latest and greatest 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
Re: [hlcoders] dynamic mesh
usage example :
void CViewRender::DrawAlienLens( IMaterialSystem * materials, IMaterial*
pMaterial )
{
materials-Bind( pMaterial );
AlienLens = materials-GetDynamicMesh( true );
CMeshBuilder meshBuilder;
meshBuilder.Begin( AlienLens, MATERIAL_TRIANGLES, 1512 );
meshBuilder.Position3f( 1.073661f, -1.167747f, 0.00f );
meshBuilder.TexCoord2f( 0, 0.959300f, 0.999500f);
meshBuilder.AdvanceVertex();
meshBuilder.Position3f( 1.009307f, -1.167747f, 0.00f );
meshBuilder.TexCoord2f( 0, 0.931700f, 0.999500f);
meshBuilder.AdvanceVertex();
... a ridiculous amount of similar calls here
meshBuilder.Position3f( -1.167747f, -1.167747f, -0.00f );
meshBuilder.TexCoord2f( 0, 0.000500f, 0.999500f);
meshBuilder.AdvanceVertex();
meshBuilder.End();
AlienLens-Draw();
}
I wrote a text parser that takes an .smd, parses the triangles
texcoords, and transforms them into this c++ code that I then just
copy/paste into my code :p
hth,
-- maarten
Hi, I have questions about using the dynamic mesh
1. what should be the order of vertices in a triangle?
2. given three points, how to order them correctly (the fastest way)?
3. how do I calculate texture coordinates?
4. what is the least needed to draw a mesh (vertices are enough, or more
is needed)?
5. how do I set the texture (is materials-bind(pMaterial) enough)?
___
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] dynamic mesh
That is correct. You are wrong ;) I use it with a custom render target material, so I don't think there are limitations to the material you're using. I believe it can also only use sprite textures. Unless I'm wrong? ___ 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] Starting mod from steam server browser doesn't work
And the winner of the Hero-of-the-Day award is... *drum rolls* o/ Rich \o Thanks a bunch man, that one was really bothering me, works now! -- Maarten You need a file named steam.inf in your mod directory with a single line: appID=215 We had the exact same problem you describe, and adding this file solved it. Cheers, Rich Tom Leighton wrote: Maybe a server issue then? Possibly steam.inf ? Tom Edwards wrote: I don't think this has anything to do with the mod (your gameinfo is fine btw). I've been able to reproduce the problem when connecting to a specific Eternal Silence server, at 62.212.73.20:27015, but if I try any other server, even for the same mod, there's no issue! An odd one, that's for sure... Maarten De Meyer wrote: attached, thanks for your effort! List the contents of your gameinfo.txt. Maarten De Meyer wrote: Hi list/valve! I'm gonna repost a problem I posted earlier since I really need a fix for this before we release. Basically, double-clicking on a server in the steam client's server browser doesn't work when not ingame. More details: If you doubleclick on a server of our mod when you're in windows, it says 'launching HL2' instead of 'launching Off Limits'. Next, it starts up the mod, which then crashes with a 'OnGameRulesCreationStringChanged: missing gamerules class 'COffLGameRules' on the client'. If you first start up the game through the 'my games' list, and then use the serverbrowser or the console when you're already ingame, there's no problem connecting. Yes, my gamerules class is included in the client project, and no, I can't find a crash in a client global ( I've started the game in debug and joined it without any more info ). Does anyone have an idea why this might happen only in this case, and a way I could even try to debug this problem? Thanks a lot, -- Maarten ___ 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 ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] tr.plane.normal only returns y value of normal?
Vector components are floats, use %f in stead of %d.
I added a secondary attack to the 357 (just for testing) in which I find
the
wall in front of the gun and find the normal vector of that wall. However,
when I read out the x,y, and z values of this vector, it seems only the y
vector changes. here's the relevant code:
Vector vecSrc = pPlayer-Weapon_ShootPosition();
Vector vecAiming= pPlayer-GetAutoaimVector( AUTOAIM_5DEGREES );
trace_t tr;
UTIL_TraceLine(vecSrc,vecSrc + vecAiming *
MAX_TRACE_LENGTH,MASK_SOLID,this,COLLISION_GROUP_NONE,tr);
if(tr.DidHitWorld())
{
Vector vUp = tr.plane.normal;
Msg(%d,%d,%d\n,vUp.x,vUp.y,vUp.z); // only vUp.y changes
}
Thanks,
Kenrick Rilee
(btw i hope i don't sound too much like a noob :/)
___
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] Starting mod from steam server browser doesn't work
Still no luck. I'd recommend to try adding: Game sourcetest in the search paths section. Maarten De Meyer wrote: attached, thanks for your effort! List the contents of your gameinfo.txt. Maarten De Meyer wrote: Hi list/valve! I'm gonna repost a problem I posted earlier since I really need a fix for this before we release. Basically, double-clicking on a server in the steam client's server browser doesn't work when not ingame. More details: If you doubleclick on a server of our mod when you're in windows, it says 'launching HL2' instead of 'launching Off Limits'. Next, it starts up the mod, which then crashes with a 'OnGameRulesCreationStringChanged: missing gamerules class 'COffLGameRules' on the client'. If you first start up the game through the 'my games' list, and then use the serverbrowser or the console when you're already ingame, there's no problem connecting. Yes, my gamerules class is included in the client project, and no, I can't find a crash in a client global ( I've started the game in debug and joined it without any more info ). Does anyone have an idea why this might happen only in this case, and a way I could even try to debug this problem? Thanks a lot, -- Maarten ___ 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] Starting mod from steam server browser doesn't work
attached, thanks for your effort!
List the contents of your gameinfo.txt.
Maarten De Meyer wrote:
Hi list/valve!
I'm gonna repost a problem I posted earlier since I really need a fix
for
this before we release. Basically, double-clicking on a server in the
steam client's server browser doesn't work when not ingame.
More details: If you doubleclick on a server of our mod when you're in
windows, it says 'launching HL2' instead of 'launching Off Limits'.
Next,
it starts up the mod, which then crashes with a
'OnGameRulesCreationStringChanged: missing gamerules class
'COffLGameRules' on the client'. If you first start up the game through
the 'my games' list, and then use the serverbrowser or the console when
you're already ingame, there's no problem connecting.
Yes, my gamerules class is included in the client project, and no, I
can't
find a crash in a client global ( I've started the game in debug and
joined it without any more info ).
Does anyone have an idea why this might happen only in this case, and a
way I could even try to debug this problem?
Thanks a lot,
-- Maarten
___
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
GameInfo
{
// This is what shows up in the 'Third Party Games' area of the Steam
games list.
gameOffLimits
developer Off-Limits Team
developer_url http://www.off-limits.be;
iconicon
title Off Limits
manual http://www.off-limits.be;
type multiplayer_only
FileSystem
{
SteamAppId 215 // This
will mount all the GCFs we need (240=CS:S, 220=HL2).
ToolsAppId 211 //
Tools will load this (ie: source SDK caches) to get things like
materials\debug, materials\editor, etc.
SearchPaths
{
Game|gameinfo_path|.
Gamehl2
}
}
}___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Starting mod from steam server browser doesn't work
Hi list/valve! I'm gonna repost a problem I posted earlier since I really need a fix for this before we release. Basically, double-clicking on a server in the steam client's server browser doesn't work when not ingame. More details: If you doubleclick on a server of our mod when you're in windows, it says 'launching HL2' instead of 'launching Off Limits'. Next, it starts up the mod, which then crashes with a 'OnGameRulesCreationStringChanged: missing gamerules class 'COffLGameRules' on the client'. If you first start up the game through the 'my games' list, and then use the serverbrowser or the console when you're already ingame, there's no problem connecting. Yes, my gamerules class is included in the client project, and no, I can't find a crash in a client global ( I've started the game in debug and joined it without any more info ). Does anyone have an idea why this might happen only in this case, and a way I could even try to debug this problem? Thanks a lot, -- Maarten ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Starting mod from steam server browser doesn't work
Ok. The AppID in my gameinfo.txt is 215, the AppID in the server's gameinfo.txt is the same ( they're on the same SVN ). Are you referring to another AppID somewhere when you say 'the AppID of the game you're launching' ? [ btw, when looking into this problem, I found out I had two gameinfo.txt's, on in my mod's root folder, one in the /scripts folder. This normal? where should it be? ] I got that long ago with the first SDK (code) release. If I recall correctly is it related to the AppID of the game you're launching, and the AppID specified in the GameInfo.txt not matching. Not too sure though! /ScarT On 06/04/2008, Maarten De Meyer [EMAIL PROTECTED] wrote: Hi list/valve! I'm gonna repost a problem I posted earlier since I really need a fix for this before we release. Basically, double-clicking on a server in the steam client's server browser doesn't work when not ingame. More details: If you doubleclick on a server of our mod when you're in windows, it says 'launching HL2' instead of 'launching Off Limits'. Next, it starts up the mod, which then crashes with a 'OnGameRulesCreationStringChanged: missing gamerules class 'COffLGameRules' on the client'. If you first start up the game through the 'my games' list, and then use the serverbrowser or the console when you're already ingame, there's no problem connecting. Yes, my gamerules class is included in the client project, and no, I can't find a crash in a client global ( I've started the game in debug and joined it without any more info ). Does anyone have an idea why this might happen only in this case, and a way I could even try to debug this problem? Thanks a lot, -- Maarten ___ 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] Rotating a player
I went through that recently. Can show you the code when I'm at home. -- Maarten Ok, well i've been working trying to rotate a player. I've figured out rotating the player model (just modify C_SDKPlayer::GetRenderAngles()). However, this doesn't modify the angle the hitboxes are at and it doesn't modify the actual display. Does anyone have any advice on how to get this done? Thanks in advance, Kenrick Rilee ___ 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] Rotating a player
Implement CSDKPlayer::PostThink, call it's baseclass's PostThink and afterwards call SetAbsAngles() with your desired angles as parameter. That will modify the hitboxes. As for rotating the player model, I've hooked CSDKPlayerAnimState::ComputePoseParam_BodyYaw() to override angRender with what I want. What do you mean with modify the actual display ? If you're talking about first person view, the view angles, you'll have to do some extra work there ( mostly patching the input classes to process mouse movement in the rotated coordinate system ). hth, --Maarten P.S.: One remark I tend to make on this subject: if your goal is players wallwalking, be warned that it is near impossible to get perfect on randomly oriented surfaces due to the lack of SOLID_OBB support; on axis-aligned surfaces it's rather easy. Ok, well i've been working trying to rotate a player. I've figured out rotating the player model (just modify C_SDKPlayer::GetRenderAngles()). However, this doesn't modify the angle the hitboxes are at and it doesn't modify the actual display. Does anyone have any advice on how to get this done? Thanks in advance, Kenrick Rilee ___ 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] A number of vehicle irregularities
We've got pretty playable multiplayer vehicles, and yeah, the script file is a mess. As for the physics behavior with the barrel rolls and all, I used a nice little hack which uses the center of mass override to set it at several meters below the ground, that way your car won't topple over anymore, no matter what you do. Nobody's complained so far :p -- Maarten Hi all, I'm new to the list, but I've got a couple of questions that don't seem to be answered anywhere in the archives or on the wiki. I've been trying to do some vehicle script modifications to the buggy in the episode 1 engine. However, in the course of mucking about with the various scripting values, I have run across a some odd behavior, and I wanted to know if anyone knew anything about them. I tried to dig through the source code and find the actual hookups, but the furthest I could get was IVPhysicsKeyParser before I was brick-walled by externs and virtual functions. #1: A number of values don't actually to do anything, or at least don't appear to. These values include autotransmission, any gear listed after the first one, shiftuprpm, shiftdownrpm, degrees, most of the values in the steering block, and stabilizerConstant in the suspension block. It doesn't cause crashes, but it does obfuscate things significantly and It would be nice to know which values I can safely remove in their entirety. #2: If the max speed and horsepower values are raised to around 85 and 850 respectively and the user hits the breaks while moving quickly, the car will do a barrel-roll instead of simply stopping. The roll will be in the last direction the user steered. This is somewhat intermittent, and only seems to happen if the car is moving in a straight line when it breaks. #3: Using the torquefactor values in the axle blocks, it is possible to shift which axle is delivering power. If you set the front torquefactor low and the rear torquevalue high to simulate a rear-wheel drive, the car will become unable to drive in a straight line and start swinging wildly out of control. Do any of you know how to solve these issues or know a place I could look for more information? The wiki's section on vehicle scripts is sadly lacking. ___ 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] Star Wars content
I'm no lawyer, but in many countries there are exceptions if what he does really classifies as a parody. ( Without this clause, parodies would be a lot less present, since many people would not allow their work to be criticised/ridiculed ). If you google for it, you'll find a lot of information on the topic. Hey Some, You would have to gain permission from the copyright holders before you convert / compile your Machinima. Good luck! Adam --- Some Person [EMAIL PROTECTED] wrote: Hello, We are doing a parody of Star Wars as a Machinima movie in HL2. I've been looking and finding Star Wars maps/models, but I don't think these are HL2 compatible. Anyone know of HL2 compatible content--specifically a Mos Eisley cantina map and a Darth Vader model? If not, is there a way to convert either of these from the Jedi Knights 3 versions? Thanks! _ How well do you know your celebrity gossip? http://originals.msn.com/thebigdebate?ocid=T002MSN03N0707A ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders Owner Nigredo Studios http://www.nigredostudios.com Special deal for Yahoo! users friends - No Cost. Get a month of Blockbuster Total Access now http://tc.deals.yahoo.com/tc/blockbuster/text3.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] SDK Update - No More Beta
Much needed. Much appreciated. Can finally finish my mod o/. Do *not* update anything for another month or two, unless if it introduces an opt-out of updates and nothing else =] Hi All- The Source SDK has been updated to address some crashes and is no longer in beta. Here are the release notes: =Enhancements= * There is now a drop list in the SDK Launcher that allows the user to switch between engine versions. * Modders can now create single player and multi-player mods based in the HL2:Episode Two source code when the engine version is set to The Orange Box. It is still possible to create mods based on HL2:Episode One. * Two new lighting preview modes are available in Hammer. * Models are automatically centered when loaded in Faceposer. =Bug Fixes= * Fixed crash and corrupt configurations for users that don't own any Orange Box games. * Resolved issues with building models for any games that that use the Half-Life 2:Episode 1 engine. * Fixed crashes in Hammer and Model Viewer when HL2 is set to the active game. =Known Issues= * Cannot create shortcuts to Hammer, Faceposer, and Model Viewer. * Linux makefiles for the Orange Box source code are incomplete and will be updated in the next release. * The Particle Editor is not presently included in the Source SDK. * SDK shader code only included with mods built to use Half-Life 2:Episode 1. * Particle Editor is not included in this release. Please overcome your typical shyness and report any problems you have to me. J -Best, 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] Bad Command {
Slightly off-topic, but still.
Is there a way to patch up the studiomdl in the ep1 source so it eg loads
the MaterialSystem.dll hardcoded/possible other fixes?
Waiting for the new studiomdl is all good and well, but if it's going to
take months ( and it's been a while already ), it's catastrophic for my
team.
You'll have to wait for the new studiomdl.
On Fri, Mar 21, 2008 at 9:34 PM, Jed [EMAIL PROTECTED] wrote:
It says its on line 36 which is around the collision model command.
Try putting the { at the end of the line after the SMD file name
rather than on a newline.
- Jed
On 22/03/2008, Jake Breen [EMAIL PROTECTED] wrote:
Okay..I can't seem to compile a model with physics with the Orange Box
studiomdl. At the moment I'm doing a series of ports of Postal 2
Player
Models (With Permission, heck they're even encouraging it.
http://oxihosting.com/files/100/maxpostal2awesome.jpg = proof.) And
I'm
at the postal babe, thought I'd try and give them something extra to
play with..So I can't simply compile with the ep1 studiomdl since it
doesn't support $jigglebone
My compile log
Created command line: D:\Program
Files\Steam\steamapps\frostbitex460\sourcesdk\bin\orangebox\bin\studiomdl.exe
-game D:\Program
Files\Steam\steamapps\frostbitex460\garrysmod\garrysmod -nop4
-nox360
C:\Projects\Postal2\SourcePort\Characters\Postal_Babe\babe.qc
WARNING: AppFramework : Unable to load module p4lib.dll!
qdir:c:\projects\postal2\sourceport\characters\postal_babe\
gamedir: D:\Program
Files\Steam\steamapps\frostbitex460\garrysmod\garrysmod\
g_path:
C:\Projects\Postal2\SourcePort\Characters\Postal_Babe\babe.qc
Building binary model files...
Working on babe.qc
SMD MODEL
C:\Projects\Postal2\SourcePort\Characters/Postal_Babe\Babe1.smd
SMD MODEL
C:\Projects\Postal2\SourcePort\Characters/Postal_Babe/Babe_Ragdoll_seq.smd
ERROR:
c:\projects\postal2\sourceport\characters\postal_babe\babe.qc(36): -
bad
command {
ERROR: Aborted Processing on 'Postal 2\Babe1.mdl'
My qc:
/
//
// Postal 2 Source Port Quake C Script
// Remember to add the file ext at the end of mesh/animations
filepaths
//
//-Jake
/
// Call the Current Directory
$cd C:\Projects\Postal2\SourcePort\Characters
// Call scale _BEFORE_ smds!!
// Not needed anymore since it's now scaled down.
//$scale .45
//head controllers
$attachment eyes MALE01 Head 0.01 -9.17 149.47 absolute
$attachment mouth MALE01 Head 0.80 -5.80 -0.15 rotate 0 -80 -90
// Model Info
$modelname Postal 2\Babe1.mdl
$model Babe1 Postal_Babe\Babe1.smd
$cdmaterials models\Postal 2\Dancer\
// Animations
//$sequence Ragdoll Postal_Male_Ragdoll_Seq.smd ACT_DIERAGDOLL 1
fps
30.00
// Physics Infoz
$sequence Ragdoll Postal_Babe/Babe_Ragdoll_seq.smd ACT_DIERAGDOLL
1
fps 30.00
$collisionmodel Postal_Babe/Babe_Ragdoll.smd
{
$mass 90.0
$inertia 10.00
$damping 0.01
$rotdamping 1.50
$rootbone MALE01 Pelvis
$jointmerge MALE01 Pelvis MALE01 Spine
$jointconstrain MALE01 Spine2 x limit -48.00 48.00 0.00
$jointconstrain MALE01 Spine2 y limit -25.00 25.00 0.00
$jointconstrain MALE01 Spine2 z limit -25.00 50.00 0.00
$jointconstrain MALE01 R upperarm x limit -39.00 39.00 0.00
$jointconstrain MALE01 R upperarm y limit -79.00 95.00 0.00
$jointconstrain MALE01 R upperarm z limit -93.00 23.00 0.00
$jointconstrain MALE01 L upperarm x limit -30.00 30.00 0.00
$jointconstrain MALE01 L upperarm y limit -95.00 84.00 0.00
$jointconstrain MALE01 L upperarm z limit -86.00 26.00 0.00
$jointconstrain MALE01 L Forearm x limit 0.00 0.00 0.00
$jointconstrain MALE01 L Forearm y limit 0.00 0.00 0.00
$jointconstrain MALE01 L Forearm z limit -149.00 4.00 0.00
$jointconstrain MALE01 L hand x limit -37.00 37.00 0.00
$jointconstrain MALE01 L hand y limit 0.00 0.00 0.00
$jointconstrain MALE01 L hand z limit -57.00 59.00 0.00
$jointconstrain MALE01 R forearm x limit 0.00 0.00 0.00
$jointconstrain MALE01 R forearm y limit 0.00 0.00 0.00
$jointconstrain MALE01 R forearm z limit -149.00 4.00 0.00
$jointconstrain MALE01 R hand x limit -60.00 60.00 0.00
$jointconstrain MALE01 R hand y limit 0.00 0.00 0.00
$jointconstrain MALE01 R hand z limit -57.00 70.00 0.00
$jointconstrain MALE01 R thigh x limit -12.00 12.00 0.00
$jointconstrain MALE01 R thigh y limit -8.00 75.00 0.00
$jointconstrain MALE01 R thigh z limit -97.00 32.00 0.00
$jointconstrain MALE01 R calf x limit 0.00 0.00 0.00
$jointconstrain MALE01 R calf y limit 0.00 0.00 0.00
$jointconstrain MALE01 R calf
[hlcoders] Model compile error - followup
Hi list, I'd like to check on the status or a workaround for this bug. Ever since orange box SDK was released my studiomdl.exe doesn't work anymore - it just says 'ERROR: Can't load MaterialSystem.dll'. I'm still on ep1 sdk, codebase tools. I use studiomdl.exe in \sourcesdk\bin\ep1\bin . Opening HLMV or hammer before calling studiomdl.exe does not fix the problem. I really *really* need to get a working studiomdl.exe. Anyone hit this problem and solved it, or, any official comment on this Valve? Thanks a lot for any help, -- Maarten ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Model compile error - followup
Thanks kevin, I use the same system. In the meantime I've deleted everything to do with any version of sourceSDK or all caches in my steam directory and I'm re-dowloading everything. Afterwards I'll check the md5 check your .exe Thanks, Maarten Maarten, I use studiomdl in EP1 all the time and it works ok for me. The version I have here is: MD5: c3904d1d72c034f587bee87e4b37c72f *studiomdl.exe Created: Wednesday, November 07, 2007, 1:01:08 PM Size: 679,936 bytes I uploaded a copy for you in case you have a different version: http://qsextreme.com//SDK/ep1_bin/studiomdl.zip I only use batch files to compile models: %sourcesdk%\bin\ep1\bin\studiomdl modelname.qc KevinO - Original Message - From: Maarten De Meyer To: hlcoders@list.valvesoftware.com Sent: Saturday, March 15, 2008 8:24 AM Subject: [hlcoders] Model compile error - followup Hi list, I'd like to check on the status or a workaround for this bug. Ever since orange box SDK was released my studiomdl.exe doesn't work anymore - it just says 'ERROR: Can't load MaterialSystem.dll'. I'm still on ep1 sdk, codebase tools. I use studiomdl.exe in \sourcesdk\bin\ep1\bin . Opening HLMV or hammer before calling studiomdl.exe does not fix the problem. I really *really* need to get a working studiomdl.exe. Anyone hit this problem and solved it, or, any official comment on this Valve? Thanks a lot for any help, -- Maarten ___ 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] Model compile error - followup
Ok, thanks. At the risk of sounding cliché, when's the next sdk update planned, in non-valve time? :p STudiomdl has been fixed for the next SDK update; hang tight! -Tony On Sat, Mar 15, 2008 at 11:24 AM, Maarten De Meyer [EMAIL PROTECTED] wrote: Hi list, I'd like to check on the status or a workaround for this bug. Ever since orange box SDK was released my studiomdl.exe doesn't work anymore - it just says 'ERROR: Can't load MaterialSystem.dll'. I'm still on ep1 sdk, codebase tools. I use studiomdl.exe in \sourcesdk\bin\ep1\bin . Opening HLMV or hammer before calling studiomdl.exe does not fix the problem. I really *really* need to get a working studiomdl.exe. Anyone hit this problem and solved it, or, any official comment on this Valve? Thanks a lot for any help, -- Maarten ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- -omega ___ 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] Studiomdl Broken
So there is a way to compile with the ep1 studiomdl? Because I'm getting the MaterialSystem.dll error, regardless if I have HLMV running or not. Is this fixed if I compile the studiomdl from the beta code? -- Maarten Well I figured out why vphysics.dll wasn't being loaded. I was running: bin\ep1\bin\studiomdl -game path to orangebox mod That caused Steam to overwrite bin\ep1\bin\vphysics.dll (and a bunch of other files) with the orangebox versions. Having HLMV running prevented those files from being overwritten. -- Tim Baker I built the EP1 studiomdl.exe using the current beta code and the function that fails is in physdll.cpp:PhysicsDLLPath... pPhysicsModule = g_pFullFileSystem-LoadModule( dllPath ); ...where dllPath is VPHYSICS.DLL. With HLMV running this function succeeds. I added these lines before the LoadModule() call: char out[1024]; Q_getwd( out, sizeof(out) ); That verified the current working directory as the bin\ep1\bin directory where vphysics.dll is located. My debugging adventures stop there as I don't think we are given the sources to IFileSystem::LoadModule. -- Tim Baker ___ 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] Noesis Interactive wants to meet you at GDC 2008!!
Not sure, I'm attending (first time woohoo), but I'm not too sure about this. I feel they're commercialising the experience you should build yourself. The whole point of modding is to learn everything yourself; and while ymmv, I learn better when I have to figure stuff out myself. Not to mention they're selling tutorials on topics on which there's a wealth of free information available. just my 2c, -- Maarten Even though I wont be attending this year, it sounds interesting. Adam --- Ben Mears [EMAIL PROTECTED] wrote: Are you a member of a successful Mod Team? Are you going to be at the Game Developers Conference in San Francisco this year? If you answered yes to both of these questions then Noesis Interactive wants to meet with you! Noesis Interactive works with industry giants such as Valve, IGN, Softimage, and Autodesk to expand knowledge regarding game modding and development through easy to follow video modules. Were interested in speaking with modders and developers about their roles and experiences in order to lend insight to the rest of the Mod community. This is a great opportunity to promote both your Mod and your team. So, if youre going to be at GDC and are interested in being involved, please respond to this message or email [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] for more details. We hope to see you there! ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders Owner Nigredo Studios http://www.nigredostudios.com Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs ___ 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] Beta SDK: Scratch SDK Bug Repository
Thanks Mike! Any idea when we can expect a fix or workaround for this bug? I miss my studiomdl really badly :) -- Maarten Yes, I'm aware of that one and hope to have a fix soon. -Mike -Original Message- From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Maarten De Meyer Sent: Tuesday, January 29, 2008 1:12 AM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Beta SDK: Scratch SDK Bug Repository Without insisting too much, I'd love to get an official reply on this or a non-official fix; not being able to compile anything is kind of blocking development :) No, that doesn't fix it in this case. studiomdl.exe has always crashed for me unless I have HLMV running. -- Tim Another issue, seemingly related to the vbsp one. I'm running studiomdl.exe to compile a model, and it fails also with a Can't load MaterialSystem.dll Any solutions for this one? -- Maarten ___ 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] Weapon Prediction Problems?
Gonna ask the default question, don't shoot me if it's too simple: Do your weapons override the IsPredicted function to return true? I remember something about this not being the case in the SDK weapons by default, so prediction wasn't even used on those weapons. -- Maarten This is a multipart message in MIME format. -- [ Picked text/plain from multipart/alternative ] Alright, Im stumped. I cant tell if this is a prediction problem, or of something else is going on. Ive written about 35 or so new weapons and they ALL experience animation and effect glitches in a laggy environment (net_fakelag 100 is how Ive been testing this). If I have a semi-auto weapon such as a pistol which is only allowed to fire every 0.2 seconds it can fire every single frame when there is any sort of lag introduced to the game. Obviously when I say fire I mean just play the effects, it doesnt actually fire on the server-side. This happens on full auto as well, but isnt so obvious to the player because it is masked by the real rate of fire. When I run the debugger, I discovered that the server and client time get out of sync, causing the m_flNextPrimaryAttack variable to become instantly stale on the client side. Here is the rundown of what is going on: 1. Client sends fire command, plays the effects 2. Client updates m_flNextPrimaryAttack to gpGlobals-curtime + x.xx 3. Server acknowledges, fires the weapon 4. Server updates m_flNextPrimaryAttack to gpGlobals-curtime + x.xx 5. Server sends client updated m_flNextPrimaryAttack time 6. Client corrects m_flNextPrimaryAttack which ends up BEHIND gpGlobals-curtime 7. Client sends fire command, plays effects 8. Client updates m_flNextPrimaryAttack to gpGlobals-curtime + x.xx 9. Server denies command because it isnt allowed to shoot on the server yet 10. Server sends client updated m_flNextPrimaryAttack time 11. Client corrects m_flNextPrimaryAttack again, ending up BEHIND gpGlobals-curtime again allowing it to shoot again Basically the server is sending the client an old m_flNextPrimaryAttack time near continuously. This would normally be OK, but the gpGlobals-curtime variables become out of sync. The server thinks it is 1263.6800 when the client has 1263.7500. This only happens when there is lag. To test to make sure it wasnt my mod, I ran a vanilla setup of the scratch SDK and discovered that the weapons built into that SDK experience the same symptoms. Im not sure if it is for the same reasons or not though, I didnt run it through the debugger. I sure hope there is some easy way to fix this. Perhaps it is just a symptom of using fake lag? Maybe I should just set up a server in the same room, then shake the Ethernet cable violently until bits fall out of the cable, creating lag? (joke) Thanks in advance. Cale No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.19.19/1256 - Release Date: 2/2/2008 1:50 PM -- ___ 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] Rotating a player
- In sdk_playeranimstate hack the angRender to get it to display oriented - in sdk_player implement a PostThink that sets AbsAngles to get the hitboxes right - If you want input to be proper, override the proper functions in in_mouse to get your mouse movement to be relative to the new orientation - If you want movement to be somewhat consistent, modify sdk_gamemovement to use the new orientation But my most important piece of advice: If you want to implement actual wallwalking, choose another engine. Unless if you're making maps with only axis-aligned surfaces, the lack of SOLID_OBB support makes it near impossible to get it done decently. We have a version that is almost as good as it gets on Source, but we've decided not to put it in our game and rather change our gameplay since in complex geometry there will always be edge cases that spoil the fun. hth, -- Maarten -- [ Picked text/plain from multipart/alternative ] How could I rotate a player? I'm trying to get the player's model to rotate, e.i. if he's running on a wall it would show him as horizontally standing, not vertically. He would be perpendicular to the wall. Any ideas or suggestions would be nice. Thanks in advance :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
