Auto rotate signals even when placed as ghosts

[blazespinnaker]

If you place a signal via robot that you've copied from another place (a common task when shuffling around signals, I use copy otherwise I have to use shift in map mode when placing stuff), the signal doesn't get auto rotated.

I didn't notice this, and it was really driving me crazy as I could not figure out why some signals weren't blinking and others were. This made signaling trains more confusing than it should be.

I imagine other new players would encounter a similar issue because they auto rotate when manually placing them (and, in fact, you can't even rotate them when placing, so they might never think to check like I didn't)

viewtopic.php?f=18&t=93638

At the very least, please mention something on the wiki pages about this. https://wiki.factorio.com/Tutorial:Train_signals

It probably wouldn't hurt to add something about circular rail connections as well that aren't broken up by other signals.

I requested a wiki acct, but it's in pending review

[ssilk]

Moment, you copy-pasted signals from some part of your factory to another and wonder, why it doesn’t get auto rotated?

I would not like that, it makes no sense to auto-rotate the signals. I would insist on keeping the orientation, because the placing algorithm cannot know, what I had in mind when I paste it. It could be, that I place more rails, so that the signals don’t need to be rotated. Or other things.

And it makes no sense to copy only the signals. A signal without rail is always not working.

So I made a counter suggestion
viewtopic.php?f=6&t=93658 Rail Signals should be selected with the Rails

[blazespinnaker]

Trains are pretty cool in factorio. Removing friction like this might be a good idea so more people can enjoy them.

Also, I generally don't think ideas / suggestions are meant to be prescriptive. It's like the chicken and the pig at breakfast. We're all just chickens, and Wube is the pig here - rather committed.

These things are mostly useful to just sort of help talk about pain. Dealing with the pain needs to be done probably more holistically than players, as self centered as we are, will ever do.

[eradicator]

(a common task when shuffling around signals, I use copy otherwise I have to use shift in map mode when placing stuff)

You had a problem. You found a workaround. And now instead of suggesting to fix the original problem you suggest to hack the workaround to make it work better in your edge case, but worse in every other case. No, that is not the way to go. Q-pipette is meant to pick up single entities, copy/paste creates a temporary blueprint of 1 to N entities. You're suggesting to make a special "intelligent" mode for blueprints with only one entity, making blueprint behavior depend on a hidden "count" mechanic. No, thank you. Game mechanics that try to outsmart/mind-read the player make the game worse in 99% of all cases, and so far Wube has done a good job at avoiding them.

-1

From your description it sounds like what you really need is an option to make Q always pick up a ghost cursor. Possibly limited to "when in map mod". Both of which are moddable.

[ssilk]

Well, you’re right. A suggestion is a suggestion and if it is implemented and how or not is out of our hands.

But practice show: it’s not so. We - the players - have not a big influence to the development, but we have. And my experience says, that good suggestions (easy to understand/good explained/high gameplay value/easy to implement) are more likely implemented than others.

Or - in this case - suggestions that have the source in a use-case of very few players are not likely to be implemented.

But - as said - it brought me and others to another idea. And that is the sense of this board:

To generate ideas.

And when I watch it like so, I see me as a truffle-pig , that sniffs around for good ideas and digging them out.

[eradicator]

Well, you’re right. A suggestion is a suggestion and if it is implemented and how or not is out of our hands.

I was merely pointing out a common bad pattern in problem solving that fixates too much on some kind of already existing workaround instead of finding a proper solution to the original problem. You can see that pattern all over the place in software development. And due to cognitive bias the persons involved often can not see it and need an outside perspective.

I have no doubt that the @OP has a valid problem. But I do not think his suggestion is a good solution to that problem. I tried to explain why. And i tried to offer a better solution to the original problem.

To generate ideas. :)

Yea sure. But discussion isn't a one-way flower-garden-road. And criticism is important to polish ideas. But your answer makes me feel like you're trying to tell me that criticism isn't welcome here.

[blazespinnaker]

(a common task when shuffling around signals, I use copy otherwise I have to use shift in map mode when placing stuff)

You had a problem. You found a workaround. And now instead of suggesting to fix the original problem you suggest to hack the workaround to make it work better in your edge case, but worse in every other case. No, that is not the way to go. Q-pipette is meant to pick up single entities, copy/paste creates a temporary blueprint of 1 to N entities. You're suggesting to make a special "intelligent" mode for blueprints with only one entity, making blueprint behavior depend on a hidden "count" mechanic. No, thank you. Game mechanics that try to outsmart/mind-read the player make the game worse in 99% of all cases, and so far Wube has done a good job at avoiding them.

