No way to place underground belt outputs facing apart

[sparr]

If you want an isolated underground belt output, you can place an input, then a matching output, then delete the input. This works 99% of the time. The sole exception is if you want two outputs in line and close enough together that they could connect if one was an input.

If you try to do this manually, there's no way to get the second one to not become an input to match the other output. I understand why this works the way it does, but I'd like to have a way to opt out of that behavior. (this part is just a feature request)

Separately, and why I'm reporting this as a bug...

If you place a blueprint with an underground belt that happens to match another nearby belt, the type (input/output) of the underground belt entity can get silently flipped. I do not expect that this is often, if ever, the desired behavior. This can happen with completely legitimate blueprints.

Worse, if you have a blueprint that explicitly includes mismatched underground belts, one of them will get flipped. It appears correct in the blueprint edit window, but the cursor ghost has one of them flipped, and the entity ghosts get place flipped.

Here are two example blueprints that exhibit this behavior:

Code: Select all

0eNqVkN0KwjAMhd/lXFfYxhzYVxEZzgUJbG1pU3GUvrv7ERHFC2+SkHC+nCShGyI5z0agE8gIC1OAPib07OkibA10rbbR1Jo4duShSwVzHgka0fTkr97OedfRIFBwNvAmTLhDFwrTHLOCTG6R2CguCrJKn9jqb+yu/OaeFPhizXYGz6D7ajjw1ZyHRf17x5PEQiPyCloq/fYmhRv5sNpo6rraF4dD1dT51W67SRZEgfwA9tN1bw==

Code: Select all

0eNqVkN0KgzAMhd/lXHfgxAn2VcYQf4IEtJWaDqX03efPGGNjF7tJQsL5cpKAuvc0OjYCHUBGWJgm6GtAy44aYWugM3WMltL4oSYHfVYw1UDQ8KYl1zm75lNNvUBhtBMfwoAZOlFY1hgVZBk3ifUyekFU4ROb/o09pd/cmwI31hxn8Aqad8MTd6bqN/XvHU8SCw2IO2ir9NubFO7kpt1GnmXpJSmKNM/iq13Wi2yIBPEB9251cA==

At minimum, the blueprint edit window showing the belts un-flipped is wrong, because it doesn't match what actually ends up in the world, no matter what is nearby. I would greatly prefer if it was possible to place these belts as they appear in the blueprint, and that not working was considered the bug here.

PS: I also think it's a bug that deleting an input can cause an output to flip to an input if there's another output for it to pair up with.

PPS: To create the second blueprint: create a north underground input A, matching north underground output B north of A. delete A. create a south underground input C south of B, matching south underground output D. Drag a blueprint across all three entities, then in the blueprint editor right click the middle entity to clear it. Save or export the blueprint.

[posila]

Hi, I moved the thread to ideas and suggestions because out of all you wrote, only bug is that when you edit out entities in blueprint creation window, underground belts don't correct themselves, but that is part of bigger issue of blueprint preview's not rendering connected entities properly (belts, pipes, walls). And also that was not your point.

[SupplyDepoo]

This is why I think underground belt sideloading should be avoided and considered a bug. It's just janky and weird to be repurposing an entity like this that's meant for a completely different mechanic. There should be a dedicated lane splitter entity or some extension to splitters/belts if this use case is deemed common enough to warrant it.

This isn't a bug, it's just a consequence of abusing that glitch. Underground belts should be used for routing belts underneath obstacles and across other belts and no more (the interaction with inserters should also be patched). Underground belts work completely fine if you use them correctly, and their behavior shouldn't be compromised to accommodate an exploit.

If you want to split lanes, use filter inserters or a circuit lane splitter (only works with a different type of items on each lane, though), or design your factory differently so that you don't need to pull items from specific mixed belt lanes.

[Ranakastrasz]

What I want to know is how anyone came to the conclusion that this abuse of underground belts was "intended". It looks like one of those bug abuse things that became really popular so the devs don't want to remove it. Given that before the Belt Optimization it was possible to make belts that only had one side open, I didn't care much about it, since mods existed to fix the issue. Since then, it isn't possible, and there still isn't a solution.

