Likely. However almost all human ships have the length as the longest edge, so at least it can be somewhat automated

Hercules series refutes this.

My suggestion is to have a table for each of the bugging ships to instruct the processing code what each side of the bounding box is.

Example

You have a ship that's 50m in width, 40m in length, 20m in height. (Complete bullshit, take a Hercules in mind) Right now the API thinks it's 40m in height and 20m in width)

So you make a table in json where the first value belongs to the largest number in the scale of the ship.

["width", "length", "height"]

The API or processing code would compare the width, height and length (scale) with eachother to make another table that's largest to smallest.

[50, 40, 20]

Now you can get make a dictionary by using the first json as the keys and the second as the values by index.

{
    "width": 50,
    "length": 40,
    "height": 20
}

Keep in mind that are these values are fake and just for demonstration purposes, reply if you have a question or want to add something to my suggestion. 👍

from api.

Might it be best to implement my solution on the Unpacker?

from api.

Upon investigation, it seems that it is not an uncommon occurrence. The bounding box size in the data do not always follow the same orientation. The same issue can be found for the Carrack as well.

from api.

I hoped the Carrack would be the only outlier..
Seems like we'd need to manually define the orientation for each ship?

from api.

Likely. However almost all human ships have the length as the longest edge, so at least it can be somewhat automated

from api.

I like the idea, and think it would be best to fix this directly when creating the json files.
The sizes are handled here: https://github.com/StarCitizenWiki/scunpacked/blob/4bdb320fefd0be9479dc819afaa0228e0e911de7/Loader/ShipLoader.cs#L530

from api.

That'd be the best place to implement it, yes :)

from api.