-1

From your description it sounds like what you really need is an option to make Q always pick up a ghost cursor. Possibly limited to "when in map mod". Both of which are moddable.

Nah, you're looking at this all wrong and should generally be reluctant to attribute motives and goals to strangers you don't know, at least without very careful review.

Some things to consider:

1. Suggestions are meant to be suggestive and not meant to be prescriptive.
2. Wube is not charging a subscription fee (yet), and new revenue will come from new players. Smoothing out any friction that keeps new players out of the ecosystem would be a rational thing to do. Talking about such friction is always good.
3. As I've mentioned a number of times and unfortunately your post motivates me to repeat myself once again - documentation would be a good approach here.

That said, it's worth noting that there are a fair number of use cases where an error message pops up when you try to ghost print something invalid. But if that's tricky to implement, doc is perfectly fine here. Most anyone who runs into this will likely have checked out the documentation at least once.

Something like "When placing signals with ghost blueprints and bots, ensure that the signals have been rotated properly where they connect to the rail. This will not be done automatically and if incorrectly rotated will cause the signals to blink invalid as they are unable to divide their respective block. Note that when placing via pipette or from your inventory, they will be rotated automatically when placed."

If that sounds a bit too much dirty laundry, than at least say that

"Blinking - The signal is not on a rail; on the rail but not rotated correctly, or the monitored block is also the block before the signal."

Providing a picture of a correctly rotated signal versus a not correctly rotated signal would be good here. Visuals are nice!

https://wiki.factorio.com/Rail_signal

I think it would be good to add something which talks about how if a block is connected on both sides (with example picture of a junction or something similar), a single signal will fail to divide the block. I learned this early on, but it was only via some reddit posts that I figured it out.

It's true, this sort of thing can spoil the pleasure of solving the problem. There needs to be a thoughtful way to present this to new users on how they should strike the right balance when resorting to wikis and tutorials. At some point, a problem gets frustrating enough that the fun parts never get experienced.

I will say, a lot of the extra stuff on the wiki I think is somewhat spoiling. Just the simple, atomic facts of the interface and mechanics of how things work is fine. Everything beyond that is the creative fun part that should be left for the player to discover. Or discussed in forum

[ssilk]

Well, you’re right. A suggestion is a suggestion and if it is implemented and how or not is out of our hands.

I was merely pointing out a common bad pattern in problem solving that fixates too much on some kind of already existing workaround instead of finding a proper solution to the original problem. You can see that pattern all over the place in software development. And due to cognitive bias the persons involved often can not see it and need an outside perspective.

I have no doubt that the @OP has a valid problem. But I do not think his suggestion is a good solution to that problem. I tried to explain why. And i tried to offer a better solution to the original problem.

To generate ideas.

Yea sure. But discussion isn't a one-way flower-garden-road. And criticism is important to polish ideas.

That is a misunderstanding. I wrote my post as answer to blazespinnakers post, just 10 minutes later than yours and sometimes I oversee, that there was a post meanwhile.

And yeah, I know that pattern, I work currently in a small project, where the product owner has “such” ideas and we as programmers need to convince him from simpler ideas, smaller steps.

But your answer makes me feel like you're trying to tell me that criticism isn't welcome here.

Uh? I put that to this missing citation. Tell me if not, I really won’t suppress criticism.

Something like "When placing signals with ghost blueprints and bots, ensure that the signals have been rotated properly where they connect to the rail. This will not be done automatically and if incorrectly rotated will cause the signals to blink invalid as they are unable to divide their respective block. Note that when placing via pipette or from your inventory, they will be rotated automatically when placed."

Why isn’t that obvious? I mean when I pick up an item via pipette it is obviously an item and behaves like an item. Blueprints behave differently. Rails for example behave completely differently as item vs. blueprint. And that’s true for many other items, especially when playing with mods.

I think it would be good to add something which talks about how if a block is connected on both sides (with example picture of a junction or something similar), a single signal will fail to divide the block. I learned this early on, but it was only via some reddit posts that I figured it out.

Granted. I don’t know the current internal Wiki documentation about signal placing. But there is already a lot:

https://wiki.factorio.com/Tutorial:Train_signals
https://wiki.factorio.com/Rail_signal#States

