Friday Facts #394 - Assembler flipping and circuit control

[Panzerknacker]

Think of a computer case, power jack, internet cable, USB port, etc. The location of everything is clear and fixed. Rotating does NOT change the input and output of the machines. We can generalize this example for all real-life machines. I understand that a machine that takes a single type of variable is not dependent on any input (which already exists in the existing factorio; example: chemical plants have 2 pipes inlet and outlet, you can make the oil gas required for plastic production from the right or left inlet.) these make sense and already exist.

However, my logic does not accept changing the liquid inputs in recipes that require different types of liquids...

I think the aspect of this that you're missing is that in factorio, you are the person designing the buildings from scratch. You are researching the tech, you are defining the manufacturing of each building. If you wanted to design and fabricate a mirrored version of a usb switch, it would be trivial. If you wanted to design your refineries to be modular buildings that can be reconfigured upon installation, you could easily do that. We're already dealing with a human that can carry hundreds of oil refineries in his pockets, I think having the ability to assemble your prefab "refinery kit" is actually a pretty chill step from the current situation. In-fact, all fluid switching could easily be handled by internal valves, which is even simpler than what I already described and probably does exist in some systems that require flexibility in real life!

Yeah but the aspect you are missing is that if you would design a PC case urself, the power supply can be wherever you want but the power cable still goes where the power supply is.

So the graphics should also flip when flipping inputs. But even then, I personally still dont like the feature of mirroring blueprints.

[floven1]

While the circuit feature for assemblers is lovely, it is not intended for the scenario you describe. That is largely covered by remote view. You don't need circuits, you can just click on an assembler on a different planet and tell it to build something different, and then you can tell its requester chest of its new demands (and remember shift-right click on the assembler and shift-left click on the requester chest). Indeed, if remote view wasn't a thing, you could not configure the combinators anyway.

hmm, your point is well said, still probably going to automate the whole process to one combinator/assembler just for the sake of efficiency and reducing points of failure in the switching process tho

...(and remember shift-right click on the assembler and shift-left click on the requester chest)...

remembering things is not my strong suit

[zamp]

One thing still missing is being able to read a list of ghost entities from a roboport. Then everything can be automated.

I've wanted this feature for a looooooong time.

[SupplyDepoo]

"Left hand" and "right hand" traffic are higher level concepts that apply to the rail network as ideas in your head, they cannot be flipped by an algorithm seeing only a blueprint of a part of the rail network.

I have found that it can make sense to flip double track (mainline) blueprints, converting them between LHD and RHD. This would allow you to have a blueprint book for RHD and effortlessly adapt to LHD when joining multiplayer servers with established LHD infrastructure, and vice versa.

It can also make sense to flip blueprints containing single rails, like stations, resulting in flipped loading/unloading machines (and everything else) but preserved track directionality.

All that's required is for the signals and train stops to be swapped to the other side of the track, so those tiles need to be free (but paired chain signals could swap places with each other).

The main issue is actually blueprints that contain both the station and double track/mainline portions, i.e. merge and split junctions. If you blueprint stations and mainline/junctions separately, you could always obtain a useful flipped version, provided all of the rail signals and train stops can be swapped to the opposite side of the track (the tiles are either free or occupied by paired signal).

[FuryoftheStars]

"Left hand" and "right hand" traffic are higher level concepts that apply to the rail network as ideas in your head, they cannot be flipped by an algorithm seeing only a blueprint of a part of the rail network.

I have found that it can make sense to flip double track (mainline) blueprints, converting them between LHD and RHD. This would allow you to have a blueprint book for RHD and effortlessly adapt to LHD when joining multiplayer servers with established LHD infrastructure, and vice versa.

It can also make sense to flip blueprints containing single rails, like stations, resulting in flipped loading/unloading machines (and everything else) but preserved track directionality.

All that's required is for the signals and train stops to be swapped to the other side of the track, so those tiles need to be free (but paired chain signals could swap places with each other).

