I am not sure if this is a bug or not.
Consider the situation in the image below, illustrating 2 tracelines fired against 2 different planes (A and B are the origins, and A' and B' the respective end positions set in trace_endpos):
At least in DP, I observed that for sky brushes, the trace_endpos vector is set in the exterior face of the brush! (which AFAIK shouldn't exist at all in a Q1BSP because it was supposed to be discarded since wasn't visible).
BTW the map in question was fully compiled and VISed with Bengt Jardrup's ports of QBSP and VIS, which AFAIK are reasonably updated and bug-free.
Now, this is not only weird, but goes against what I learned about Q1BSP's.
Can anyone explain me WTF is going on here ?
weird traceline behavior
-
- Posts: 2126
- Joined: Sat Nov 25, 2006 1:49 pm
weird traceline behavior
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC (LordHavoc)
Re: weird traceline behavior
solid > sky > outside > water > empty
(earlier versions of qbsp prioritised outside over sky)
impacts happen when it crosses nodes into a volume that is solid. sky is non-solid, so that's where it impacts, on the boundary between the sky and the outside/solid.
the qc can then use pointcontents to see if the impact happened within the sky volume, assuming the outside didn't flood into and consume the sky.
(earlier versions of qbsp prioritised outside over sky)
impacts happen when it crosses nodes into a volume that is solid. sky is non-solid, so that's where it impacts, on the boundary between the sky and the outside/solid.
the qc can then use pointcontents to see if the impact happened within the sky volume, assuming the outside didn't flood into and consume the sky.
Re: weird traceline behavior
Even though the point A' I guess is beyond the skybox, the traceline still considers that area not brushed with anything to be a solid? I believe watertype is -1 in those boundaries.
Re: weird traceline behavior
I have these
I guess the engine gets points content collision differently
that will detect the brush at the front...
im not sure what frag.machine is testing or just noticed something odd with traceline...
Code: Select all
// point content values
float CONTENT_EMPTY = -1;
float CONTENT_SOLID = -2;
float CONTENT_WATER = -3;
float CONTENT_SLIME = -4;
float CONTENT_LAVA = -5;
float CONTENT_SKY = -6;
Code: Select all
void () T_HookTouch =
{
if (clanring_state & CLANRING_MATCH_PAUSED)
return;
if ((other != self.owner))
{
if ((pointcontents (self.origin) == CONTENT_SKY) || (gameover))
{
HookVanish ();
return;
}
else
{
im not sure what frag.machine is testing or just noticed something odd with traceline...
-
- Posts: 2126
- Joined: Sat Nov 25, 2006 1:49 pm
Re: weird traceline behavior
This odd behavior was the cause of a bug in my procedural map code. As a temporary workaround, I am ensuring in my maps that I will always fire traceline() against solid walls. Maybe later I'll deal with this special case scenario, but for now this is good enough.r00k wrote:im not sure what frag.machine is testing or just noticed something odd with traceline...
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC (LordHavoc)