Friday Facts #280 - Visual Feedback is the king

[Mike5000]

could we make construction robots prioritize power poles first when being built and make them last when deconstructing? this would help all the items inside the power lines. especially when they build a roboport but have not connected it to power

You can right-click your deconstruction planner and then blacklist roboports and power poles.

For construction I prefer the existing behavior as the base grows more steadily as power poles and roboports are placed. Indeed in the mid game I sometimes keep roboports in a steel chest rather than a passive provider and place them manually so as to indicate to the construction bots the areas I want built next.

[F117nighthawkX]

Regarding the trains, is there a chance 'Cargo Inventory' checking can see the fuel in the train, so we can set up a station condition to visit a refueling depot if there is less than some arbitrary fuel value remaining?

[Zool]

The and/or buttons should be moved up half a row, aligning them between conditions (which is their behaviour). My mockup:

download/file.php?id=41767

While I LOVE nearly everything the Factorio Crew has done in this FFF, I really think this detail change of Rhamphoryncus makes it even better!

[LDVSOFT]

The game is looking better and better, so I though...

What about another remake of the trailer with new graphics and elements? I guess the save file is still preserved, of course it will require some effort to be updated, but man it will look good.

[bNarFProfCrazy]

I'm not sure whether this is the right place for it.

But would it be possible to add an "Read this FFF on our blog" to the top of the Steam announcement?
Because the steam page does not show the animated pictures/videos and it takes multiple clicks to view them,
which severely disturbs the reading flow.

I know I can just go there myself, but in most cases the steam page is the first and easiest page I run across.

[glee8e]

For some reason I'm encountering increasing lag when reading the FFF. Scrolling is like PPT and the Firefox almost froze on some circumstance. I figured out it's that ten gif-like-but-actually-video playing in the background that has caused the lag. Anyone else with this issue?

[Recon777]

I may have missed if the was added to the game, but could someone tell me if REFUELING has been handled in the new train system? This has been one of the big problems, directing trains to go to a specific station for refuel but to NOT include that station as a stop if there is plenty of fuel. That would be amazing if this was added to the game.

Another issue has been in having multiple trains running the same route. Like let's say you have multiple coal mines as well as multiple stations which need coal delivered. In a really large setup, you'd run into throughput problems by trying to achieve this with only one train. But if you try to do this with multiple trains, you're going to run into congestion problems because you may very well get both trains going to the same station at the same time and then things get jammed up.

[factoriouzr]

This is all great, but can we also have logistics request and trash merged into one in the GUI. When I request 100 turrets for eg. I want exactly that many all the time. If I pick up more during construction/deconstruction activities, I want the excess to be auto trashed. Same for belts, inserters and literally everything in the game.

Right now it's cumbersome to set the requester limit, then go to a new tab and find the item again and set a trash limit to the same as the request limit.

It makes much more sense to have the requests and trash slots merged and have two sliders for the item, one for a request limit and one for a trash limit, but have a checkbox that links the two sliders and makes them the same value. This checkbox should be on by default (or make it an option to be on by default in the options menu of the game).

I have been requesting this for a long time, now would be the perfect time to do this with the UI changes and improvements.

[factoriouzr]

Firstly, thank-you! Not just for the great new features in the FFF, but for all of it. The game, the constant improvements, the response to our feedback, all of it. Hurrah for roboport/leg toggles, and the new train control features, all good stuff.

Secondly, toolbar idea: 'Switch train to manual' for a train you're on board, so it isn't sitting checking for an arbitrary circuit condition to stop it buggering off when I get where I'm going, or if I just need to do a bit of manoeuvering, without me having to open the gui and find the little switch. (In my ideal PAX train setup 'switch to manual' would be a possible 'wait' condition, but as you're moving on from train features for this release...)

Thirdly, (only semi-) related: Pics of the new toolbar have reminded me of a personal gripe: because all slots on it are to be filtered the annoyance of having slots the same colour as blueprints/books will go away - please can this be true in the main inventory too? Perhaps it's just me as I have the ui shrunk pretty small, but I find having totally unrelated things use the same blue background visually confusing and cluttery. (Re. last weeks FFF I would prefer to still be able to have unfiltered slots on the bar for last thing crafted/picked up, as others suggested.)

I like the train toggle, can we also have a GUI that pops up when you enter a train with all the stops (ideally you can also favourite stops and they show up at the top) and you can just click on a stop to go there instead of having to open the map and find the stop on the map every time you go to the same outposts.

[factoriouzr]

a little bit better presentation but still not predictable

here the screen of FFF