The main issue is actually blueprints that contain both the station and double track/mainline portions, i.e. merge and split junctions. If you blueprint stations and mainline/junctions separately, you could always obtain a useful flipped version, provided all of the rail signals and train stops can be swapped to the opposite side of the track (the tiles are either free or occupied by paired signal).

Something to consider: does the player want to just flip the signals, only the other entities around the tracks, or both? I can see use cases for all 3, but this would require additional modes to handle, which, to me, just further bloats an already fairly bloated set of keybinds. *shrug*

Edit: And I would think that flipping signals would only be a MP issue? I mean, I suppose I can't speak for everyone, but I only use 1 style because that's my preferred and it'd make it confusing as all get out if I was alternating between the two between different playthroughs, let alone on the same one. I also think it'd probably be good form if MP servers hosted their respective LHT/RHT track blueprints knowing this, then players can just have trackless blueprints for their desired setups. I suppose another thing that would be of use considering is that everyone has different spacing preferences between tracks, so it'd be kind of hard to have all the correct LHT/RHT blueprints, anyway.

[IronfistXIII]

Thank you for making flipping possible. It's been bugging me for the longest time.

[Tnarg]

Minor Request: When the mouse is over an underground belt you the mirror/flip key should change the direction currently you can do this with the rotate key but I think both should work. I always hit the flipping key by mistake first try.

[Anima117]

I think flipping is going to be great for more compact designs. I am someone who tends to make very unorganised factories because I tend to just go the "I'll do this and fix it later" approach, and then never fix it, or apply a bandaid on it until it is so bad that it needs to be fixed for the factory to keep going (Yes, I am one of these players). So at least flipping up some buildings is going to be quite usefull for less spaghetti pipes and belts.

For the circuit thing, I can't speak on that too much, I am not using them too much.

[mmmPI]

"Left hand" and "right hand" traffic are higher level concepts that apply to the rail network as ideas in your head, they cannot be flipped by an algorithm seeing only a blueprint of a part of the rail network.

If you blueprint stations and mainline/junctions separately, you could always obtain a useful flipped version, provided all of the rail signals and train stops can be swapped to the opposite side of the track (the tiles are either free or occupied by paired signal).

Something to consider: does the player want to just flip the signals, only the other entities around the tracks, or both? I can see use cases for all 3, but this would require additional modes to handle, which, to me, just further bloats an already fairly bloated set of keybinds. *shrug*

Currently in the game you can flip blueprint containing rails , but not blueprint containing train signals or train stops and i think it make sense because sometimes it would be impossible due to tile not being free whereas rails can always be built on top of each other.

This is one example of junction that cannot be made RHD given the rail layout, considering it's a 32x32 junction that fit 1 chunk :

From reading the FFF and trying to apply the same reasonning as Josh did, it can be seen that this junction cannot be flipped because it is impossible to find a single line for a folding symetry, even diagonals do not works due to signal missmatch, maybe it's easier to say it's only 180°x2 rotationnal symetry and not 90°x4 but i'm not sure that's the proper mathematical way of saying

no rhd.jpg (199.54 KiB) Viewed 1390 times

[DrakeyC]

Those mirrored oil refineries make me want to weep tears of joy for how much simpler it'll make my pipelines. Thank you for this gift. That screenshot of the 6 refineries sharing direct pipes was beautiful.

[Kadet123]

I don't recall this being asked anywhere.. but when we set a new recipe on the assembler, what happens to the built up productivity bonus? Does the productivity progression carry over to the new recipe, or does it reset?

If it carries over, that could be gamed for profit. For example, set up a circuit to make gear, gear, gear, Robotic Control Unit, such that the RCU is always timed when the productivity bonus will hit.

If it doesn't carry over, then switching recipes negates productivity bonuses. I'm betting this is what will happen.

[Qon]

I don't recall this being asked anywhere.. but when we set a new recipe on the assembler, what happens to the built up productivity bonus? Does the productivity progression carry over to the new recipe, or does it reset?

If it carries over, that could be gamed for profit. For example, set up a circuit to make gear, gear, gear, Robotic Control Unit, such that the RCU is always timed when the productivity bonus will hit.

