Friday Facts #280 - Visual Feedback is the king

[Mike5000]

While you're working on the train GUI how about making something in the big list of all trains match each train's assigned color?

This would make it easier to find specific trains when you have a lot of them.

[EvanT]

Hi great improvement of the UI. The Dev team is a prime example of how it should be done.

;TLDR: Make a train choose a random station with the same name instead of the nearest.

While we are at trains I would like to see a slight change in the behaviour of multiple trains which have multiple stations with the same name on their route. To my knowledge when a train hits a destination where multiple stations are available it will choose the nearest to go to. This is problematic because if you have more trains on that route all trains will go to the same station.
You can deactivate a station if conditions are meet but the condition will stay available as long as no train has reached the station and was sufficiently processed. In case of supply trains it might even result in all trains circulation to one station because the requested good is currently unavailable while all other requester stations are ignored. You can set a time delay at the supply station but that will limit the throughput and is a badly working workaround.
An alternative would be to set a "max trains to have this station as destination number" instead of just de-/activate the station, but I guess this would be way more complex to change than the destination from nearest to random.

[Sad_Brother]

An alternative would be to set a "max trains to have this station as destination number" instead of just de-/activate the station, but I guess this would be way more complex to change the destination from nearest to random.

You mean substitute "Station enable" condition by "Trains allowed" setting?
Or keep "Station enable" condition and add "Trains allowed" setting?
It can help really.

[EvanT]

You mean substitute "Station enable" condition by "Trains allowed" setting?
Or keep "Station enable" condition and add "Trains allowed" setting?
It can help really.

I would prefer an option in the train's schedule to choose the selection method. But random would be a great alternation which should not need too much development time.
More Options:

• Longest time active
• Longest time without visit
• Highest request priority (set by circuit at the station eg. count of needed items)

The trains would need to know how many trains are already on route to that particular station. While this would be the optimal solution I would not mind for the train to just pic a random station from the available ones.

There must be some kind of selection algorithm already in place otherwise we would see the trains go to the oldest station first but to my experience the train will go to the nearest regardless of placement time.

[Zavian]

You mean substitute "Station enable" condition by "Trains allowed" setting?
Or keep "Station enable" condition and add "Trains allowed" setting?
It can help really.

Or just use the enable/disable station capability for things like supply/fuel request/trash trains, where you want one train to supply multiple different outposts on an occasional/on-demand basis. For things like mining/production outposts which are located too far apart to share stations with the same name, give every outpost uniquely names stations and it's own set of trains.

[EvanT]

Or just use the enable/disable station capability for things[..]

Maybe there is a misunderstanding. I already use the de-/aktivate station feature. Otherwise the setup would not work at all.

[Parking]-[Supplying Station] -> [active supplied Stations with same name] -> repeat
The supplied Stations will deactivate if no materials are needed. But all trains will go to the same (nearest) station. So you have multiple trains changing target mid travel instead of each heading to a different outpost.

So instead of a dynamic self managing set of trains supplying all stations with only one supply-refill station and one parking lot. (With stack inserters a supply train can be ready within seconds) I need a supply-refill station with separate parking for each group of supplied stations. This does not solve the problem it multiplies the supplying side and does only reduce the number of stations which do not get supplied. To have sufficient buffer you would need more trains more stations and more parking.
We are talking maps with 30+ Outposts to supply with all kinds of needed stuff from ammunition over repair packs to walls.

If you want to use your method you would have to split the system into 5-8 Outpost per group. Having to manage the member count in reference to the outpost position every time a new outpost is set up or an old one goes. And hoping the nearest Outpost stays supplied long enough so all the other Outposts get supplied too. Yes this is a workaround I'm currently using but having the train just pic a random destination from the available stations would improve things a lot.

[Mike5000]

You mean substitute "Station enable" condition by "Trains allowed" setting?
Or keep "Station enable" condition and add "Trains allowed" setting?
It can help really.

I would prefer an option in the train's schedule to choose the selection method. But random would be a great alternation which should not need too much development time.
More Options:

• Longest time active
• Longest time without visit
• Highest request priority (set by circuit at the station eg. count of needed items)

The trains would need to know how many trains are already on route to that particular station. While this would be the optimal solution I would not mind for the train to just pic a random station from the available ones.

