KPS Jumpdrives and connectors
Since the 1.210 update, it has become very dangerous to attempt a jump with multiple ships attached to a main jump ship.
After the jump, Klang comes for a visit. The ships start gyrating wildly, spinning out of control, and significantly exceeding the in-game speed limit.
There isn't much of a solution to this beyond disconnecting the ships... which ALWAYS causes a lot of destruction. This is... NOT fun.
It's a lot of work/effort to do these things in SE. Build big ships. Go hunt the Factorum. Fix your ships. Go out again.
When something like this happens, the whole faction just wasted several hours of their lives minimum... on a bug in this game. The fun thing we wanted to do... attack the Factorum... did not happen. Instead we get frustration, and a lot of repair work to do... which honestly is the least fun aspect of the game.
Please make the game fun again.
Here are 2 videos of 2 back to back experiences on a Keen Server. This was very discouraging.
It happened a third time. and now we are not jumping without merging all our ships together as one... which really sucks. It costs a lot of PCU, and then the grids get renamed.
So yeah... there's a work around., but this kind of bug is NOT fun. Please fix it.
Here are 2 videos for the first 2 times this happened. It happened a third time as well. But we're done with connectors now.
I have the same bug
ALSO.
Projections that attach to the main grid no longer work.
The game is unplayable.
Projection starts with a merge block. Merge block welds. merge block is NOT considered part of the grid. Merge blocks floats away and another merge block is placed. Over and Over.
It is now impossible to build missiles. Which is critical to my current playthrough that I am actively making a YT series about. So that's totally muffed up now. As I can no longer do that in game.
My only option is to go back to a previous build of the game, and re-shoot my episode. This is not a work around. This is not acceptable. This is me unable to play the game because you have broken it.
let me re-state.
You refactored something delicate without thinking through the consequences or testing properly. The game is now broken.
ALSO.
Projections that attach to the main grid no longer work.
The game is unplayable.
Projection starts with a merge block. Merge block welds. merge block is NOT considered part of the grid. Merge blocks floats away and another merge block is placed. Over and Over.
It is now impossible to build missiles. Which is critical to my current playthrough that I am actively making a YT series about. So that's totally muffed up now. As I can no longer do that in game.
My only option is to go back to a previous build of the game, and re-shoot my episode. This is not a work around. This is not acceptable. This is me unable to play the game because you have broken it.
let me re-state.
You refactored something delicate without thinking through the consequences or testing properly. The game is now broken.
I had ChatGpt analyze the two code bases. It determined which changes are causing these issues. PLEASE FIX.
Projection welding and merge-block changes1. Merge blocks now refresh structural neighbours after state updates — high relevanceFile: SpaceEngineers.Game/SpaceEngineers.Game.Entities.Blocks/MyShipMergeBlock.cs
New in 1.210: lines 737–742 inside UpdateOnceBeforeFrame():
MyCubeGrid.UpdateBlockNeighbours (lines 8659–8670) removes and re-adds neighbour relationships, marks disconnect detection dirty, and schedules DetectDisconnects.
Why this is directly relevant:
This is the strongest file-level explanation for a version-dependent difference in welding a projection that connects to an existing grid through merge blocks.
2. Core projector CanBuild logic is unchanged — high confidenceFile: Sandbox.Game/Sandbox.Game.Entities.Blocks/MyProjectorBase.cs
The file is byte-identical. Its 1.210 CanBuild method (lines 2090–2134) still:
Therefore, a changed result in this workflow is more likely caused by changed grid/merge state feeding into CanBuild, not by a rewritten projector algorithm.
3. Ship-welder projection selection/build path is materially unchangedFile: SpaceEngineers.Game/SpaceEngineers.Game.Entities.Blocks/MyShipWelder.cs
At lines 281–351, the ship welder still:
The projection-related removal in this file is the building-music notification, not the buildability logic.
4. Help Others welding behavior was removedFiles:
In 1.210, HelpOthers returns false and its setter does nothing; the terminal control and synchronized field were removed; existing-block repairs call IncreaseMountLevel(..., isHelping: false, ...) at MyShipWelder.cs line 263. The object-builder field is obsolete.
This can affect repair ownership/faction semantics on existing blocks. It does not appear to alter projected-block creation because that path calls Projector.Build, not the existing-block repair call.
5. Projector terminal coordinate controls were remappedFile: SpaceEngineers.Game/Entities.Blocks/MySpaceProjector.cs
Changes include:
This is a user-interface/coordinate correction. It can make old and new versions display or manipulate the same stored projection orientation differently, but it does not change CanBuild connectivity.
6. Nested projector data is now cleaned recursively during grid pasteFiles:
Grid-paste setup now processes every block and component; projector object builders recursively call SetupForGridPaste() on stored projected grids. This is relevant to copied/pasted grids or grids containing saved projector state. It is not a direct live-welding change.
7. Merge event-controller behavior was stabilizedFile: SpaceEngineers.Game/SpaceEngineers.Game.EntityComponents.Blocks.Events/MyEventMerged.cs
1.210 caches the last boolean locked state, ignores transient MergeState.Unset, and raises the event only when locked/unlocked actually changes. This changes event-controller output and reduces transient/duplicate merge events, but it does not perform the physical merge.
Physics-system changes likely to be materialBatched physics-body reinsertionFile: Sandbox.Game/Sandbox.Engine.Physics/MyPhysics.cs, lines 1853–1895
New ReinsertBodiesBatched(List<MyPhysicsBody>) ensures cluster space, enables every body through the batch path, finishes the Havok batch, then restores body constraints. The source comment states the purpose: avoid rejecting a constraint when its partner body has not yet re-entered the physics world.
Used by:
This is a high-impact physics reliability change for mechanically connected grids, especially jumps/teleports and attachment creation.
I had ChatGpt analyze the two code bases. It determined which changes are causing these issues. PLEASE FIX.
Projection welding and merge-block changes1. Merge blocks now refresh structural neighbours after state updates — high relevanceFile: SpaceEngineers.Game/SpaceEngineers.Game.Entities.Blocks/MyShipMergeBlock.cs
New in 1.210: lines 737–742 inside UpdateOnceBeforeFrame():
MyCubeGrid.UpdateBlockNeighbours (lines 8659–8670) removes and re-adds neighbour relationships, marks disconnect detection dirty, and schedules DetectDisconnects.
Why this is directly relevant:
This is the strongest file-level explanation for a version-dependent difference in welding a projection that connects to an existing grid through merge blocks.
2. Core projector CanBuild logic is unchanged — high confidenceFile: Sandbox.Game/Sandbox.Game.Entities.Blocks/MyProjectorBase.cs
The file is byte-identical. Its 1.210 CanBuild method (lines 2090–2134) still:
Therefore, a changed result in this workflow is more likely caused by changed grid/merge state feeding into CanBuild, not by a rewritten projector algorithm.
3. Ship-welder projection selection/build path is materially unchangedFile: SpaceEngineers.Game/SpaceEngineers.Game.Entities.Blocks/MyShipWelder.cs
At lines 281–351, the ship welder still:
The projection-related removal in this file is the building-music notification, not the buildability logic.
4. Help Others welding behavior was removedFiles:
In 1.210, HelpOthers returns false and its setter does nothing; the terminal control and synchronized field were removed; existing-block repairs call IncreaseMountLevel(..., isHelping: false, ...) at MyShipWelder.cs line 263. The object-builder field is obsolete.
This can affect repair ownership/faction semantics on existing blocks. It does not appear to alter projected-block creation because that path calls Projector.Build, not the existing-block repair call.
5. Projector terminal coordinate controls were remappedFile: SpaceEngineers.Game/Entities.Blocks/MySpaceProjector.cs
Changes include:
This is a user-interface/coordinate correction. It can make old and new versions display or manipulate the same stored projection orientation differently, but it does not change CanBuild connectivity.
6. Nested projector data is now cleaned recursively during grid pasteFiles:
Grid-paste setup now processes every block and component; projector object builders recursively call SetupForGridPaste() on stored projected grids. This is relevant to copied/pasted grids or grids containing saved projector state. It is not a direct live-welding change.
7. Merge event-controller behavior was stabilizedFile: SpaceEngineers.Game/SpaceEngineers.Game.EntityComponents.Blocks.Events/MyEventMerged.cs
1.210 caches the last boolean locked state, ignores transient MergeState.Unset, and raises the event only when locked/unlocked actually changes. This changes event-controller output and reduces transient/duplicate merge events, but it does not perform the physical merge.
Physics-system changes likely to be materialBatched physics-body reinsertionFile: Sandbox.Game/Sandbox.Engine.Physics/MyPhysics.cs, lines 1853–1895
New ReinsertBodiesBatched(List<MyPhysicsBody>) ensures cluster space, enables every body through the batch path, finishes the Havok batch, then restores body constraints. The source comment states the purpose: avoid rejecting a constraint when its partner body has not yet re-entered the physics world.
Used by:
This is a high-impact physics reliability change for mechanically connected grids, especially jumps/teleports and attachment creation.
Replies have been locked on this page!