If it doesn't carry over, then switching recipes negates productivity bonuses. I'm betting this is what will happen.

It will reset. They fixed this exact issue for furnaces before.

[traches]

I'll drop my thoughts on the "stack" vs "bulk" naming situation as a programmer, though I haven't read the other comments so sorry if I'm being repetetive.

"Stack" is a word that already has meaning within the context of Factorio. If you change that meaning, then existing documentation, personal experience, habits, and quite likely naming conventions within the code base itself will become out of date. Conversations on forums and such become confusing, because some people are working with the old meaning and some are working with the new meaning. I've made changes like this before and while it's certainly possible, I really do think a better alternative is to avoid changing existing terminology and instead introduce a brand new term.

My strong suggestion: Use the word "bundle" for the new feature. "Stack" should continue to mean exactly what it always has.

[mindmix]

One thing still missing is being able to read a list of ghost entities from a roboport. Then everything can be automated.

i want this feature as well

[FuryoftheStars]

I'll drop my thoughts on the "stack" vs "bulk" naming situation as a programmer, though I haven't read the other comments so sorry if I'm being repetetive.

"Stack" is a word that already has meaning within the context of Factorio. If you change that meaning, then existing documentation, personal experience, habits, and quite likely naming conventions within the code base itself will become out of date. Conversations on forums and such become confusing, because some people are working with the old meaning and some are working with the new meaning. I've made changes like this before and while it's certainly possible, I really do think a better alternative is to avoid changing existing terminology and instead introduce a brand new term.

My strong suggestion: Use the word "bundle" for the new feature. "Stack" should continue to mean exactly what it always has.

I imagine that most people know and look for the "stack" inserter as the "green" inserter, so changing the name isn't going to affect much. For those that do pay closer attention to the names, I also imagine that having the "stack" inserter not be the one that actually places items in stacks on the belts to be confusing (because it certainly doesn't move actual stacks of items). As such, in this case, I see the change as a good and potentially necessary thing.

Besides, it certainly couldn't be any more confusing than eliminating the filter stack inserter so that its color can be reused for something else....

[SupplyDepoo]

Something to consider: does the player want to just flip the signals, only the other entities around the tracks, or both? I can see use cases for all 3, but this would require additional modes to handle, which, to me, just further bloats an already fairly bloated set of keybinds. *shrug*

That is overcomplicating it. Think of tracks like transport belts. If you have a blueprint with belts running north, then west, then north again, and you flip it horizontally, then the result will be north, east, north. Overall, items would still be moved from south to north, but diverted east instead of west in the middle.

belt-flip.png (733.91 KiB) Viewed 992 times

For tracks, it should be the same: the track direction should be preserved. Northbound should stay northbound, southbound should stay southbound, and bidirectional should stay bidirectional. In the case of northwest-bound track, it would become northeast-bound after a horizontal flip.

rail-flip.png (1.15 MiB) Viewed 992 times

The only difference to belts is that rail pieces have no directionality built into them. It's a "feature" you add to them by attaching rail signals and train stops. If belts didn't have built-in directionality, but required a motor to be attached on the side that could apply torque in only one direction (so direction would be determined by which side of the belt you attached it to), then we would have the same problem. But the semantics of flipping such belts would be the same as the belts we have in the actual game.

engine-powered-belt.png (669.14 KiB) Viewed 992 times

The other notion of flipping that you're thinking of would be analogous to reversing belt lines. This could be a more specialized tool for rail signals, or a mode of some sort of "rail planner", but it is not something that a general flipping operation should do. The F/G flipping shortcuts are general flipping shortcuts so I want to focus on that. There is always room to add other tools or shortcuts, but I am more interested in expanding the existing flipping feature in a way that makes the most sense.

Another thing is that we all know about elevated rails in the expansion, and in the case of elevated rails the collision issue of rail signals goes away completely, because there are no other entities that can be attached to rails or that can collide with rail signals on that layer. So should we be unable to flip elevated rails when there is nothing preventing signals from being adjusted to preserve directionality?