There must be some kind of selection algorithm already in place otherwise we would see the trains go to the oldest station first but to my experience the train will go to the nearest regardless of placement time.

Random destination choice is a problem because trains repath many times en route and if the destination changes randomly it could take a long time to actually reach a destination.

Limiting the number of trains headed to a destination is the easiest solution: viewtopic.php?f=6&t=64162

Request priority is difficult to integrate with A* pathfinding but request penalty (e.g. large constant minus item count) would be easy.

[EvanT]

Random destination choice is a problem because trains repath many times en route and if the destination changes randomly it could take a long time to actually reach a destination.

Limiting the number of trains headed to a destination is the easiest solution: viewtopic.php?f=6&t=64162

Request priority is difficult to integrate with A* pathfinding but request penalty (e.g. large constant minus item count) would be easy.

As long as the train recalculates the path to the same station it piced when searching for the next destination I do not see a problem.

Train Limit: yes I would prefer this.

You just set a value at the station (via circuit network). When the train hits a target with multiple available stations it pics the one with the highest value.

Calculating the distance to each available station and comparing them must be more complex than just compare some integers. (time, priority) Or picking a random target.

[Mike5000]

As long as the train recalculates the path to the same station it piced when searching for the next destination I do not see a problem.

This would mean changing the train pathfinder to ignore stations with identical names under certain circumstances, and would require additional smarts for the case where the locked-in station was no longer accessible if the train stop was disabled or a biter ate a track segment. Random destinations are not trivial and right now I'm focused on trivial solutions in the hopes that a dev will find a few spare minutes rather than having to schedule a day or two.

Train Limit: yes I would prefer this.

You just set a value at the station (via circuit network). When the train hits a target with multiple available stations it pics the one with the highest value.

Calculating the distance to each available station ...

The A* pathfinder does not have to determine the distance to every station. It's like dropping a rock in a small pond and observing which bank the ripples reach first. You don't have to wait until the ripples have reached the entire circumference before knowing which bank is closest.

... and comparing them must be more complex than just compare some integers. (time, priority) Or picking a random target.

The full train pathfinder still has to run to verify that the highest-scoring station is accessible from the train's current location and orientation, and to determine the optimum path to the selected destination station.

[EvanT]

A* uses an estimate distance to target to calculate the next best start point for the interval. It is used to find the best path from A to B. The Pathfinding is not used to find the nearest station but to calculate the path to it. For A* to work with multiple destinations you would need to have estimated distance values for each possible destination or select the closest one for each node. Either way would result in distance calculations for every possible target for each end-of-path-node.
Each iteration starts at the end of a possible path with the lowest actual cost + estimated cost as long as the destination has not been reached or no more nodes are available. While this is totally plausible selecting a random station from the list of stations with the same name and calculating the path to it does hardly result in more load since you would not have to calculate the estimated distance for all stations in the list but only for one. Only if the Station is / becomes unreachable you would have to calculate the path for the next possible station.

My suggestions does not affect Pathfinding but give a preselection of the target for it.

[Mike5000]

A* uses an estimate distance to target to calculate the next best start point for the interval.

TTBOMK Factorio's rail pathfinder's heuristic to estimate distance to target is zero. This is allowed with A* as zero is both admissible and monotone. And zero is very fast.

My suggestions does not affect Pathfinding but give a preselection of the target for it.

There is no single target when a train starts pathfinding. There is a set of targets. Pathfinding starts from the train and searches until it runs out of options or else it reaches one of the pre-selected set of possible destinations - those stations with matching names which are not disabled. If you limit the set of possible destinations to one then at best the search will take the same amount of time and in many cases it will take longer.

Thus the somewhat surprising result that searching for one matching station is no better than - and often worse than - searching for all matching stations at the same time.

[EvanT]

A* uses estimated distance (h) to target. This is a integral part of the algorithm. Setting this (h) to Zero would result in a more or less recursive search pattern since then all end-of-path-nodes would have the same cost value (g) and thus the exact same cost value (f). Reffer to: https://www.geeksforgeeks.org/a-search-algorithm/
Your statement does not make any sense. At least as far as I understand it.
I would suggest to move the A* discussion to PM since it misses the point of the suggestion completely.

[Mike5000]

