News | Forum | People | FAQ | Links | Search | Register | Log in
Mapping Help
This is the place to ask about mapping problems, techniques, and bug fixing, and pretty much anything else you want to do in the level editor.

For questions about coding, check out the Coding Help thread: https://www.celephais.net/board/view_thread.php?id=60097
First | Previous | Next | Last
 
There are two bounding box sizes: 32x32x56 and 64x64x88. There needs to be some space around and above them for the monsters to be able to move and not produce a warning (or for items not to fall out) - they must not touch a wall or ceiling, but they can be placed right on the ground. As Spud pointed out, a space as small as 1 unit can be enough. 
Quake Collisions And Placing Stuff 
Vertical, have at least 1 unit of space above the heights below. 2 is recommended. The origin(center point) can be put exactly on the floor, though for monsters it is best to put 1 or 2 units above the floor at least to avoid potential position rounding errors sticking them through the floor (should be rare in newer editors).

Horizontal have at least 2 units of space beyond the sizes below.

Items are an effective 62 units tall. Items are 32x32x56 tall and get moved 6 units up on level start so that they can be "dropped" straught down to instantly put them on the floor and also check to see if they are below the floor and thus "fell out of level".

Monsters have 2 different collision hulls regardless of the bounding box sizes shown in Hammer/Worldcraft or other which negke mentioned above. The bounding box size for monsters shown in the editor should be close. Most smaller or narrower enemies use 32x32x56 (hull1), the larger enemies such as shamblers and vores use the 64x64x88 (hull2) size.
Dogs are a little wierd in that they have same size collision as shamblers, BUT...

There is a 4th layer of collisions...the qc code can define any bounding size it wants for an enemy. The engine rounds this size to the hull closest to either of the 2 enemy sizes for all collisions except raytracing and bullets. The qc lets, for unstance, giant monsters such as the gug, vermis, or boglord, get shot more easily in a way that is believable rather than only having bullets affect it right in the center 64units. Also tiny monsters such as fish or spiders don't get hurt if you shoot the empty air above or below them even though there could be 20-30 units of collision hull above these smaller enemies, shooting the air doesn't hurt them.

That is why, even though enemies appear to fit in niches in the editor and make sense from where you can shoot them, the tiny enemies still all need 57 units of vertical space. You can cheat it visually by using func_illusionary so long as the player can't reach the niche. 
 
That explains a lot. 
Odd BBOX Sizes 
Also note that entities with bboxes will collide with each other according to their actual size, even though when colliding with BSP entities they snap to the two fixed sizes discussed above. Useful applications of this fact are left as an exercise... 
Possibly A Stupid Question But 
Do I need a different gbsp light and vis for Quake II or do the ones we use for q1 work? 
They're Different For Q2 
I think these are the most commonly used ones:
http://home.insightbb.com/~gryndehl/q2compile/quake2.html 
Falling Through Part Of A Brush 
First up: swear I had the screenshots folder selected but oh well. I have had a quick look through mapping help re: nonsolid brushes but not finding this issue atm.
My brushes look like this in TB2
http://www.quaketastic.com/files/spz1dm1_brush1.jpg (view from above)
If i move past the vertical line here I fall through the brush
http://www.quaketastic.com/files/spz1dm1_brush2.jpg (view from below)
I am using Ericw's latest tools. 
@oGkspAz 
Not sure but you can try downgrading to a different version of the tools first just in case. 
Func_illusionary? 
Are the brushes a func_ of some sort? Or plain bsp. Workarounds: clip to split them up into diferent brushes, make new brushes from scratch, make another brush inside them that is 1 unit smaller all around...or to add a clip brush around them.

Check that they DO NOT have an origin key. 
 
This is an annoying one. Assuming these are worldspawn brushes, it's a qbsp bug, but usually it can be worked around. Try the command in TB to snap the selected selected brushes to integer. Try turning the selected brushes into func_detail (not a direct fix, but it will cause qbsp to chop that area of the map in a different order and might randomly fix the problem) 
Re: Non Solid Brush 
I'll have to give these suggestions a go but I'm half asleep atm. Will update when I do. Thanks 
14 posts not shown on this page because they were spam
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.