Check spawn (utility)

[Cobalt]

Forgot I wrote this , and not sure if there are any better ones out there, but I was trying to confirm a spawn spot on a map is a safe spot for the player to spawn at without conflicting with a solid, or being in lava or other hazard.....but its flagging alot of known good spawn spots as bad when I run it on several of the id maps, can anyone improve it?

Code: Select all

float (vector org) IsGoodSpawnPoint =
{
local float pos;
pos = (pointcontents(org));

	if (pos != -1 || pos != -3)
	{
		return (FALSE);
	}
	if ((pointcontents ((org + '16 16 -24')) != -1))
	{
		return (FALSE);
	}
	if ((pointcontents ((org + VEC_HULL_MIN)) != -1))
	{
		return (FALSE);
	}
	if ((pointcontents ((org + '16 -16 -24')) != -1))
	{
		return (FALSE);
	}
	if ((pointcontents ((org + '-16 16 -24')) != -1))
	{
		return (FALSE);
	}
	if ((pointcontents ((org + VEC_HULL_MAX)) != -1))
	{
		return (FALSE);
	}
	if ((pointcontents ((org + '-16 -16 32')) != -1))
	{
		return (FALSE);
	}
	if ((pointcontents ((org + '-16 16 32')) != -1))
	{
		return (FALSE);
	}
	if ((pointcontents ((org + '16 -16 32')) != -1))
	{
		return (FALSE);
	}
	return (TRUE);
};

[Spike]

I would use tracebox.
droptofloor would also work if you want to avoid extensions, but is more messy.

if (pos != -1 || pos != -3)

if its -1 then its not -3 and the function will return false, and vice versa.

[Cobalt]

Ah, righto. I like droptofloor() idea. I guess droptofloor would return false if we tried it on a spot over lave or slime , or water for that matter?
Checkbottom - probably no.

Maybe devising a score system depending on these checks would calibrate it more accurately? Also, could put the call to this function in any of the Quaked functions themselves - deathmatch, coop or teleport destinations...and if check fails, do a remove (self) on them...or disable the reverse targets teleoprter....

As for tracebox, also good idea. I searched around here, and saw you helped with it once before....code I found is:

Code: Select all

tracebox(self.origin, self.mins, self.maxs, self.origin + '0 0 -1', FALSE, self);
 if (trace_fraction < 1 && trace_plane_normal_z > 0.7) // we're on ground, and not on a slope too steep

Its a start, but it was for problems with the movetypes and slopes....will have to be modified.

I would use tracebox.
droptofloor would also work if you want to avoid extensions, but is more messy.

if (pos != -1 || pos != -3)

if its -1 then its not -3 and the function will return false, and vice versa.

[Spike]

with tracebox, use start==end and check trace_startsolid after the call to see if the box is empty. Its basically an oversized pointcontents when used that way.

[Cobalt]

Ok tried that.....but seems after the check for startsolid, its never detecting. Do I need to perhaps set a model to the entity and then a setsize?
I suppose we could set the player model into the spawn spot with a temp entity and the default setsize of the player model.....

with tracebox, use start==end and check trace_startsolid after the call to see if the box is empty. Its basically an oversized pointcontents when used that way.

[Cobalt]

Ok, Thanks to Lord Havoc for the help. Came up with:

Code: Select all

tracebox(self.origin, '-16 -16 0', '16 16 32', self.origin, FALSE, self);
       if (trace_startsolid || !droptofloor (self))
	{
                 // For debugging....
	//SpawnMarker (self.origin, 240); 
	//self.effects = EF_BRIGHTFIELD;
	return (FALSE);
	}

	return (TRUE);

seems to be flagging them correctly so far. No need for the score system either.

[Baker]

Code: Select all

tracebox(self.origin, '-16 -16 0', '16 16 32', self.origin, FALSE, self);

1 out of 6 of those numbers do not look right to me ..

// Player hull which is hull 1
VectorSet (hull->clip_mins, -16, -16, -24);
VectorSet (hull->clip_maxs, 16, 16, 32);

I'm thinking if you are using the normal Quake guy, you would want '-16 -16 -24' and not '-16 -16 0' if I am understanding what you are doing correctly.

[Note: I like this thread because I've wondered this one myself.]

[frag.machine]

You're right Baker, player default height is 56 units.

[Cobalt]

Yes, I had tried the -24 value and it always seemed to fail. If I understand the tracing function, -24 puts us beneath the origin of the self entity and in this case I am working with teleport_destinations, to see if they are good. So far they all seem to be just a bit above the ground, though the spawn code for them sets their self.origin 27 units higher via self.origin , but its not actually using setorigin, so I dont think that is enough to change its origin....because if I spawn a test bubble sprite there, its pretty close to the floor always....not 27 units higher. Tricky stuff these spawns. But from what I understand, the tracebox will draw a box from self.origin 16 units in each dfirection x and y, then for the z coordinates, it will not start at -24 units below self.origin, rather its at self.origin, and draw to 32 units above self.origin_z. I could be wrong though? Lord Havoc says there are only 3 sizes: point, player and shambler.....?

The other bummer I forgot about is that droptofloor() no matter how its called, drops the self entity to the floor you are executing the code in.

Code: Select all

tracebox(self.origin, '-16 -16 0', '16 16 32', self.origin, FALSE, self);

1 out of 6 of those numbers do not look right to me ..

// Player hull which is hull 1
VectorSet (hull->clip_mins, -16, -16, -24);
VectorSet (hull->clip_maxs, 16, 16, 32);

I'm thinking if you are using the normal Quake guy, you would want '-16 -16 -24' and not '-16 -16 0' if I am understanding what you are doing correctly.

[Note: I like this thread because I've wondered this one myself.]

[Spike]

bsp collisions are aligned to origin+mins. if you change the mins, you _move_ the entire bbox. this allows you to have monsters of different heights but still firmly keep its feet on the ground. projectiles will still hit the proper bbox, but you might see their head poke into the ceiling in certain areas.

tracebox calls must use the same .mins of the object that will be in that space that you're trying to trace through, or its results are unreliable.

beware of this in info_teleport_destination.
self.origin = self.origin + '0 0 27';
and this in PutClientInServer
self.origin = spot.origin + '0 0 1';
in either case, the position of the object as seen in the map editor is not entirely correct, and your tracebox must be aware of the offsets or the box will be in the wrong place and might fail as a result.

droptofloor does drop it to the floor, yes... but you can always restore the origin to what it was before you made the call now that you know it can freely move downwards (thus isn't stuck).

[Cobalt]

Right. In this case, I am calling checkspawn and spawning a bubble debug marker at the origin before its bumped up 27 units. Probably I ought to redo it so that it adds 27 units and checks that way. Then the -24 value Baker noticed could be used with a 3 unit tolerance above ground, or I can merely bump it the full -27 units I suppose....and even add one unit to the top to factor in the other value you pointed out.

Using the Darkplaces engine , also need to remember it unsticks entities and will drop them to floor in worldspawn....and during the game.
Just now wondered why spawn locations could not be static...and tried making them static, but it turns out they must loose their target value or something because teleporters no longer work at all.

beware of this in info_teleport_destination.
self.origin = self.origin + '0 0 27';
and this in PutClientInServer
self.origin = spot.origin + '0 0 1';