collisionVolumeType ignored?
Moderator: Moderators
- PepeAmpere
- Posts: 591
- Joined: 03 Jun 2010, 01:28
collisionVolumeType ignored?
is collisionVolumeType setting igonred for planes in Spring 94? i get strange collision spheres. Instead of elypsoids set in unitDef, i get boxes or cyllinders.
Re: collisionVolumeType ignored?
Aren't ellipsoids extinct?
- Silentwings
- Posts: 3720
- Joined: 25 Oct 2008, 00:23
Re: collisionVolumeType ignored?
yes, ellipsoids & elliptic based cylinders have been deprecated since 92.0
- PepeAmpere
- Posts: 591
- Joined: 03 Jun 2010, 01:28
Re: collisionVolumeType ignored?
- if you dont set anything (use default type), you get ellipsoid hitsphere of the same size as model sphere
- if you set ellipsoid type of hitsphere, you get a box
- if you dont set anything (use default type), and set collisionVolumeScales=x y z;, you get ellipsoud hitsphere of size = max{x,y,z}.

Its really different behavior then it is described in Spring 92 changelog:
Code: Select all
CollisionVolumes:
! drop support for ellipsoid-cylinders and ellipsoids
cylinders with round(!) baseplates are still supported!
simplify how damage from an explosion is calculated, fewer magic numbers, etc
no more distance approximations means no more invincible units (or features)
and no more general "weird" cases like 3103
THIS WILL CAUSE BALANCE CHANGES, BE PREPARED
! get rid of TYPE_FOOTPRINT, it was an alias for TYPE_SPHERE in the continuous case which is now default and the
original intent (a shape defined by the CSG intersection of sphere and footprint) would have been tricky to get
right
instead support a {Unit,Feature}Def key "useFootPrintCollisionVolume" which
makes a collision volume a box with dimensions equal to the object's footprint
(this overrides any custom scaling and/or offsets)
! let projectiles explode _on_ collision volumes and not in a interpolated pos in front of it
- rework projectile-vs-volume special cases so they can be distinguished better for the above
! rewrite TraceRay::{TestConeHelper, TestTrajectoryConeHelper} for #3399
these now no longer use any bounding-radius approximations to
figure out if an object will potentially be hit, but calculate
the exact colvol surface distance taking spread into account