It's true, this sort of thing can spoil the pleasure of solving the problem. There needs to be a thoughtful way to present this to new users on how they should strike the right balance when resorting to wikis and tutorials. At some point, a problem gets frustrating enough that the fun parts never get experienced.

I will say, a lot of the extra stuff on the wiki I think is somewhat spoiling. Just the simple, atomic facts of the interface and mechanics of how things work is fine. Everything beyond that is the creative fun part that should be left for the player to discover. Or discussed in forum

But you cannot have both: one one hand a super descriptive document about how signals need to be placed (it’s in my eyes very obvious how to place signals) to work and on the other hand as less documentation as possible.

What I currently think is this:
A) you cannot place a signal wrong, if you place it as item. It’s not possible to place a signal not besides a piece of rail, or a ghosted rail. And it has the right orientation, depending on where you place it, except for special cases at junctions.
B) but that’s possible when you place it as blueprint.
C) But that’s only possible/makes only sense, if you have robots.
D) But train-signals are much, much earlier.

How did you get over this stage of about 5 game-hours without seeing A and B? Didn’t you need to build trains? Why?

I ask, because I want to understand the real issue behind this.
My current guess: it’s not obvious for players, that placing blueprints is different from placing items/ghosts.

[jodokus31]

From your description it sounds like what you really need is an option to make Q always pick up a ghost cursor. Possibly limited to "when in map mod". Both of which are moddable.

Nice Idea. The mod "Brave New World" does this (among a lot of other things!!). You also can pick the ghosts from crafting menu, since you cannot handcraft in BNW
After I played BNW for a while, I often opened crafting menu to pick an item

[eradicator]

Off topic:

@ssilk: Yes. If that post wasn't adddressed at me it makes more sense ;).

Wall of text about text by other people

Nah, you're looking at this all wrong and should generally be reluctant to attribute motives and goals to strangers you don't know, at least without very careful review.

How am I supposed to write any answer at all if i'm not "allowed" to try to understand the goals of someone? You're literally objecting to basic human interaction. Natural language is always ambigious and must be interpreted by the reader/reciever.

When you think you're being misunderstood you should try to reflect on if your description of the problem can be improved. Not lash out at the other person. You yourself should not assume that everybody who says things you don't like didn't "review carefully". Because from my POV it's you who didn't think the solution through before posting it.

If your description of the problem is insufficient then neccesarily my understanding will also be insufficient. And i find it bothersome most of the time to waste time on trying to use the exact flavour of $polite-speech that someone else might like at the time they read my text. So i write text without politeness-fluff.

Maybe it's you who's over-interpreting my motives ;). You might notice that I did not dismiss your problem, just your solution.

1. Suggestions are meant to be suggestive and not meant to be prescriptive.

The pinned threads say the opposite: precise example implmenetations ("mods") are better than vague speculations.

At the very least, please mention something on the wiki pages about this.

Have you considered making an account and adding it yourself? The wiki is a community effort.

documentation would be a good approach here.

Sure. But you can't just add more and more walls of text to every in-game tooltip. And adding it to any place out-of-game makes it invisible to most players. Also keeping an up-to-date documentation isn't free.

Just as a reminder: Most other games don't have official support for the wiki (or even a wiki at all). Information being spread all over the internet is the norm. And Wube clearly is making an effort to create good documentation.

Smoothing out any friction that keeps new players out of the ecosystem would be a rational thing to do. Talking about such friction is always good.

I never disagreed with that. In fact talking was all i did. But friction can't be reduced to 0. And there are diminishing returns. And it's you who wrote a wall of text about not liking my text instead of discussing how to refine the solution to your problem ;).

On topic:

@blazespinnaker: You seem to be not considering that signal rotation is not unique for every position - in y junctions there's usually a spot with two distinct valid rotations. But blueprints have only 4 rotations while signals have 8. This would make things really complicated if you allowed auto-rotations for blueprints with more than one entity. But inconsistent if you didn't.

If you place a signal via robot that you've copied from another place (a common task when shuffling around signals, I use copy otherwise I have to use shift in map mode when placing stuff), the signal doesn't get auto rotated.

So I'll go one step back to your premise. You seem to be saying that "using shift" solves your problem. But you don't explain why you're not using that solution.

[blazespinnaker]

Why isn’t that obvious? I mean when I pick up an item via pipette it is obviously an item and behaves like an item. Blueprints behave differently. Rails for example behave completely differently as item vs. blueprint. And that’s true for many other items, especially when playing with mods.

