[Dr. Greg House]

I don't know if there is a right place to ask this particular question.
Here's a "description" on what sequence boxes are and what they look like.

http://forums.steampowered.com/forum....php?t=2230561
http://facepunch.com/showthread.php?t=1140200

Very basically, the issue that I am having is that these sequence boxes are what seem to trigger trigger-brushes. Since those boxes are way too big, I can't accurately detect collision (starttouch, endtouch) with these boxes.
There's a few workaround possibilities which would involve either own calculations, tracehull-spamming or invisible dummy-replacements (that I parent to specific entities) of models that have a decent sequence box. But basically I have no idea what is going on here. Maybe (hopefully) someone else has some insight.

Thanks in advance!
House

[friagram]

Sequence box is the box which encompasses the model's render bounds, they are rectangular and have 6 square faces. You would have to specify that you want to use that bounding box for collision, because by default it's vphysics, not bounding. Bounding will not turn when the model rotates, it always faces origin, so its very inaccurate for collision detection. Vphysics is most commonly used for fine physics collision, like throwing a ball and having it roll properly or bound off of a wall. Vphysics is why a ragdoll will deform and rest against objects and not clip into them or itself. It is very expensive to use, so even for bullet calculations, it's not used.. You can use a traceray to hit vphysics objects if you need that kind of accuracy. Generally, Hit-boxes are used instead, which are rectangular boxes tied to the model's bones.

Trigger brushes (bsp entities) use models which are embedded in the map, they have numeric identifiers, and while they may be rectangular, they can consist of any collection of convex shapes (you could have several spheres for example).


This is how it works:
Seq boxes- tell the renderer when to render stuff (is the model too far past the zclip plane, should we bother rendering it at all? Fade/exclude by leaf vis, occluder, or areaportal). Due to this nature, the sequence box is always big enough to encompass the entire model, including all of the mesh's verts, attachments, bones, origins, and all elements of the vphysics (collision) model if it has one. Rectangular (faces origin).
Hit box- decide if bullets (hitscan) weapons can hit the model, rectangular (moves with model bones). They are enumerated, so that head, left arm, right arm, torso, etc can be identified.
Bounding box- specifies the model's volume in the world (mins/maxs) Mostly used for player and npc collision, so that crouching and jumping players will collide properly, and not clip into eachother, or world geometry, rectangular (faces origin)
Vphysics- specifies the model's volume in the world, and possibly joint/collision relationships with itself. Used to calculate collision with physics objects. Concave (moves with model bones).

[Dr. Greg House]

Ah okay, so now I know why sequence boxes need to have a "certain" size.
However the issue is that while the size of the trigger_multiple is accurate, the colliding object's sequence box is being used to determine trigger hits. I don't know why, anyone would expect a simple vecMin/vecMax check along with proper translations and stuff.

However, I recompiled a model, moving an attachment point outside of the sequence box, and according to hlvw the sequence box hasn't changed and the attachment point is outside of it.
So neither the mystery of what define sequence boxes is solved, nor why trigger entities seem to use these for collision and if and how to change that.

[friagram]

I'm not 100% sure, but when the model is exported, the smd will contain the coordinates for the verts, along with the bones. Those coordinates will define the bounds. i thought attachments and illumposition would factor in as well, but since they ar client side effects, it would make sense for the, to be left out.

You can use hlmv and add/modify a hitbox, that would change it for sure.
It's better though to make a proper collision hull and use vphysics.

I'm talking about like, cbase animating models, not brush/ bsp models.
Are you trying to set a .mdl to a brush? Because I don't think that will work.
All you can do when creating a trigger by name is setting it's mins/maxs, so it will always be rectangular.

[Dr. Greg House]

Originally Posted by friagram [...]You can use hlmv and add/modify a hitbox, that would change it for sure.[...]

According to the second link that won't work, unfortunately.

Originally Posted by friagram [...]It's better though to make a proper collision hull and use vphysics.

It's what I was afraid of.
I just don't know why a trigger_once/-multiple would work this way and doesn't have the option to change the behavior.

[friagram]

You need to change the colliding object to use vphysics instead of bounding box, assuming the object has vphysics. I think bbox is solid 2, and vphysics is solid 6.
There are some other solid flags and collision props you can send to make things hit unsolid objects (like make a trigger hit a nonsolid vphysics object by marking it as debris). Some physics objects are more picky than others. Prop physics and prop physics multiplayer have spawn flags for mark as debris, and force serverside (you need this), also trigger interaction. You can set trigger interaction with a sendprop, i think its a solidflag. As for the trigger, you will need to set its spawn flags to hit physics objects (not enabled by default) else it will not trigger the vphysics object on touch.

Note that im talking about trigger multiples. Other entities like nobuilds, hurts, and the like may not have the flags to detrct physprops. Also, even when hooked, some won't detect prop interaction u less they have specific collision groups/solid flags set.

[Dr. Greg House]

I have set the solidtype of the object to 6, also the trigger to only interact with physic objects (spawnflags to 8 ).
I have looked around and I don't know what else to set actually.

EDIT:
Apparently this gets fixed by setting "m_nSurroundType" to "1". (It is 0 by default)