Re: [hlcoders] Creating a Sphere Trace
--
[ Picked text/plain from multipart/alternative ]
I think you misunderstood what I'm attempting. I'm trying to create a
Sphere Trace against the map planes, not entities. I probably should of put
that in the subject.
On 9/25/07, Ben Everett [EMAIL PROTECTED] wrote:
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,
CUtlVectorint *pOutput, int iContentsMask = 0x )
bool GetBrushInfo( int iBrush, CUtlVectorconst cplane_t * *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
--
___
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 tracked down the source of my issue. Someone once posted a bug fix
for jittery AI animations by changing
C_BaseEntity::PreDataUpdate( DataUpdateType_t updateType )
{
...
if ( !IsSelfAnimating() )
{
m_flAnimTime = engine-GetLastTimeStamp();
}
}
to
if ( IsSelfAnimating() )
Meanwhile, another fix courtesy of the official Wiki says to remove this
whole block of code (
http://developer.valvesoftware.com/wiki/SDK_Known_Issues_List#Animations_are_jittery
). Both of these fixes are wrong! m_flAnimTime needs to be set for the
weapons otherwise they'll act jittery when a new sequence is sent from
the server. The correct fix is as follows:
C_BaseEntity::PreDataUpdate( DataUpdateType_t updateType )
{
...
if ( !IsSelfAnimating() !IsNPC() )
{
m_flAnimTime = engine-GetLastTimeStamp();
}
}
Check and see if you've wrongly implemented one of the other incorrect
fixes like I had.
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
Re: [hlcoders] FW: SDK Needs to be fixed
--
[ Picked text/plain from multipart/alternative ]
I pointed this one out on hlcoders 14/8/06 and Yahn was the one who said to
remove the line entirely. The original suggested fix by me was to remove the
!
Regards,
Paul
On 9/26/07, Justin Krenz [EMAIL PROTECTED] wrote:
I tracked down the source of my issue. Someone once posted a bug fix
for jittery AI animations by changing
C_BaseEntity::PreDataUpdate( DataUpdateType_t updateType )
{
...
if ( !IsSelfAnimating() )
{
m_flAnimTime = engine-GetLastTimeStamp();
}
}
to
if ( IsSelfAnimating() )
Meanwhile, another fix courtesy of the official Wiki says to remove this
whole block of code (
http://developer.valvesoftware.com/wiki/SDK_Known_Issues_List#Animations_are_jittery
). Both of these fixes are wrong! m_flAnimTime needs to be set for the
weapons otherwise they'll act jittery when a new sequence is sent from
the server. The correct fix is as follows:
C_BaseEntity::PreDataUpdate( DataUpdateType_t updateType )
{
...
if ( !IsSelfAnimating() !IsNPC() )
{
m_flAnimTime = engine-GetLastTimeStamp();
}
}
Check and see if you've wrongly implemented one of the other incorrect
fixes like I had.
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
--
Re: [hlcoders] Creating a Sphere Trace
-- [ Picked text/plain from multipart/alternative ] Does physenv-CreateSphereObject do what you want? Check out CPhysSphere, which creates a sphere instead of using the models physics data. I'm assuming that, internally, creating a physics sphere this way will use fast sphere/plane intersection but Jay would know for sure. This way, you can make a spherical entity and handle collisions in VPhysicsCollision. It's not a trace but it might work for you depending on what you wanted to do with the trace. Regards, Paul On 9/25/07, Joel R. [EMAIL PROTECTED] wrote: -- [ 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, CUtlVectorint *pOutput, int iContentsMask = 0x ) bool GetBrushInfo( int iBrush, CUtlVectorconst cplane_t * *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 -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Creating a Sphere Trace
-- [ Picked text/plain from multipart/alternative ] I really don't like the Physics system due to the many limitations we have with it, including tracing. Which is why I want to build my own trace. I took a quick look at the Quake2 source code and they do a RecursiveHullTrace which I believe HL/HL2 uses, maybe if I mimic it and take into account the radius of my sphere I could get the trace I'm looking for. I'll have to test this method out and see how it pans out. If I do happen to get this trace working I'll be glad to share my results with the everyone. On 9/26/07, Paul Peloski [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] Does physenv-CreateSphereObject do what you want? Check out CPhysSphere, which creates a sphere instead of using the models physics data. I'm assuming that, internally, creating a physics sphere this way will use fast sphere/plane intersection but Jay would know for sure. This way, you can make a spherical entity and handle collisions in VPhysicsCollision. It's not a trace but it might work for you depending on what you wanted to do with the trace. Regards, Paul On 9/25/07, Joel R. [EMAIL PROTECTED] wrote: -- [ 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, CUtlVectorint *pOutput, int iContentsMask = 0x ) bool GetBrushInfo( int iBrush, CUtlVectorconst cplane_t * *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 -- ___ 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] Creating a Sphere Trace
Joel R. wrote: -- [ Picked text/plain from multipart/alternative ] I really don't like the Physics system due to the many limitations we have with it, including tracing. Which is why I want to build my own trace. I took a quick look at the Quake2 source code and they do a RecursiveHullTrace which I believe HL/HL2 uses, maybe if I mimic it and take into account the radius of my sphere I could get the trace I'm looking for. I'll have to test this method out and see how it pans out. If I do happen to get this trace working I'll be glad to share my results with the everyone. The last time I was into this, the Source SDK as we have it has no support for sweeping anything other than AABBs. Swept VCollides don't work (I forgot the name exactly), and physics tests only happen once per frame in static positions. Really a PITA when you're trying to do anything with unusual player movement (read: proning, vehicles). -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Re: FW: SDK Needs to be fixed
-- [ Picked text/plain from multipart/alternative ] Justin that a good little fix to know I might try putting that in out mod today to see what the difference is like..although with the official fix it seem pretty good to me. I'm just wondering if you are playing around with the NPC's then have you had the same issue I have had with combines not shooting correctly? Ive tried quite a few things but I'm still not able to get them to shoot unless my player is hidden behind a crate or something. all the source code for the changes I have made are on my website under http://www.adamdonovan.net/hl2coding.html Still trying to get them to fire..but it aint working..I planned to make a tutorial about it including modifying models to work as npc's and player models..cant do that unless I get them to work. any help still welcome adam _ NEW jobsjobsjobs.com.au. Find thousands of jobs online now! http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fad%2Eau%2Edoubleclick%2Enet%2Fclk%3B114014868%3B17770752%3Bi%3Fhttp%3A%2F%2Fwww%2Ejobsjobsjobs%2Ecom%2Eau_t=762242361_r=Hotmail_email_tagline_July07_m=EXT -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