Stack filter inserters are the best bet for now at least.

[sparr]

It looks like one of those bug abuse things that became really popular so the devs don't want to remove it.

Pretty much.

However, even if all that gets fixed, I still don't like that blueprint underneathies will flip direction based on entities outside the blueprint.

[impetus maximus]

you can see the devs using an underground entrance to take iron plate form a belt that also has gears on it in the Factorio trailer.

a work around for not being able to have two entrances face opposite directions is to use two different speed belts.

[Ranakastrasz]

you can see the devs using an underground entrance to take iron plate form a belt that also has gears on it in the Factorio trailer.

a work around for not being able to have two entrances face opposite directions is to use two different speed belts.

Yes, and I understand that even the Devs use it. That doesn't change it being a counter-intuitive and hack-ish solution, rather than a good one.

[sparr]

a work around for not being able to have two entrances face opposite directions is to use two different speed belts.

https://www.reddit.com/r/factorio/comme ... k/dha4q3e/

https://i.imgur.com/AZMI2pE.png

Workaround only works as long as your primary belt is yellow or red. Once you get to blue, you've got to build the larger version that doesn't have this limitation.

[impetus maximus]

Yes, and I understand that even the Devs use it. That doesn't change it being a counter-intuitive and hack-ish solution, rather than a good one.

it being hack-ish is what's so cool about it though.

Workaround only works as long as your primary belt is yellow or red. Once you get to blue, you've got to build the larger version that doesn't have this limitation.

true

[SyncViews]

Not sure about removing entities from a blueprint in general, but I think the blueprint should just build like it shows in this case. It does actually store a "type" field with "input" or "output" (as seen in the preview), but seems the game corrects it on build if you made it invalid in the sense you couldn't direct build it.

Could also be nice to have a mode/method to just explicitly place an input/output easily (especially when placing ghosts).

[SupplyDepoo]

it being hack-ish is what's so cool about it though.

But it breaking with blueprints in certain situations is not so cool now is it?

It's also not so cool that it makes semantically no sense. Just because I want to split a belt lane off I shouldn't need an orphaned underground belt. There should be a good reason for digging a hole in the ground and putting a belt on an incline coming out of a tunnel, and that's avoiding obstacles like rails and other belts. It's impossible to use this technique while designing a neat, logical factory. It's a dirty trick that I always try to pretend I didn't see when others use it. It's as if placing an inserter facing another inserter made it prefer to pick up from the far side of the belt or something. Just totally illogical.

[Ranakastrasz]

it being hack-ish is what's so cool about it though.

But it breaking with blueprints in certain situations is not so cool now is it?

It's also not so cool that it makes semantically no sense. Just because I want to split a belt lane off I shouldn't need an orphaned underground belt. There should be a good reason for digging a whole in the ground and putting a belt on an incline, and that's avoiding obstacles like rails and other belts. It's impossible to use this technique while designing a neat, logical factory. It's a dirty trick that I always try to look away from and pretend it isn't there when others use it. It's as if placing an inserter facing another inserter made it prefer to pick up from the far side of the belt or something. Just totally illogical.

Exactly. I mean, I can understand why it occurs, but I can't understand why we don't have a proper method of splitting belts, and have this mechanic removed. I mean, there was a mod that let you place tiny blocks which blocked off an entire side of the lane. After belt optimization, this mechanic broke, and noone has figured out how to script a replacement yet.

That was one of the few mods I felt was absolutely mandatory, because its painful to look at this type of setup.

[sparr]

It does actually store a "type" field with "input" or "output" (as seen in the preview), but seems the game corrects it on build if you made it invalid in the sense you couldn't direct build it.

It's actually worse than that. An orphaned UB near the edge of a blueprint will reorient to match an existing UB outside of the blueprint. So it's not just if the blueprint itself couldn't be direct-built, but also if the environment plus placed blueprint couldn't be direct built. I consider that behavior a bug, which is why I originally put this in the bug report forum.

[Ranakastrasz]

It does actually store a "type" field with "input" or "output" (as seen in the preview), but seems the game corrects it on build if you made it invalid in the sense you couldn't direct build it.

