Resolve compatibility issue with current ROLib version - #1
Conversation
…gging changes correctly.
panic-7700
changed the title
| /// Calls the generic ROT procedural drag-cube updating routines. Will update the drag cubes for whatever the current model state is. | ||
| /// </summary> | ||
| private void UpdateDragCubes() => ROLModInterop.OnPartGeometryUpdate(part, true); | ||
| private string ShapeKey => $"ROStations|{coreModule}|{upperModule}|{lowerModule}|{topModule}|{bottomModule}|{bodyRadialModule}|{upperRadialModule}|{lowerRadialModule}|{currentHabitat}|{currentVScale}|{currentDiameter}"; |
There was a problem hiding this comment.
Not sure if this is the correct way of creating a uid here. Using currentHabitat seems like it's more likely to pick up changes with the upper/lower/etc modules, but it does not inherently represent external dimensions as the slider can be adjusted independently.
There was a problem hiding this comment.
coreModule, upperModule etc are of type ROLModelModule. Does that type really have a sane ToString() implementation?
There also appears to be a bunch of VScale parameters (currentTopVScale, currentUpperVScale, currentLowerVScale, currentBottomVScale which can all affect the mesh of the resulting part. Oof, and then there's a bunch of rotations as well. I cannot even start to comprehend what those V.Offset and H.Offset fields do.
Overall the amount of knobs you can tune here is absolutely overwhelming and perhaps it shouldn't try to use the drag cube cache at all?
|
Any chance of a review or merge here? |
|
The KSPRoot addition needs this as well: |
2 participants
This simply gets the existing version of ROStations working with the current RO/RP-1 versions. I've made no changes to functionality. I'm new to KSP modding, so let me know if there is any specific testing I should be doing for this!
(I also updated the
.csproj, in the hopes that using theKSPRootglobal would be useful to other folks.)