Problems
- Controls for rail planning introduce friction
- ambiguity: [SHIFT] for ghost planning and [CTRL] for planning with obstacle avoidance produce almost the same result. From personal experience, I've never used Ctrl for rail planning. Are there any differences between the two modes? I don't recall there being any differences. @EDIT — I've been informed, that "obstacle" is "a tree, a cliff or a rock". This is an unfortunate wording for the "obstacle avoiding planning" and a mechanic for solving a very specific kind of problem
- conflicts: [SHIFT] during rail planning conflicts with reverse rotation ([SHIFT]+[R]), which often leads to a problem where I press [R] 7 times to rotate a rail in a proper direction.
- lack of control: Can't change the [SHIFT]+[LMB] shortcut for rail planning (@EDIT it can be changed, but only by changing the ghost building key which is solid tradeoff). Only [CTRL]+[LMB] can be changed for obstacle avoidance building.
- manual difficulties: It's difficult to rotate with [R] when using [SHIFT] or [CTRL] mode. Rotating in CCW requires as much as 3 simultaneous keys pressed at the same time, all of which twist the hand substantially (CTRL+SHIFT+R)
- counterintuitiveness: Holding [CTRL] and [SHIFT] at the same time deactivates rail planning, but makes sense verbally: "ghost planning with obstacle avoidance"
- feature divergence: Rotating with [R] doesn't work in the [CTRL] mode. It only works in the [SHIFT] mode.
- Planning a ghost rail, then pressing UNDO updates the starting point of a track. Here is a quick demonstration (LMB, SHIFT+LMB, CTRL+Z, SHIFT+LMB):
- It's difficult to plan rails with obstacles in the way, for example through the belts.
- rails don't align with already laid tracks when planning, requiring explicit rotations with [R], which, as mentioned earlier, doesn't work with [CTRL] mode:
Proposed solutions
I propose new controls and new modes for the rail planning that, in my opinion, would somehow solve the above. Some of the ideas below have some little problems of their own, which require more thought.- Remove [SHIFT] from track planning. Instead, the [CTRL] would TOGGLE the rail planning mode, and it would cycle between 4 of them:
- REACH (default) - for placing tracks in player's reach (like already present in game after clicking [LMB] on a rail without any accelerators)
- SAFE PLANNING - like the current SHIFT/CTRL planning with obstacle avoidance. If there is no path, then the red X cross is shown like it is now
- UNSAFE PLANNING - a mode, which would allow for train tracks to path through simple obstacles. This mode would NOT destroy existing entities, but would find way through simple entities and show conflicts appropriately.
- Be default it would path through belts, pipes and walls.
- Supported entities could be converted to their other variants: walls to gates, belts to underground belts and pipes to underground pipes.
- Optionally add filters (like for blueprints/upgrade/deconstruction planners) which could allow pathing through entities. Example: player would mark trees, rocks, rails signals, train stations, combinators, electric poles and logistic chests as pathable, because he can easily move those entities. This would allow players for more control when planning. It could also help when designing things like crossings and compact spaghetti bases.
- When an unsafe path is found, the tracks change tint from green to yellow/orange and a warning icon is displayed.
- Some indicator would show which entities/tracks collide with each other. Currently vanilla supports showing entities planned for deconstruction and ghost entities in the same place, so that would be similar.
- A global warning could be shown similar to the one saying "entity is missing material for construction"
- (This is my preferred way now) Alternatively to the idea above with [CTRL] as toggle I came up with this idea: first, [LMB] on a track to enter planning mode (like it is now), second use [SHIFT]+[MOUSE-WHEEL] to scroll between 3 modes: REACH, SAFE and UNSAFE (like above). This has an additional advantage of similar controls being already present in the game — when scrolling the paste buffer. It would also remove the need for using [CTRL] altogether for rail planning.
- To solve the UNDO issue — store path starting point on the undo stack to solve the undo problem. This way a misplaced branch can be undo-ed and placed again without navigating to the beginning of the misplaced track. It would be helpful when planing long tracks.
- For tracks auto-aligning — Check if there is a rail on one of the hovered tiles, snap to it and adjust initial rotation. This could massively help when planning tracks. [R] would rotate the rail ignoring the snap. [F] would flip the direction the rail is going in.
Problems, opportunities and things worth consideration with proposed solutions
- (relates to first proposition of for CTRL) Using [CTRL] for switching planning could be a bit confusing. [SHIFT] is assigned to ghost building already, and planning is similar to ghost building. Tracks are planned as ghosts as well. Would [CTRL] be confused with [SHIFT] due to player's expectations about that key? How should [SHIFT] be handled then, as a NO-OP? Maybe use [SHIFT] to enter the planning mode as toggle, but then how to change the mode? Using [SHIFT]+[MOUSE-WHEEL]? (While writing this I came up with the idea of using [LMB] on track to enter planning and [SHIFT]+[WHEEL] to change mode) Would it be confusing if [SHIFT] worked as toggle only when building tracks?
- Marking overlapping entities would be something new in the game. There is however a infrastructure to show them in an intuitive way (yellow/orange tinted ghost + warning at the bottom and on map), so it would be also something familiar
- Marking overlapping blocks could open way to other feature requests like copy-pasting entities over
- How a player would choose which overlapping entity to build and which to destroy? I propose using currently held item in the cursor as a selector. Use [SHIFT]+[MOUSE-SCROLL] to cycle between overlapping entities. Building/Ghost building ([LMB]) an entity with selected item accepts it, while using [RMB] selects the other one.
- How many entities can overlap? I would say 2 distinct entities per single tile, because I don't expect anyone trying to plan multiple layers of overlaps at the same time.
- Related to snapping and aligning rail rotation to an existing rail — What would be the best way to handle pressing rotation, then moving to another tile? Snap again, or preserve rotation? I'd say snap again.
Only now have I realized, that undo support could be moved to a separate suggestion/bug thread, and sorry for that, but this seemed like a tightly coupled idea when I was writing this post before.
The tip wording "you can ALSO hold CTRL..." could be understood that two keys can be pressed at the same time
