Suggestions for countering the Robotic Drifting issues.
The robotic parts permanently move away from the attachment points (Radially or Node) each time a craft is loaded when a force is applied
Each time its loaded the further the movement, causing crafts to become inoperable.
1. Each time a craft is loaded into a scene have KSP remember what the attachment points were for the robotics, then reapply them to the craft when they are unloaded.
What I mean by this is that KSP is remembering what the attachment points were when the craft was created and returns it to that configuration each time.
- Craft is launched via the Launch Button in the Editor
- KSP remembers the robotic parts attachment points on launching (on creation) from the craft file.
- On changing scenes/unloading craft from scene, KSP rewrites the original robotic attachment points in memory
- Then on reloading of a scene/loading a craft KSP does the same thing, keeping the attachment points locked to the same positions for the rest of its creation
- Longer load time
- The pause when a craft comes into render range/physics range may end up more obvious.
- There might end up being a pause when a craft moves out of render range/physics range.
- When the craft is reloaded, depending on the robotics. the craft could end up under the ground.
- Might be a problem if the robotic part is the root part with reloading the craft later on as the root part determines the distance above the ground. not the bottom of the craft.
- The robotic parts will never twist out of position permanently if that is important
2. Have it built into Timewarp
I know this happens with normal parts at times. Timewarp will snap parts back into position, either until Timewarp ends or permanently
This used to happen all the time to normal parts (connections) when they got 'bent' from being hit by a large force (like hitting the planet surface)
- This can possibly move the craft in unexpected ways so the craft ends up in the ground or at an angle
- After timewarp the snapping of the robotics could cause a violent movement which for complicated crafts like EJ_SA might make things worse for craft to craft interaction
3. Robotic parts have the 'Reset to Build Extension' what about having one like 'Reset Attachments to Origin Points'The advantage of this is that the player can choose which ones they need to reset in order to avoid craft stability issues.
- Player could have 100s of robotic parts to reset
4. Somehow create a subassembly in the code that treats anything connected to robotic parts as one part like part welding and cant be twisted or moved.
I have no idea how Unity really works so, this one is just a random thought.
- Whole subassembly blows up when one single part is destroyed
- How the subassembly works with docking ports could be an issue.
- Subassembly could be huge if all the robotics are connected
These suggestions will most likely have a need for more memory.
These suggestions are just for the main attachment points. I haven't tested yet how parts within the robotic parts are affected.
#4 Updated by [email protected] 8 days ago
Idea #2: There is option at settings to have gravity assist on, same kind of setting should be for robotic parts too: when vessel is loaded it helps vessel stabilize before making any sudden robotic movements, like they does now and it leads for vessels jump grazy sometimes. To be honest i am not sure if jumping is because of robotic parts acting or vessels clipping trought terrain when loaded, this might need further investigation. I had one base which had addons connected with robotic parts, but those addons were on wheels, which broke after/before jump.
This isn't about robotic parts being under the ground.
Its about robotic parts recording their in game stress locations into the save/persistent file which then KSP treats as if that's where they were originally
each time the scene is loaded.
Over multiple loading of the scene or Quicksave/Loads the 'drift' accumulates.
KSP doesn't account for gravity/stress in a craft, therefore on saving the craft's parts locations should be returned to its original positions of attachment.
If stress/gravity was accounted for the game saves would probably be massive.
The only thing that should change is the rotation/extension of the robotic part and all attached parts as if no force was ever stressing the craft.