Spring RTS Engine

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).

zwzsg wrote:

Kloot wrote:only aircraft use the collision sphere for actual unit vs. unit coldet

We need custom collision shape for weapon vs unit ColDet, too, if not mostly!



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.

Ah, well I only ever played with two or three, and none of them worked right

As I recall, in OTA planes would only use them whilst on patrol or when order to directly (a move order onto the pad)

true but that doesn't matter in spring since we have land at and fuel an such...

Alas, in Spring I don't believe you can order them to move and stay on a pad.

That would be cool.

How feasible would this be to make functional, per mod or for all spring?

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.

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.

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.

Eaglebird wrote:

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.

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.

Yeah but it would greatly increase the processing power necessary for testing collision.

KDR_11k wrote:

Eaglebird wrote:

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.

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.

Yeah but it would greatly increase the processing power necessary for testing collision.

As opposed to making odd shapes of hitboxes or, for large aircraft or untis, splitting them up as such?

*bump*

This still being worked on?

bump for great justice! HOW'S IT GOIN'????

smoth wrote:bump for great justice! HOW'S IT GOIN'????

^

BUMP

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

What I haven't done yet:

• * 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

bump for progress.

bump for interesting detail pics and WHAT HAVE YOU

I'd rather have partial support than no support at all.

AF wrote:I'd rather have partial support that no support at all.

QFT.