high building counts cause noticeable lag spikes, even when most buildings are idle. enabling/disabling parallel rendering and shape previews has no noticeable effect. when paused, there are no visible/noticeable spikes. the spikes in the attached image occur around every half a second.
the savegame attached is the one i have with noticeable lag, it has 1.7m buildings and is in manufacture mode. there are no wires.
i have an intel i5 11400 with a GTX 1660 super.
#[SPZ2-5924] [1.0.0-A5-RC2] Stutters at high building counts
51 messages ยท Page 1 of 1 (latest)
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 25 reports awaiting team review. Due to the high volume, it may take a little longer for us to get to yours.
โฐ Our team is off on weekends, so it may take a bit longer for us to review your report. Thank you for your patience!
๐ Log files help us investigate issues. You can find yours here:
โข Windows: %USERPROFILE%\AppData\LocalLow\tobspr Games\shapez 2\Player.log
โข Linux: ~/.config/unity3d/tobspr Games/shapez 2/Player.log
๐พ [1.0.0-A3-A5] manufacture mode
Version
1.0.0-alpha3-rc1
Scenario
Manufacture Mode - Regular
Seed
59515
Research
76%
Buildings
1,767,959
Completed
No
i'm not sure how much of a difference it makes, if any, but this is a savegame started in A3-RC1 and upgraded to A4-RC1, A5-RC1 and A5-RC2
here's a video of the performance while paused and unpaused
and the statistics for my shapes being delivered
so it's safe to say there are only really 4 running factories; being the operator shapes, polishing depot and ruby factory (which has overflow protection โ it's the only one that has this)
and here is my log file, if it helps at all. the majority of the log is me just playing, but also includes exiting in and out of the save a couple times to make this bug report
๐ Log File Analysis
Log Analysis (Player.log):
System.Exception: Failed to load background savegame โ menu savegame version 1129 is below minimum supported version 1130, thrown inBackgroundSavegameOptionsFactory.PrepareExistingMenuSavegameand called fromBackgroundSavegameOptionsFactory.CreateOptions. This same error occurred 4 times.
Building conflicts can cause significant lag
Done โข Priority: High โข Fix: 4 - Early Access โข Game: 0.0.0-alpha23 โข Resolution: Done
When there are a large number of Structure conflicts, significant lag occurs. The issue is triggered when copying and pasting large amounts of Structures, particularly when copying entire Space Platform contents. The lag happens because the game calculates conflicts between all overlapping Structures, even though a simpler approach of just checking if Structures exist at the same time could be used. The performance issue is noticeable with hundreds of thousands of Structures, and occurs regar...
Autosaves impacts gameplay when they happen at higher structure counts
Done โข Priority: Medium โข Fix: None โข Game: 1.0.0-dev โข Resolution: Won't Fix
Autosaves cause noticeable gameplay pauses when they occur at higher structure counts. The issue is triggered every 5 minutes during autosave with high structure and space platform counts, demonstrated with a savegame containing 616K structures. Each autosave creates an obvious pause that interrupts smooth gameplay. Players expect to play smoothly even when autosaves occur. The issue was closed as won't fix, with the suggestion to increase autosave interval time.
Larger saves have really long save times for alpha 4+5 (3+ hours for 1.4million structural units)
In Progress โข Priority: Critical โข Fix: 1.0 Release [1.0.0]
Large savegames with over 1 million structures are taking significantly longer to load in alpha 4 and alpha 5 compared to alpha 3. One user reported a savegame with 172k machines going from about 1 minute in alpha 3 to over 8 minutes in alpha 4 and 5, while another reported 3+ hours for 1.4 million structures. Rocket baking added in alpha 4 contributes roughly 1.5 seconds of additional load time. However, the issue has been difficult to reproduce consistently, as some testers see stable loadi...
๐ฌ Threads: [1.0.0-ALPHA5-RC1] Loading saves is very
Big savefiles have very long loading times and cause the game to freeze if it's minimized while loading
To Do โข Priority: Medium โข Fix: 1.0 Release [1.0.0] โข Game: 0.1.1
Large savegames with over 500,000 structures experience very long loading times in shapez 2. When the game is minimized during loading in borderless mode, it appears to freeze and may show a "stopped working" error message, though it will eventually load if given enough time. The loading widget stops spinning during longer loads, making players think the game has crashed. Testing showed that loading times have increased in newer builds, with borderless mode taking significantly longer when fo...
๐ฌ Threads: [0.1.1][Windows] Freezes when quitting
Loading time is extremely slow with ~450k buildings
Done โข Priority: Highest โข Fix: 4 - Early Access โข Game: 0.0.0-alpha22.4 โข Resolution: Done
Loading time for savefiles with approximately 450,000 structures is extremely slow, taking around 4-5 minutes to complete. The performance issue was suspected to be caused by quadratic scaling in the loading algorithm. This significantly impacts players with large factories, making the game difficult to access. The issue has been verified and fixed, with loading time improved by roughly 40% through linear scaling optimization.
Multiple failed assertion notifications are displayed when loading a specific save with 540K machines.
To Do โข Priority: Critical โข Fix: None
Loading a savegame containing 540K machines triggers over 20 failed assertion notifications in the console log. This occurs on the master build when importing and loading the specific save file, which takes a minute or two to load. The issue does not reproduce on Alpha 5, though both builds show multiple failed allocations at the end of the log. Expected behavior is that the game runs without errors. The issue reproduces consistently at a rate of 5 out of 5 attempts.
Found 6 similar reports โข Searched 3,194 reports โข Use /check-duplicates to recheck
same save, but with more chart info and a fixed max ms of 120
Can I have your settings.json file to look at?
Looks like there are possibly a few issues there.
โ Thank you for providing further information, our team will have a look again!
Try it with v-sync off?
no change.
โ Thank you for providing further information, our team will have a look again!
something i noticed; i booted the game fresh and my performance graph looks like this with the same graph settings as this message here
that first graph was taken during an hours long session
after a minute or so of going around the map loading my factories
๐ค
And that is constant after the minute of moving around?
yes. i'll see if going to the main menu and back has any effect
i did also change video settings (and then changed them back) in that time as well, so that may have affected it too. i'll test that next relaunch
going to the main menu and back has no effect - back up to almost 100ms spikes now. i'll relaunch and see if i can isolate what makes the spikes bigger
I have a computer closer to your specs for testing. That seems to be showing what you are experiencing.
Then I install OBS studio to get a video and it changes ๐
after some experimenting
- turning vsync off seems to help somewhat. it does help to lower the spikes a bit, or spread them across more frames somehow? but the spikes are definitely still there.
- finnicking with settings and the game unpaused didn't seem to affect any values at all.
- did a test (video attached) looking at a currently active factory and then jumping back to the same place. it did have an effect
at the start of the video the numbers are slightly high as the game isn't focused. you can see it approach 40ms before i jump to a factory
though i couldn't seem to replicate this when jumping to more factories such as ruby and sapphire
oh. i tabbed back into the game after typing all that and the spikes are now at 130ms..
๐ซ 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-5924 for reference. If you want to provide further information, just comment on this thread.
[SPZ2-5924] [1.0.0-A5-RC2] Stutters at high building counts
@kindred fern It's happening for my lower spec machine, not my higher spec machine. That is what I will make the internal ticket about. My main computer shows nothing like this issue.
very weird. i'll do some more testing to see what exactly might be causing it
Not sure if you need to do that. We have tools that should be able to reveal what is happening.
got it. i sat in the same place after a fresh launch for a solid 5 minutes or so. no change in spikes. clicked waypoints to a few different factories, and went straight back. no change. clicked on one of the ones i already clicked, but zoomed in to see buildings and shapes, then went straight back to the original spot. spikes now reach a consistent 85ms, when they were below 50ms before
now i know how to avoid them a bit better ๐
I could see it happening for me and I barely moved.
You had previews off right?
yeah the spikes are there no matter what, but something causes them to increase over time. definitely don't think i have the ability to find what causes them to start in the first place lol
yes
vsync seems to help when the spikes are less intense, but no difference when they're already reaching 100ms
oh woah wait a sec, turning off simulation threads causes the spikes to become basically identical to https://discord.com/channels/1000343719314198548/1481617104485482668
oh wait no i'm wrong. it gives me one huge spike and one tiny spike every time. the tiny ones are the ones this report is about, but they're likely still related since they happen in sync with eachother
i think for now though i've reached the limit of usefulness for tests i can do. i'll leave it to the smart people lol