Actually, there is still the potential for circuit network connections to exceed the maximum wire reach after a signal is adjusted, but how often would that happen?

This is the issue of universality: just because not every scenario can be handled, should we forgo tools when they could be useful in many or even a majority of other scenarios? We already have blueprint flipping even though some entities cannot be flipped, meaning that the game checks each blueprint for the presence of such entities and, if it finds any, prevents you from flipping the blueprint.

So we have the ability to flip blueprints when it is useful, and we don't when it isn't. I suggest that this logic be extended to rails by adjusting rail signals and train stops whenever possible, taking into account the two considerations: collisions and wire reach limits (for rail signals and train stops). If a safe flip is not possible, a floating text would appear saying "Cannot flip blueprint. At least one rail signal cannot be adjusted."

It might be a lot more work to check these things, but there are surely ways to optimize it (and it only really would need to be done once for each blueprint, some time between setup and the first attempt to flip it, which would pretty much always be at least several ticks, during which the game could complete this task, in small chunks at a time, so that it doesn't cause noticeable UPS dips for extremely large blueprints).

Edit: And I would think that flipping signals would only be a MP issue? I mean, I suppose I can't speak for everyone, but I only use 1 style because that's my preferred and it'd make it confusing as all get out if I was alternating between the two between different playthroughs, let alone on the same one.

Flipping can still be useful for other blueprints, like stations, where the LHD <> RHD swapping isn't an issue.

flippable-station.png (1.42 MiB) Viewed 992 times

I also think it'd probably be good form if MP servers hosted their respective LHT/RHT track blueprints knowing this, then players can just have trackless blueprints for their desired setups.

Good idea, but some blueprints have circuit network logic hooked up to the train stops or rail signals, so they work better as a single blueprint.

I suppose another thing that would be of use considering is that everyone has different spacing preferences between tracks, so it'd be kind of hard to have all the correct LHT/RHT blueprints, anyway.

True, but 2- and 3-spacing is so common that I have found having a few mainline blueprints just for that is enough usually.

Currently in the game you can flip blueprint containing rails , but not blueprint containing train signals or train stops and i think it make sense because sometimes it would be impossible due to tile not being free whereas rails can always be built on top of each other.

Why limit a general feature because of specific problem cases? It is up to the player to decide how to design things and which considerations to prioritize or ignore. If you don't care about being able to have a LHD variant of your intersection, why should everyone else be limited? Nothing would force you to flip your rail blueprints, and if you pressed the shortcut by accident, you just press it again to unflip it.

You can make certain inserter and belt configurations that cannot be flipped properly. This is not a reason to make all blueprints containing inserters facing belts unflippable. The game doesn't even prevent you from flipping such arrangements and doesn't alert you to it when you do. It's okay to trust players to figure these things out.

inserter-dropoff-bias.png (244.43 KiB) Viewed 992 times

Also, putting mainline junctions and stations in a single blueprint and criticizing the fact that flipping would screw up the junction (because LHD <> RHD is flipped) is like putting a subfactory and a mainbus tap in a single blueprint (which might become more common practice with super force build in 2.0 maybe?) and criticizing the fact that flipping does not pull the correct items from the bus to where they need to go. It's up to the player to be aware of the semantics of flipping a blueprint. Either 1) don't do it, 2) fix the junctions, or 3) make separate blueprints for different chirality.

mainbus-vs-mainline-junctions.png (2.32 MiB) Viewed 992 times

Analogous situation -- apply the same reasoning.

This is one example of junction that cannot be made RHD given the rail layout, considering it's a 32x32 junction that fit 1 chunk

And there are many more possible junctions that can, like this one:

flippable-celtic.png (977.89 KiB) Viewed 992 times

From reading the FFF and trying to apply the same reasonning as Josh did, it can be seen that this junction cannot be flipped because it is impossible to find a single line for a folding symetry, even diagonals do not works due to signal missmatch, maybe it's easier to say it's only 180°x2 rotationnal symetry and not 90°x4 but i'm not sure that's the proper mathematical way of saying

