Inside3D!
     

Player Bounding Box

 
Post new topic   Reply to topic    Inside3d Forums Forum Index -> QuakeC Programming
View previous topic :: View next topic  
Author Message
Quake Matt



Joined: 05 Jun 2005
Posts: 129

PostPosted: Tue Jun 14, 2005 4:12 am    Post subject: Player Bounding Box Reply with quote

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?
Back to top
View user's profile Send private message
Urre



Joined: 05 Nov 2004
Posts: 1073
Location: Sweden

PostPosted: Tue Jun 14, 2005 6:33 am    Post subject: Reply with quote

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.
_________________
Look out for Twigboy
Back to top
View user's profile Send private message Visit poster's website
Wazat



Joined: 15 Oct 2004
Posts: 732
Location: Middle 'o the desert, USA

PostPosted: Tue Jun 14, 2005 2:15 pm    Post subject: Reply with quote

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

But I'm not volunteering!

/me cowers
Wink
_________________
When my computer inevitably explodes and kills me, my cat inherits everything I own. He may be the only one capable of continuing my work.
Back to top
View user's profile Send private message MSN Messenger
Dr. Shadowborg
Inside3D Staff


Joined: 16 Oct 2004
Posts: 726

PostPosted: Tue Jun 14, 2005 3:07 pm    Post subject: Reply with quote

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

But I'm not volunteering!

/me cowers
Wink


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! Wink
_________________
"Roboto suggests Plasma Bazooka."
Back to top
View user's profile Send private message
Quake Matt



Joined: 05 Jun 2005
Posts: 129

PostPosted: Tue Jun 14, 2005 5:34 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Sajt



Joined: 16 Oct 2004
Posts: 1026

PostPosted: Thu Jun 16, 2005 4:09 am    Post subject: Reply with quote

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.
_________________
F. A. Špork, an enlightened nobleman and a great patron of art, had a stately Baroque spa complex built on the banks of the River Labe.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    Inside3d Forums Forum Index -> QuakeC Programming All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2004 phpBB Group