[1.201.013] Projector shows blueprint at the wrong location

The question is, why does the projector, which itself has all sliders set at 0, still show the blueprint at this seemingly weird offset.

Certainly my own understanding was that the projector refers to the blueprint grid pivot, and the grid pivot only, to determine in which position the blueprint is projected. However, this does not appear to be the case. Observe:

Here I took the projector vessel from the test world, multiplied it, and loaded each with a small test blueprint. (I also moved the projector vessel's pivot to a new, gray-colored block in the back so it doesn't confuse the issue.)

From right to left:

Right: The blueprint is a single red block, with its privot within that block. The projector shows it in the expected position, overlapping with itself.

Center: The blueprint is two blocks, the pivot within the front, yellow one. The projector shows it in the expected position, overlapping with itself.

Left: The blueprint is a single red block, but the pivot is outside, one block in the front. The projector, however, on its own, displays it, shifted, one block to the front so that the block is overlapping and the pivot is one block ahead.

I say again, none of the projectors have any offset specified in their terminals. The only notable difference is that the pivot in the blueprint lies outside the volume occupied by a block in any direction.

This "proactivity" in adjustment is unexpected and thus cannot be planned for by the player, at least not with what the game trains them to expect. It should be removed to always make the pivot be the sole reference so that the projection behavior becomes, and remains, predictable.

Attachment: Updated world with vessels and blueprints seen in screenshot

Also, perhaps interesting to note, or to rule out one suspicion, is that loading the original blueprint into the modified projector vessel (the one with one extra gray block in the back) does not cause the projector to "autocompensate" for the new, increased length; so, whatever determines by how much the blueprint is unexpectedly shifted, its probably not the vessel's own length.

Hello, andersenman!

Thank you for commenting and helping with the issue. I have looked at your save file and like with the original poster, could you explain what you'd expect to happen? This way I can speak with a designer and see if there is an issue. I appreciate you're showing what the issue is in your opinion, but it would be great to read/see what you think SHOULD happen in comparison si I can gather a full understanding as it's not hugely obvious to me (and I apologise for this) :)

Kind Regards

Laura, QA Department

Okay, please excuse the baby steps for ensuring common understanding of the issue.

The grid pivot is the location used as a reference, the origin, from which any and all blocks in a blueprint, or in fact a grid in a world, are displaced to make up a build. It is the place from which the <Min> element counts the spaces, the grid cells, to tell SE where that block sits. If a block sits at <Min x="0" y="0" z="0" />, the <Min> element is omitted and implied. Example:

[…]
          <CubeBlocks>
            <MyObjectBuilder_CubeBlock xsi:type="MyObjectBuilder_CubeBlock">
              <SubtypeName>LargeBlockArmorBlock</SubtypeName>
              <ColorMaskHSV x="0.122222222" y="0.05" z="0.46" />
              <BuiltBy>144115188075855895</BuiltBy>
            </MyObjectBuilder_CubeBlock>
            <MyObjectBuilder_CubeBlock xsi:type="MyObjectBuilder_CubeBlock">
              <SubtypeName>LargeBlockArmorBlock</SubtypeName>
              <Min x="0" y="0" z="1" />
              <ColorMaskHSV x="0" y="0.15" z="0.25" />
              <BuiltBy>144115188075855895</BuiltBy>
            </MyObjectBuilder_CubeBlock>
          </CubeBlocks>
[…]

The grid pivot may be visualized in game by flipping the appropriate switch:

In the 3D view, the pivot looks like this:

Notably, a grid's pivot, its origin, may be outside a block, or in fact a place where there is no other block anywhere in X, Y, or Z. In practice, this is caused by as little as placing a block, adding another one to it, and then removing the first block.

Subsequent additional block placements on that grid do not ever change where this pivot is.

The only way to change where a grid's pivot is located is by placing a completely new, separate block, then taking a copy of the grid whose pivot you want to change, and pasting it onto that new grid. This effectively recalculates and rewrites the <Min> information for all pasted blocks to now relate to the new location of the origin.

(Of course, now you could remove what was the new and separate block until now and continue building, with the pivot now remaining in the new location.)

As shown in the screenshot that compares the three projections, for whatever implemented logic, let alone reason, if there is not actually a block in the place of the pivot or origin in a blueprint, the projector arbitrarily adds an offset to the projection to "correct" for it so that it comes to be aligned with the grid position in the blueprint where there is a block present after all.

And this is bad.

Why? Because as blueprints change, especially if outwardly the same blueprint is manually rebuilt but this time with the pivot or origin in a different place, the reason for the correction may or may not be present anymore, causing any deliberately set offsets in the projector's terminal (including offsets of zero) to not be applicable anymore, leading only to confusion and frustration of which SE has plenty enough already if I dare say so.

So, whatever logic causes this unauthorized displacement should be eliminated or corrected so that the player has a chance to reliably anticipate, even predict, where and how a blueprint's projection ends up given known offsets in the terminal and known position of a grid's pivot.

And as a note, all of this does not only apply to translation but to rotation, too.

By the way, now that I think about it, I could imagine this automatic adjustment is deliberately in place to prevent any potentially exploitative or otherwise undesirable effects. Say, a blueprint that may only have a few blocks but an offset of a magnitude that's way greater in numeric figure that it's actually in size on account of the blocks it's built from. You know, have a projector on Earthlike and display a sky-filling middle finger built from blocks to the Moon or something.

However, indiscriminately "normalizing" that pivot offset seems like a disproportionate countermeasure that punishes those players who do need such an offset; so, if this is really the reason behind the automatic offset correction, then a more reasonable and proportionate method to mitigate potentially unwanted side effects should be found.

Besides, it takes just one block that's actually at that distance in the blueprint to defeat this countermeasure, so, nothing gained either way.