That's a bit wrong. There's nothing about symmetry that prevents that design from being flipped. All rail entities, including signals and train stops, work in every orientation. FFF #394 is dealing with symmetry in entity prototypes, and there is no such problem with the rail/signal/train stop prototypes. Flipping is simply inverting all of the x-coordinates or y-coordinates and the rotations.

Here is the same junction, but modified to be slightly bigger (the smallest possible in 2.0 with the new rail shapes), which can now have enough space in the middle for chunk-aligned big electric poles, and for the rail signals to be swapped to the opposite side when flipping.

modified-junction-flippable.png (1.42 MiB) Viewed 992 times

Really the only thing that breaks this for rails is that if rail signals are adjusted (as they should be, if my arguments above were persuasive enough) there can be situations where the opposite side of the track is not free, or circuit wire would stretch further than permitted. So this design is unflippable only because of the tight spacing in the center.

If all signals can be "flipped" to the opposite side of the track in order to maintain directionality then the whole design is flippable.

(and if you flip the design naively by only negating the coordinates then you get something that works, but all of the entry chain signals become normal rail signals, and the exits become chain signals, which would be just bad)

[SupplyDepoo]

Hopping around on multiplayer servers, I have found several large subfactories that would be flippable, or could be made flippable with a few small modifications.

This one for example I found and made it 100% flippable by removing 20 or so lamps (that were not adding any benefit whatsoever because every lamp was doubled up with another lamp next to it, and I only had to remove one of each pair to make space for the rail signals).

huge-flippable-subfactory.png (135.83 KiB) Viewed 947 times

As long as mainline junctions are not part of the station/subfactory blueprint, and the signals and train stops can be swapped, you could flip the whole blueprint.

If we could embed blueprint books inside of blueprints and choose how embedded blueprints are flipped, then we could do something like this and include mainline junctions in the station blueprint via "flippable reference". It would solve the problem of junctions being flipped from LHD to RHD and vice versa -- the embedded blueprint book would select the correct junction blueprint to match the context.

station-and-junction-with-embedded-blueprint.png (2.11 MiB) Viewed 947 times

A slightly more general version of this could be applied for things like custom blueprint dragging behavior, which could enable automatic corners for multi-belt busses, like the Belt Turner mod, and probably many more things -- but that's for another topic.

One more thing: there are some cues that could help remind players about allowing signals to be flipped:

1. Draw a decal or some spare wires on the opposite side of the track where a rail signal could be swapped to. It would have no collision so you could place anything there if you want, including another rail (chain) signal to make bidirectional track of course. But a small visual detail could be enough to prevent players from accidentally blocking that tile if they intend to have a flippable blueprint in the end.
2. When holding a placeable item/entity in the hand, and if it would block a rail signal spot if placed at the cursor's location, the game could draw a white highlight box around the rail signal which would be blocked from flipping.
3. When connecting circuit network wires to a rail signal, it could draw a small red X on the opposite side of the rail if it would not be able to reach that position.

The player can simply ignore these hints (or perhaps turn them off completely), and after placing an entity on the opposing tile, they would entirely go away.

[FuryoftheStars]

Something to consider: does the player want to just flip the signals, only the other entities around the tracks, or both? I can see use cases for all 3, but this would require additional modes to handle, which, to me, just further bloats an already fairly bloated set of keybinds. *shrug*

That is overcomplicating it. --snip--

And all that 'splaining could've been summed up as a "no, I'd only want/support flipping the entities and track, not the signals themselves so the direction is preserved."

However, take that very first image of the track with a signal you posted. The signal had to be moved some to work. If there had been other entities in that blueprint, it may have caused a conflict:

Flipping1.jpg (368.51 KiB) Viewed 923 times

Edit: And I would think that flipping signals would only be a MP issue? I mean, I suppose I can't speak for everyone, but I only use 1 style because that's my preferred and it'd make it confusing as all get out if I was alternating between the two between different playthroughs, let alone on the same one.