A* uses estimated distance (h) to target. This is a integral part of the algorithm. Setting this (h) to Zero would result in a more or less recursive search pattern since then all end-of-path-nodes would have the same cost value (g) and thus the exact same cost value (f). Reffer to: https://www.geeksforgeeks.org/a-search-algorithm/
Your statement does not make any sense. At least as far as I understand it.
I would suggest to move the A* discussion to PM since it misses the point of the suggestion completely.

From the article you cite: "Dijkstra is a special case of A* Search Algorithm, where h = 0 for all nodes."

h=0 is allowed in A* and TTBOMK is the heuristic that Factorio's train pathfinding uses.

Why doesn't Wube call their pathfinding Dijkstra instead of A*? I can only guess. There are several variants of Dijkstra. The train pathfinder is readily understood as A* with h=0. And they wouldn't have to change the documentation if they later implemented a different h.

[EvanT]

If that is the way it is done by factorio, pathfinding will stop when the first station with that name is found. The neglected h means that you don't calculate the estimated distance but have to evaluate every possible path as long as the destination is not hit. If the dev team uses this over A* they will have done tests to calculate the average load. And I will believe them that this is more efficient here.

If the isStationTheTarget is calculated by station name only, this would have to be changed to exclude stations depending on additional parameters. Which would result in an additional check per station for definitive values.

If you separate your supplied stations in groups by name the pathfinding would still look at the closer stations but reject them on the different name.

So if one would do this within the pathfinding worst case would mean that the algorithm can only stop when the last possible station has been found and ordered according to priority.
The number of stations with that name is known and according to the presented UI-changes the reachability status for each station is also known. So the Pathfinding to each station with that name has been done already. From that there is absolutely no significant additional load in picking one of those already calculated paths by a selection method.

[Mike5000]

If that is the way it is done by factorio, pathfinding will stop when the first station with that name is found.

Exactly. The neat thing about A* is that it searches in such a way that the first found is the best!

If the isStationTheTarget is calculated by station name only this would have to be changed to exclude stations depending on additional parameters. Which would result in an additional check per station for definitive values.

Indeed. However for performance reasons the set of acceptable destinations is calculated only once before starting A* instead of evaluating each train stop encountered during the search so the runtime cost of additional constraints on acceptable train stops is insignificant.

So if one would do this within the pathfinding worst case would mean that the algorithm can only stop when the last possible station has been found and ordered according to priority.

Priority does not play well with A*. One can instead use "large constant minus priority" which acts like a cost which A* handles naturally but it tends to make A* do more work than without prioritisation.

A* works best without priorities - given a set of acceptable train stops find the least cost path to any one of them. For example, you could use circuits to disable all but the highest priority train stop(s).

[Pi-C]

Pi-C, how many exit signals (located on mainline/branch after the switch) is one routing station controlling?
I've seen some designs with many (up to extreme 20) red signals in a row to *really* discourage the train from choosing that path.

One. I could try to use more signals in a row, I guess. (Actually, it should be enough to set just the signal that is the farthest away from the routing station, right?)

According to wiki, a red circuit-networked signal has penalty of 1000, so each such red signal counts.

So, blocking a row of signals by circuit condition would increase the penalty … I'll give it a try, perhaps it might help. I don't want to block trains past the routing station, though, so these signals would have to be very close to each other, right? It certainly would look weird to have five or more signals right behind each other.

[Pi-C]

Alas, there is the problem that signals don't flow one way over red/green wires. In fluid networks, you can dictate the direction of fluid flow by inserting pumps.

The equivalent of a one way pump on the circuit network is a arithmetic combiner with the condition: Each + 0 = Each

Connect all of your branches to the main network through two of these (one for red, one for green).

Well, that part was about using one wire for signals sent by regular stations (requesting/guiding trains) and for signalling train contents. I don't really see how they could coexist on the same wire. Signals transmitting train contents should go in only one direction (forward); the reset signals to clear the previous block also go in only one direction (backwards). That works with the combinators, as you have pointed out. But the requesting/guiding signals should go everywhere, it's crucial that all stations in the network are connected with each other. Seems like I'll have to wire the network with two rows of poles.

[EvanT]

@Mike5000
You completely missed my point. And you have to make your mind up. A* without estimated distance to target is not A* as you yourself pointed out.

