IPartSizeModifier

[lo-fi]

Evening!

We've had various issues with skinned meshes - such as get used on tracks - and detected bounds sizes in KSP. For some reason it generates bonkers numbers for the part sizes if parts contain a skinned mesh. This causes two issues:

1) The editor icons were always tiny. xEvilReeperx kindly addressed this with PartIconFixer.

2) Reported vessel sizes in the editors are way out of whack, leading to problems with the low end buildings in career mode. I've never been able to address this.

I came across a few posts, the most helpful of which being this one: http://forum.kerbalspaceprogram.com/threads/103152-What-s-new-in-0-90. Having messed about with the GetModuleSize method, I can't seem to figure out what on earth it's supposed to do. It gets called three times when a part implementing it is added, some Vector3's get flung about and that's about all I can figure out. I was hoping it would get passed the vessel size before the part was added in the first pass, but that doesn't seem to be the case.

Using:

public Vector3 GetModuleSize(Vector3 defaultSize)
        {
            print(defaultSize);
            return defaultSize;
        }

I get:

KF.TrackLong added to ship - part count: 3

(Filename: C:/buildslave/unity/build/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)


(5.9, 9.5, 50.9)

(Filename: C:/buildslave/unity/build/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)


(11.9, 19.0, 101.8)

(Filename: C:/buildslave/unity/build/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)


(5.9, 9.5, 50.9)

(Filename: C:/buildslave/unity/build/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

The reported size of the vessel is H 1.0m, W 2.8m, L 5.2m before adding the track. Any pointers on how we're supposed to be using this interface?

Many thanks

[NathanKell]

If it's like the others, it'll store the bounds of the part when the part is first loaded (and turned into a prefab), and then if the bounds change later you need to return the offset between your current bounds and part.partInfo.partPrefab's bounds.

[Crzyrndm]

If it's like the others, it'll store the bounds of the part when the part is first loaded (and turned into a prefab), and then if the bounds change later you need to return the offset between your current bounds and part.partInfo.partPrefab's bounds.

I was messing round with this for PWings, IIRC the offsets returned from GetModuleSize were not accounting for part occlusion in any way. That meant any non-zero modifier returned was added/subtracted from the vessel size even if that part had no effect on the vessel boundaries. I ended up just leaving it as Vector3.zero because of this issue (I really didn't want to have to make a bunch of raycasts to work out what lengths weren't occluded...). This was pre-1.0 and I wasn't particularly thorough so take that with a grain of salt

[lo-fi]

OK, thanks. I noticed you'd returned vector3.zero in pwings, but it didn't seem to help in my case. We may end up resorting to passing negative values, but these will have to be manually calculated for each part, I suspect.