InsideQC Forums

Posted: **Sat Mar 28, 2015 7:39 pm**

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 ?

Posted: **Sat Mar 28, 2015 8:05 pm**

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.

Posted: **Thu Apr 02, 2015 11:47 am**

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.

Posted: **Thu Apr 02, 2015 3:57 pm**

I have these

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;

I guess the engine gets points content collision differently

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
		{

that will detect the brush at the front...
im not sure what frag.machine is testing or just noticed something odd with traceline...

Posted: **Thu Apr 02, 2015 7:01 pm**

r00k wrote:im not sure what frag.machine is testing or just noticed something odd with traceline...

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.

InsideQC Forums

weird traceline behavior

weird traceline behavior

Re: weird traceline behavior

Re: weird traceline behavior

Re: weird traceline behavior

Re: weird traceline behavior