-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
stock ModulePartVariants does not recreate part joints correctly when loading from a save file #179
Comments
I can think of two approaches to fixing this, one general and one specific: General solution: Alter how vessels in flight store their attachnodes to be more like how it's done in craft files. The position, rotation, and size of the node should be persisted. This should fix the problem for all modules that change attachnodes, though it may have unintended effects if some modules expect the nodes to be unmodified by the time they reach OnStart, etc. This also doesn't help with ships that are already in flight, and loading the old form of the data must still be supported. Specific solution: Have ModulePartVariant move the attachnode somewhere in the start process. This seems congruent to how it works in the editor scene (although it shouldn't move child parts). This will work for ships in flight and might have a smaller surface area. |
* New KSP QoL/performance patch : [**LowerMinPhysicsDTPerFrame**](#175) : Allow a min value of 0.02 instead of 0.03 for the "Max Physics Delta-Time Per Frame" main menu setting. This was already possible by manually editing the `settings.cfg` file, but changes would revert when going into the settings screen. * Add tooltip describing the "Max Physics Delta-Time Per Frame" main menu setting * merging master to dev (#181) * zh-cn localization for ManufacturerFixes.cfg (#178) * Remove ENABLE_PROFILER define that got added recently --------- Co-authored-by: zhangyuesai <zhangyuesai@live.com> * Fix #182: ModulePartInventory now accounts for changes to a part's mass or volume -for example, changing a part's variant (rcs thruster blocks, structural tube) or its resource level could change its mass, but when you store it in inventory the mass would always use the value from the prefab * oops, revert a couple changes to the csproj that made it into the last commit by accident * Fix #185: calculate the correct mass for parts when picking them up off the ground in EVA construction * Fix #104 : set dead kerbals to missing when loading a game and respawning is enabled * Standardize spaces for indent in .editorconfig and add it to the SLN (note personally I'd prefer tabs for indents, but all the existing code in here that didn't come from me uses spaces and consistency is more important) * Change tabs -> spaces in the few files that used it Whitespace-only change. (note most of these were originally authored by me, but the project as a whole uses spaces pretty consistently) * Fix #180: add ZeroCostTechNode patch * Better editor undo redo (#176) * BetterEditorUndoRedo : Exploratory fix for undo/redo state, doesn't work because of VesselCrewManifest side effects See #172 * BetterEditorUndoRedo : functional, obvious issues fixed, still likely to cause side effects. * disable BetterEditorUndoRedo by default --------- Co-authored-by: JonnyOThan <jonnyothan@gmail.com> * PAWGroupMemory is no longer per-window, but rather per-group (#186) * Fix #50: PAWGroupMemory is no longer per-PAW, but stores the expansion state for all windows and is not cleared on scene changes -possible future work: persist the collapse state to disk * collapse or expand PAW groups when the PAW is shown * Fix #179: ModulePartVariants now applies node position changes in all scenes * enable BetterEditorUndoRedo by default * Merge master -> dev (#187) * zh-cn localization for ManufacturerFixes.cfg (#178) * Remove ENABLE_PROFILER define that got added recently --------- Co-authored-by: zhangyuesai <zhangyuesai@live.com> * update readme with the new fixes --------- Co-authored-by: gotmachine <24925209+gotmachine@users.noreply.github.com> Co-authored-by: zhangyuesai <zhangyuesai@live.com>
ModulePartVariants can alter attachnode positions. The most apparent example of this is the structural tubes from Making History.
When you first launch a craft file, the attachnode positions come directly from the craft file and are correct:
After reverting to launch, or saving and reloading the scene, etc. the attachnode positions are wrong. This causes the game to create the physics joints between parts in the wrong place:
Note that in this craft file, one "arm" has the "top" node connected at the center, and one has the "bottom" node connected at the center. That is, the tubes are pointed in the same direction. It's pretty clear that the bottom node isn't in the right place. This can be verified with the debugger or unityexplorer.
Craft file used above:
ModulePartVariant-joints.zip
The text was updated successfully, but these errors were encountered: