Hitvertx seems to be working fine in the first 6.4 release, but appears to be broken in 6.404.

I have read all of the forum posts, and also about the changes to c_trace in the buglist, and still am showing an error. Included please find hitvertex.zip. This is the most basic level, with only the necissary code to shoot and move.

If you run this under the original 6.4 version, when you move around (mouse and 'W' key) and shoot(Ctrl), you will see a small sphere at the hit point on both the model and the walls. If you shoot at the model, you will also see a red cylander appear at the vertex closest to the hitpoint.

This is all behaving well. If you upgrade to 6.404, the red cylander doesn't do what it is supposed to, and doesn't appear as expected.

Notes: If built under 6.404, if you shoot the head neck area, it will kind of work, but below this not. In 6.4, it works 100%, except for a strange area around the naval, which returns a vertex on the arm??
hitvertex.zip

The MDL bounding box is initialized with a default size of +/-32 units from the MDL center. To get a better fitting bounding box try calling c_updatehull. If you need really accurate collisions you will have to set the MDLs POLYGON flag to ON.

action hit_man
{
c_updatehull(my,0); // get accurate cube size
// or: my.polygon=on; to get polygon collision
my.event=hit_event;
my.enable_shoot=on;
}

Thx! Headshots are working much better now. On the himan test, I set the polygon flag, and also added a hollow skycube, in case that was affecting my results, and I am still showing a hit point near the naval that returns a vertex at the end of the arm, and what appear to be a few other minor tweaks. I am not worried about one vertex... just thought you might wanty to check it out.

The model should be correct AFAIK - it is closed and the UV is really straight forward. I have the Max file if that helps at all.

Some might assume that a hit_man is a moving, animating entity, not a terrain, .wmb entity, a static model, etc.
If the entity is, indeed a moving, animating entity, the advice to set the polygon flag to on for such entity might seem to conflict with documentation available in some versions of the manual and on the website.
manual quote:

Quote:

---

*Only one of the objects involved in a collision should have a polygonal hull. Thus do not set this flag for moving actors.
*This flag does not use animation, so don't set it for animated models

---

Quote for collision page (web site) setting polygon = on:

Quote:

---

The reason for this distinction is speed and stability. For entities with a high polygon count using its box will be faster. Entities that move can get entangled when collision is done with the ellipsoid-polygon routine.
To summarize: when you have static entities with low polygon count set my.POLYGON=on for these entities. When you have entities that move about (enemies, other players in a multiplayer game) or that have a lot of polygons you should set their my.POLYGON flag to off.

---

In addition, it would almost seem that issues of AUM advocate setting the polygon flag to on for moving, animated models.
Maybe some users report bugs or post comments of frustration when models stick together.

It is not my intention to uses quotes from the documentation of the product to address statements made by a developer of the product.
Such might be ridiculous.

slacker, even with polygon precise collision (polygon = on), if the model is animated, and the vertices and polygons move around quite a bit, I may be wrong, but the collision may not appear to be accurate. It is my impression that only the arrangement and position of polygons for the first frame of animation are used for polygon precise collision.

Hopefully, someone will correct any inaccuracies.

See manual -> c_trace -> use_polygon.