Projector replication causing file size issues

Psyc shared this bug 3 months ago
Reported – Awaiting fix

Step 1- You design a ship and then like most people do, blueprint the ship "blueprint 1" and place it into the projector so you can repair it

Step 2- Blueprint the ship again, with the projector projecting the ship so it saves "blueprint 2".

Step 3- If you then head into the projector and add that blueprint "blueprint 2" into the projector the ships file size and supposed block count gets larger.

Step 4- Continue this process until the file size becomes unbearable and causes a lot of lag when copying or blueprinting.

Not so much a bug but more an unfortunate mechanic that makes updating projectors less intuitive.

Comments (4)

photo
1

Haha, yeah. This can get out of hand. I've had to resort to loading the blueprint into the projector, align the projector, then remove the blueprint, and save a final blueprint. Then if I ever make the ship, I have to know to load up the same blueprint into the projector after its done. Reduces the bloat, but also is a real PITA.

Unsure how this dynamic could ever be 'bettered' though. It really is a catch22 loop.

photo
1

Haha I did see your report and then I saw it's date and was thinking "Oh no, this'll never get fixed". I was making a blueprint and couldn't figure out why the blueprint kept getting bigger and bigger while I was developing it.

photo
photo
1

God I remember reporting this years ago. We ran into an issue where we couldn't load a specific blueprint onto a server we were playing on at the time and then we realised the blueprint was ~80MB because it had so many 'previous versions' cached in the blueprint via the 30 or 40 projectors worth of data it was now storing.


If memory serves, someone actually submitted a fix for it back when the game code was open sourced on GitHub but it never made it into the game.

photo
1

Even more so when each one of those has a couple PB's with 80k scripts in them! Every projection has all the data from CustomData, and Program Block scripts stored as well. It can easily get out of hand ... like 80mb lol

photo
photo
1

Hello, Engineers!

Thank you for reporting this and I'm sorry you're experiencing this issue. Would it be possible to provide a video of this being done? I have been trying for quite some time to reproduce the issue but can't seem to quite understand how this is being done despite your steps. It would be great to see this visually if any of you could please provide one. I apologise for asking for further information! :) If you could please do this via GoogleDrive and remember to put the video to public so it is viewable for me :)

Kind Regards

Laura, QA Department

photo
1

Hello Laura, I can reproduce it in a video for you but, not for the next few days as I'm away. I'll be able to do so in 4-5 days. One of the others seems to understand the bug, perhaps one of them could help you sooner than I. If it helps at all, you can start my steps with a large blueprint so the replication is more visible. It's mainly an issue with using grids which are using a projector which is on and projecting itself. Blueprinting said grid will duplicate the projector and grid size and block count. If you then project the blueprint you just made on the original grid you'll see the size has gone up by 1/3 or so as it's now the grid + the grid in a projector and the grid again in the projector of the grid projected.

photo
1

Hello, Psyc!

That's no problem, this will remain open for you :) if you could, that would be excellent when you are free. So far I have been unable to reproduce the issue.

Kind Regards

Laura, QA Department

photo
1

Hello, Psyc!

Have you been able to create a video at all? I am still unable to reproduce the issue sadly.

Kind Regards

Laura, QA Department

photo
1

https://drive.google.com/drive/folders/1eseDBqOHOyjSDxEXfFnfIKbHqJNJNiHd?usp=sharing

Here's a video explaining it, I hope I am clear enough in it. The link should contain the video and the blueprint I used in it too.

photo
2

Hello, Psyc!

Thank you so much for the video and blueprint, this was a perfect explanation! :) I have successfully reproduced the issue and reported this internally.

Kind Regards

Laura, QA Department

photo
1

Okay Laura, thanks for the support!

Oh and do bugs with pressurisation get looked into at all?

photo
1

I found a quick fix for this back in the day as I was wanting to upload cleaner BP's to the Steam Workshop etc...

I FIXED it by building the large Blueprint file from scratch using a projector in creative mode, I then copied the item as normal and replaced the old BP file with the recent built copy (or create a new one entirely).

I used many Nanobot/build & repair, sat back and watched as it was my large ship haha... More than halved the original BP file

Hope this helps

ShArPy1o1

:)

photo
photo
3

Great that you work on a fix finally.

But please do not resolve this issue by crippling nested projections by introducing a strict limit on recursion depth.

The main problem is when a projector is projecting itself with a projection loaded. This is the typical self-repair projector use case which can easily build up deep nesting as players iterate on their design and repeatedly blueprint the ship and loading it back into the same projector.

It can be solved by detecting this case and not projecting the self-repair projector without the projection loaded. It is never a problem, since after building such a ship from a projection one can always load the original blueprint into the designated repair projector. Also, it should not affect paste (F10) operations.

Limiting the recursion depth on saving or saving without the projection loaded are not proper solutions.

Many advanced ships are using 1-2 levels of nested projections to build bombs, missiles and other tricky stuff, which would still need recursive projections if such a ship is welded in-game rather than pasted in.

There are even self-printing arm designs depending on 5-6 levels of recursive projection for their segments, but those are using separate projectors, therefore do not belong into the case described above.


Please consider the above while fixing the issue. Thanks!