projector - storing nested projector data
Bottom line: I think the projector is storing all the data of the nested projectors and causing my world and blueprint files to grow exponentially.
I was playing with Nanobot build and repair system mod (https://steamcommunity.com/sharedfiles/filedetails/?id=857053359) and I was working on an idea for a multi-projector self-repair system. (each projector held a section of the ship up to the next projectors, 5 total sections, the reason I was trying this: the offset limits to the projector could not get the projection to match up to the ship I was building with the currently limited projector offsets (large ship ~200 blocks long ~100 blocks wide).) and I noticed while I was working on it my computer kept getting slower and slower, then started to take 20+ minutes to save. (I7 5820K, 16 gigs of ram, GTX-980) so I went to look into why and noticed my save file was ~11gig, and the blueprints for each section of the ship were huge as well, sections:1.7gb, 3.3gb, 619mb,2.2gb, 2.0gb.
I get how the logic for the projector works to save it, but essentially my idea breaks how the projector works, if you all have a fix for having a ship divided into smaller separate projectors that hold the information for the projectors next to them without exponentially growing the world I would love to hear it. but I know that if this concept works in mp, someone could easily take it into a server to exponentially grow the world/potentially crash the world which is the reason I am mentioning it here.
simple repeat,
create a ship with 2 projectors
step 1: blueprint ship, apply blueprint to projector 1
step 2: blueprint ship, apply blueprint to projector 2
- repeat steps 1 and 2 until your world/projector files are huge
The file continually grows and grows as the projectors will hold all projector data for 1 and 2 in a continual growing nested piece of data, even though you should never get to most of those other blueprints within them.
I have the same bug
side note: if you create some way to automatically section off ships for multiple projections and store their data as separate parts to a single whole it would also complete what I was trying to accomplish and lower the amount of data to be displayed by a single projector on massive ships.
side note: if you create some way to automatically section off ships for multiple projections and store their data as separate parts to a single whole it would also complete what I was trying to accomplish and lower the amount of data to be displayed by a single projector on massive ships.
Hello, Engineer!
Thank you for your feedback! Your topic has been added between considered issues.
Please keep voting for the issue as it will help us to identify the most serious bugs.
We really appreciate your patience.
Hello, Engineer!
Thank you for your feedback! Your topic has been added between considered issues.
Please keep voting for the issue as it will help us to identify the most serious bugs.
We really appreciate your patience.
You don't even need two projectors for this to happen. Growing blueprint file size can be reproduced easily by repeatedly snapshotting a grid and putting the resulting blueprint back into a single projector on that same grid. Every repetition grows the depth of projections stored in the blueprint, thus the serialized XML becomes deeply nested and much bigger in general.
This happened during the development of a race car I modified. After every modification I made a blueprint of the car, then put it back into the "repair" projector of the same car I blueprinted.
A few iterations resulted in a deeply nested structure of <ProjectedGrid> elements (among others) in the bp.sbc file produced.
Please find the resulting blueprint attached. It speaks for itself.
Keen, please, don't just nurf the projectors/blueprints by not storing the projection or so.
I would suggest adding a parameter to the projector to limit nesting. The default value of this parameter would be 1, which would allow for a self-repair projection for the projector's own grid.
If somebody wants a self-repairing torpedo/bomber ship, then this parameter could be increased to 2, which would mean that the projector used for the torpedos/bombs could be repaired with the proper torpedo/bomb blueprint loaded and positioned correctly. I don't think there would be realistic use cases above 2 levels of nesting, but as you know, 640kB is enough for everything...
Actually, here is a use case for the N-level nesting:
https://support.keenswh.com/spaceengineers/pc/topic/projector-blueprint-loop-lost-settings
You don't even need two projectors for this to happen. Growing blueprint file size can be reproduced easily by repeatedly snapshotting a grid and putting the resulting blueprint back into a single projector on that same grid. Every repetition grows the depth of projections stored in the blueprint, thus the serialized XML becomes deeply nested and much bigger in general.
This happened during the development of a race car I modified. After every modification I made a blueprint of the car, then put it back into the "repair" projector of the same car I blueprinted.
A few iterations resulted in a deeply nested structure of <ProjectedGrid> elements (among others) in the bp.sbc file produced.
Please find the resulting blueprint attached. It speaks for itself.
Keen, please, don't just nurf the projectors/blueprints by not storing the projection or so.
I would suggest adding a parameter to the projector to limit nesting. The default value of this parameter would be 1, which would allow for a self-repair projection for the projector's own grid.
If somebody wants a self-repairing torpedo/bomber ship, then this parameter could be increased to 2, which would mean that the projector used for the torpedos/bombs could be repaired with the proper torpedo/bomb blueprint loaded and positioned correctly. I don't think there would be realistic use cases above 2 levels of nesting, but as you know, 640kB is enough for everything...
Actually, here is a use case for the N-level nesting:
https://support.keenswh.com/spaceengineers/pc/topic/projector-blueprint-loop-lost-settings
Implemented Python script to remove nested<ProjectedGrids> elements from blueprints:
Please find the script attached. Proper file extension is just .py, but that cannot be attached here, so I appended .txt to the filename.Usage: blueprint_cleaner.py bp.sbcRequires Python 3.6 or above. Works on both Windows and Linux.
Blueprint files are called bp.sbc and encoded in XML format.
If you use it with a custom server, please install the defusedxml Python package as well, which will fix the XML based denial of service attacks. You do not need it if your users cannot upload custom blueprints or if you use it only for your blueprints.
The blueprint I attached to my previous comment was 11MB uncompressed (bp.sbc file size). After the cleanup it is 443kB, but still contains the top level projection required for repairing the car. All the "historical" projections accumulated during the iterative build/fix process have been removed.
Implemented Python script to remove nested<ProjectedGrids> elements from blueprints:
Please find the script attached. Proper file extension is just .py, but that cannot be attached here, so I appended .txt to the filename.Usage: blueprint_cleaner.py bp.sbcRequires Python 3.6 or above. Works on both Windows and Linux.
Blueprint files are called bp.sbc and encoded in XML format.
If you use it with a custom server, please install the defusedxml Python package as well, which will fix the XML based denial of service attacks. You do not need it if your users cannot upload custom blueprints or if you use it only for your blueprints.
The blueprint I attached to my previous comment was 11MB uncompressed (bp.sbc file size). After the cleanup it is 443kB, but still contains the top level projection required for repairing the car. All the "historical" projections accumulated during the iterative build/fix process have been removed.
Hello, Engineers!
Just to let you know that his sounds like this thread here https://support.keenswh.com/spaceengineers/pc/topic/projector-replication-causing-file-size-issues I have reproduced and reported it internally. Please keep an eye on the mentioned thread for any further updates :)
Kind Regards
Laura, QA Department
Hello, Engineers!
Just to let you know that his sounds like this thread here https://support.keenswh.com/spaceengineers/pc/topic/projector-replication-causing-file-size-issues I have reproduced and reported it internally. Please keep an eye on the mentioned thread for any further updates :)
Kind Regards
Laura, QA Department
Replies have been locked on this page!