Flipping can still be useful for other blueprints, like stations, where the LHD <> RHD swapping isn't an issue.

Yes, that's the "don't flip the signals" method.

[mmmPI]

From reading the FFF and trying to apply the same reasonning as Josh did, it can be seen that this junction cannot be flipped because it is impossible to find a single line for a folding symetry, even diagonals do not works due to signal missmatch, maybe it's easier to say it's only 180°x2 rotationnal symetry and not 90°x4 but i'm not sure that's the proper mathematical way of saying

That's a bit wrong. There's nothing about symmetry that prevents that design from being flipped. All rail entities, including signals and train stops, work in every orientation. FFF #394 is dealing with symmetry in entity prototypes, and there is no such problem with the rail/signal/train stop prototypes. Flipping is simply inverting all of the x-coordinates or y-coordinates and the rotations.

Here is the same junction, but modified to be slightly bigger (the smallest possible in 2.0 with the new rail shapes), which can now have enough space in the middle for chunk-aligned big electric poles, and for the rail signals to be swapped to the opposite side when flipping.

Really the only thing that breaks this for rails is that if rail signals are adjusted (as they should be, if my arguments above were persuasive enough) there can be situations where the opposite side of the track is not free, or circuit wire would stretch further than permitted. So this design is unflippable only because of the tight spacing in the center.

If all signals can be "flipped" to the opposite side of the track in order to maintain directionality then the whole design is flippable.

(and if you flip the design naively by only negating the coordinates then you get something that works, but all of the entry chain signals become normal rail signals, and the exits become chain signals, which would be just bad)

I'm afraid i wasn't convinced by your arguments, but it may be because i wasn't able to be very precise in the first place, and as such i feel we are missing each others point.

I maintain that the picture of the junction posted illustrate a situation where there is no way to draw a line for a folding symmetry that would cut the junction in 2 parts which would superpose. The diagonal line would create a missmatch in signals. That's what i observed on the junction, with the FFF in mind.

Since you cannot draw such line on the junction, in order to "flip it" you would need to draw that line next to the junction, and create an inverted copy when folding. (i imagine wet ink on a book ) But if you do that, you create a junction with broken signals, the regular signals supposed to be at the "exit" would be at the "entrance". That's going to be the case for all junctions. ( if that was not the case, then it would have been possible to find the previously mentionned line , that's what i got from the FFF but i may be misunderstanding that wouldn't be the first time x) ).

Now if you say "also swap the signal on the other side of the rail", then it's not possible in the posted pictures due to the middle. But that's another 2nd thing.

This illustrate at least 2 problems, one you demonstrated when enlarging the blueprint, is that it creates situations that the game cannot solve automatically, if you had the original blueprint in hand and press the flip key, it wouldn't be possible to expect the game to handle the enlargment of the blueprint. ( sorry to criticize your version but the point of having 32 tile junction is to fit in 1 chunk , if you build other things around the junction and press the swap hotkey, the game will tell you "nope , can't do")

The other you mentionned being that some signal need to be swapped chain=>regular, on top of being placed on the other side of the rail which is also i think not possible for the game to handle, because it couldn't know if you are attempting to flip a full blueprint or not and in one case it's easy to locate the entrance and exit for a human, but if you are only selecting 3/4 of a blueprint and try to flip and paste to complete your junction, then the game cannot possibly know.

Regarding the train stop, to me it's the same thing, i made a picture that hopefully illustrate what i mean :

no flip.png (209.03 KiB) Viewed 879 times

To me when trying to "flip" both the bottom setup fail to have enough room for a loco before the train stop. that's a problem.
There are other problems, why the bottoom right setup you may ask ? , well because why would flipping the design make the belt suddently point the other direction compared to the train ? What kind of magic only affect one of the entities ?
Also both side belts in the flipped proposals are located AFTER the station compared to alongside where the train would sit waiting.

What do you expect to see when pressing the "flip" hotley with such thing selected ?

[SupplyDepoo]

And all that 'splaining could've been summed up as a "no, I'd only want/support flipping the entities and track, not the signals themselves so the direction is preserved."

