Capitalship tag for aircraft
Moderator: Moderators
But all those shapes can be defined by only need two FBI tags!Kloot wrote:just don't blame me for planting some more trees in the tag-forest.
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?
@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.
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:
Code: Select all
BoundingVolumeType={Ellipsoid | Cylinder{X | Y | Z} | Box};
BoundingVolumeSize=X Y Z;
BoundingVolumeOffset=A B C;
@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.
Last edited by Kloot on 19 May 2007, 22:14, edited 1 time in total.
No smoth I was asking why zwzsg seemed to be suggesting in his last line: (this one)
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 prettierAlso, isn't there any room to store them in the S3O instead of the FBI?
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.
You'll want to strip out my old collisionspherescale and collisionsphereoffset code then.Kloot wrote:Code: Select all
BoundingVolumeType={Ellipsoid | Cylinder{X | Y | Z} | Box}; BoundingVolumeSize=X Y Z; BoundingVolumeOffset=A B C;
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.
) so it'll probably be slimmed down in some ways.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.
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.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.
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: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
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.