Player Bounding Box

[Quake Matt]

Hey, guys!

I'm having a bit of trouble changing the hull size of the player - it never seems to be the size I tell it to be!

Setting the size to '0 0 0' works fine, and the origin can go right up to and touch walls and floors, no problem. It starts to go awry whenever I try to set it to anything else...

Say I'm using setsize(self, '-2 -2 -2', '2 2 2'), then the -2 part seems to work perfectly, and I can right up to surfaces without them quite falling out of view. However, the engine seems to totally ignore the +2 part and just use what appears to be the default player size.

Any ideas what's going on? Maybe I should be using something other than the setsize command?

[Urre]

For entity->world collisions, there are only 3 possible sizes: point size ('0 0 0' '0 0 0'), player size ('-16 -16 -24' '16 16 32') and shambler size ('-32 -32 -24' '32 32 64').

The latter 2 are also known as VEC_HULL_MIN, VEC_HULL_MAX and VEC_HULL2_MIN, VEC_HULL2_MAX in defs.qc.

For entity->entity collisions, any size works.

This whole inconvenience is a limitation of the q1bsp format. q2bsp and q3bsp support any size for entity->world collisions. DarkPlaces, FTE and possibly others support q3bsp. I think mhquake might support q2bsp.

[Wazat]

It would be cool if someone recompiled all the Q1 maps into q2 format...

But I'm not volunteering!

/me cowers

[Dr. Shadowborg]

It would be cool if someone recompiled all the Q1 maps into q2 format...

But I'm not volunteering!

/me cowers

The main problem I have with q2bsp is that unlike q1bsp, it stores all it's textures externally I believe. (Worse, it doesn't even package these textures into a nice compact wad file, it has them as a separate file for each and every texture) This means, whenever you use custom textures, you've got to include those texture files in the distribution zipfile in addition to the actual bsp, thereby pushing the sizes of the distribution file upwards... It can be particulary atrocious, as some maps can reach sizes of 4mb or more just zipped alone, whereas a similarly sized map in q1bsp format can run around 2mb, and pack more fun into it. I personally don't mind not having crouching, as more often as not, I forget to use it effectively, and as a result it becomes little more than a cliche plot tool. (i.e. path is blocked, crawl under something)

Just my random mumbling and rantage on q2 bsp, that's probably horribly rife with inaccuracies. =P

BTW, congrats on your victory in DarkSnow's QC modding compy, Quake Matt!

[Quake Matt]

Ah, that explains things a bit! Strange that I've never noticed this before, even after all these years...

What I'm trying to do is resize the player view model in Reinforcer, so that you don't get stuck behind monsters and architecture while moving about. Looks like I'm either going to have to write a cheesy QC collision system with tracelines or somehow fudge the .owner fields so that the game doesn't test for collisions between the player and his Reinforcers (which should fix most of the problems). Either way, it's going to be tricky...

Changing topic slightly, does anyone know how to copy a string from one field to another rather than reference it? I've been trying to use .netname as a way of getting strings from the engine to the code, but all the strings change along with the netname.

[Sajt]

Nearly all engines support the FRIK_FILE extension (or even the old QSG_FILE), which adds the functions strzone and strunzone.

local string s;
s = strzone (whatever_string);

will allocate memory on the zone (you can read more about the zone... somewhere), then strcpy the string into there. After that, the string can be used for such things. Just be sure to unzone after:

strunzone (s);

This will free the memory used. After strunzone, s will be a pointer to unallocated space, so don't try to reference it afterwards.