This object is in archive!
Projector replication causing file size issues
Not a Bug
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.
Files:
Bugos.jpg
I have the same bug 
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.
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.
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.
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.
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
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
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!
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!
Hello, Engineers,
after this behavior was checked by our internal teams, it turned out that this is actually not broken but working as expected.
As the projector keeps copy of the grid, the blueprint size will grow. This is not a bug.
I will close this thread now.
Thank you for your understanding.
Kind Regards
Keen Software House: QA Department
Hello, Engineers,
after this behavior was checked by our internal teams, it turned out that this is actually not broken but working as expected.
As the projector keeps copy of the grid, the blueprint size will grow. This is not a bug.
I will close this thread now.
Thank you for your understanding.
Kind Regards
Keen Software House: QA Department
Replies have been locked on this page!