I refer to the above, reducing and thinking about friction for new players is important. Obvious? Well, it's obvious to me that it's not obvious.

But more friendly: The reason why it wouldn't be obvious to new players, is because the behavior is inconsistent and therefore surprising.

Consider -
1. Other items auto rotate when ghost printed, eg - pipes, belts.
2. Other blueprints error out when printing invalid. Eg: trains / cargo / wagon will error out if not printed on rails. Miners (burners + electric) when not printed on resources. Pumps when not printed on water. Anything when you try to print on water (This last is particularly a pain because you can add land afterwards in the same print, or heck, in a previous print!)
3. The hinting graphical detail that indicates the reason why there would be an issue is minute and difficult to see, especially if you're zoomed out or physically lack visual acuity.

Most importantly though, is the bottom line. Puzzling through inconsistent interfaces == not fun. However, trains and bots are hugely fun in factorio. Wube has invested and done a terrific job there. Hurdles to enjoying that investment like knowing to correctly rotate a ghost signal without even a note in the docs seems like a damn shame.

[blazespinnaker]

So I'll go one step back to your premise. You seem to be saying that "using shift" solves your problem. But you don't explain why you're not using that solution.

The problem is the friction for new users.

You seem to be not considering that signal rotation is not unique for every position

Sure, but how do you explain belts / pipes then. The inconsistency might be necessary, but it begs for docs at a minimum.

Figuring out optimal placement of nuclear reactors given clear, known rules of physical simuation = fun.

Puzzling through inconsistent interfaces with zero doc? Yah, I wouldn't pay for that.

[blazespinnaker]

Is it just me or this a lot of drama over a very minor doc issue?

I'm always surprised at what people like to talk about.

[ssilk]

Blazespinnaker, please make one followed post, when answering to many posts.

1. Other items auto rotate when ghost printed, eg - pipes, belts.

No, they don’t. Watch that behavior exactly! Pipes don’t have any rotation, and belts have complicated rules connecting other belts.

2. Other blueprints error out when printing invalid. Eg: trains / cargo / wagon will error out if not printed on rails. Miners (burners + electric) when not printed on resources. Pumps when not printed on water. Anything when you try to print on water (This last is particularly a pain because you can add land afterwards in the same print, or heck, in a previous print!)

Trains can exist only ON rails.
Mines can exist also on depleted land. Pumps can exists also, when the lake they where on is land filled.
Signals can exist without rails. They go then into the blinking state. Quite obvious, that such a signal isn’t working then.

Hm. The point you are making here is, that it makes indeed not much sense to print a signal via blueprints, when there is no rail in a possible direction. That’s nearly identical to your example with mines.

The more I think about it, the more I think that would solve this issue.

Other readers: Is there any known case, where that doesn’t make sense? Where you need blueprinted signals without rails? Issues with connected blueprints?

3. The hinting graphical detail that indicates the reason why there would be an issue is minute and difficult to see, especially if you're zoomed out or physically lack visual acuity.

But that’s the players responsibility. If I place a blueprint in map mode, I go normally back to it when built ready and look, if everything is right. And I need to zoom in for that.

Is it just me or this a lot of drama over a very minor doc issue?

It isn’t a doc issue. Docs are never read, when they should be.

No, you found here something, which really points to a (small) problem. It was introduced slowly over the times and now it is inconsistent. But us older players don’t mind it anymore, we are blind for that, and the devs too, because we know the story around it.

And finding a good solution for that isn’t so simple. That’s why I’m going into the discussion around it.

And as said, I think the solution is just to not blueprint signals, if there is no matching rail. Like the miners, when there is no resources.

This always disturbed me, when I had to create blueprints so, that some single signal hangs into the “air” and I needed to delete them.

[blazespinnaker]

No, they don’t. Watch that behavior exactly! Pipes don’t have any rotation, and belts have complicated rules connecting other belts.

Uhm, are we playing the same game? If you ghost print a pipe down the bot will fix the rotation when it places it to match adjacent pipes. Sure belts have complicated rules. So do pipes, for that matter. So do signals. That's totally my point. There's no consistency here, and much opportunity for suprises.

Anyways, this is really getting a bit silly.

There's an old software dev tale borrowed from sherlock I like to use in cases like this. Crimes aren't always obvious when they occur, dogs don't always bark. And, in fact, the dog not barking is a clue on how to solve them. Frustrated new players will just leave the ecosystem without complaining. You need to detect that and solve the issue.

