Capitalship tag for aircraft
Moderator: Moderators
While this is cool, I still think the best solution would be multiple collision spheres, as many as one per piece (with individual settable offsets and diameters for each piece) rather than going into the mathematical nightmare of non-spherical collisions. Plus, with that the experimental melee-weapon code wouldn't have to be completely rewritten for non-spherical collisions (simply select the closest sphere to attack) since the melee-weapon stuff would be a nightmare with non-sphereical collisions
TargetBorder wouldn't work with multiple spheres either, just set the unit radius to something good and the unit's collision shape won't matter.
Multiple spheres would be less accurate than simple cylinders or boxes for most units, very few can benefit from a series of spheres. They're also more complex to set up and more complex to evaluate (seriously, collision with primitives is a well researched area of math, even arbitrary convex shapes are easy).
Multiple spheres would be less accurate than simple cylinders or boxes for most units, very few can benefit from a series of spheres. They're also more complex to set up and more complex to evaluate (seriously, collision with primitives is a well researched area of math, even arbitrary convex shapes are easy).
Ah, well I only ever played with two or three, and none of them worked rightzwzsg wrote:We need custom collision shape for weapon vs unit ColDet, too, if not mostly!Kloot wrote:only aircraft use the collision sphere for actual unit vs. unit coldet
In TotalA.exe, air units would use flying air pads fine. Damaged air units would find flying airpad, land on it, get repaired, take off, it was working fine. The only issue is that when the pad itself gets damaged, then it tries to land on itself, and so that makes it drift out of map / drift under ground / drift under water / drift higher and higher / ... well drift forever in whatever direction its own pad is.
-
Guessmyname
- Posts: 3301
- Joined: 28 Apr 2005, 21:07
-
[XIII]Roxas
- Posts: 182
- Joined: 20 Jun 2007, 23:44
A patch to hitboxes to change their shapes and divide them up would make a lot of things better. What about each piece of a model having its own hitbox. Then it would only be bad for models with large pieces.AF wrote:At the very minimum I think collision boxes should be more appropriate to spring as an interim patch if only to make towers and long units more feasible.
Yeah but it would greatly increase the processing power necessary for testing collision.Eaglebird wrote:A patch to hitboxes to change their shapes and divide them up would make a lot of things better. What about each piece of a model having its own hitbox. Then it would only be bad for models with large pieces.AF wrote:At the very minimum I think collision boxes should be more appropriate to spring as an interim patch if only to make towers and long units more feasible.
As opposed to making odd shapes of hitboxes or, for large aircraft or untis, splitting them up as such?KDR_11k wrote:Yeah but it would greatly increase the processing power necessary for testing collision.Eaglebird wrote:A patch to hitboxes to change their shapes and divide them up would make a lot of things better. What about each piece of a model having its own hitbox. Then it would only be bad for models with large pieces.AF wrote:At the very minimum I think collision boxes should be more appropriate to spring as an interim patch if only to make towers and long units more feasible.
What I have done so far:
- * unit vs. projectile collisions (ie., hit detection) for each of the three types of primitives
* the mouse raytracing bits for unit selection
- * figure out how to deal with explosions (I'm leaning towards just keeping the damage and impulse calculations sphere-based as they are now)
* update all the other stuff that uses unit->radius in some way
* unit vs. unit collisions