Page 1 of 1

collisionVolumeType ignored?

Posted: 30 Apr 2013, 16:28
by PepeAmpere
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?

Posted: 30 Apr 2013, 16:30
by Anarchid
Aren't ellipsoids extinct?

Re: collisionVolumeType ignored?

Posted: 30 Apr 2013, 20:03
by Silentwings
yes, ellipsoids & elliptic based cylinders have been deprecated since 92.0

Re: collisionVolumeType ignored?

Posted: 30 Apr 2013, 20:10
by PepeAmpere
  • 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}.
Is this a joke??? :roll:

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
Or, at least debug (ALT+V) is broken, because it shows what wrote above.