Technically the signals would be flipped across the axis of reflection (the horizontal or vertical line that divides the blueprint in half) along with the rails. I can see why you might think of it as "not flipping the signals" but I am thinking about it in a technical sense (see image below).

However, take that very first image of the track with a signal you posted. The signal had to be moved some to work. If there had been other entities in that blueprint, it may have caused a conflict:

Yes, the issue of collision was mentioned several times in my post.

Flipping can still be useful for other blueprints, like stations, where the LHD <> RHD swapping isn't an issue.

Yes, that's the "don't flip the signals" method.

Again, technically the signals would be flipped. Not flipping the signals only really works if the track itself is the axis of reflection, which only works if there is exactly one straight track.

flipping-semantics.png (1.62 MiB) Viewed 825 times

In other words: if you flip the rails, then the signals must be flipped (except in the special case of a single straight horizontal or vertical length of track), if you don't flip the rails, then it is very likely that some entities (like the big electric pole in the top left) could not be flipped, because it would be ambiguous (if a curved rail itself is considered as the center line around which entities are flipped) or it could collide with the rails.

I maintain that the picture of the junction posted illustrate a situation where there is no way to draw a line for a folding symmetry that would cut the junction in 2 parts which would superpose. The diagonal line would create a missmatch in signals. That's what i observed on the junction, with the FFF in mind.

Perhaps we are talking past each other, because I think we mean the same thing? I just don't think it's accurate to say that it's about symmetry. The junction can be flipped straightforwardly via simple coordinate transform. What you then get is a working junction, albeit with very suboptimal signalling. As I demonstrate in the following image, the chain signals in the interior of the junction, which are circled in white, are correct, with only marginally worse positioning. The entry and exit signals however are swapped in a bad way.

The 36x36 version however, which is topologically the same, only slightly pulled apart to make space in the middle, could be flipped the way I described resulting in perfect signalling.

its-not-about-symmetry.png (1006.21 KiB) Viewed 825 times

That's why I'm saying that, after a simple coordinate transform, each signal (and train stop) should be rotated and moved to the opposite side of the rail to which it is attached. This step does not care about symmetry, only about available space (and circuit wire reach).

See the large subfactory I showed in my previous post for a very non-symmetrical blueprint that is 100% flippable when space is available.

Since you cannot draw such line on the junction, in order to "flip it" you would need to draw that line next to the junction, and create an inverted copy when folding. (i imagine wet ink on a book ) But if you do that, you create a junction with broken signals, the regular signals supposed to be at the "exit" would be at the "entrance". That's going to be the case for all junctions. ( if that was not the case, then it would have been possible to find the previously mentionned line , that's what i got from the FFF but i may be misunderstanding that wouldn't be the first time x) ).

Yes, we agree on that, but I think you're misapplying the concepts shown in FFF to this topic. I think the FFF is dealing with prototype definitions, which can impose some limitations, but blueprints are really just an array of entities and their positions and rotations, and they can always be changed independently of each other.

As an absurd example, if I said "every rail signal should be moved 5 tiles north and 6 tiles west, unless the coordinate is a multiple of 8, in which case it should be moved 0 tiles vertically and 1 tile east" then this could still be achieved as long as there happens to be free tiles at all of those positions. So I maintain that it's not about symmetry, although I might be explaining it badly/incorrectly.

But even if I'm wrong about the theoretical analysis of this example junction, I still firmly believe in the practical benefits of being able to flip rail signals and train stops whenever it is possible and desired by the player.

Now if you say "also swap the signal on the other side of the rail", then it's not possible in the posted pictures due to the middle. But that's another 2nd thing.

Yes, and my motivation for adding the ability to flip rail stuff in the way I described is because I think there are many situations where you would not encounter that problem and you would benefit from the feature. I don't care that there is a subset of cases where it doesn't work, even if the player might be a bit negatively surprised the first few times because they have not yet developed an accurate intuition about the flipping operation.

