[SPZ2-6293] [1.0.3-rc3] Belt connected to irrelevant loop moves shapes at 177/min instead of 180/min

[lost spindle]

A belt saturated by 4 miners (180/min) leading to trash should move shapes at a rate of 180/min, but due to the presence of a loop which is blocked it instead moves at a rate of 177/min.

This behavior depends on placement order:

• If the belt is transporting 177/min, this design can be made to transport 180/min by deleting and re-placing the belt merge consuming the stacker output.
• If the belt is transporting 180/min, this design can be made to transport 177/min by deleting and re-placing the belt splitter supplying the stacker input.

When reloading a save or pasting the design, which behavior it has appears to depend unpredictably on the location it is placed.

Blueprint:

SHAPEZ2-4-H4sIALCs72kA/5yUbUvDMBDHv8vhy/girSDk5dyEwQaylaHIXhztbQuGZFxTdIx+d1M6S611DyWQEHK//O+JO8IKlJTxo4DRC6gj3PnDnkDBqNAm03YLAqaps9XTGD2Cegcd7urnPQdhC2PqDfId7kk9FfWCdSlgYj1rygN4hFdQ9w8C3sIhBSRBJmHMd2PaYGH81Hpii2aFrNF6KEVDLEBFNTAi40/2M9p0mblmdkxZw8ZddkGYEfcr/qGjxtfwSTzIgajtwHJvtA/2MnHR7BIpfyVq6TH9uNpx2VadE2+Jo8TJs5q9OX52/Imc/VMaKYZQp6xG15e1Q9ay8lJ0LaqbjDiYn9WQw3su7glv8uUZU+/4fKvH7fhuRgfK3aa2DoNCW+TDijjX1WCopkdZfgsgwAAmIF2pSQQAAA==$

This MCVE is reduced from my crystal-free standalone pin manufacturer, which re-uses the scaffolding shapes in a loop. I first reduced it to a stacker loop, then when testing realized that the shapes don't even need to traverse the loop to observe a throughput reduction.

[prisma lotus]

Thank you for reporting this bug! Our team will review your report soon.
Feel free to add more details in follow-up messages — we're also scanning for duplicate reports automatically now.
📨 There are currently 89 reports awaiting team review. Due to the high volume, it may take a little longer for us to get to yours.

📋 Log files help us investigate issues. You can find yours here:
• Linux: ~/.config/unity3d/tobspr Games/shapez 2/Player.log

💾 Savegame files (.spz2) are very helpful if relevant to the issue!
Export via Main Menu → Play → click the download icon on the relevant savegame.
You can also find them here:
• Linux: $XDG_CONFIG_HOME/unity3d/tobspr Games/shapez 2/

1. [SPZ2-4833] — 👀 72% similar

Conveyor belt slower than other belts when connected to several swapper outputs
Done • Priority: High • Fix: 1.0 Release [1.0.0] • Resolution: Fix Verified

A Conveyor Belt connected to multiple Swapper outputs runs slower than other Conveyor Belts in the same setup, even when both belts receive input from six Swappers. The issue occurs when placing structures and becomes more frequent when clicking on things on the Space Platform. Belt Readers show the same Throughput on all belts despite the visible speed difference. The bug was caused by an error in the update order computation when branches were created and merged within a cluster.
💬 Threads: Swappers with unknown inputs from outsid

2. [SPZ2-3302] — 👀 68% similar

Inefficient belts cause precision loss when there is a fast belt path in the middle of them
Blocked • Priority: Low • Fix: None

When a fast Conveyor Belt path exists between slower Conveyor Belts, precision loss occurs due to timing rounding. The issue happens when an Item is stopped 1 step before a Belt's Output because the next BeltPort's PreAcceptHook prevents handover. When movement resumes, the Item must travel that 1 step first, which takes 1/360 tick at 360 steps/tick speed. This fractional tick gets rounded during the handover calculation, resulting in a 359-step gap. The impact appears negligible as the syste...

3. [SPZ2-3683] — 👀 65% similar

[0.0.9-rc4] Conveyor belt merge inefficient offscreen
Done • Priority: Medium • Fix: Version 0.0.9 • Game: 0.0.9-rc4 • Resolution: Done

Conveyor Belt merge junctions show efficiency bouncing between 99% and 100% when offscreen, resulting in gaps throughout the production line. The issue occurs when placing 2 Conveyor Belts and merging them, then moving the camera away from the Merge. In some cases it happens even while onscreen. The display shows a full belt but calculations swap between approximately 90% and 100% efficiency. The issue is inconsistent and difficult to reproduce reliably.

4. [SPZ2-3426] — 👀 60% similar

Pipe Gates cause inefficiency when not in view
Done • Priority: Highest • Fix: Version 0.0.9 • Resolution: Done

