Translocator - getting stuck

[Orion]

Hi there.

I've made a translocator, and when I fire a "grenade" in sharp corners, the player doesn't teleport -- just spawns 2 tfogs in your old and new position. I've tried to fix by setting the size of the "grenade" to '-16 -16 0', '16 16 0'.. But as the "grenade" spins in the air, its bouding box turns, causing it ho hit walls/ceilings with extra size. This fixed the stucking problem, but have any other ways to fix that with '0 0 0' size? And this is why the player doesn't teleport -- it will get stuck so he won't teleport...

thx!

[Urre]

But as the "grenade" spins in the air, its bouding box turns, causing it ho hit walls/ceilings with extra size.

Um, no it doesn't. If it did Quake would rock even more trousers than it does. Quakes bounding boxes can't rotate in any direction. The reason you didn't get stuck with the upped size was because it simply was far away enough from all the walls for the player to get stuck. If the '0 0 0' size translocator gets crammed into a corner, obviously the player with the size of '-16 -16 -24' '16 16 32' would get stuck, as his bounding box overlaps the world geometry. If you want to still use the '0 0 0' size translocator, but without the stuckage, you'll have to add some form of empty space testing in random directions around (most likely slightly above) the translocator. I don't know if you're using an enhanced engine with tracebox features or not, but Quake also provides some stuff you could do it with. You could spawn an entity, walkmove it, and if it returns true that's a safe place to spawn.

If that doesn't make sense, then you're screwed, cause I'm not in the mood of exlpaining more.

[scar3crow]

My first thought is if that happens just bprint "Translocation failed, not enough room". Probably because that seems like the type of thing thatd happen in real life - or you would gib...

[Urre]

scar3: UT's translocator can handle tight spaces just fine. Besides, you pretty much always need to do free space checking, to avoid getting stuck in the floor.

[scar3crow]

Urre: I know - But if it does land in to tight a spot, its not going to work then period... in UT or in Quake.

I did like that you could damage the UT translocator, though I never saw it in use, never saw anyone use it as a Recall Point.

[Spike]

What Urre said.

tracebox or walkmove.
Might need to make nearby players non-solid first so you can teleport in to gib them.
note that walkmove can call touch functions. perhaps you can use that to find what it teleported into.


... '-16 -16 0', '16 16 0' ... *shudder*

[FrikaC]

It likely spins mid air because there's only 3 standard clipping hulls (used for entity collisions against world): point, player size and shambler size. I'm guessing based on the weird size you tried it went for player size.

[Orion]

Don't think so.

The grunt's size is '-16 -16 -24' '16 16 40', the player's size is '-16 -16 -24' '16 16 32'...

The grunt's z offset is a little greater than the player's size, and it collides normally. You can set ant size that it'll hit the world.. I've reduced the fiend's maxs_z to don't go so high as the shambler.. And it works correctly. There are infinite clipping hulls. Am I right?

[Entar]

No. For entity to world collision, there is only the point hull, the player hull, and the shambler hull. The engine rounds to the nearest of these hulls when colliding entities to the world - with entity to entity collision, though, you can do whatever you want without getting rounded.

[Sajt]

Don't think so.

The grunt's size is '-16 -16 -24' '16 16 40', the player's size is '-16 -16 -24' '16 16 32'...

The grunt's z offset is a little greater than the player's size, and it collides normally. You can set ant size that it'll hit the world.. I've reduced the fiend's maxs_z to don't go so high as the shambler.. And it works correctly. There are infinite clipping hulls. Am I right?

The hulls are

'0 0 0', '0 0 0'
'-16 -16 -24', '16 16 32'
'-32 -32 -24', '32 32 64'

When you use setsize it picks the nearest hull size to use with collision against bsp objects, but I can't remember how exactly it rounds. I'm pretty sure though that '-16 -16 0' '16 16 0' (which is scary by the way) goes to player size.

Like Entar said any size will go for entity vs entity collisions, including traces, so because the player has a maxs_z of 40, you can shoot an extra piece of the top of his bounding box, but when he jumps, his head at 32 will hit the ceiling.

[Spike]

And yes, '-16 -16 0' '16 16 0' is <=32 units in the x direction so qualifies for hull1 (player sized) (y and z are ignored for choosing hulls).


From the engine code:

// calculate an offset value to center the origin
VectorSubtract (hull->clip_mins, mins, offset);
VectorAdd (offset, ent->v.origin, offset);

or, in qc with the relevent values inserted
offset = '-16 -16 -24' - '-16 -16 0';
offset = offset + ent.origin;

Or, in other words, use a mins_z of 0 and the grenade is moved down by 24 units, so will always teleport the player into the ceiling in small passageways.
(effectivly you're using a '-16 -16 -48' '16 16 8' min max for world collisions... which of course means that teleporting the player in puts them 24 units into the air, due to the differences in sizes)

I have no idea why the engine code does this.
The max size being a bit taller makes no difference except for entity/entity collisions (rockets, nails, etc). But the min size being different offsets it in wieeeerd ways.

Just for an example, change the player's max_z to something like 1024... Notice how you can still run through small passageways, exactly as before. Change min_z, notice how you get stuck when you spawn.

[Orion]

Yeah, that's right...
This is why if I set the rocket's size to something like '-8 -8 -2', '8 8 2' I'll get funky entity-to-world collisions, a good example is on e2m5's start elevator. Firing a rocket in its centre it will explode anyway.

But looks like the mins won't affect the clipping hulls... Notice the below code, I've made a new monster model, and see its size below:

Code: Select all

setmodel (self, "progs/knight_commander.mdl");
   
setsize (self, '-16 -16 -32', '16 16 38');
self.health = 350;
   
self.th_stand = com_stand;
self.th_walk = com_walk1;
self.th_run = com_run1;
self.th_melee = com_spear1;
self.th_missile = com_missile;
self.th_die = com_death;
   
walkmonster_start ();
self.origin = self.origin + '0 0 10'; // don't get stuck on the floor


If I don't call self.origin = self.origin + '0 0 10' it'll get stuck.. Looks like only the maxs are affected by clipping hulls...

[CocoT]

My first thought is if that happens just bprint "Translocation failed, not enough room". Probably because that seems like the type of thing thatd happen in real life - or you would gib...

Pretty much what I decided to do with Transloquake... but then the later mod doesn't really rely (most of the time) on the need to *quickly* translocate, which might not be the case here. And I'm a lazy coder.

[FrikaC]

Don't think so.

Don't dare you question me in the future.

[Orion]

What??
I said "I don't think so" <----- I forget the I.