Factorio Forums

The blueprint to remove the belt also blocks the belt

A belt marked for deconstruction stops transporting items; this is the intended behaviour as far as I know.

If that's not the situation you are trying to describe, I think you need to explain more clearly: steps to replicate, the expected result and the actual result.

SoShootMe wrote: ↑

Fri Jul 07, 2023 6:58 am

A belt marked for deconstruction stops transporting items; this is the intended behaviour as far as I know.

This behavior is wrong, how blueprint can stops the items on working belt? Event deconstruction blueprint.

another example, the blueprint that changes the direction of the belt does not stops the belt

SoShootMe wrote: ↑

Fri Jul 07, 2023 6:58 am

A belt marked for deconstruction stops transporting items; this is the intended behaviour as far as I know.

If that's not the situation you are trying to describe, I think you need to explain more clearly: steps to replicate, the expected result and the actual result.

That is correct and working as intended.

Rseding91 wrote: ↑

Fri Jul 07, 2023 7:50 am

SoShootMe wrote: ↑

Fri Jul 07, 2023 6:58 am

A belt marked for deconstruction stops transporting items; this is the intended behaviour as far as I know.

If that's not the situation you are trying to describe, I think you need to explain more clearly: steps to replicate, the expected result and the actual result.

That is correct and working as intended.

as indeed by whom? Please, explain how factorion developers understand the meaning of blueprint? What is it and what is the purpose of blueprint?

Also, please return this topic to the original thread and do not move it without reason, thank you.

Your bug report is based on fundamentally incorrect assumption that it is the "blueprint" (entity ghost) that is causing the observed behavior while its not that. Items stop flowing because a transport belt is marked to be deconstructed.

When a belt is marked to be deconstructed, it must stop moving. If it would not stop moving, a construction robot would arrive to it, would see there are some items to pickup before belt can be deconstructed, it would get rid of the items but later when it would arrive again to collect the belt there would be new items since that belt would be moving. That means such belt would be literally undeconstructible even when a player requested it to be deconstructed. That is working as intended right now and a belt will not be made to work even when marked to be deconstructed. Also a belt marked to be deconstructed cannot keep working because it disconnects from neighbour belts, it does not cause side loaded tranport belt from changing shape for example. There is also a consistency reason here, we do not save-load belt connections so on a given tile there may be at most 1 entity of a given force connecting to nearby belt connectables, when belt is marked to be deconstructed it disconnects because a belt ghost over it will become one connecting to nearby belts and ghosts.

As for why placing splitter ghost causes belt to be marked as to be deconstructed, that is required because belt and splitter are not upgradable to each other as they have different positions and sizes. A player may place splitter as one action but construction robots cannot so there are 2 actions queued: belt is marked to be deconstructed and splitter ghost is placed.

datarza wrote: ↑

Fri Jul 07, 2023 6:29 pm

Also, please return this topic to the original thread and do not move it without reason, thank you.

No

If you still have trouble understanding what is happening open a Gameplay help topic.