is the 2nd condition
- A or ( B and C )
- (A or B ) and C

The 2nd condition doesn't have an or in it. That or splits the 2 conditions.
It's
(Empty Cargo AND 30s passed)
OR
(Passenger Present AND 20s inactive AND Circuit condition)
I'd actually like it if the groupings didn't include the OR, they'd be a bit more clear. But still it is what it is.

I agree this new visualization for conditions is still confusing. I like the one suggested by someone else where the "and" and "or" is between conditions and moved left more to indicate nesting.

As a fallback option, at least put the "and" and "or" inbetween conditions and make your current friday facts visualization lines only group and conditions, then you end up with something like A or (B and C) or (D and E) where the brackets are the only things joined by the line.

[factoriouzr]

Can we click on a blueprint in a blueprint book to select it now instead of having to scroll to it even though we have the blueprint book open and have the mouse pointed at the blueprint we want? There should be a way to click to select a blueprint without removing it / picking it up from the book.

[Pi-C]

For some reason I'm encountering increasing lag when reading the FFF. Scrolling is like PPT and the Firefox almost froze on some circumstance. I figured out it's that ten gif-like-but-actually-video playing in the background that has caused the lag. Anyone else with this issue?

Same here! I opened the FFF in a new tab and all of a sudden, top showed 348% CPU usage for Firefox. After manually deactivating the "Loop" option for every video, the value dropped to normal values, so the computer responded to input (mouse/keyboard) again.

[factoriouzr]

Great Stuff.

Tools:
1. Disable logistics requests
2. Belt Inertia Dampening
3. Mirror Blueprint

1. See Xterminators video
2. Stop being carried away on belt. I got this from a mod which added this with a researchable item
3. Not sure how it worked but there was a mod that I used that did this. It is super handy for flipping things like logistics to belt load/unloaders.

yes for all 3

[factoriouzr]

I'm starting to feel like the black sheep in that I create player access stations explicitly for player travel to key sectors of the factory.

I do that too

There is also the Shuttle Train Lite mod that automatically brings up a list of stations when you enter a shuttle train

Yeah, me too!

Me too!!!

[Pi-C]

Reading the FFF for the first time, I was really pleased with the news. I like the GUI changes for trains, especially that for the waiting conditions. Some people complained that the new design would still not be quite easy to grasp, and putting OR on a separate line would make things more obvious. In my opinion, the developers' design is very efficient: The braces on the left side clearly structure the conditions into sets/blocks, and having the OR operator right in the first line of a block is really useful because it saves screen real estate. It might take getting used to it, but if there was an explanation of how the new GUI works in a tutorial or something, new players shouldn't have much trouble figuring it out.

The greatest surprise for me was the introduction of waypoints. I had wished for something like that for quite some time; in fact, I left a comment about it just in the thread for last week's FFF. After rereading the FFF, however, I realized that this kind of waypoint won't help me at all. Obviously, these waypoints will work magnificently for conventional train networks with trains dedicated to specific stations. However, I still have not given up on the idea of having a train network where all stations have the same name, and all trains the same schedule (2 times the same station name, both with conditions set to "Circuit network GREEN" AND "Inactivity 1 second").

I know such a system might have limitations and throughput won't be optimal, but it seems so interesting to try.

With the new waypoints, trains will pass through but not stop at a station if they have said station in their schedule and if they have no waiting conditions set for it. My trains will path to such waypoints, because these will have the same name as all other stations. However, they will also stop there because they do have a waiting condition set for it. In my case, such a waypoint would always act just like any other station.

What I had in mind when thinking about waypoints was the opposite approach: Not the trains decide whether they will consider a station as a waypoint, but the station enforces on trains that it is a waypoint and they should just pass it. Now, the current behaviour does make sense for conventional networks because the same station could serve as a normal stop for some trains and as waypoint for others. But I think these two approaches could be combined!

How about adding an option to the train station's GUI, something like "Waypoint -- trains won't stop here"? If turned on, this option would take precedence over the "Train has no waiting conditions for this station" condition, so all trains would pass through. If turned off, the usual behaviour (trains stop if they have this station with a waiting condition in their schedule) would kick in. This should be compatible with conventional and 1 stationname/1 schedule networks, even though it might seem a bit messy on first sight. However, this new GUI option would change nothing for people with conventional train networks -- they could just ignore it (obviously, the option should be turned off per default) and everything will work as expected.

What do you think, could something like that be implemented? That would make somebody very happy!

[nepp95]

So.

It is February.

You said that in February we would get the date for 0.17.

So when can we expect 0.17? Please?

28th of February is still February. Why the rush...