Trains became 95% less confusing when I figured out all the blinking signal problems (well that plus the train debug visual aids). All the other documentation is frankly an unnecessary distraction, and a spoiler in some cases.

I imagine there is a lot of invisible confusion here that Wube is not aware of on all sorts of issues. Add a short note on the docs, and very large portions of that risk goes away.

And yes, people absolutely read docs and anyone who plays factorio to this point, eventually does. It really is impossible not to and the game attracts more methodical, curiosity prone folks.

It'd be great if there was some uber cool software change to fix all this, but I doubt it as everything behaves a bit differently and it's likely there are much bigger fish to fry. For example, this (what should theoretically be trivial) feature - viewtopic.php?f=6&t=59554 opens up an entire new category of game play with blueprints and bots.

And if there is an easy way to solve it, it will be wube figuring it out, not us. They know the code, the time it takes to implement things, and they have a holistic view over their players. We can really only share our pain (and pleasure!

[jodokus31]

No, they don’t. Watch that behavior exactly! Pipes don’t have any rotation, and belts have complicated rules connecting other belts.

Uhm, are we playing the same game? If you ghost print a pipe down the bot will fix the rotation when it places it to match adjacent pipes. Sure belts have complicated rules. So do pipes, for that matter. So do signals. That's totally my point. There's no consistency here, and much opportunity for suprises.

Pipes and Belts don't autorotate.
a regular pipe just connects to all adjacent pipes, which is visually indicated in preview
a belt connects to other belts, if the rotation is matching, but it doesn't get autorotated. also indicated in preview
an underground pipe/belts shows visual indicators, if it would connect.

If you have a blueprint or a real item in hand, those indicators are shown.

for rail signal, the indicators are only shown if you have the real item in hand. But not in a blueprint.

It could show visual indicator for rail signals, if you have it in a blueprint.

[blazespinnaker]

So, when I ghost print a pipe it's pointing at a fixed 90 degrees.

When the bot places it, it ..... rotates to connect to another pipe. If that isn't auto rotation, I don't know what is.

When I ghost print a belt, if there is an adjacent belt, it will change the rotation in some cases. Again, how is that not auto rotation?

Anyways, those are totally rhetorical questions. Won't be replying to semantic points when it is totally orthogonal to the problem of new players and friction. Folks are weirdly completely and utterly missing the point for reasons I clearly do not have the capability of understanding. I tried my best to explain.

I encourage you to re-read the posts above.

[Koub]

So, when I ghost print a pipe it's pointing at a fixed 90 degrees.

When the bot places it, it ..... rotates to connect to another pipe. If that isn't auto rotation, I don't know what is.

Technically, the pipes don't rotate. They have a single orientation, and only make connections according to some simple rules (if there is a pipe in an adjacent tile, connect both).

[jodokus31]

So, when I ghost print a pipe it's pointing at a fixed 90 degrees.

When the bot places it, it ..... rotates to connect to another pipe. If that isn't auto rotation, I don't know what is.

When I ghost print a belt, if there is an adjacent belt, it will change the rotation in some cases. Again, how is that not auto rotation?

Anyways, those are totally rhetorical questions. Won't be replying to semantic points when it is totally orthogonal to the problem of new players and friction. Folks are weirdly completely and utterly missing the point for reasons I clearly do not have the capability of understanding. I tried my best to explain.

I encourage you to re-read the posts above.

Rotation is, when your character goes there and you press the rotate key to rotate it. Try that with a pipe.
Regarding belts, you always place the selected rotation, it does not autorotate. It just connects differently to adjacent belt. Try different rotations for belts in different places.
Also train signal, there are special cases, where you can go there and rotate the signal, because the position can align to ambiguous rail segments.

I don't think, the solution is autorotate, because it does not happen to other entities.
My proposals are:
- don't allow placing rail signals from a blueprint, if it doesn't align to a train segment. Show them red in preview and allow the rest of bp to be placed by shift-click.
- OR show the same preview like with a real signal in blueprint mode. If it does not connect, it will blink after placing

[SuicideJunkie]

Pipes don't rotate, they simply have alternate graphics so they look nicer when adjacent to other pipes.
Much like wall segments, actually.


The only reasons I can think of to place a rail signal down without a railway next to it (so far) are:
- to use like a power pole for stringing logic wire.
- so I can shoot and destroy it to remove the excess from my inventory.

However, it might be nice to use it as a road traffic light, EG for tanks & cars if you were able to wire it up to logic and get a simple mini-multi-lamp.