Projectors need to remember toolbar configurations
In a nutshell projectors need a rework so they remember singular blocks placed on Control Seat action bars and not forget them if built/rebuilt from a projector. Photos attached for reference as to what I'm referring to.
In the first photo you will see a control seat toolbar for a ship I was working on at the time of submitting this. You can see the user has their choice of 7 turrets they can choose to control. However if something happens and the seat is destroyed and has to be rebuilt, or is being built for the first time (less common), you'll get an instance of the second picture where the projector will NOT remember your toolbar configuration if repairing from an onboard projector, or building for the first time. Instead you will be treated to those gray cubes on your bar because the projector doesn't remember what is there when it needs to.
A potential workaround is to assign each of the 7 turrets to its own group where it is the only member. However this has its flaws too. If I assign Turret One to a group by itself, the bar may be able to remember that group and singular turret for something such as Subsystem Targeting. However it doesn't allow me to actually take control of the turret using the group function. I would have to again clear out a slot on the bar, search through the list of blocks, then reassign it to the action bar.
This is extremely infuriating as it completely defeats the purpose of being able to assign individual blocks to the action bar as part of blueprints if the projectors won't even remember the configuration. Because then if something happens or I'm building for the first time, I'm having to reprogram half my ship or station. The only way to prevent this from happening is to essentially delete the old copy and spawn in a new one. This seriously needs to change as I should not need to reassign half my toolbars when the project should be remembering them as it's entire reason for existing is remembering blueprints for the purposes of production/repair.
I have the same bug 
This is actually an issue with all action bars in the game e.g. timers, sensors, buttons etc - the only thing that is remembered is groups. I've also been using this workaround for a long time, using group(s) for each type of block(s) I need in an action bar. Sadly I think this bug has been around since the beginning of the game, which I think says a bit about the QoL.
Also, if I remember correct, the camera has the same issue, where one cannot view through it using a group?
This is actually an issue with all action bars in the game e.g. timers, sensors, buttons etc - the only thing that is remembered is groups. I've also been using this workaround for a long time, using group(s) for each type of block(s) I need in an action bar. Sadly I think this bug has been around since the beginning of the game, which I think says a bit about the QoL.
Also, if I remember correct, the camera has the same issue, where one cannot view through it using a group?
This is actually an issue with all action bars in the game e.g. timers, sensors, buttons etc - the only thing that is remembered is groups. I've also been using this workaround for a long time, using group(s) for each type of block(s) I need in an action bar. Sadly I think this bug has been around since the beginning of the game, which I think says a bit about the QoL.
Also, if I remember correct, the camera has the same issue, where one cannot view through it using a group?
This is actually an issue with all action bars in the game e.g. timers, sensors, buttons etc - the only thing that is remembered is groups. I've also been using this workaround for a long time, using group(s) for each type of block(s) I need in an action bar. Sadly I think this bug has been around since the beginning of the game, which I think says a bit about the QoL.
Also, if I remember correct, the camera has the same issue, where one cannot view through it using a group?
My understanding of what's happening here is that toolbar references from built blocks to unbuilt blocks in a projection are pointed to the virtual block in the projection, but if the projection is turned off, those references are broken. You can see this in action during the assembly of a projected grid if you turn the projection off. the reason that groups can persist through this is because it is the responsibility of the block to know it's part of a group, and to have that group generated if it doesn't exist. groups are then string-matched by their name (which is why you can have groups merge and unmerge when grids are connected and disconnected) so toolbar connections to a group will survive provided the group has a type that reflects the toolbar's command when the first block in that group is first functional and produces the group in the terminal.
TL:DR block refs are done by block ID, which changes when things get rebuilt (or built the first time?), but group references are done by string names, which is more generic and doesn't change. Your replacement chair is referencing virtual blocks in the projection, not the real blocks sitting in their places.
This issue has been around a very, very long time. It's been around long enough that the multigrid projector plugin adds a button to projectors that re-applies all the toolbar references. Because ships don't know their "blueprint" once they've been finished references.
I bet if references were stored as coordinates relative to the block doing the referencing they would survive a lot better and even open up options for modularity for people who really know how the game works.
I hope they solve this problem a better way for SE2, because projector and toolbar nonsense is one of the big barriers to efficient logistics and good "plug-and-play" hardware.
My understanding of what's happening here is that toolbar references from built blocks to unbuilt blocks in a projection are pointed to the virtual block in the projection, but if the projection is turned off, those references are broken. You can see this in action during the assembly of a projected grid if you turn the projection off. the reason that groups can persist through this is because it is the responsibility of the block to know it's part of a group, and to have that group generated if it doesn't exist. groups are then string-matched by their name (which is why you can have groups merge and unmerge when grids are connected and disconnected) so toolbar connections to a group will survive provided the group has a type that reflects the toolbar's command when the first block in that group is first functional and produces the group in the terminal.
TL:DR block refs are done by block ID, which changes when things get rebuilt (or built the first time?), but group references are done by string names, which is more generic and doesn't change. Your replacement chair is referencing virtual blocks in the projection, not the real blocks sitting in their places.
This issue has been around a very, very long time. It's been around long enough that the multigrid projector plugin adds a button to projectors that re-applies all the toolbar references. Because ships don't know their "blueprint" once they've been finished references.
I bet if references were stored as coordinates relative to the block doing the referencing they would survive a lot better and even open up options for modularity for people who really know how the game works.
I hope they solve this problem a better way for SE2, because projector and toolbar nonsense is one of the big barriers to efficient logistics and good "plug-and-play" hardware.
Still an issue. Hopefully we'll know more soon enough on what they plan to do because this cripples certain builds completely. highlighted a "best answer" for the moment as it shows how far reaching this issue is.
Still an issue. Hopefully we'll know more soon enough on what they plan to do because this cripples certain builds completely. highlighted a "best answer" for the moment as it shows how far reaching this issue is.
still an issue as of 1.206 and Fieldwork release. Changes in Fieldwork to projectors are most certainly welcome and the team did well with them. Simultaneously this still needs to be fixed yesterday as it drastically reduces usefulness of projectors and makes them nigh useless.
still an issue as of 1.206 and Fieldwork release. Changes in Fieldwork to projectors are most certainly welcome and the team did well with them. Simultaneously this still needs to be fixed yesterday as it drastically reduces usefulness of projectors and makes them nigh useless.
Hello Engineers,
Thanks a lot for the detailed explanation and screenshots — they really help clarify the situation.
At the moment, when rebuilding a block like a control seat from a projector, toolbar setups don't always come back the way they were originally configured — especially when assigning individual blocks like turrets. So even if the blueprint had everything set up, the newly built version may show empty or default toolbar slots.
In the background, this happens because blocks in a blueprint and blocks placed by a projector are treated as new entities with different internal IDs. That makes it tricky to match toolbar assignments exactly, since there's no 1:1 reference to the original block.
A common workaround is to use groups, even if it’s just one block per group. This helps preserve some functionality — like targeting or triggering — though we know it doesn’t fully replace direct control.
This is a known limitation and something we’d like to improve, but it hasn’t been prioritized just yet. Your feedback helps underline how impactful this is — so thank you again for raising it.
Best Regards,
Ludmila Danilchenko
Head of Space Engineers QA
Keen Software House
Hello Engineers,
Thanks a lot for the detailed explanation and screenshots — they really help clarify the situation.
At the moment, when rebuilding a block like a control seat from a projector, toolbar setups don't always come back the way they were originally configured — especially when assigning individual blocks like turrets. So even if the blueprint had everything set up, the newly built version may show empty or default toolbar slots.
In the background, this happens because blocks in a blueprint and blocks placed by a projector are treated as new entities with different internal IDs. That makes it tricky to match toolbar assignments exactly, since there's no 1:1 reference to the original block.
A common workaround is to use groups, even if it’s just one block per group. This helps preserve some functionality — like targeting or triggering — though we know it doesn’t fully replace direct control.
This is a known limitation and something we’d like to improve, but it hasn’t been prioritized just yet. Your feedback helps underline how impactful this is — so thank you again for raising it.
Best Regards,
Ludmila Danilchenko
Head of Space Engineers QA
Keen Software House
Replies have been locked on this page!