[quyxkh]

[stations all have the same name, all differences happen because of layout]

I think you could get that with what's described for 0.17 by putting a no-condition "Exit" entry immediately after each (or rather the only) ordinary station in your schedules and a train stop named "Exit" at the exit of each real station, no?

[Pi-C]

[stations all have the same name, all differences happen because of layout]

I think you could get that with what's described for 0.17 by putting a no-condition "Exit" entry immediately after each (or rather the only) ordinary station in your schedules and a train stop named "Exit" at the exit of each real station, no?

It could work, but I would need more than twice the original number of stations for that, which might get a bit messy. Basically, I would have to change the schedule from "1) Station A (Circuit + Inactivity), 2) Station A (Circuit + Inactivity)" to "1) Station A (Circuit + Inactivity), 2) Exit (no condition)".

The reason I need waypoints at all is because I need routing stations in addition to normal loading/unloading stations. All trains have the same schedules, so the network is supposed to direct the trains based on what they carry. Before branches, I stop each train to read its content (which imposes a penalty on train speed already). If a train carries something that is needed off the main line, the main line will be closed for this train and the branch-off will open. Now, it may happen that the routing station is close to a regular loading/unloading station on the main line. Without a waypoint on the branch-off, the train will see that there is a station it has on its schedule on the main line and try to go there -- which it can't because the main line is closed, so it is blocking the line until I can manually intervene.

With my suggestion, I would just have to put one dedicated waypoint after a routing station -- but only if the next (routing or regular) station in the one direction is considerably further away than the next (routing or regular) station in the other direction. Going by your suggestion, I would have to use 2 waypoints after each routing station + 1 waypoint after each regular station. This is more expensive in regard to material needed, it would clutter up the map -- and I'm afraid it could also be expensive UPS-wise, just because I would have to put so many new stations on the map.

[pleegwat]

[stations all have the same name, all differences happen because of layout]

I think you could get that with what's described for 0.17 by putting a no-condition "Exit" entry immediately after each (or rather the only) ordinary station in your schedules and a train stop named "Exit" at the exit of each real station, no?

It could work, but I would need more than twice the original number of stations for that, which might get a bit messy. Basically, I would have to change the schedule from "1) Station A (Circuit + Inactivity), 2) Station A (Circuit + Inactivity)" to "1) Station A (Circuit + Inactivity), 2) Exit (no condition)".

The reason I need waypoints at all is because I need routing stations in addition to normal loading/unloading stations. All trains have the same schedules, so the network is supposed to direct the trains based on what they carry. Before branches, I stop each train to read its content (which imposes a penalty on train speed already). If a train carries something that is needed off the main line, the main line will be closed for this train and the branch-off will open. Now, it may happen that the routing station is close to a regular loading/unloading station on the main line. Without a waypoint on the branch-off, the train will see that there is a station it has on its schedule on the main line and try to go there -- which it can't because the main line is closed, so it is blocking the line until I can manually intervene.

With my suggestion, I would just have to put one dedicated waypoint after a routing station -- but only if the next (routing or regular) station in the one direction is considerably further away than the next (routing or regular) station in the other direction. Going by your suggestion, I would have to use 2 waypoints after each routing station + 1 waypoint after each regular station. This is more expensive in regard to material needed, it would clutter up the map -- and I'm afraid it could also be expensive UPS-wise, just because I would have to put so many new stations on the map.

I don't think you could make decisions here on waypoint stations anyway. even if a waypoint reads the train for one tick, you'd then have to get through all the requisite combinator logic before the train arrives at the branch.

I think there's an alternative though - you could have a couple of combinators next to each signal acting as a latch. That makes the train contents travel along the line, advancing to the next signal as the train passes the previous. At a simple exit, you can use the forwarded signal to control the switch without having to read the train again.

I'm not quite sure how to build a logic gate that works correctly at a merge (since in conflict situations you need to detect which train advanced). The idea probably also requires that signals are non-red for at least one tick between one train leaving the block and another train entering, but I think this is the case anyway.

[JCav]

Regarding the trains, is there a chance 'Cargo Inventory' checking can see the fuel in the train, so we can set up a station condition to visit a refueling depot if there is less than some arbitrary fuel value remaining?

That cannot be done in the manner you desire. Fuel would have to be checked against a different value than 'cargo' otherwise trains would not be capable of actually carrying fuel from source to destination for offloading.

That having been said, this issue is one of the thing I'd really like to see dealt with. It's easy enough to just have trains wait at a fuel depot until they get a signal indicating they are needed somewhere, but that's an inelegant solution to the problem.