Spring RTS Engine

oh and i want a flying car out of marshmallows and a bunny and a gigantic fluffy motorcycle and a flying fortress out of chocolate and an elephant

Kloot wrote:just don't blame me for planting some more trees in the tag-forest.

But all those shapes can be defined by only need two FBI tags!
HitBoxShape=Ycylinder;
HitBoxDimension=20 10 50;

Where "HitBoxShape" can take the values of:
- Xcylinder
- Ycylinder
- Zcylinder
- cube
- sphere


And where HitBoxDimension are the radius, or half-side in case of box, or half-height in case of one dimension of the cylinder, along the axis X,Y,Z. With X being left-right, Y being up-down, and Z being front-rear.

Strictly speaking when all radius aren't the same, it aren't a box but a parallelepiped, it aren't a sphere but an ellipsoid, it aren't a cylinder but a ellipse-based-right-prism. However I figured it's easier to type and remember "cube" and "sphere" than the true names.

Also, isn't there any room to store them in the S3O instead of the FBI?

WUT about 3do and dont say pah..

it is part of the fbi fang. that means 3do also

zwzsg wrote:Where "HitBoxShape" can take the values of:
- Xcylinder
- Ycylinder
- Zcylinder
- cube
- sphere

Cube as in cuboid?

@zw:
Since the bounding volumes only exist as mathematical definitions, storing them in a unit's FBI so models can stay agnostic to their presence seems the best option to me. And FTR, the tags I've introduced so far are:
Size and offset are in world units; the size parameters represent the full (not half) axis lengths. You can use the offset tag to produce somewhat better fits for weirdly shaped models.

@smoth:
No, shields won't be affected (though defining custom shield shapes could be done in much the same way, you would only have to change the projectile deflection/absorption logic and the code that draws them).

@sinbad:
Not possible without really ugly hacks that I don't want on my conscience.

I has wrote:could the collision model be attached to the root object of the model?

Would be very useful for a number of reasons.

Or does it involve really ugly hacks as well? :P

Good good.

No smoth I was asking why zwzsg seemed to be suggesting in his last line: (this one)

Also, isn't there any room to store them in the S3O instead of the FBI?

that we skip making fbi tags and just store this in s3o, unless he meant store in s3o but make tags for 3do.. im not sure I dont think its good to discount off 3do even if s30 is prettier

Well, since we already set the sphere radius and the height of s3o in UpSpring, and considering how it would be nicer to edit them in UpSpring and see the change immediatly instead of editing the fbi then running Spring, and considering how Kloot was worried about breeding the tree forest, storing hitbox in the s3o didn't seem that silly the time I wrote it. But I'm fine with FBI tags, and anyway looks like it's the path Kloot took.

Kloot wrote:

Code: Select all

BoundingVolumeType={Ellipsoid | Cylinder{X | Y | Z} | Box};
BoundingVolumeSize=X Y Z;
BoundingVolumeOffset=A B C;

You'll want to strip out my old collisionspherescale and collisionsphereoffset code then.

bump for progress?

Any word on the progress of this patch? I eagerly await new collision stuff.

Sorry, work on this has stalled a bit (I've been extremely busy with a uni project for the last five weeks, but I'll try to pick it up again soon). I want to stress once more though that for ground units you wouldn't see any difference since only aircraft use the collision sphere for actual unit vs. unit coldet, and in retrospect I'm not really sure the extra computational cost of doing projectile-in-volume checks for everything else all the time is worth it (especially considering the amount of code that needs to be changed ) so it'll probably be slimmed down in some ways.

kloot, something like this makes a space rts more plausible and it'll make my coms in gundam function much better. I EAGERLY look forward to when you resume work!

kloot since ur dabbling in the area of aircraft collisions can u see why flying air repair pads don't work...

from ingame tests its clearly obvious that the landing unit is bumping into the unit with the pad... so im wondering is there a way to have a the landing unit ignore collisions with the pad its trying to land on...

sry for wandering away from the topic at hand.

j5mello wrote:kloot since ur dabbling in the area of aircraft collisions can u see why flying air repair pads don't work...

from ingame tests its clearly obvious that the landing unit is bumping into the unit with the pad... so im wondering is there a way to have a the landing unit ignore collisions with the pad its trying to land on...

sry for wandering away from the topic at hand.

I don't think they worked in OTA either.

they worked in ota.

Kloot wrote:Sorry, work on this has stalled a bit (I've been extremely busy with a uni project for the last five weeks, but I'll try to pick it up again soon). I want to stress once more though that for ground units you wouldn't see any difference since only aircraft use the collision sphere for actual unit vs. unit coldet, and in retrospect I'm not really sure the extra computational cost of doing projectile-in-volume checks for everything else all the time is worth it (especially considering the amount of code that needs to be changed ) so it'll probably be slimmed down in some ways.

Units use the collision sphere to determine when to back off and of course they're used for mouseclicks. Currently the lolimod has a collision sphere that only covers the upper body so clicking near their feet won't do anything. With cylinders we could make tanks that are difficult to hit with inaccurate weapons from the front and side without having projectiles pass through their sides.

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.