The priority is as I said earlier just an integer (or what ever is used by the circuitnetwork) after the pathfinding is set and done (and like I said the pathfinding is done for every possible station with the actual destination name otherwise the UI would not know how many stations with that name are reachable, available, active,.. to put the info in the tooltip) the majority of the load has already been done. After that you have a list of paths, their length and target station information. All what has to be done is either pick one of those by random or any other selection method. There is no rerun of the pathfinding needed.
As I said the new UI must run the pathfnding for every statiton with the actual name already - So no additional load regardless of the pathfinding method.

[Mike5000]

A* without estimated distance to target is not A* as you yourself pointed out.

A camel is also an ungulate and a mammal. Being an ungulate (special case) does not stop a camel from being a mammal (general case).

The train pathfinder is A* and also one of the Dikstra variants and also a SPF (shortest path first) and best-first search.

A* with h=0 is a special case of A* but it is still A* and this is confirmed by your own citation of https://www.geeksforgeeks.org/a-search-algorithm/

The priority is as I said earlier just an integer (or what ever is used by the circuitnetwork) after the pathfinding is set and done (and like I said the pathfinding is done for every possible station with the actual destination name otherwise the UI would not know how many stations with that name are reachable, available, active,.. to put the info in the tooltip) the majority of the load has already been done. After that you have a list of paths, their length and target station information. All what has to be done is either pick one of those by random or any other selection method. There is no rerun of the pathfinding needed.
As I said the new UI must run the pathfnding for every statiton with the actual name already - So no additional load regardless of the pathfinding method.

Code for dialogs and tooltips only runs when they are visible. The train pathfinder does not continuously find paths to all train stops. It finds the least cost path from the train's current track segment and orientation to any member of the destination train stop set. It only does so when forced or needed. It is typically needed several times per train journey but nowhere near continuously.

[MaxUser01]

Regarding of the Quickbar and the Tool bar

In the FFF #278:

keys 1 to 0 will pick the item in the slots of the top selected page. Shift + 1 to Shift + 0 will change the the top selected page.

By Shingen:

as of 1-5, shift + 1-5/1-0, i personally prefer 1-0. Never gotten used to this weird shift system, and partially because of that i'm only using keys for the most important 1-5 items anyway.

By Raphaello:

As for 1-0 discussion: I am not using Shift+1-5 now as I find it uncomfortable so I would prefer 1-0 keys.

And others...
I also personally prefer 1-0 hotkeys, it's much more practical to press a key only rather of a modifier key + the hotkey. And I understand the "hours of muscle memory" thing of others, then I propose the following for a better experience in the 1-0 hotkeys (Quickbar) and also an yet better Tool bar:


- Proposal Nº 1:

Proposal Nº 1-A.png (199.85 KiB) Viewed 7445 times

Pros:
- The hotkey hint is much more intuitive than having to remember/analyze which key is for each item (even more the shortcut bar that is very dynamic).
- No more have to memorize hotkeys for items, neither to press any modifier key, just see the hotkey hint (1-0 numbers) and go, in one key only!
- The arrow button allows easily minimize and expand the Tool bar (no more have to "re-select" the items for expand).

Proposal Nº 1-B.png (101.89 KiB) Viewed 7029 times

- Essential/utility "toggles" are QoL items that players have been asking for a long time. There are mods for them but it would be great to have them all together in the new toolbar in vanilla game:

• Toggle personal roboport - (added to the game)

• Toggle exoskeleton - (added to the game)

• Toggle night vision

• Toggle logistic & trash

• Toggle belt immunity

• Toggle minimap

• Toggle entity info - (the panel below the minimap)

• Toggle day/night cicle - (streaming/YouTube videos friendly)

- Proposal Nº 2:

Proposal Nº 2-A.png (143.8 KiB) Viewed 7029 times

I like mods (thanks a lot to the mod community!!!). I sometimes play with several mods at the same time, but I find those icons/buttons in the top left of screen ugly, because there is no pattern between them, they are misaligned, with very different sizes, like this:

Factorio 0.16 - (Mod Buttons).png (393.81 KiB) Viewed 7029 times

I think that this proposal can help to improve the pattern of mod buttons, decrease the (ugly) mess on the screen, and not overload the new toolbar with many buttons/items.

I believe that these proposals contribute to game value.
I would like the proposals to be evaluated/considered by the community (and perhaps by devs!?). I also had a hard time working on them ...
Thank you!