Update KAS base #106
Merged
Update KAS base #106
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…pdate version number
In the process replace the quaternion code that only works for nodes oriented in 6 hard-coded directions.
…ching. This object contains the current position of the part in a private field and in some circumstances resists it being changed. The only way around this seems to be to delete and re-create it as needed. Specific example of bad position: grabbing a rover wheel when on ground.
Unless OnLoad is called, they don't produce any power and spam the debug log with messages about nonexistant resource with id 0.
Specifically, connect A to B, B to C, C to A, then unlink A-B or B-C. The C to A connection tries to upgrade to docking while the undocking is still in process, and breaks everything.
The size is set to 5 because it is close in size to a cubic strut, especially if you consider that without anything to attach on, the ladder is just three bent bits of metal. Also, 6 of these ladders are just about enough to match the big ladder, and that's 30. It is also necessary to fix the handling of isTrigger or the ladder stops working once grabbed until save/reload.
The old code actually led to different size of KSP and KAS-created parts.
The previous changes to fix rotations broke this case it seems, so some fixes to the node directions are necessary. Note that the new orientations are more consistent with stock parts.
The most easily reproducible effect is a small jump in the camera focus location when you press Link from EVA because of the rigidbody CoM shifting away for one frame.
The new antenna models are way bigger than most parts rated as 5.
This prepares data structures for adding parts stored with their individual state, and also makes sure that resource mass is counted in the total mass of the container.
Parts that contain resources or have irreversible state transitions like breaking cannot be stored into the container by just incrementing a counter, because that introduces a way to cheat. This implements an option to store the complete state for some part types. Full backwards compatibility is provided by representing current stock for each part type with a pristine counter plus a list of fully specified second-hand instances, and ensuring that the brand-new part counts are stored in exactly same way as before. Since the UI does not provide any way to distinguish parts of the same type, a somewhat cumbersome but workable way to select a specific item is provided by ensuring that Store and Take work in a FIFO order.
That "(KAS created)" string made its way into the rTrf field of saved parts, and the mission id seems to be supposed to mark all parts coming from one launch.
- Docking is symmetric, so both modules should know they are docked. - Calling AttachDocked when restoring from save kills the vesselInfo. - The winch code also sometimes does redundant calls to AttachDocked.
…bit. The problem here is that during the few frames where the part is not completely initialized, its colliders can hit things they shouldn't. At 150 m/s orbital speed this causes big problems. To fix this, initialize the part as physicless at first, and disable its colliders. The enabled property doesn't stop them from colliding with other vessels for some reason, so deactivate the whole GameObject.
Specifically, loading another vessel from an OnStart of the vessel loaded via quickload may cause its position to not update properly, with consequent explosions if it's connected by a winch. It's also a bad idea to attach the winch joint to a still packed vessel.
Docking the port, and then attaching it causes big problems, even up to a CTD due to a stack overflow in some cases it seems.
Without this, plugging the winch in orbit causes a small bump.
Previously placing a non-port part below the winch in the stack permanently broke it. Now it should be possible to use a decoupler to continue the stack.
When linked, either end of the pipe now has a context menu option that allows enabling or disabling fuel flow in that direction. Pipe ends attached from EVA in previous versions have to be grabbed and reattached to use this feature, or the button won't show up. If both ends are editor-attached, it should work immediately.
Specifically, ensure that the nodes are detached when the winch is extended, and relinked when it's locked back. This ensures that stack flow is possible across the connection iff the head is locked.
It thought that stuff attached below it was actually on its head.
KospY
added a commit
that referenced
this pull request
Aug 30, 2014
Update KAS base from Majiir and Angavrilov work
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.