RE: [hlcoders] Creating a Sphere Trace
CEntitySphereQuery.
Example:
CBaseEntity *ent = NULL;
for (CEntitySphereQuery sphere(GetAbsOrigin(),
FORSAKEN_SPAWN_RADIUS);
(ent = sphere.GetCurrentEntity()) != NULL;
sphere.NextEntity())
{
CBaseEntity *plent = ent;
if ( plent && plent->IsPlayer() && plent != pPlayer
)
return false;
}
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Joel R.
Sent: Tuesday, September 25, 2007 5:40 PM
To: hlcoders
Subject: [hlcoders] Creating a Sphere Trace
--
[ Picked text/plain from multipart/alternative ]
I've been attempting to create my own sphere trace using 2 engine functions.
void GetBrushesInAABB( const Vector &vMins, const Vector &vMaxs,
CUtlVector *pOutput, int iContentsMask = 0x )
bool GetBrushInfo( int iBrush, CUtlVector *pPlanesOut, int
*pContentsOut )
I had 2 theories to go about doing this using a start/end point and a
radius.
First theory was to create a box around my start/end positions and grab all
plane data within the confines of this box.
I'd do something like so:
float d1 = (plane.dist - radius) - start;
float d2 = (plane.dist - radius) - end;
and using that to determine for a hit/miss based on the positive and
negative values of the distance. However surrounding a box around my
start/end would give me extra planes that'll give me a bunch of false
positives on planes that are very tiny, since this algorithm is used for
infinite sized planes..
Second theory was to slide the box in intervals and check for planes at each
interval with a mins/max box the size of my radius. Then back checking the
distance to see if I hit or penetrated any planes within.
Both of these methods seem to not work after thinking about different
possibilities that could arise due to the infinite sized plane algorithm. I
then noticed there was extra values in the cplane_t structure that I'm not
very familiar with: cplane_t::signbit and cplane_t::type. What purpose do
these serve for the plane? Do they help determine if I'm within the planes
constrictions for a collision?
Anyone out there familiar with collision detection could help me out? I'd
really like to have a sphere trace.
--
___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
__ NOD32 2550 (20070925) Information __
This message was checked by NOD32 antivirus system.
http://www.eset.com
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] FW: SDK Needs to be fixed
Yeah, you're right. I tried the base SDK and an old version from a year
ago, and both didn't have the problem. I'm pretty sure I introduced the
bug when I updated to the last major sdk update.
Yahn Bernier wrote:
Well, I'm 100% sure we don't have this bug in our current codebase. So
probably when the SDK gets imaged from it the bug will be fixed for all.
Yahn
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Nick
Sent: Tuesday, September 25, 2007 7:13 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] FW: SDK Needs to be fixed
These bugs scare me, if neither Valve nor the more experienced coders
can fix them. What hope is there for the rest of us less experienced
coders?
On 9/25/07, Justin Krenz <[EMAIL PROTECTED]> wrote:
It seems that fix only comes into play when getting an attachment from
the local weapon. My problem is elsewhere as it happens during all
animations. Is anyone else experiencing my problem? I suppose I
should create a new base sdk mod and see if it happens there too to
make sure it's not something I've broken, but I know it's not
occurring in the HL2DM sdk.
Yahn Bernier wrote:
This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ] There is another
bug fix which will go into the Orange Box version of the SDK related
to the view models "replaying" part of their previous animation.
(And there are a few other fixes which explain why cl_showerror is
overly spammy on m_nTickBase/m_vecOrigin errors for the local
player).
It's due to the interaction of the sequence blending code with the
networking and prediction systems. To fix, we had to make the
following change (new code in red) in c_baseanimating.cpp:
//--
---
// Purpose: if the active sequence changes, keep track of the
previous ones and decay them based on their decay rate
//--
---
void C_BaseAnimating::MaintainSequenceTransitions( CStudioHdr *hdr,
float flCycle, float flPoseParameter[], Vector pos[], Quaternion
q[], int boneMask ) {
VPROF( "C_BaseAnimating::MaintainSequenceTransitions" );
if ( !hdr )
return;
if ( prediction->InPrediction() )
{
m_nPrevNewSequenceParity = m_nNewSequenceParity;
return;
}
Give that a try and see if it fixes your issue
(You'll need to include "prediction.h" in the .cpp file, too)
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Justin
Krenz
Sent: Tuesday, September 25, 2007 5:00 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] FW: SDK Needs to be fixed
Yeah, I'm ashamed for all of us that we didn't find this sooner. :P
Tell me how this fix works for you. It fixes the issues I was
having with glitchy shoot animations and of course the shoot
animations occurring over twice as fast for rapid fire weapons.
However, I'm still getting a jittering in the animations when
deploying the weapon and with net_fakelag set to at least 100. This
doesn't occur in the HL2DM SDK, and doing a cl_pdump of the
predicted view model and the weapon itself shows that everything is
exactly the same. The jittering occurs right when the client
receives the new m_nSequence at the bottom of
baseviewmodel_shared.cpp via the recvproxy.
Are you experiencing this same problem?
Tony "omega" Sergi wrote:
--
[ Picked text/plain from multipart/alternative ] Wow, great catch
man.
I didn't even notice that!
-Tony
On 9/25/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Great News if this is the case. :P
--
___
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 vi
RE: [hlcoders] FW: SDK Needs to be fixed
Well, I'm 100% sure we don't have this bug in our current codebase. So
probably when the SDK gets imaged from it the bug will be fixed for all.
Yahn
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Nick
Sent: Tuesday, September 25, 2007 7:13 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] FW: SDK Needs to be fixed
These bugs scare me, if neither Valve nor the more experienced coders
can fix them. What hope is there for the rest of us less experienced
coders?
On 9/25/07, Justin Krenz <[EMAIL PROTECTED]> wrote:
> It seems that fix only comes into play when getting an attachment from
> the local weapon. My problem is elsewhere as it happens during all
> animations. Is anyone else experiencing my problem? I suppose I
> should create a new base sdk mod and see if it happens there too to
> make sure it's not something I've broken, but I know it's not
> occurring in the HL2DM sdk.
>
> Yahn Bernier wrote:
> > This is a multi-part message in MIME format.
> > --
> > [ Picked text/plain from multipart/alternative ] There is another
> > bug fix which will go into the Orange Box version of the SDK related
> > to the view models "replaying" part of their previous animation.
> > (And there are a few other fixes which explain why cl_showerror is
> > overly spammy on m_nTickBase/m_vecOrigin errors for the local
> > player).
> >
> > It's due to the interaction of the sequence blending code with the
> > networking and prediction systems. To fix, we had to make the
> > following change (new code in red) in c_baseanimating.cpp:
> >
> > //--
> >
> > ---
> > // Purpose: if the active sequence changes, keep track of the
> > previous ones and decay them based on their decay rate
> > //--
> >
> > ---
> > void C_BaseAnimating::MaintainSequenceTransitions( CStudioHdr *hdr,
> > float flCycle, float flPoseParameter[], Vector pos[], Quaternion
> > q[], int boneMask ) {
> > VPROF( "C_BaseAnimating::MaintainSequenceTransitions" );
> >
> > if ( !hdr )
> > return;
> >
> > if ( prediction->InPrediction() )
> > {
> > m_nPrevNewSequenceParity = m_nNewSequenceParity;
> > return;
> > }
> >
> > Give that a try and see if it fixes your issue
> >
> > (You'll need to include "prediction.h" in the .cpp file, too)
> >
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of Justin
> > Krenz
> > Sent: Tuesday, September 25, 2007 5:00 PM
> > To: hlcoders@list.valvesoftware.com
> > Subject: Re: [hlcoders] FW: SDK Needs to be fixed
> >
> > Yeah, I'm ashamed for all of us that we didn't find this sooner. :P
> >
> > Tell me how this fix works for you. It fixes the issues I was
> > having with glitchy shoot animations and of course the shoot
> > animations occurring over twice as fast for rapid fire weapons.
> > However, I'm still getting a jittering in the animations when
> > deploying the weapon and with net_fakelag set to at least 100. This
> > doesn't occur in the HL2DM SDK, and doing a cl_pdump of the
> > predicted view model and the weapon itself shows that everything is
> > exactly the same. The jittering occurs right when the client
> > receives the new m_nSequence at the bottom of
baseviewmodel_shared.cpp via the recvproxy.
> >
> > Are you experiencing this same problem?
> >
> >
> > Tony "omega" Sergi wrote:
> >> --
> >> [ Picked text/plain from multipart/alternative ] Wow, great catch
man.
> >
> >> I didn't even notice that!
> >> -Tony
> >>
> >> On 9/25/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >>> Great News if this is the case. :P
> >>>
> >>>
> >> --
> >>
> >> ___
> >> 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
vi
Re: [hlcoders] FW: SDK Needs to be fixed
--
[ Picked text/plain from multipart/alternative ]
Fixing the bug isn't the issue... its tracking down the exact cause.
On 9/26/07, Nick <[EMAIL PROTECTED]> wrote:
>
> These bugs scare me, if neither Valve nor the more experienced coders
> can fix them. What hope is there for the rest of us less experienced
> coders?
>
> On 9/25/07, Justin Krenz <[EMAIL PROTECTED]> wrote:
> > It seems that fix only comes into play when getting an attachment from
> > the local weapon. My problem is elsewhere as it happens during all
> > animations. Is anyone else experiencing my problem? I suppose I should
> > create a new base sdk mod and see if it happens there too to make sure
> > it's not something I've broken, but I know it's not occurring in the
> > HL2DM sdk.
> >
> > Yahn Bernier wrote:
> > > This is a multi-part message in MIME format.
> > > --
> > > [ Picked text/plain from multipart/alternative ]
> > > There is another bug fix which will go into the Orange Box version of
> > > the SDK related to the view models "replaying" part of their previous
> > > animation. (And there are a few other fixes which explain why
> > > cl_showerror is overly spammy on m_nTickBase/m_vecOrigin errors for
> the
> > > local player).
> > >
> > > It's due to the interaction of the sequence blending code with the
> > > networking and prediction systems. To fix, we had to make the
> following
> > > change (new code in red) in c_baseanimating.cpp:
> > >
> > >
> //--
> > > ---
> > > // Purpose: if the active sequence changes, keep track of the previous
> > > ones and decay them based on their decay rate
> > >
> //--
> > > ---
> > > void C_BaseAnimating::MaintainSequenceTransitions( CStudioHdr *hdr,
> > > float flCycle, float flPoseParameter[], Vector pos[], Quaternion q[],
> > > int boneMask )
> > > {
> > > VPROF( "C_BaseAnimating::MaintainSequenceTransitions" );
> > >
> > > if ( !hdr )
> > > return;
> > >
> > > if ( prediction->InPrediction() )
> > > {
> > > m_nPrevNewSequenceParity = m_nNewSequenceParity;
> > > return;
> > > }
> > >
> > > Give that a try and see if it fixes your issue
> > >
> > > (You'll need to include "prediction.h" in the .cpp file, too)
> > >
> > > -Original Message-
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED] On Behalf Of Justin
> Krenz
> > > Sent: Tuesday, September 25, 2007 5:00 PM
> > > To: hlcoders@list.valvesoftware.com
> > > Subject: Re: [hlcoders] FW: SDK Needs to be fixed
> > >
> > > Yeah, I'm ashamed for all of us that we didn't find this sooner. :P
> > >
> > > Tell me how this fix works for you. It fixes the issues I was having
> > > with glitchy shoot animations and of course the shoot animations
> > > occurring over twice as fast for rapid fire weapons. However, I'm
> still
> > > getting a jittering in the animations when deploying the weapon and
> with
> > > net_fakelag set to at least 100. This doesn't occur in the HL2DM SDK,
> > > and doing a cl_pdump of the predicted view model and the weapon itself
> > > shows that everything is exactly the same. The jittering occurs right
> > > when the client receives the new m_nSequence at the bottom of
> > > baseviewmodel_shared.cpp via the recvproxy.
> > >
> > > Are you experiencing this same problem?
> > >
> > >
> > > Tony "omega" Sergi wrote:
> > >> --
> > >> [ Picked text/plain from multipart/alternative ] Wow, great catch
> man.
> > >
> > >> I didn't even notice that!
> > >> -Tony
> > >>
> > >> On 9/25/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > >>> Great News if this is the case. :P
> > >>>
> > >>>
> > >> --
> > >>
> > >> ___
> > >> 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
>
>
--
Matt Stafford (Wraiyth)
http://www.wraiyth.com
NightFall HL2 Mod - http://www.nightfallmod.com
Re: [hlcoders] FW: SDK Needs to be fixed
These bugs scare me, if neither Valve nor the more experienced coders
can fix them. What hope is there for the rest of us less experienced
coders?
On 9/25/07, Justin Krenz <[EMAIL PROTECTED]> wrote:
> It seems that fix only comes into play when getting an attachment from
> the local weapon. My problem is elsewhere as it happens during all
> animations. Is anyone else experiencing my problem? I suppose I should
> create a new base sdk mod and see if it happens there too to make sure
> it's not something I've broken, but I know it's not occurring in the
> HL2DM sdk.
>
> Yahn Bernier wrote:
> > This is a multi-part message in MIME format.
> > --
> > [ Picked text/plain from multipart/alternative ]
> > There is another bug fix which will go into the Orange Box version of
> > the SDK related to the view models "replaying" part of their previous
> > animation. (And there are a few other fixes which explain why
> > cl_showerror is overly spammy on m_nTickBase/m_vecOrigin errors for the
> > local player).
> >
> > It's due to the interaction of the sequence blending code with the
> > networking and prediction systems. To fix, we had to make the following
> > change (new code in red) in c_baseanimating.cpp:
> >
> > //--
> > ---
> > // Purpose: if the active sequence changes, keep track of the previous
> > ones and decay them based on their decay rate
> > //--
> > ---
> > void C_BaseAnimating::MaintainSequenceTransitions( CStudioHdr *hdr,
> > float flCycle, float flPoseParameter[], Vector pos[], Quaternion q[],
> > int boneMask )
> > {
> > VPROF( "C_BaseAnimating::MaintainSequenceTransitions" );
> >
> > if ( !hdr )
> > return;
> >
> > if ( prediction->InPrediction() )
> > {
> > m_nPrevNewSequenceParity = m_nNewSequenceParity;
> > return;
> > }
> >
> > Give that a try and see if it fixes your issue
> >
> > (You'll need to include "prediction.h" in the .cpp file, too)
> >
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of Justin Krenz
> > Sent: Tuesday, September 25, 2007 5:00 PM
> > To: hlcoders@list.valvesoftware.com
> > Subject: Re: [hlcoders] FW: SDK Needs to be fixed
> >
> > Yeah, I'm ashamed for all of us that we didn't find this sooner. :P
> >
> > Tell me how this fix works for you. It fixes the issues I was having
> > with glitchy shoot animations and of course the shoot animations
> > occurring over twice as fast for rapid fire weapons. However, I'm still
> > getting a jittering in the animations when deploying the weapon and with
> > net_fakelag set to at least 100. This doesn't occur in the HL2DM SDK,
> > and doing a cl_pdump of the predicted view model and the weapon itself
> > shows that everything is exactly the same. The jittering occurs right
> > when the client receives the new m_nSequence at the bottom of
> > baseviewmodel_shared.cpp via the recvproxy.
> >
> > Are you experiencing this same problem?
> >
> >
> > Tony "omega" Sergi wrote:
> >> --
> >> [ Picked text/plain from multipart/alternative ] Wow, great catch man.
> >
> >> I didn't even notice that!
> >> -Tony
> >>
> >> On 9/25/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >>> Great News if this is the case. :P
> >>>
> >>>
> >> --
> >>
> >> ___
> >> 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] FW: SDK Needs to be fixed
It seems that fix only comes into play when getting an attachment from
the local weapon. My problem is elsewhere as it happens during all
animations. Is anyone else experiencing my problem? I suppose I should
create a new base sdk mod and see if it happens there too to make sure
it's not something I've broken, but I know it's not occurring in the
HL2DM sdk.
Yahn Bernier wrote:
This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
There is another bug fix which will go into the Orange Box version of
the SDK related to the view models "replaying" part of their previous
animation. (And there are a few other fixes which explain why
cl_showerror is overly spammy on m_nTickBase/m_vecOrigin errors for the
local player).
It's due to the interaction of the sequence blending code with the
networking and prediction systems. To fix, we had to make the following
change (new code in red) in c_baseanimating.cpp:
//--
---
// Purpose: if the active sequence changes, keep track of the previous
ones and decay them based on their decay rate
//--
---
void C_BaseAnimating::MaintainSequenceTransitions( CStudioHdr *hdr,
float flCycle, float flPoseParameter[], Vector pos[], Quaternion q[],
int boneMask )
{
VPROF( "C_BaseAnimating::MaintainSequenceTransitions" );
if ( !hdr )
return;
if ( prediction->InPrediction() )
{
m_nPrevNewSequenceParity = m_nNewSequenceParity;
return;
}
Give that a try and see if it fixes your issue
(You'll need to include "prediction.h" in the .cpp file, too)
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Justin Krenz
Sent: Tuesday, September 25, 2007 5:00 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] FW: SDK Needs to be fixed
Yeah, I'm ashamed for all of us that we didn't find this sooner. :P
Tell me how this fix works for you. It fixes the issues I was having
with glitchy shoot animations and of course the shoot animations
occurring over twice as fast for rapid fire weapons. However, I'm still
getting a jittering in the animations when deploying the weapon and with
net_fakelag set to at least 100. This doesn't occur in the HL2DM SDK,
and doing a cl_pdump of the predicted view model and the weapon itself
shows that everything is exactly the same. The jittering occurs right
when the client receives the new m_nSequence at the bottom of
baseviewmodel_shared.cpp via the recvproxy.
Are you experiencing this same problem?
Tony "omega" Sergi wrote:
--
[ Picked text/plain from multipart/alternative ] Wow, great catch man.
I didn't even notice that!
-Tony
On 9/25/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Great News if this is the case. :P
--
___
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] FW: SDK Needs to be fixed
This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
There is another bug fix which will go into the Orange Box version of
the SDK related to the view models "replaying" part of their previous
animation. (And there are a few other fixes which explain why
cl_showerror is overly spammy on m_nTickBase/m_vecOrigin errors for the
local player).
It's due to the interaction of the sequence blending code with the
networking and prediction systems. To fix, we had to make the following
change (new code in red) in c_baseanimating.cpp:
//--
---
// Purpose: if the active sequence changes, keep track of the previous
ones and decay them based on their decay rate
//--
---
void C_BaseAnimating::MaintainSequenceTransitions( CStudioHdr *hdr,
float flCycle, float flPoseParameter[], Vector pos[], Quaternion q[],
int boneMask )
{
VPROF( "C_BaseAnimating::MaintainSequenceTransitions" );
if ( !hdr )
return;
if ( prediction->InPrediction() )
{
m_nPrevNewSequenceParity = m_nNewSequenceParity;
return;
}
Give that a try and see if it fixes your issue
(You'll need to include "prediction.h" in the .cpp file, too)
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Justin Krenz
Sent: Tuesday, September 25, 2007 5:00 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] FW: SDK Needs to be fixed
Yeah, I'm ashamed for all of us that we didn't find this sooner. :P
Tell me how this fix works for you. It fixes the issues I was having
with glitchy shoot animations and of course the shoot animations
occurring over twice as fast for rapid fire weapons. However, I'm still
getting a jittering in the animations when deploying the weapon and with
net_fakelag set to at least 100. This doesn't occur in the HL2DM SDK,
and doing a cl_pdump of the predicted view model and the weapon itself
shows that everything is exactly the same. The jittering occurs right
when the client receives the new m_nSequence at the bottom of
baseviewmodel_shared.cpp via the recvproxy.
Are you experiencing this same problem?
Tony "omega" Sergi wrote:
> --
> [ Picked text/plain from multipart/alternative ] Wow, great catch man.
> I didn't even notice that!
> -Tony
>
> On 9/25/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> Great News if this is the case. :P
>>
>>
> --
>
> ___
> 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] FW: SDK Needs to be fixed
Yeah, I'm ashamed for all of us that we didn't find this sooner. :P Tell me how this fix works for you. It fixes the issues I was having with glitchy shoot animations and of course the shoot animations occurring over twice as fast for rapid fire weapons. However, I'm still getting a jittering in the animations when deploying the weapon and with net_fakelag set to at least 100. This doesn't occur in the HL2DM SDK, and doing a cl_pdump of the predicted view model and the weapon itself shows that everything is exactly the same. The jittering occurs right when the client receives the new m_nSequence at the bottom of baseviewmodel_shared.cpp via the recvproxy. Are you experiencing this same problem? Tony "omega" Sergi wrote: -- [ Picked text/plain from multipart/alternative ] Wow, great catch man. I didn't even notice that! -Tony On 9/25/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Great News if this is the case. :P -- ___ 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] Creating a Sphere Trace
-- [ Picked text/plain from multipart/alternative ] I've been attempting to create my own sphere trace using 2 engine functions. void GetBrushesInAABB( const Vector &vMins, const Vector &vMaxs, CUtlVector *pOutput, int iContentsMask = 0x ) bool GetBrushInfo( int iBrush, CUtlVector *pPlanesOut, int *pContentsOut ) I had 2 theories to go about doing this using a start/end point and a radius. First theory was to create a box around my start/end positions and grab all plane data within the confines of this box. I'd do something like so: float d1 = (plane.dist - radius) - start; float d2 = (plane.dist - radius) - end; and using that to determine for a hit/miss based on the positive and negative values of the distance. However surrounding a box around my start/end would give me extra planes that'll give me a bunch of false positives on planes that are very tiny, since this algorithm is used for infinite sized planes.. Second theory was to slide the box in intervals and check for planes at each interval with a mins/max box the size of my radius. Then back checking the distance to see if I hit or penetrated any planes within. Both of these methods seem to not work after thinking about different possibilities that could arise due to the infinite sized plane algorithm. I then noticed there was extra values in the cplane_t structure that I'm not very familiar with: cplane_t::signbit and cplane_t::type. What purpose do these serve for the plane? Do they help determine if I'm within the planes constrictions for a collision? Anyone out there familiar with collision detection could help me out? I'd really like to have a sphere trace. -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] FW: SDK Needs to be fixed
-- [ Picked text/plain from multipart/alternative ] Wow, great catch man. I didn't even notice that! -Tony On 9/25/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Great News if this is the case. :P > > -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] FW: SDK Needs to be fixed
Great News if this is the case. :P ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] FW: SDK Needs to be fixed
I'm glad you brought this topic back up, and I've found the definite
fix. The original problem was that weapons would shoot too fast, but
I've been encountering a problem where weapon animations are just plain
glitchy when not at a sub 50 ping. Both of these problems are only
evident in the base SDK and not the HL2 DM SDK. Your moving the
m_flNextPrimaryAttack variable into the player is an interesting hint at
the real source of the problem, but the problem is not due to anything
about how networked data is updated or received. The problem is that no
weapons are being predicted!
If you put "cl_predictionlist" in the console, it will print a list of
all entities in the world that are being predicted. If you run in HL2
DM, the list is something along the lines of player, view model, and
player weapons. However, if you look at the list in a base SDK mod,
only the player and view model are listed. That's because your weapons
aren't being predicted. The reason they're not predicted is because
CWeaponSDKBase does not override C_BaseEntity's ShouldPredict() function
to tell the game to predict the weapons. In the HL2 DM sdk, the weapons
are derived from CWeaponHL2MPBase which overrides ShouldPredict() and
returning true if the local player is the one holding the weapon.
How to fix this bug:
In weapon_sdkbase.h, add:
#ifdef CLIENT_DLL
virtual bool ShouldPredict();
#endif
In weapon_sdkbase.cpp, add:
#ifdef CLIENT_DLL
bool CWeaponSDKBase::ShouldPredict()
{
if ( GetOwner() && GetOwner() == C_BasePlayer::GetLocalPlayer())
return true;
return BaseClass::ShouldPredict();
}
#endif
Tony "omega" Sergi wrote:
--
[ Picked text/plain from multipart/alternative ]
I was thinking about it and talking in irc briefly with Joel about it, and I
think it may simply have to do with the order of networking, and the way the
prediction works.
Whereas, (Someone at valve, correct me if i'm wrong, but it appears this is
what's happening)
Player networking is processed, player is simulated on the client for
prediction, which calls into the weapons; m_flNextPrimaryFire is still in
the past for every single one of these prediction calls, so the weapon keeps
firing.
weapon entities now update and receive networked data, and have the correct
time. oops, too late, player handles the firing!
so effectively, putting it in the player, allows the weapon code which is
totally HANDLED by the player, to predict properly, since the physical
weapon entity is nothing more than a seperate data container with custom
functions. that the player manipulates every bit of. -- effectively an
extension.
So thus, the solution appears to be store anything that you need to be
accurate, on the player and NOT the weapon, even if only one particular
weapon needs it. (Hell, abuse the send proxy abilities and add seperate
tables that get sent through the player when and only when the player has
that particular weapon)
-Tony
On 9/17/07, Jonathan Murphy <[EMAIL PROTECTED]> wrote:
--
[ Picked text/plain from multipart/alternative ]
Interesting omega, might need to try it in RnL as I think we have this
problem on occasion too.
On 9/18/07, Tony omega Sergi <[EMAIL PROTECTED]> wrote:
--
[ Picked text/plain from multipart/alternative ]
Bringing back an old topic, because I am having this issue too.
However, I seem to have solved it, I don't know WHY this solves it
(unless
it has to do with the prediction after all!)
I moved all my weapon timers (m_flNextPrimaryAttack / secondary) into
the
PLAYER.
so in CSDKPlayer / C_SDKPlayer i have m_flNextPrimaryFire and
m_flNextSecondaryFire, it's networked exactly the same as the
basecombatweapon one, with the same DEFINE_PRED_FIELD_TOL values on the
client.
i put it in public so i can just do pPlayer->m_flNextPrimaryFire etc.
did
a
find in replace for all my weapons, tested with fakelag, bug gone.
My guess is because of the way the prediction works, it's predicting the
player fine, but not other entities attached to the player.
*shrug*
at least this works without any 'hacks'.
oh and i send it as localplayer exlusive.
On 4/19/07, Yahn Bernier <[EMAIL PROTECTED]> wrote:
I'll take a closer look at this since it's in the vanilla SDK.
Yahn
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Garry
Newman
Sent: Thursday, April 19, 2007 7:49 AM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] FW: SDK Needs to be fixed
I think I might have seen this in GMod. Does it happen more when
you're
jumping?
On 4/19/07, Mark Chandler <[EMAIL PROTECTED]> wrote:
Here is some videos that I took over the last couple of days to show
you the bug.
Hidden:
http://lodle.net/mf/ hidden.avi
Golden Eye Dev:
http://lodle.net/mf/ges.avi
NimMod:
http://lodle.net/mf/NimMod.avi
Plan Of Attack:
http://lodle.net/mf/planofattack.avi
Empires:
http://lodle.net/mf/empires.avi
Codec is 3ivx.
-Original Message-
From: [EMAIL PROTE
RE: [hlcoders] Engine Plugin Interface Problems
[ Converted text/html to text/plain ]
plugins dont need a full sdk. We just need to know what happend to the
interfaces that plugins use. Hopefully a min update can come to allow us
update our plugins. Perhaps someone from valve could email us offlist with the
changes, im sure most of us are willing to accept that there will be changes
untill the sdk but some information on the interfaces would allow us to fix
the plugins.
Best Regards
Erling K. Sæterdal
http://www.thexsoft.com/index.php?page=basic-admin-tool[1]
On Tue Sep 25 5:38 , 'Mark Chandler' sent:
Mike said around 4 weeks after tf2 comes out (8th October)
-Original Message-
From: [EMAIL PROTECTED]
[EMAIL PROTECTED]','','','')">[EMAIL PROTECTED]
On Behalf Of
[EMAIL PROTECTED]
Sent: Tuesday, September 25, 2007 1:23 PM
To: [EMAIL PROTECTED]
Subject: Re: [hlcoders] Engine Plugin Interface Problems
Hello,
so we have to wait on OrangeBox and Port the plugin to get this problem
fixed? Or
is there the same problem right now?
Is there a date for the OrangeBox SDK?
Will it be a new SDK or gets the Source SDK Updated?
Can you send us a "example", what we have to change to get Orange Box
compatible?
And after the Orange Box is released and CS:S is Portet, will CS:S stay on
the old Source
Engine or get this old Engine deleted?
Thanks!
With friendly Reguards
Ratman2000
- Original Message -
From: "Mike Durand" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, September 24, 2007 11:33 PM
Subject: RE: [hlcoders] Engine Plugin Interface Problems
> We've found the root cause of the problem, but with the release of
> Orange Box haven't had a chance to implement a solution yet.
>
> -Mike
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [EMAIL PROTECTED]','','','')">[EMAIL PROTECTED]
On Behalf Of Tony Paloma
> Sent: Monday, September 24, 2007 2:08 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [hlcoders] Engine Plugin Interface Problems
>
> Mike Durand has told me at least twice that he would look into this. At
> one
> point, I believe somebody at Valve said they may have found the issue. I
> have not heard anything about it since.
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [EMAIL PROTECTED]','','','')">[EMAIL PROTECTED]
On Behalf Of
> [EMAIL PROTECTED]
> Sent: Monday, September 24, 2007 12:16 PM
> To: [EMAIL PROTECTED]
> Subject: [hlcoders] Engine Plugin Interface Problems
>
> Hello,
>
> i have a big Problem...
>
> I need to unload my Plugin and load it again.
> After i have unloaded the plugin i delete the *.so file and
> copy a new version to this position...
>
> But when i than load the plugin again (without restart the server)
> the old plugin version gets loaded so i think, that the plugin get
> loaded
> from memmory...
>
> Is there any way, to delete all content like cvars and other by
> unloading
> the plugin so i can load a newer version without restart the server?
>
> Thanks
>
> With friendly reguards
>
> Ratman2000
>
> - Original Message -
> From: "Ratman2000" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, September 12, 2007 10:51 AM
> Subject: Re: [hlcoders] Error in Query Protocoll ???
>
>
> > Hello,
> >
> > yes the select supports UDP Sockets... becouse it uses the descriptors
> to
> > read the state.
> >
> > How can i check the 4 Bytes?
> >
> > My problem is, that i dont get 2 Packets, so the first packet i have
> > recieved isnt ok and
> > there are nothing following...
> >
> > You know what i am meaning?
> >
> > With friendly Reguards
> >
> > Ratman2000
> >
> > - Original Message -
> > From: "Ronny Schedel" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Wednesday, September 12, 2007 11:24 AM
> > Subject: Re: [hlcoders] Error in Query Protocoll ???
> >
> >
> > > Hello,
> > >
> > > check the first 4 Bytes response
> > >
> > > FF FF FF FF means: only one packet is send
> > > FE FF FF FF means: it is a multipacket response
> > >
> > > Use the packet ID to sort the packets and to check which packets are
> > > missing.
> > >
> > > To understand what you got, save every packet to a new file and take
> a
> > look
> > > with a hex editor/viewer.
> > >
> > > Check the select() documentation to figure out if it really support
> UDP
> > > sockets or not, as far as I remember it does not, but I could be
> wrong.
> > >
> > > Best regards
> > >
> > > Ronny Schedel
> > >
> > > >
> > > > Hello,
> > > >
> > > > i have tested this and have tested to recieve another packet but i
> dont
> > > get
> > > > any...
> > > >
> > > > My code after i have connected i send the request and recieve it
> with
> > this
> > > > function:
> > > >
> > > > FD_ZERO( &ReadSet );
> > > > FD_SET( Socket, &ReadSet );
> > > > timeVal.tv_sec = 1;
> > > > timeVal.tv_usec = 0;
> > > >
> > > > for ( int i = 1; i <= 3; i++ )
> > > > {
> > > > if ( select( Socket+1, &ReadSet, NULL, NULL, &timeVal
> ) ==
> > 1 )
> > > > {
> > > > if ( FD_ISSET( Socket, &ReadSet ) )
> > > > {
> > > > bytes = recv( Socket, buffe