Pipe Gates cause machines to operate at reduced efficiency when not in view. A setup with correct ratios runs at 100% efficiency when focused but drops to approximately 75% when the camera zooms out or looks elsewhere, then recovers when refocused again. The issue disappears when Pipe Gates are bypassed and affects all primary, secondary, and tertiary color processing. The root cause was that DeepCopy failed to copy the ResearchSpeedId field from the base class, preventing container capacity ...

5. [SPZ2-4806] — 👀 58% similar

Gaps are present on conveyor belts with shapes
To Do • Priority: High • Fix: Post 1.0

Conveyor Belts with Shapes show gaps and reduced throughput below the expected 180/m at max Belt Speed. The issue was inconsistent during testing, sometimes appearing when changing FPS limits or when moving away from and returning to Asteroid Miners. The problem may be related to cluster simulation updates being applied at different times, causing desyncs between isolated simulation sets. Developer testing suggests the gaps might be a byproduct of how clusters update independently rather than...
💬 Threads: [0.1.1] Conveyor belts/space belts causi

6. [SPZ2-802] — 👀 45% similar

Merger may block after clearing belts
Done • Priority: High • Fix: 2 - Demo • Resolution: Done

The Merge may block after clearing Conveyor Belts. When Conveyor Belts feeding into a Merge are cleared, the Merge becomes locked in its current position and will not switch inputs until all previous Inputs have Shapes flowing again. To reproduce, place two Conveyor Belts with Shapes merging into one Conveyor Belt, let it fill up, then clear the Conveyor Belts. The Merge should reset its memory when Conveyor Belts are cleared instead of staying locked.

Found 6 similar reports • Searched 3,522 reports • Use /check-duplicates to recheck

[latent kindle]

Hey Kelvin! I seem to be unable to reproduce this issue on my end. Would you be willing to share a save with this issue occurring?

[prisma lotus]

❓ We need a bit more information to investigate this bug. Please check the comments above and provide the requested details.

📋 Log files help us investigate issues. You can find yours here:
• Linux: ~/.config/unity3d/tobspr Games/shapez 2/Player.log

💾 Savegame files (.spz2) are very helpful if relevant to the issue!
Export via Main Menu → Play → click the download icon on the relevant savegame.
You can also find them here:
• Linux: $XDG_CONFIG_HOME/unity3d/tobspr Games/shapez 2/

[lost spindle]

Pasting the blueprint into new save, the decreased throughput state seems to be higher, with the belt reader showing 180 most of the time and occasionally dipping to 179.
Another way to observe the decreased throughput is to place an overflow splitter after the miners (doing so may change the behavior of the setup; delete and re-place the splitter belt to switch it to decreased throughput). In the decreased throughput state, it will divert a shape occasionally, but it will not in the full throughput state.
Another way to observe the decreased throughput is to look at the position of the shapes relative the the arrows on the belt. At full throughput, the shapes will be stationary relative to the arrows. With decreased throughput, the shapes will slowly drift relative to the arrows over time.

I hope that this is the correct save file; the "export save" button crashed the game (segfault trying to show the save file dialog). When I open this save, both copies show the decreased throughput behavior.

[prisma lotus]

✅ Thank you for providing further information, our team will have a look again!

[prisma lotus]

💾 Untitled Savegame

⚠️ Cheats Used — results may differ from normal gameplay

Started in

1.0.3-rc3

Last played in

1.0.3-rc3

Scenario

Classic - Regular

Seed

5066

Research

8%

Buildings

36

Completed

No

[lost spindle]

I also recorded a video of this; it is a bit too long to upload to Discord at high enough quality to see the shapes drift relative to the conveyor belt arrows, so I uploaded it to youtube: https://www.youtube.com/watch?v=MABW5AyEVPU

After pasting the blueprint and adding an overflow splitter to the bottom copy, the top copy runs at decreased throughput and the bottom copy runs at full throughput. This can be seen from the belt readings; in the top copy, the shift of the belt arrows from between shapes to beneath shapes from 0:10 to 0:30; and in the bottom copy, the overflow splitter does not divert any shapes.

At about 0:33, I delete and re-place the belt splitter in the bottom copy, and it switches to the decreased throughput state. The overflow splitter now diverts shapes occasionally.

At 0:45, I delete and re-place the belt merger in the top copy, and it switches to the full throughput state. The belt reader reads a constant 180 and the shapes do not drift relative to the belt arrows.

At 0:59 I switch the bottom copy to full throughput. At 1:09 I switch both copies to reduced throughput.

[lost spindle]

This appears to be framerate-dependent. When the system is in the reduced-throughput state, setting the FPS limit to 60 significantly reduces the number of shapes diverted by the overflow splitter:

[wild nexus]

Yeah, that's weird. Doesn't seem to happen outside of the asteroid miners though.

[prisma lotus]

🎫 Many thanks for reporting this issue! We have created an internal ticket for further investigation and will keep you updated. The internal ticket ID is SPZ2-6293 for reference. If you want to provide further information, just comment on this thread.

[SPZ2-6293] [1.0.3-rc3] Belt connected to irrelevant loop moves shapes at 177/min instead of 180/min