collisionVolumeType ignored?

collisionVolumeType ignored?

Discuss your problems with the latest release of the engine here. Problems with games, maps or other utilities belong in their respective forums.

Moderator: Moderators

Post Reply
User avatar
PepeAmpere
Posts: 591
Joined: 03 Jun 2010, 01:28

collisionVolumeType ignored?

Post 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.
User avatar
Anarchid
Posts: 1384
Joined: 30 Nov 2008, 04:31

Re: collisionVolumeType ignored?

Post by Anarchid »

Aren't ellipsoids extinct?
User avatar
Silentwings
Posts: 3720
Joined: 25 Oct 2008, 00:23

Re: collisionVolumeType ignored?

Post by Silentwings »

yes, ellipsoids & elliptic based cylinders have been deprecated since 92.0
User avatar
PepeAmpere
Posts: 591
Joined: 03 Jun 2010, 01:28

Re: collisionVolumeType ignored?

Post 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.
Post Reply

Return to “Help & Bugs”