• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

Bounding box in CAT

Is the bounding box in CAT now useful (please read the post below for details)?

  • Yes, but please let CAT do the rotation maths

    Votes: 0 0.0%
  • Yes, the bounding box is fine like it is now

    Votes: 0 0.0%
  • No, drop the bounding box all together, it is not useful

    Votes: 0 0.0%

  • Total voters


Staff member
FSDevConf team
Resource contributor
In the new beta of CAT you can also use a bounding box as animation condition or animation trigger. But as I posted in the announcement, this box does rotate with your object when you place it. This means that you will have to specify to box to match the rotation you intend to use later.

Do you think it would be better if CAT allowed you to enter a rotation and does the math for you to get the box on the proper place? Or do you think it is OK like it is now? Or do you maybe think that due to this restriction the bounding box is not useful at all?
Yup, that rotation thing is a shame...
But because the bounding box is consistent in reading the aircraft refpoint variable in any view, it deserves to survive :)
Backdraw is that you have not a generic object, but a object for only one heading...
Too bad we can't read the arguments given in the xml file

Yep, I fully agree with you. Unfortunately we can not read the heading somewhere (as far as I know). So I will have to write it very clear in the manual that it only works as designed for one certain heading. Too bad when you want to release your objects as a library or so.

rotating bound boxes would be great for me, as I am working on docking system on LKPR now and it would be very useful to make it just once as library object and than place it all over airport in a very simple way.

But I have got one note here - It can probably be a hard task for you as a programmer ( may be even impossible ), but the box that will rotate should remain shaped as rotated box, otherwise it become useles for precision use like docking system.

I'll include painting as an explanation what I mean.

If it would not be possible, please make possible to make more than one bound box, so we can approximate the shape more precisly.

Thanx for reply and for great work.


  • rotated_box.jpg
    24 KB · Views: 565
I am afraid that I have to dissapoint you.

First the box will never rotate with the heading of the XML code. That is the basic problem, so if you make a library of them, you will have to make a seperate version for each heading you want to use it at.

As the command used to define the box does not rotate, the shape of the box will change with the rotation. It is like the picture you attached, it will become bigger with the rotation.

I don't know how you are using GMax animations with your docking system, but the docking systems I am working on do not use GMax animations. I am handcoding the change of the display in the ASM code. The commands I use there do rotate with the object, but with these I can not define a box, only a plane. Therefore they are not really usefull for CAT (I think).
I thought it woun't be possible, but I had to give it a try ;)

My docking system idea was based on few small box objects with different textures placed on them, which are moving out from the box based on the position of the aircraft...... I didn't know there is other possibility, so this was a good workaround for me until I found that neither bounding box nor X, Y and Z valuse doesn't rotate with object.

I am very glad to hear that some other way exist. Plane would be enough for me for docking system, so would you be so king and give me some hints ( just link to documentation f.e., I can study it myself.... )? I am able to do such a think in SCASM, but it is a bit outdated and slowing down FPS a lot, that is why was looking for some different modern way.

Thanx a lot for ideas.
As I progress with my docking system I am also writing a tutorial about it, but at the moment it is not finished yet.

Basically I use the BGLC equivalent of the SCASM VectorJump command to check your position. After I wrote my previous reply I have been wondering if I can use that in CAT as well, but I haven't had the time to test it yet. So I will do that.
arno said:
After I wrote my previous reply I have been wondering if I can use that in CAT as well, but I haven't had the time to test it yet. So I will do that.

I have tested the VectorJump/SEPERATION_PLANE command for CAT now, but like the commands used before it uses the eye point and not the reference point of the aircraft. So when in spot plan it does not work correct.

Therefore CAT will keep the current used IFIN_BOX command, together with an textbox in the next version that allows you to enter the rotation it should have.