This illustrate at least 2 problems, one you demonstrated when enlarging the blueprint, is that it creates situations that the game cannot solve automatically, if you had the original blueprint in hand and press the flip key, it wouldn't be possible to expect the game to handle the enlargment of the blueprint. ( sorry to criticize your version but the point of having 32 tile junction is to fit in 1 chunk , if you build other things around the junction and press the swap hotkey, the game will tell you "nope , can't do")

Haha, I am certainly not suggesting for the game to automatically enlarge junctions or to play the game for me. It is up to me to make designs that are flippable when I want that, and to know what will happen when I flip a blueprint. And ultimately it is completely optional to take this into consideration. Nothing is lost for anyone by removing a limitation on a feature that they can simply abstain from using.

I think we agree that it would not be technically feasible for the game to enlarge junctions. What is absolutely technically possible is for the game to swap rail signals and train stops, and I would argue that it's almost always what the player wants, not a pure x to -x and y to -y transformation like for other entities. I could post some more examples of how this breaks things, aside from your 32x32 junction. Stations, depots, etc, would almost always break by simply flipping the whole blueprint without adjustments to signals and train stops. I can imagine that it might be slightly useful for junction design/exploration, but it should be a separate tool/mod.

I hope you don't misinterpret me as saying that you should not be able to do 32x32 junctions or that they are not cool or whatever, but this is just a little FYI that Factorio 2.0 (or 2.1) will do away with the current rail shapes and the new rail ships won't allow you to construct 32x32 junctions with a circle in the middle anymore, as shown in FFF #377 (you probably know about it, I'm just mentioning it for readers who missed the news). Also, chunk-aligned blueprints provide a mostly esoteric benefit, as even the devs have stated that there is little to no performance benefit or any other significant benefit to it (I can't remember who said it, but it might have been Rseding91).

The other you mentionned being that some signal need to be swapped chain=>regular, on top of being placed on the other side of the rail which is also i think not possible for the game to handle, because it couldn't know if you are attempting to flip a full blueprint or not and in one case it's easy to locate the entrance and exit for a human, but if you are only selecting 3/4 of a blueprint and try to flip and paste to complete your junction, then the game cannot possibly know.

See the above image of the 36x36 junction. It's really not that hard. If I selected 3/4 of the junction it would flip all the same. There is nothing for the game to guess, it only has to check signal positions.

Regarding the train stop, to me it's the same thing, i made a picture that hopefully illustrate what i mean :

The way I have described the adjustment of rail signals and train stops would give the following result.

flip-okay.png (523.1 KiB) Viewed 804 times

To me when trying to "flip" both the bottom setup fail to have enough room for a loco before the train stop. that's a problem.
There are other problems, why the bottoom right setup you may ask ? , well because why would flipping the design make the belt suddently point the other direction compared to the train ? What kind of magic only affect one of the entities ?
Also both side belts in the flipped proposals are located AFTER the station compared to alongside where the train would sit waiting.

It seems surprisingly difficult to convey the concept of adjusting rail signals after flipping, but I have tried my best to explain why the objections are wrong, or at least founded on a bad understanding. Please review my illustrations above if it's still unclear to you what I mean, because I'm not sure what else I could do to explain it better (except more pictures/examples, which is a bit time-consuming for me to create).

If you understood the exact flipping mechanics that I am proposing then you might still think it's not practical, and it would be a more subjective discussion.

What do you expect to see when pressing the "flip" hotley with such thing selected ?

I will try to explain it one more time, in different words:

1. Flip every entity the same way: +x → -x, -x → +x, +y → -y, -y → +y, rotate 0º or 90º or 180º depending on if the rail signal is on a diagonal rail and if it's a horizontal/vertical flip (in this case 0º for a vertical flip and 180º for horizontal)
2. For each rail signal, chain signal, and train stop, try to move it to the opposite side of the rail (3 tiles offset for rail signals), and rotate 180º
3. If it's not possible, due to a lack of space or exceeding a circuit wire reach limit, show an error message at the player's cursor and nothing happens to the blueprint in the hand.