It's actually worse than that. An orphaned UB near the edge of a blueprint will reorient to match an existing UB outside of the blueprint. So it's not just if the blueprint itself couldn't be direct-built, but also if the environment plus placed blueprint couldn't be direct built. I consider that behavior a bug, which is why I originally put this in the bug report forum.

Now that part, I agree, is a bug.


That said, I am pretty sure that UB should be like Conveyers and use the given orientation, without autocorrect. I kinda understand it for manual placement, but blueprints, really shouldn't use that logic.

[SupplyDepoo]

It's not a bug. It's no more a bug than the glitch you're exploiting which is the only reason you noticed this behavior. It's only a bug if you think underground belt lane splitting isn't a bug (and yes, it is a bug, even if it's been grandfathered by the developers).

The current behavior is perfectly fine if you're using underground belts for their intended purpose. It's convenient that rotating one end of the underground belt also rotates the other end, since there's no use in having two belts shove items under the ground with no exit or come out from the ground with no items, unless you're using this 'hack'.

Also, there's nothing special about the placement of entities from ghosts or blueprints. Construction robots place the entities in the same way that the player would manually place them. Making it behave the way you want would literally require a hack in the code, an exception.

Now consider this: suppose you were able to place two underground belt exits in opposite directions the way you want. This would mean the underground belts aren't linked. Now let's say you place an underground belt entrance here...



Now you've just linked the left underground belt exit and the new underground belt entrance, with the orphaned exit in the middle. Now you could repeat this over and over and achieve belt braiding with a single belt type. This is not meant to be possible by design. It would be a hell of a mess to decipher which entrance is connected to which exit, too.

After everything is said and done, this results in bad design. That's why I oppose this suggestion and say address the source of the problem: underground belt lane splitting. Replace these shenanigans with a dedicated input/tool (like rotate, fast entity transfer, ...), a new entity ('belt lane splitter') or a new option in the belt and/or splitter panel (like they did with the inserter stack size override).

[sparr]

It's not a bug. It's no more a bug than the glitch you're exploiting which is the only reason you noticed this behavior. It's only a bug if you think underground belt lane splitting isn't a bug (and yes, it is a bug, even if it's been grandfathered by the developers).

"grandfathered" isn't the right term. They have explicitly said it's not a bug. More so, they have said we won't be getting any other lane-splitting entity, because UBs do the job.

Also, there's nothing special about the placement of entities from ghosts or blueprints. Construction robots place the entities in the same way that the player would manually place them. Making it behave the way you want would literally require a hack in the code, an exception.

I call shenanigans. I can create the entities in question with a Lua command, calling the same core functionality that is used by everything else to create entities.

Now consider this [...] Now you've just linked the left underground belt exit and the new underground belt entrance

So then make them not link in that case. Problem solved.

After everything is said and done, this results in bad design. That's why I oppose this suggestion and say address the source of the problem: underground belt lane splitting. Replace these shenanigans with a dedicated input/tool (like rotate, fast entity transfer, ...), a new entity ('belt lane splitter') or a new option in the belt and/or splitter panel (like they did with the inserter stack size override).

This has already been rejected repeatedly by the devs.

[SupplyDepoo]

I'm against the idea of being able to achieve certain things with blueprints only and not manually. It would just make it a tedious process to work around the fact that underground belts weren't designed for this purpose, and it isn't what blueprints are meant for. You're asking for yet another hack to be added to the game to support your hack addiction.

[SyncViews]

Yes, which I agree is not good.

But given placing underground belts using ghosts is already a pain even for intended use (so many times I built half a bus with them the wrong way ), I dont think just changing the blueprints to be hacky without making a better way to place them in the first place is a solution. Should just be able to place them as desired (even "invalid" ways since the devs say its intended) and the follow on from that is if I make a blueprint of something complete, it should build that way (*and as such blueprinting half a UB or removing one in preview, should likely do so as well).

To be honest, even if the devs were to agree that such half UB's are not intended, I think they should block it being built entirely not magically change its direction and make "broken halfs" stop moving, but don't see them taking that stance.