Allow single-block groups full functionality on toolbars (esp. cameras)
Submitted
Currently, many blocks bound to toolbars are erased after being destroyed, even if they are replaced via projector. This can be circumvented in many cases by placing a single block (such as a timer block or a camera) in its own group, and putting the group on the toolbar.
Unfortunately, in the case of the camera, this prevents the "View" option from bring bound. This makes sense for multiple cameras in one group... but not-so-much for a group consisting of only one camera. I believe the same is true for the Jump Drive block, even when there is only one drive in the group.
One should be able to bind all possible functions to a toolbar when the group consists of only one block. Players waste a lot of time constantly re-binding blocks.
I like this feedback
To clarify: The "Jump" function of the Jump Drive block.
To clarify: The "Jump" function of the Jump Drive block.
For some reason looks like players are not too receptive regarding toolbar improvements :( This a very good idea, not sure why it did not get more votes in 3 weeks.
My toolbar related improvement ideas did not receive more than 3-4 votes in weeks, also.
For some reason looks like players are not too receptive regarding toolbar improvements :( This a very good idea, not sure why it did not get more votes in 3 weeks.
My toolbar related improvement ideas did not receive more than 3-4 votes in weeks, also.
I hit the same issue with blocks replaced from a projection. Since blueprints change the ID of the blocks from the original, hotbars don't work with blocks that are replaced from the projection, and if the control seat is destroyed and replaced from the projection your hotbars are full of greyed-out cubes. Except for the block groups, of course.
If a user adds more blocks to a group after it's been bound to the hotbar with a function that doesn't apply to multiple blocks (view for cameras, control for remote controls, run with argument for programmable blocks (although I don't know what this one isn't actually supported - you can "run" but it doesn't allow you to set an argument), jump for jump drives etc.), the hotbar item could just become greyed out. The game already does this sort of sanity-checking on the hotbars, e.g. greying out hotbar items to blocks that are no longer functional, so it seems like it would be straightforward to enforce that the hotbar binding is only enabled as long as the group contains precisely one working block. This would mean that you could even have a group with multiple functional blocks, but switch off all but one of them to enable the hotbar item.
I hit the same issue with blocks replaced from a projection. Since blueprints change the ID of the blocks from the original, hotbars don't work with blocks that are replaced from the projection, and if the control seat is destroyed and replaced from the projection your hotbars are full of greyed-out cubes. Except for the block groups, of course.
If a user adds more blocks to a group after it's been bound to the hotbar with a function that doesn't apply to multiple blocks (view for cameras, control for remote controls, run with argument for programmable blocks (although I don't know what this one isn't actually supported - you can "run" but it doesn't allow you to set an argument), jump for jump drives etc.), the hotbar item could just become greyed out. The game already does this sort of sanity-checking on the hotbars, e.g. greying out hotbar items to blocks that are no longer functional, so it seems like it would be straightforward to enforce that the hotbar binding is only enabled as long as the group contains precisely one working block. This would mean that you could even have a group with multiple functional blocks, but switch off all but one of them to enable the hotbar item.
Replies have been locked on this page!