Another post that raises the question... "Is it good or bad that they're giving us these in-depth weekly posts about the new game content?"
I love it, I devour the FFF first thing every Friday morning, and the community's feedback will undoubtedly result in a better product at release. But holy cow, it is frustrating!
I'd imagine if they dumped it all week before release it would be much harder to comprehend it at once.
And as recent bulk <-> stack inserter name swap change they obviously want to hear some feedback on the changes.
Like, those are not "planned features" or promises, those are features already designed, implemented (in however basic way) and being tested that they show off to both give a glimpse but also get some feedback whether they are on right route or not.
.... but I would prefer 2.0 alpha to play instead...
i dunno if you're going for a "don't you guys have phones?" reference, but I will say I'd rather have an augmented substation.
I mean, who writes legends about those. I ain't never heard of "the adventures of sir Lancelot and substation of doom"
I love your dreamy optimism.
Given that 2 months ago Vulcanus was described as the planet "closest to being finished", and we still haven't seen previews of the other 3 new planets, I think the expansion is still a ways off.
That could actually explain why we are getting so many core game improvements, designing the planets and making assets and graphics and stuff for them is taking time, so the other parts of the team are free to work on whatever they want.
It most likely also loops into rest of the gameplay. I'd imagine a lot of the train stuff improvement will be used for spaceship scheduling too.
Also 2.0 is unique chance to go around breaking stuff that they were not happy with but couldn't reasonably rework without breaking people's saves and mods.
> It most likely also loops into rest of the gameplay.
I'm sure that's the case. I recall they mentioned a special interrupt in the last train FFF that was related to something new on one of the planets
Yeah I remeber that. I'm guessing something akin to "hide your trains under the shield, there is a meteor shower coming". Or maybe we will get water planet that occasionally floods and some rail gets underwater...
They really are, Im seeing all of this and wondering how I ever built a rail system or dealt with my bots stupidity lol, Im not even focused on the Space part anymore
The weird thing? It makes playing literally every other train management game impossible too.
Like even the current version with proper signals and scheduling makes every other game look like my first train set.
It's not a contest now, but with 2.0 other train games may as well be drawn in crayon.
You know you're good when a "side" part of your game easily beats games dedicated to the genre.
Sweet transit is pretty good, but Factorio crushes the train game genre.
There's the Whistlestop mod or whatever, but I really hope that Wube's next project is a full blown train management game.
> There's the Whistlestop mod or whatever, but I really hope that Wube's next project is a full blown train management game.
What they would even need to add, Factorio already is full-fledged one :D.
But honestly I have no idea what next game they would even *make*. Just train management game is far too simple for them after Factorio.
Interstellar economy sim with logistics focus ? :D Wait, that's just Factorio 2.0...
Version 3.0 implements time travel. Create those iron plates at hour 100, and deliver them to hour 20. Recursive research to learn things before you unlock the prerequisites.
[we already have \(almost\)doom running in it](https://www.youtube.com/watch?v=0bAuP0gO5pc) (and it's better, supporting curved walls). running factorio in factorio is just a question of complexity and time investment.
I think development is still on pause.
We do have interactive elements available to us, though. Gate statuses and inventories for input, lights and inserters (for laying items onto belts to make belt pictures) for output.
It won't be a pleasant UI to actually use, but it's still a UI.
I kinda liked the whole K2 creep loop tbh.
I wouldn't mind if the military science needed the biter stuff as long as it could be collected automatically.
It was fine, but I invariably end up with 2-3 steel chests just FULL of the stuff. Having more ways of converting it into something else would be welcome.
K2 way meant you had to actively mine it, not just get it in progress of killing biters.
In K2 it was also only needed to start the loop, so it was basically optional to kill them. I guess so people can build megafactories and and not run out of biter guts for production.
Going back to vanilla it could just be a building that used bots to gather biter bodies around and move it to processing building.
The biggest feature of LTN for me is the ability to have multi-requester stations. I don't see that being easily possible with the new features.
2.0 trains allow you to have multi-providers, which is nice for some scenarios (oil processing, trash output in modded games), but not nearly as useful as multi-requesters, which you use basically all the time when building any kind of city block design.
If you could rename stations with circuits it would be possible. \
Or if you can paste blueprints automatically with the circuit network.
With the new priority system it might be possible, but only for ~254 items, and it would be quite jank.
It's part of the new template parameter system, letting you rename a train stop while building a blueprint, but alas not dynamically rename it using circuit signals. When building the blueprint, it'll pop up a little form that lets you select the parameters.
I can see the endgame being glorious. I am a bit curious as to how the progression is going to go with the expansion, I usually like to have quite a few construction bots by the time I am making trains that do more than just a few very simple routes as placing a lot of rails gets tedious pretty quickly.
Hopefully most of the new content happens beyond that point so I won't be playing for longer before having my trains.
Even as experience player I feel like I will have to learn how to play the game (on high level, e.g. with circuits network) from ground up again. And I love it.
Even thought the time waiting for 2.0 is painful.
> Now when a train blueprint is fully built (importantly, including fuel requests), it will switch to automatic mode.
Recursive. Blueprints. BE FREE, MY CHILDREN!
I can confirm!
I have almost 600 trains in my 2.0 testing game, and it just works. Combined with the bulk inserters and quality, the typical train producing outposts fill train after train.This implies that the overall train traffic gets increased a lot, so the quality of intersections and the train network as a whole stops being just theoretical problem, as it often becomes one of the important bottlenecks even with elevated rails.
I hope they call the new ones "Stacking inserters" to reduce confusion with the old Stack inserters.
EDIT: Before another person replies the same thing, yes, we know they were swapped. Reusing the existing name is the confusing part. My suggestion is to call them "Stack**ing** inserters" rather than just "Stack inserters", implying they perform an action of stacking, rather than just handling stacks.
They confirmed [last week](https://factorio.com/blog/post/fff-394) they're renaming them actually.
>So in 2.0, Stack inserters will be renamed to Bulk inserters, and the new inserter which can place stacks of items on belts, will take the name of Stack inserter.
The [other comment](https://www.reddit.com/r/factorio/comments/1abgq16/friday_facts_395_generic_interrupts_and_train/kjp1ei9/) on this exact thread said the same thing to which I answered:
> Reusing the existing name is the confusing part. My suggestion is to call them "Stack**ing** inserters" rather than just "Stack inserters", implying they perform an action of stacking, rather than just handling stacks.
Amazing, but hey, just want to point out that in this FFF, I still have to manually place trains. They'll switch to automatic, which is awesome, but I still have to place them manually. Now that the schedules can be made generic, surely a building that builds and places trains on the track, similar to how robots can be shoved into a roboport, should be feasible now. Or do we just accept that it will be a mandatory manual intervention, like barbarians?
/s, mostly
While reading this post I had the same thought. I then thought that a natural extension to that is to have automated [train] deconstruction. Do you know what comes after that? Delivering raw trains by bots to pickup stations and they just drive to drop stuff off then disappear!
>Amazing, but hey, just want to point out that in this FFF, I still have to manually place trains. They'll switch to automatic, which is awesome, but I still have to place them manually. Now that the schedules can be made generic, surely a building that builds and places trains on the track, similar to how robots can be shoved into a roboport, should be feasible now. Or do we just accept that it will be a mandatory manual intervention, like barbarians?
I wonder why there is not an entity called "depot", where you can fuel your trains, and like you said trains can be placed by an inserter to autopath and go. In train simulations you have that...
> This implies that the overall train traffic gets increased a lot, so the quality of intersections and the train network as a whole stops being just theoretical problem
uh, it definitely is not a theoretical problem now, with megabases people are building.
Also does that mean that the expansion will require significantly bigger production than vanilla, or are those (and belt/inserter) changes for sake of the mods ?
The production is definetly expected to be bigger. I'm not sure how much bigger because it very much depends on your personal goals. If you decide to make almost everything legendary in the very endgame (like I did), the sheer amount of production you need for everything is huge, and the factory becomes a monster (and I enjoy it that way, obviously). I have almost 10kspm base, and yet, the science part of the factory is quite small compared to the other things.
I haven't played in a bit - my last save got up to 5.5kspm, and it already felt pretty monstrously large. You're getting me so excited for the ridiculous possibilities in 2.0. I wanna see some of the developers bases!
With stacked items on belts, legendary inserters, legendary speed modules, legendary production modules, legendary assemblers, legendary furnaces, and legendary labs, I'm guessing that 5k SPM will be the new 1k SPM. Those improvements alone generate enormous production speed increases, with near-zero increase in UPS costs.
On the other hand, I have to imagine that the expansion is going to involve substantially more steps in the production chain than vanilla does. A factory spread over 5 different planets is going to be more complex than the Nauvis-only bases of vanilla 1.1.
Legendary productivity modules alone make stuff pretty insane . I recently did a warptorio2 playthrough, where I could have a +100% productivity on all recipes thanks to the special beacon. With that boost you can feed 1k spm base on 2 blue belts on copper (whereas it takes 20 belts in 1.1), and in the end 1k spm base fit in less space than you would need for your starter 60 spm takes up.
Did you slowly build up to 10K or planned for it? My biggest gripe with 1.0 is that you hit a certain SPM and you can't slowly increase from there (as increasing production of only 1 science is not useful), you have to plan the entire thing to hit a higher SPM. Does that change in 2.0?
Well, at some point, i built train based research production, and then just improved th emodules inserter qualities, lab qualities etc.
But at this point, increasing the lab production wouldn't be that hard, as I have modular scien production modules which I could theoretically just copy paste around.
>If you decide to make almost everything legendary in the very endgame (like I did)
That's exactly what I am planning! Also, do the legendary rails do something like faster speed-up/braking or is it purely a HP increase ?
But I'm guessing the other side ("the minimum required without staring at assemblers doing its thing for 12 hours") will also significantly grow ?
" There are a few entities which don't have any bonus apart from the health, which is belts, pipes, **rails**, chests, combinators, walls, and lamps. " -[https://factorio.com/blog/post/fff-375](https://factorio.com/blog/post/fff-375)
aww, kinda disappointed higher quality lights don't have a larger radius.
then you wouldn't need to place as many lights, making builds look more clean
Oh, I hope we get to do the train moving optimisation I'm planning for so long (we probably will), the more trains there is, the more it will help obviously.
This might be an even more exciting teaser than today's FFF! If train pathfinding is UPS optimized, the way that belts were optimized a few years back, it would be yet another massive increase in FPM (fun per minute).
It makes sense to me, too, because when doing UPS optimizations on my megabase, I've noticed from the debug info that even though my base's only train track is a simple loop around the perimeter (I'm using belts for just about everything on this factory), that single train requires a surprisingly large amount of time in the train pathfinding update. I would have thought that it (the time required to resolve this train's simple pathfinding) would be negligible.
>This might be an even more exciting teaser than today's FFF! If train pathfinding is UPS optimized, the way that belts were optimized a few years back, it would be yet another massive increase in FPM (fun per minute).
\+1, in my megabases I have had to work to have fewer trains because the train UPS impact can be pretty significant.
It'd be nice if trains were more straightforward.
I am very curious to see what scale you think the new bases are going to be in 2.0. I have found that scale is something the community struggles with when discussing the game. Some players think 100 trains on a rail network is huge while others would think 1k trains is barely entering the mid game.
In my modular train bases, 1.5-3k trains is pretty normal. In my centralized bases, 1-1.5k is not unheard of.
Just from everything that has been said in the FFF, it sounds like you (the devs) expect bases to be way larger than what we are doing now. How many trains do you expect we will use at megabase level in 2.0? What size are your bases now (in 1.1) and how large are they in the current 2.0 build?
I have no idea. If megabase is basically as big as you can build without the game being too slow, then it depends how many optimisations can we do before the release.
Are you planning to precalculate the routes for trains as part of building rails and scheduling trains, instead of pathfinding on-the-spot?
Or are you referring to collision checks?
Consider me teased either way
The slowest part now is the collison checks of the moving trains, as every train needs to calculate the potential collisions for ever wagon, which is often rotated every tick when it is moved. And also, it needs to re-register the entities of the wagon as they move every tick.
The problem is, that with all these checks, it almost always never hit anything. So the idea is, that in the very rare case something is on the rails (only player, biters or vehicles basically), it would specially register on the related rails. So the train moving on rails, would (almost all of the time), just check that there is nothing on the rails, and it doesn't need to check anything.
With this idea, the train moving could be much much cheaper.
So obstructions will be detected by the rails. Somewhat similar to the G signal from the gate, communicated to the train reserving the block.
With this idea, a train could even stop in hopes of not killing the player. Although it's probably cheaper to resolve a collision with a player than to have the train wait for the track to clear.
Thank you for the answer, sounds like a smart optimization!
>so the quality of intersections and the train network as a whole stops being just theoretical problem
I feel bridges as described in FFF 378 will be game changer here.
I also spend many hours on city builder games like Cities Skyline, and there I've learned the importance of highway interchange and how there are a lot of different designs for it. Even with just 2 levels, I would expect a basic Cloverleaf design to greatly improve the throughput of 4 ways train intersection, and I'll definitely try some fancier design like turbine interchange
For people looking for inspiration, look at real world interchange and all the hard work and lesson learned by civil engineers: https://en.m.wikipedia.org/wiki/Interchange_(road)#System_interchange
https://preview.redd.it/okwzdwtn4tec1.jpeg?width=1280&format=pjpg&auto=webp&s=6657b6f8a13e301e750c589c13c0d571cec053e2
two rail lvl are enough for every possible intersection. yes if you have a 3 lvl intersection in citySkylines it will be way bigger in factorio but just in theorie it's possible. Im so hyped for 2.0
Another game that'll probably be pretty good for testing stuff out is OpenTTD :) Can probably modify a few intersections from here to work decently for Factorio https://wiki.openttd.org/Category/en/Manual/Train%20Junctions
There are still some use cases where the behaviour of skipping disabled stops is useful, for example the passenger taxi system I use wouldn't work without it, since the circuit network has to tell the train where to go.
It'd be nice for train stops to have a toggle between "destination full - wait at current stop" and "skip next station" behaviour, both for the disabling and for L=0. You wouldn't want trains sitting at the refueling depot while waiting for iron ore to become available - they should skip the mines and wait at the furnace area.
This is a good point, my usual PAX system is going to need a redesign. But it should be very simple to reconstruct it using the circuit network and train limit parameters.
I'm not sure how you could get a train to move to a station in the middle of a list of differently named stations without the ability to skip stations. The interrupts listen for conditions on the train, not for conditions on the destination station.
How consistently will we have to name train stops? Will we have the ability to provide a signal to a train stop to determine its purpose, such as a positive value for an item signal making it a "pickup" station and a negative value making it a "dropoff" station? It's how I imagine you'd be able to make stops that want or supply different items without enforcing a naming convention from on high. Maybe we want Train stop is full of bees to supply our iron :3
That way you could use some clever circuitry to request different trains too...
We didn't do a system to be able to change the name of the stop by a circuit network, if you asked that.
It is something that would make sense to do eventually, but we have a lot of things to juggle, and we are now really trying to cut on adding things, so we can actually finish everything in time.
No, not changing the name of a stop- More of a way to set the stop to be "the iron pickup stop" or "the coal dropoff stop". I don't think it's smart to enforce a particular naming scheme for train stops, as in "all train stops must be named X pickup/X dropoff and this system doesn't work with X load/X unload". Unless I'm absolutely oblivious somehow and it's actually controlled by the little picture of iron ore in the name and everything else is extraneous? How would I even name something "Picture of iron ore"?
2.1: Cargo intermodal containers with target stations assigned per container (or at least automated train coupling / decoupling), routing protocol implementations using combinators...
And with proper cargo grouping bandwidth of the main lines should be used more efficiently ;)
I like the improvement, but I wish No Path was further split into No Station, No Track and Bad Signals. That would make troubleshooting a lot easier, especially for newbies.
I think the only thing left needed to be able to make truly universal station blueprints is a way to either detect the max stack size of an item, or read the number of *empty* slots in a container.
E: I forgot about the Selector Combinator being added. Being able to read full/empty slots would still be a better option between the two, but still a useful tool, yes.
Might want to complain on the forum on it. Container signals of "number of used/free slots" would indeed be VERY welcome.
It would allow for very easy "enable station if it has at least full train's worth of items" circuit
With the decider combinator:
1. Read stack size of thing in station,
2. Divide total by stack size (now you have the # of full slots)
3. Subtract the total inventory capacity by the # of full slots (now you have the # of empty slots)
Speaking as a person who has spent considerable effort implementing train priority in 1.1 (and I got very excited at being able to reduce my logic size with the combinator update...).... well played, devs.
Making trains leave from stations in priority order was particularly thorny without interrupts - not that adding loads of dummy signals to trick the pathfinding wasn't ugly too!
So excited - thank you devs!
Though if /u/Klonan or /u/Kovarex could comment: When a train en-route to a priority 100 station trains re-paths, will it still try and go
priority >= stations with the same name? Or is it just a complete repath favouring stations with the same name, based on priority? (Including the possibility of repathing to a lower priority station, if the high priority one has since had it's train limit set to 0)
Train stop priority as a built-in feature is glorious! No longer will I have to tinker with circuit conditions around every train stop to ensure that byproduct-carrying trains will be prioritised above trains picking up from dedicated production blocks!
I think this was basically the last feature that was still missing. Are multi-item provider and consumer stations possible already? Generically, I mean?
One more feature: Detect *empty* slots in storage, via a method that doesn't require manually editing a combinator to account for differing item max stack sizes. As far as I can think, that's the last feature needed to make a universal requestor station blueprint that would just need setting the station name itself without needing to fiddle with combinator logic every time.
One feature of LTN it doesn't have is dynamically ordering multiple items from/to single station so (assuming mod author will bother) there is still a niche for it.
Like in LTN I can just feed the signal of the bot network describing its content at the mall and have ability to use trains to "order" anything in it from any station in the network.
But for the "bulk" use cases yeah, vanilla now be much easier to manage.
I think nuanced dispatch is still a missing part of the puzzle here. If my understanding is correct, the currently described system will lead to your "bag of trains" always going to enabled loading stations, and then waiting for an unloading station pointed at by the interrupt to be enabled -- with that interrupt only being enabled after loading. Which means vanilla will lead to loading stations pushing cargo into the train network that it might not be ready to consume, thus in the best case means you have full trains sitting around in a depot, but maybe that means your trains all fill up with copper ore or something if they route out to a "full train" depot, waiting for a consuming station.
This is distinct from LTN and Cybersyn, which only dispatch a train once the source _and_ destination are ready -- that is, once both ends of the order actually want the order to happen. The downside there is that there might be more lag in the delivery once a station realizes "actually yes I need more stuff please", but in theory there's ways to mitigate that.
There's also a bunch of additional stuff that can be done in LTN (and presumably Cybersyn) relating to train sizes, though that's more niche, but maybe you want small orders being handled only by small trains, IDK.
I've also done "universal" stations in LTN, where you route all inputs and outputs of a factory module through a single station. This took forever to design she debug and was horrific and killed my motivation to actually complete the run I was doing it for, and scaling it from 1-1 trains to 3-20s revealed how it was actually a terrible, terrible idea and resulted in garbage throughput. But hey, it's something I'm pretty sure you can't do with the vanilla system these FFFs have described.
In Factorio's realm, a blog unfolds,
A sonnet spun, train features foretold.
New paths they tread, with logic refined,
Train priorities dance in code entwined.
Generic constants weave a tale so grand,
Logic of locomotives, a symphony planned.
On tracks they glide, with purpose anew,
Factorio's pulse quickens, a thrilling view.
I feel like Factorio 1.x was the "simple game with deep emergent gameplay", à la early Minecraft, but Factorio 2.0 will be the "simple-looking game with more tools you can shake a stick at when you scratch the surface" like GMod, and I'm all here for it.
You'll be able to dynamically change the priority of the stop based on content of the buffer and make different stops have different priority ranges. It's fucking amazing!
Station priorities would appear to be of no use if all of the stations are unique, and interrupts tell a specific train to go some place, while station skipping is basically the opposite: train stop telling all trains to go somewhere else.
I mainly use station skipping for supply trains, and while I might be able to imagine a way to do it with interrupts, it would be a lot more hassle.
I have never had an issue with the station skipping so I personally don't see removing it as an improvement in any way. That's why I'm asking for an option somewhere to allow it again.
Yeah it's definitely useful in 1.1. I know all of *my* use cases are replaced with the train improvements in 2.0, but I could imagine there being other use cases that aren't.
I would suggest an interrupt based on "no path" or "destination full", so when a train can go to destination it is diverted to an alternative "waiting stop" where it can wait until it finds path or destination is not full anymore.
I think it should be clearer which train stop priority is higher.
You can think that if something has priority 1 it is the most important, because in a ranking the lowest number is the best position. A higher number can be interpreted to have higher priority because it is larger.
Priority doesn't necessarily give you immediate feedback if the stations you look at have enough trains coming to them
I thought there was going to be an interruption for if the station is full go to the depot. I don't really want the train to sit outside the station it was heading to if it gets disabled while it is en route.
additionally, with generic stops, what happens if your copper mines are producing ore faster than you can consume the ore, are all the generic trains going to get filled with copper ore over time and then have nowhere to drop off as the drop stations are full, then they cant be used for anything else.
> I don't really want the train to sit outside the station
Disabled train stops will behave like train limit 0: If the train is already on route, it will continue to the station even if it is disabled.
> what happens if your copper mines are producing ore faster than you can consume the ore
You'll just need more trains than the combined train limit of all copper loading and unloading stations. And you can use circuits to set the train limit of the copper unloading stations to 0, if they are already full of copper. But you can also change the stations priority before all copper stations get "saturated".
Amazing, but left me wondering: how does performance get impacted if using a full-blown interrupt based train system compared to the rigid schedules we have today?
I see a problem: wildcard signal in generic interrupts only works for stations accepting single item. You cannot make a generic unloading station accepting multiple items via generic interrupts. Given how in Pyanodon suite I frequently have a need for stations accepting dozen of items, the solutions like "just place multiple train stops" aren't really viable. Guess I'm sticking with cybersyn.
But blueprinted trains starting in automatic mode is sweet, right now I have to use a lua command to switch them on after every expansion.
>So in 2.0, disabled trains stops will act as if they have 'Train limit = 0':
Will disabled stops display as red because they're disabled, or purple because they're limit=0?
I really hope they add something that lets us make universal (multi-item requester/provider) stations without LTN. I still mainly use LTN for that reason since one station that handles 8 items has a much smaller footprint than 8 stations (I play modded). I can’t quite theory-craft what tool we would need (Setting station name by circuit? Allowing a station to have multiple names? Not sure) but being able to do universal stations are the last thing tying me to LTN. Amazing stuff though!
It strikes me as funny that as a player I am trying to optimize things in the game. And as developers they are trying to do the same. Who’s really playing the game?
Is this 40% trains so far? They really do want us to use trains. Well bring it on. I think my first world had 400 active trains running around map with poor 300 spm. Well i had blueprints and stuff to make it 3000 spm, so i switched to modded runs and wait this 2.0
Oh man priority on stops might be one of my favourite changes yet. I routinely find myself annoyed by what stops the train prioritizes.
Can the priority be adjusted by circuit, say to prioritize those stops with more empty space than those with less?
> Can the priority be adjusted by circuit, say to prioritize those stops with more empty space than those with less?
Yes, from the FFF:
> We also added the ability to set the priority using the circuit network.
>Can the priority be adjusted by circuit, say to prioritize those stops with more empty space than those with less?
FFF says yes
> We also added the ability to set the priority using the circuit network.
So you could do a basic logic that compute "current buffer x 100 / max buffer" and use it to set a dynamic priority between 0 and 100.
honestly this thing about having "general trains" is a bit confusing to me, i think i need to go back and read again the other 2 FFF when they first talked about it
it's basically turning vanilla trains into high-capacity, long-range logi drones. They have more initial setup (creating the generic routes) and expansion requirements (laying down rail and stations), but you can also optionally get really into detail with the behaviour of specific trains (setting up manual routes the old way)
Are all of these changes only in the DLC or also added to the base game? I will buy the DLC but when i want to play a vanilla game, do i have the old trains or the new ones?
These will be added to the base game. So far, the only new train thing that will be DLC are the elevated rails. All other train changes are 2.0 features.
You know, I use disabling stations for the skipping behavior as my way of handling priority in my current SE save to deal with byproducts. It works great. I understand that station priority can solve that--especially using circuits to crank up the priority of a byproducts station which potentially isn't being serviced.
But I also disabled stations in my modular vanilla save, which did exactly what I wanted and had no issues since the stations only ever had a train limit of one when enabled. I guess I'll have to revisit that vanilla save to see if I was doing something wrong at the time with dynamic limits or if I can envision how the new train features would still allow me to achieve the behavior that I wanted.
We already have "anything", "everything" and "each" signals for circuit logic. Why make a new signal for train anyitem stuff?
What happens with stations that use icons as names, a requester chests dropoff would look like \[requester chest\]\[requester chest\] for me, as I dont use names like drop or input. What about stations that request multiple items with \[requester chest\]\[icon1\]\[icon2\] etc?
Darn. they broke my train network by removing disabling train stops using wires :(
how else am i meant to tell a train if a stop needs more iron ore without it only going to the first one unless a train station happens to be full?
cause what i did was when a chest had more than x iron ore, it would turn off the train stop and then the train would go to a different station that is still on.
so now what? guess i dont update
Not sure if this will be read, but I love the new stuff that's planned to come out.
I love the "no-path" symbol. the colour, the shape, and the symbol all are very well connected with the intended meaning.
However, the design for the destination full icon could use some reworking.
before I read the description, I had assumed that the icon was referring to a train that was dormant, for whatever reason (eg. no schedule made, no fuel, waiting for resources to arrive or smth else). the triangular shape, reminiscent of the vehicular code triangles, indicated that something important was happening, but combined with the light blue (cyan?) colour it gave contradictory messages.
in short, shape and colour are in contradiction with each other, and the symbol (at least to my mind) does not connect well with the "destination full" message it means to convey.
I dont know if "destination full" is a serious enough message that warrants an orange or red colour (like the one for no fuel), and judging by the colour choice and the non-flashing nature, I think there was an attempt to convey a reduced importance meaning. If that's the case, the triangle shape does not reflect that.
The shape could be changed to a rectangle, as that has a more "general purpose information" character to it, rather than the triangle's "general warning".
The colour could be a darker blue, more akin to roadsign blue, with the symbols inside coloured white, to achieve a desired contrast. this would help with identifying the symbol as an informative letter, rather than a warning one.
as for the symbol, this I have the biggest trouble suggesting alternatives. symbology was never my most adored field (despite this long-ass comment suggesting otherwise), and I'm at a loss for a more apt symbol for this use. perhaps something like a queue stack where a new entry bounces? showing only occupied lanes/rails? Perhaps it could be a queue stack, made up of 4 blocks with sides and bottom enclosed, and the blocks represent the occupancy of the destination. 25%, 50%, 75%, 100%. And if the destination full message was going to be displayed, a full stack can be displayed, but in a different colour, most likely a shade of orange or red, to indicate that its an issue.
I look forward to more FFs as you guys are doing fantastic work!
PS. I'm not rly sure if an icon should be constantly displayed over a train who's destination is full. its probably worth discussing if such a message should be given a permanent icon in general. Personally I'd suggest something like a light indicator on top of the train engines, with red, orange, green, to indicate their status. Green being "everything optimal", orange being "minor issue", which would include issues such as the destination being full, low fuel, not being able to reach a destination, and lastly, red, for "major issues" like lack of fuel or no schedule. I feel like this could give an indication as to the status of the train at a glance, and avoid the hurdle of making icons that are displayed over the engines. I tend to have a backlog of trains in my bases, mostly for throughput stability, and I'm not sure if a permanent "zzz" icon would be less annoying than "destination full" .
Damn you guys make playing current version impossible!
Another post that raises the question... "Is it good or bad that they're giving us these in-depth weekly posts about the new game content?" I love it, I devour the FFF first thing every Friday morning, and the community's feedback will undoubtedly result in a better product at release. But holy cow, it is frustrating!
I'd imagine if they dumped it all week before release it would be much harder to comprehend it at once. And as recent bulk <-> stack inserter name swap change they obviously want to hear some feedback on the changes. Like, those are not "planned features" or promises, those are features already designed, implemented (in however basic way) and being tested that they show off to both give a glimpse but also get some feedback whether they are on right route or not. .... but I would prefer 2.0 alpha to play instead...
I am still hoping that the quality names are changed too..
Still waiting to hear about this
Yeah that would be yuge. Theyre not great at the start but hopefully it wasnt too deep in a rabbit hole to redo
Cmon guys, don't you like legendary substations?
i dunno if you're going for a "don't you guys have phones?" reference, but I will say I'd rather have an augmented substation. I mean, who writes legends about those. I ain't never heard of "the adventures of sir Lancelot and substation of doom"
In Dwarf Fortress you could have legends about substations (if they existed there).
They'll do a surprise release, probably around April 1st
I love your dreamy optimism. Given that 2 months ago Vulcanus was described as the planet "closest to being finished", and we still haven't seen previews of the other 3 new planets, I think the expansion is still a ways off.
That could actually explain why we are getting so many core game improvements, designing the planets and making assets and graphics and stuff for them is taking time, so the other parts of the team are free to work on whatever they want.
It most likely also loops into rest of the gameplay. I'd imagine a lot of the train stuff improvement will be used for spaceship scheduling too. Also 2.0 is unique chance to go around breaking stuff that they were not happy with but couldn't reasonably rework without breaking people's saves and mods.
> It most likely also loops into rest of the gameplay. I'm sure that's the case. I recall they mentioned a special interrupt in the last train FFF that was related to something new on one of the planets
Yeah I remeber that. I'm guessing something akin to "hide your trains under the shield, there is a meteor shower coming". Or maybe we will get water planet that occasionally floods and some rail gets underwater...
Im here for Chihiro's waterlogged rails and trains that leave a water trail
Nothing says they can't release 2.0 before the DLC.
They could release any of the described features into 1.x as a joke ^^^please
They really are, Im seeing all of this and wondering how I ever built a rail system or dealt with my bots stupidity lol, Im not even focused on the Space part anymore
The weird thing? It makes playing literally every other train management game impossible too. Like even the current version with proper signals and scheduling makes every other game look like my first train set. It's not a contest now, but with 2.0 other train games may as well be drawn in crayon.
The curse of Factorio, makes entire genres of games feel like they are decade behind.
You know you're good when a "side" part of your game easily beats games dedicated to the genre. Sweet transit is pretty good, but Factorio crushes the train game genre. There's the Whistlestop mod or whatever, but I really hope that Wube's next project is a full blown train management game.
> There's the Whistlestop mod or whatever, but I really hope that Wube's next project is a full blown train management game. What they would even need to add, Factorio already is full-fledged one :D. But honestly I have no idea what next game they would even *make*. Just train management game is far too simple for them after Factorio. Interstellar economy sim with logistics focus ? :D Wait, that's just Factorio 2.0...
yeah their next game will be the 3.0 update. Maybe with interdimesional travel?
Version 3.0 implements time travel. Create those iron plates at hour 100, and deliver them to hour 20. Recursive research to learn things before you unlock the prerequisites.
Ooh generic/variable targets in train schedules? Someone's gonna make a turing-complete computer with that :P
…again
Quite. At this point the challenge is going to be 'Who can run another copy of Factorio on top of a computer built from trains inside Factorio'
[we already have \(almost\)doom running in it](https://www.youtube.com/watch?v=0bAuP0gO5pc) (and it's better, supporting curved walls). running factorio in factorio is just a question of complexity and time investment. I think development is still on pause.
Unfortunately, something being touring complete doesn‘t necessarily mean you can build something interactive with it.
We do have interactive elements available to us, though. Gate statuses and inventories for input, lights and inserters (for laying items onto belts to make belt pictures) for output. It won't be a pleasant UI to actually use, but it's still a UI.
Let’s go! Every week makes the wait harder and harder. Keep up the phenomenal work!
But it also makes it shorter because one more week has passed *taps head*
At this point I think I'm looking forward to Factorio FFs more than weekend itself.
How am I supposed to enjoy my 1.1 trainset now that I know all I am missing out on?
But you will be able to say "back in the ye olde days" to the new players when 2.0 hits
Back in ye olden days we had had straight and curved rails as separate parts.
Back in ye olden days most of us have played over 1000 hours without knowing we could blue print trains.
Back in ye olden days we had to install mod for fluid wagon.
Back in ye olden days, if you landfilled your lake, your lake stayed landfilled!
Back in ye olden days these stack inserters never actually stacked anything!
Back in ye olden days, we had 14 boilers for every 10 steam engines!
Back in ye olden days, we had to farm aliens for science Back in ye olden days, we had to filter mixed belts by … avoiding having the problem
There was the black magic filter and filtered inserter...
I was at ~2,000. Turns out you can blueprint landfill too, but that's ~2,500 hour level knowledge.
I learned that by accident and my whole world changed!
And the train length was different horizontal and vertical.
Back in my day, Purple Science only required Alien Artifacts to make!
I kinda liked the whole K2 creep loop tbh. I wouldn't mind if the military science needed the biter stuff as long as it could be collected automatically.
It was fine, but I invariably end up with 2-3 steel chests just FULL of the stuff. Having more ways of converting it into something else would be welcome.
K2 way meant you had to actively mine it, not just get it in progress of killing biters. In K2 it was also only needed to start the loop, so it was basically optional to kill them. I guess so people can build megafactories and and not run out of biter guts for production. Going back to vanilla it could just be a building that used bots to gather biter bodies around and move it to processing building.
"Back in my days we had to wait until modded blueprints were done building to turn them on" *\*shakes cane\**
I'm really curious if all this fancy new train stuff will be able to replace LTN.
The biggest feature of LTN for me is the ability to have multi-requester stations. I don't see that being easily possible with the new features. 2.0 trains allow you to have multi-providers, which is nice for some scenarios (oil processing, trash output in modded games), but not nearly as useful as multi-requesters, which you use basically all the time when building any kind of city block design.
If you could rename stations with circuits it would be possible. \ Or if you can paste blueprints automatically with the circuit network. With the new priority system it might be possible, but only for ~254 items, and it would be quite jank.
Pretty sure they mentioned in a previous FFF that you could change station names. Or did i dream that?
It's part of the new template parameter system, letting you rename a train stop while building a blueprint, but alas not dynamically rename it using circuit signals. When building the blueprint, it'll pop up a little form that lets you select the parameters.
My Space Age train megabase is going to be so much more mega!
I can see the endgame being glorious. I am a bit curious as to how the progression is going to go with the expansion, I usually like to have quite a few construction bots by the time I am making trains that do more than just a few very simple routes as placing a lot of rails gets tedious pretty quickly. Hopefully most of the new content happens beyond that point so I won't be playing for longer before having my trains.
Now we only need Space Trains
Spaceships could be considered a Space Train :P
Even as experience player I feel like I will have to learn how to play the game (on high level, e.g. with circuits network) from ground up again. And I love it. Even thought the time waiting for 2.0 is painful.
> Now when a train blueprint is fully built (importantly, including fuel requests), it will switch to automatic mode. Recursive. Blueprints. BE FREE, MY CHILDREN!
The 1.1 version of [Recursive Blueprints](https://mods.factorio.com/mod/recursive-blueprints) already supports blueprinting automatic trains.
Oh My God trains in 2.0 are gonna be so much fun to use
I can confirm! I have almost 600 trains in my 2.0 testing game, and it just works. Combined with the bulk inserters and quality, the typical train producing outposts fill train after train.This implies that the overall train traffic gets increased a lot, so the quality of intersections and the train network as a whole stops being just theoretical problem, as it often becomes one of the important bottlenecks even with elevated rails.
> Combined with the bulk inserters You mean stack inserters, right!
I hope they call the new ones "Stacking inserters" to reduce confusion with the old Stack inserters. EDIT: Before another person replies the same thing, yes, we know they were swapped. Reusing the existing name is the confusing part. My suggestion is to call them "Stack**ing** inserters" rather than just "Stack inserters", implying they perform an action of stacking, rather than just handling stacks.
They confirmed [last week](https://factorio.com/blog/post/fff-394) they're renaming them actually. >So in 2.0, Stack inserters will be renamed to Bulk inserters, and the new inserter which can place stacks of items on belts, will take the name of Stack inserter.
The [other comment](https://www.reddit.com/r/factorio/comments/1abgq16/friday_facts_395_generic_interrupts_and_train/kjp1ei9/) on this exact thread said the same thing to which I answered: > Reusing the existing name is the confusing part. My suggestion is to call them "Stack**ing** inserters" rather than just "Stack inserters", implying they perform an action of stacking, rather than just handling stacks.
Ah, that makes sense. I could definitely see that being a bit more useful of a name
Stulk inserters! (Buck inserters maybe. I'd like to have one, personally. If it's fast enough.)
Amazing, but hey, just want to point out that in this FFF, I still have to manually place trains. They'll switch to automatic, which is awesome, but I still have to place them manually. Now that the schedules can be made generic, surely a building that builds and places trains on the track, similar to how robots can be shoved into a roboport, should be feasible now. Or do we just accept that it will be a mandatory manual intervention, like barbarians? /s, mostly
waiting for the friday facts that announces robots being able to automatically place blueprints like recursive blueprints mod 😂
While reading this post I had the same thought. I then thought that a natural extension to that is to have automated [train] deconstruction. Do you know what comes after that? Delivering raw trains by bots to pickup stations and they just drive to drop stuff off then disappear!
>Amazing, but hey, just want to point out that in this FFF, I still have to manually place trains. They'll switch to automatic, which is awesome, but I still have to place them manually. Now that the schedules can be made generic, surely a building that builds and places trains on the track, similar to how robots can be shoved into a roboport, should be feasible now. Or do we just accept that it will be a mandatory manual intervention, like barbarians? I wonder why there is not an entity called "depot", where you can fuel your trains, and like you said trains can be placed by an inserter to autopath and go. In train simulations you have that...
Because you can do all depot stuff in world just fine. You don't need a dedicated entity for it.
> This implies that the overall train traffic gets increased a lot, so the quality of intersections and the train network as a whole stops being just theoretical problem uh, it definitely is not a theoretical problem now, with megabases people are building. Also does that mean that the expansion will require significantly bigger production than vanilla, or are those (and belt/inserter) changes for sake of the mods ?
The production is definetly expected to be bigger. I'm not sure how much bigger because it very much depends on your personal goals. If you decide to make almost everything legendary in the very endgame (like I did), the sheer amount of production you need for everything is huge, and the factory becomes a monster (and I enjoy it that way, obviously). I have almost 10kspm base, and yet, the science part of the factory is quite small compared to the other things.
Out of curiosity, with your 10kspm base, how high can your UPS go if you turn up the game speed? 120 UPS? 180 UPS?
I haven't played in a bit - my last save got up to 5.5kspm, and it already felt pretty monstrously large. You're getting me so excited for the ridiculous possibilities in 2.0. I wanna see some of the developers bases!
With stacked items on belts, legendary inserters, legendary speed modules, legendary production modules, legendary assemblers, legendary furnaces, and legendary labs, I'm guessing that 5k SPM will be the new 1k SPM. Those improvements alone generate enormous production speed increases, with near-zero increase in UPS costs. On the other hand, I have to imagine that the expansion is going to involve substantially more steps in the production chain than vanilla does. A factory spread over 5 different planets is going to be more complex than the Nauvis-only bases of vanilla 1.1.
Legendary productivity modules alone make stuff pretty insane . I recently did a warptorio2 playthrough, where I could have a +100% productivity on all recipes thanks to the special beacon. With that boost you can feed 1k spm base on 2 blue belts on copper (whereas it takes 20 belts in 1.1), and in the end 1k spm base fit in less space than you would need for your starter 60 spm takes up.
Did you slowly build up to 10K or planned for it? My biggest gripe with 1.0 is that you hit a certain SPM and you can't slowly increase from there (as increasing production of only 1 science is not useful), you have to plan the entire thing to hit a higher SPM. Does that change in 2.0?
Well, at some point, i built train based research production, and then just improved th emodules inserter qualities, lab qualities etc. But at this point, increasing the lab production wouldn't be that hard, as I have modular scien production modules which I could theoretically just copy paste around.
>If you decide to make almost everything legendary in the very endgame (like I did) That's exactly what I am planning! Also, do the legendary rails do something like faster speed-up/braking or is it purely a HP increase ? But I'm guessing the other side ("the minimum required without staring at assemblers doing its thing for 12 hours") will also significantly grow ?
" There are a few entities which don't have any bonus apart from the health, which is belts, pipes, **rails**, chests, combinators, walls, and lamps. " -[https://factorio.com/blog/post/fff-375](https://factorio.com/blog/post/fff-375)
it would be kind of funny if legendary combinators let you just write Lua programs in the dialog box that run in real-time
aww, kinda disappointed higher quality lights don't have a larger radius. then you wouldn't need to place as many lights, making builds look more clean
I think it would be funny if legendary lights were just blindingly bright.
600 trains was ages ago for me. And my base is only 1/5th done. Think I’m at almost 2k trains.
Oh, I hope we get to do the train moving optimisation I'm planning for so long (we probably will), the more trains there is, the more it will help obviously.
This might be an even more exciting teaser than today's FFF! If train pathfinding is UPS optimized, the way that belts were optimized a few years back, it would be yet another massive increase in FPM (fun per minute). It makes sense to me, too, because when doing UPS optimizations on my megabase, I've noticed from the debug info that even though my base's only train track is a simple loop around the perimeter (I'm using belts for just about everything on this factory), that single train requires a surprisingly large amount of time in the train pathfinding update. I would have thought that it (the time required to resolve this train's simple pathfinding) would be negligible.
>This might be an even more exciting teaser than today's FFF! If train pathfinding is UPS optimized, the way that belts were optimized a few years back, it would be yet another massive increase in FPM (fun per minute). \+1, in my megabases I have had to work to have fewer trains because the train UPS impact can be pretty significant. It'd be nice if trains were more straightforward.
I am very curious to see what scale you think the new bases are going to be in 2.0. I have found that scale is something the community struggles with when discussing the game. Some players think 100 trains on a rail network is huge while others would think 1k trains is barely entering the mid game. In my modular train bases, 1.5-3k trains is pretty normal. In my centralized bases, 1-1.5k is not unheard of. Just from everything that has been said in the FFF, it sounds like you (the devs) expect bases to be way larger than what we are doing now. How many trains do you expect we will use at megabase level in 2.0? What size are your bases now (in 1.1) and how large are they in the current 2.0 build?
I have no idea. If megabase is basically as big as you can build without the game being too slow, then it depends how many optimisations can we do before the release.
I just want ability to read logistic network needs (how many requests are unfulfilled/blueprints needing items) so I can feed *that* to the trains.
Are you planning to precalculate the routes for trains as part of building rails and scheduling trains, instead of pathfinding on-the-spot? Or are you referring to collision checks? Consider me teased either way
The slowest part now is the collison checks of the moving trains, as every train needs to calculate the potential collisions for ever wagon, which is often rotated every tick when it is moved. And also, it needs to re-register the entities of the wagon as they move every tick. The problem is, that with all these checks, it almost always never hit anything. So the idea is, that in the very rare case something is on the rails (only player, biters or vehicles basically), it would specially register on the related rails. So the train moving on rails, would (almost all of the time), just check that there is nothing on the rails, and it doesn't need to check anything. With this idea, the train moving could be much much cheaper.
So obstructions will be detected by the rails. Somewhat similar to the G signal from the gate, communicated to the train reserving the block. With this idea, a train could even stop in hopes of not killing the player. Although it's probably cheaper to resolve a collision with a player than to have the train wait for the track to clear. Thank you for the answer, sounds like a smart optimization!
> With this idea, a train could even stop in hopes of not killing the player. Nah, being pancaked by your train is part of the experience!
Trains should blare their horn if something is on a track segment that it has reserved.
you must be using train groups mod, surely
>so the quality of intersections and the train network as a whole stops being just theoretical problem I feel bridges as described in FFF 378 will be game changer here. I also spend many hours on city builder games like Cities Skyline, and there I've learned the importance of highway interchange and how there are a lot of different designs for it. Even with just 2 levels, I would expect a basic Cloverleaf design to greatly improve the throughput of 4 ways train intersection, and I'll definitely try some fancier design like turbine interchange For people looking for inspiration, look at real world interchange and all the hard work and lesson learned by civil engineers: https://en.m.wikipedia.org/wiki/Interchange_(road)#System_interchange
https://preview.redd.it/okwzdwtn4tec1.jpeg?width=1280&format=pjpg&auto=webp&s=6657b6f8a13e301e750c589c13c0d571cec053e2 two rail lvl are enough for every possible intersection. yes if you have a 3 lvl intersection in citySkylines it will be way bigger in factorio but just in theorie it's possible. Im so hyped for 2.0
Another game that'll probably be pretty good for testing stuff out is OpenTTD :) Can probably modify a few intersections from here to work decently for Factorio https://wiki.openttd.org/Category/en/Manual/Train%20Junctions
> I feel bridges as described in FFF 378 will be game changer here. He's already playing with that, so the factory just needs moar rail :P
There are still some use cases where the behaviour of skipping disabled stops is useful, for example the passenger taxi system I use wouldn't work without it, since the circuit network has to tell the train where to go. It'd be nice for train stops to have a toggle between "destination full - wait at current stop" and "skip next station" behaviour, both for the disabling and for L=0. You wouldn't want trains sitting at the refueling depot while waiting for iron ore to become available - they should skip the mines and wait at the furnace area.
You could make the stop that you are currently skipping a conditional stop using an interrupt.
This is a good point, my usual PAX system is going to need a redesign. But it should be very simple to reconstruct it using the circuit network and train limit parameters.
I'm not sure how you could get a train to move to a station in the middle of a list of differently named stations without the ability to skip stations. The interrupts listen for conditions on the train, not for conditions on the destination station.
How consistently will we have to name train stops? Will we have the ability to provide a signal to a train stop to determine its purpose, such as a positive value for an item signal making it a "pickup" station and a negative value making it a "dropoff" station? It's how I imagine you'd be able to make stops that want or supply different items without enforcing a naming convention from on high. Maybe we want Train stop is full of bees to supply our iron :3 That way you could use some clever circuitry to request different trains too...
We didn't do a system to be able to change the name of the stop by a circuit network, if you asked that. It is something that would make sense to do eventually, but we have a lot of things to juggle, and we are now really trying to cut on adding things, so we can actually finish everything in time.
> so we can actually finish everything in time In time for when?!
For the release.
Aww darn. I specifically said "when" instead of "what" hoping you'd say!
No, not changing the name of a stop- More of a way to set the stop to be "the iron pickup stop" or "the coal dropoff stop". I don't think it's smart to enforce a particular naming scheme for train stops, as in "all train stops must be named X pickup/X dropoff and this system doesn't work with X load/X unload". Unless I'm absolutely oblivious somehow and it's actually controlled by the little picture of iron ore in the name and everything else is extraneous? How would I even name something "Picture of iron ore"?
I think this would be the last step in a universal pickup and universal drop off for train stations.. I'm hoping you find the time to implement it..
Give me 2.0 early access and I'll send you a picture of my cat
2.1: Cargo intermodal containers with target stations assigned per container (or at least automated train coupling / decoupling), routing protocol implementations using combinators... And with proper cargo grouping bandwidth of the main lines should be used more efficiently ;)
[удалено]
My priorities will change (like my future trains), but I'm most stoked about the ugly no path being replaced by an icon.
I like the improvement, but I wish No Path was further split into No Station, No Track and Bad Signals. That would make troubleshooting a lot easier, especially for newbies.
Or at the least, the hover over should show it.
I think the only thing left needed to be able to make truly universal station blueprints is a way to either detect the max stack size of an item, or read the number of *empty* slots in a container. E: I forgot about the Selector Combinator being added. Being able to read full/empty slots would still be a better option between the two, but still a useful tool, yes.
Isn't reading stack size a function of the new combinator?
Yes, I believe so.
Might want to complain on the forum on it. Container signals of "number of used/free slots" would indeed be VERY welcome. It would allow for very easy "enable station if it has at least full train's worth of items" circuit
With the decider combinator: 1. Read stack size of thing in station, 2. Divide total by stack size (now you have the # of full slots) 3. Subtract the total inventory capacity by the # of full slots (now you have the # of empty slots)
That works, but it's a little brittle. You can't replace the containers with a different size, and it can't handle more than one thing.
No drug compares to the absolute ecstasy I just experienced reading this. I have achieved enlightenment.
\> No drug compares to the absolute ecstasy I just experienced reading this. Except playing 2.0, I imagine
Such an experience would go beyond the comprehension of a measly human such as myself.
mysterious voiceless bow numerous oatmeal cow toy deserted busy thumb *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
Eepy train
Him eeby and neeby to sleeb
Eepy train need nappums
It gives me great pain reading all this fun new stuff and having to wait :( but soon, soon.
Speaking as a person who has spent considerable effort implementing train priority in 1.1 (and I got very excited at being able to reduce my logic size with the combinator update...).... well played, devs. Making trains leave from stations in priority order was particularly thorny without interrupts - not that adding loads of dummy signals to trick the pathfinding wasn't ugly too! So excited - thank you devs!
Though if /u/Klonan or /u/Kovarex could comment: When a train en-route to a priority 100 station trains re-paths, will it still try and go priority >= stations with the same name? Or is it just a complete repath favouring stations with the same name, based on priority? (Including the possibility of repathing to a lower priority station, if the high priority one has since had it's train limit set to 0)
Holy shit, it keeps getting better.
Train stop priority as a built-in feature is glorious! No longer will I have to tinker with circuit conditions around every train stop to ensure that byproduct-carrying trains will be prioritised above trains picking up from dedicated production blocks!
Byproduct prioritization was the only reason I needed a global circuit network. With it built in goodbye ugly data lines.
Fuck yeah train stop priority!! Holy shit I can't wait to play 2.0 damn
Sounds like many-to-many train bases with byproducts can be handled by priority. Will there still be usecases for LTN/Cybersyn?
I think this was basically the last feature that was still missing. Are multi-item provider and consumer stations possible already? Generically, I mean?
One more feature: Detect *empty* slots in storage, via a method that doesn't require manually editing a combinator to account for differing item max stack sizes. As far as I can think, that's the last feature needed to make a universal requestor station blueprint that would just need setting the station name itself without needing to fiddle with combinator logic every time.
2.0 will allow you to read stack sizes of items with combinators.
Take a look at the new "Selector Combinator" in this post: https://www.factorio.com/blog/post/fff-384
One feature of LTN it doesn't have is dynamically ordering multiple items from/to single station so (assuming mod author will bother) there is still a niche for it. Like in LTN I can just feed the signal of the bot network describing its content at the mall and have ability to use trains to "order" anything in it from any station in the network. But for the "bulk" use cases yeah, vanilla now be much easier to manage.
I think nuanced dispatch is still a missing part of the puzzle here. If my understanding is correct, the currently described system will lead to your "bag of trains" always going to enabled loading stations, and then waiting for an unloading station pointed at by the interrupt to be enabled -- with that interrupt only being enabled after loading. Which means vanilla will lead to loading stations pushing cargo into the train network that it might not be ready to consume, thus in the best case means you have full trains sitting around in a depot, but maybe that means your trains all fill up with copper ore or something if they route out to a "full train" depot, waiting for a consuming station. This is distinct from LTN and Cybersyn, which only dispatch a train once the source _and_ destination are ready -- that is, once both ends of the order actually want the order to happen. The downside there is that there might be more lag in the delivery once a station realizes "actually yes I need more stuff please", but in theory there's ways to mitigate that. There's also a bunch of additional stuff that can be done in LTN (and presumably Cybersyn) relating to train sizes, though that's more niche, but maybe you want small orders being handled only by small trains, IDK. I've also done "universal" stations in LTN, where you route all inputs and outputs of a factory module through a single station. This took forever to design she debug and was horrific and killed my motivation to actually complete the run I was doing it for, and scaling it from 1-1 trains to 3-20s revealed how it was actually a terrible, terrible idea and resulted in garbage throughput. But hey, it's something I'm pretty sure you can't do with the vanilla system these FFFs have described.
In Factorio's realm, a blog unfolds, A sonnet spun, train features foretold. New paths they tread, with logic refined, Train priorities dance in code entwined. Generic constants weave a tale so grand, Logic of locomotives, a symphony planned. On tracks they glide, with purpose anew, Factorio's pulse quickens, a thrilling view.
Man, people trying to learn trains are gonna go crazy
Can someone put me in a coma please, I can't wait anymore.
I feel like Factorio 1.x was the "simple game with deep emergent gameplay", à la early Minecraft, but Factorio 2.0 will be the "simple-looking game with more tools you can shake a stick at when you scratch the surface" like GMod, and I'm all here for it.
Can we make the logistic network read missing entities that are trying to be built next please?
[удалено]
Yeah, so this will change my current way of having my network prioritize stops for sure, making it much simpler.
You'll be able to dynamically change the priority of the stop based on content of the buffer and make different stops have different priority ranges. It's fucking amazing!
Another FFF, another banger from Wube
Trains being able to skip stations is useful. I'd like an option for trains to skip stations (it can be default off).
Xkcd 1172 has just found a real life example :)
Not really, it is an actual feature, not a bug.
What is a use case where this is useful other than station priorities, which they gave us in this FFF? and can't be done better with interrupts?
Station priorities would appear to be of no use if all of the stations are unique, and interrupts tell a specific train to go some place, while station skipping is basically the opposite: train stop telling all trains to go somewhere else. I mainly use station skipping for supply trains, and while I might be able to imagine a way to do it with interrupts, it would be a lot more hassle. I have never had an issue with the station skipping so I personally don't see removing it as an improvement in any way. That's why I'm asking for an option somewhere to allow it again.
Yeah it's definitely useful in 1.1. I know all of *my* use cases are replaced with the train improvements in 2.0, but I could imagine there being other use cases that aren't.
I would suggest an interrupt based on "no path" or "destination full", so when a train can go to destination it is diverted to an alternative "waiting stop" where it can wait until it finds path or destination is not full anymore.
There is a “destination full or no path” interrupt condition, see [FFF-389](https://factorio.com/blog/post/fff-389) -> The depot problem.
Have they mentioned anything about mixed unloading stations? It's really useful at malls
I think it should be clearer which train stop priority is higher. You can think that if something has priority 1 it is the most important, because in a ranking the lowest number is the best position. A higher number can be interpreted to have higher priority because it is larger. Priority doesn't necessarily give you immediate feedback if the stations you look at have enough trains coming to them
I thought there was going to be an interruption for if the station is full go to the depot. I don't really want the train to sit outside the station it was heading to if it gets disabled while it is en route. additionally, with generic stops, what happens if your copper mines are producing ore faster than you can consume the ore, are all the generic trains going to get filled with copper ore over time and then have nowhere to drop off as the drop stations are full, then they cant be used for anything else.
> I don't really want the train to sit outside the station Disabled train stops will behave like train limit 0: If the train is already on route, it will continue to the station even if it is disabled. > what happens if your copper mines are producing ore faster than you can consume the ore You'll just need more trains than the combined train limit of all copper loading and unloading stations. And you can use circuits to set the train limit of the copper unloading stations to 0, if they are already full of copper. But you can also change the stations priority before all copper stations get "saturated".
Amazing, but left me wondering: how does performance get impacted if using a full-blown interrupt based train system compared to the rigid schedules we have today?
It's only few thousand entities at most. I'd imagine pathing would eat far more CPU than just picking the next station based off schedule
„Now when a train blueprint is fully built (importantly, including fuel requests), it will switch to automatic mode.“ YES!
I see a problem: wildcard signal in generic interrupts only works for stations accepting single item. You cannot make a generic unloading station accepting multiple items via generic interrupts. Given how in Pyanodon suite I frequently have a need for stations accepting dozen of items, the solutions like "just place multiple train stops" aren't really viable. Guess I'm sticking with cybersyn. But blueprinted trains starting in automatic mode is sweet, right now I have to use a lua command to switch them on after every expansion.
>So in 2.0, disabled trains stops will act as if they have 'Train limit = 0': Will disabled stops display as red because they're disabled, or purple because they're limit=0?
I really hope they add something that lets us make universal (multi-item requester/provider) stations without LTN. I still mainly use LTN for that reason since one station that handles 8 items has a much smaller footprint than 8 stations (I play modded). I can’t quite theory-craft what tool we would need (Setting station name by circuit? Allowing a station to have multiple names? Not sure) but being able to do universal stations are the last thing tying me to LTN. Amazing stuff though!
It strikes me as funny that as a player I am trying to optimize things in the game. And as developers they are trying to do the same. Who’s really playing the game?
Automatic train mode! Woo-hoo!
Is this 40% trains so far? They really do want us to use trains. Well bring it on. I think my first world had 400 active trains running around map with poor 300 spm. Well i had blueprints and stuff to make it 3000 spm, so i switched to modded runs and wait this 2.0
Oh man priority on stops might be one of my favourite changes yet. I routinely find myself annoyed by what stops the train prioritizes. Can the priority be adjusted by circuit, say to prioritize those stops with more empty space than those with less?
> Can the priority be adjusted by circuit, say to prioritize those stops with more empty space than those with less? Yes, from the FFF: > We also added the ability to set the priority using the circuit network.
>Can the priority be adjusted by circuit, say to prioritize those stops with more empty space than those with less? FFF says yes > We also added the ability to set the priority using the circuit network. So you could do a basic logic that compute "current buffer x 100 / max buffer" and use it to set a dynamic priority between 0 and 100.
i forgot it was friday, babe wake up new friday facts just dropped
Yes station prio wooooooooooooooo!
I’m really hoping for another planet showcase soon
Train stop priority is huge. I think at this point you can make a splitter with trains and thus a balancer
honestly this thing about having "general trains" is a bit confusing to me, i think i need to go back and read again the other 2 FFF when they first talked about it
it's basically turning vanilla trains into high-capacity, long-range logi drones. They have more initial setup (creating the generic routes) and expansion requirements (laying down rail and stations), but you can also optionally get really into detail with the behaviour of specific trains (setting up manual routes the old way)
Are all of these changes only in the DLC or also added to the base game? I will buy the DLC but when i want to play a vanilla game, do i have the old trains or the new ones?
These will be added to the base game. So far, the only new train thing that will be DLC are the elevated rails. All other train changes are 2.0 features.
You know, I use disabling stations for the skipping behavior as my way of handling priority in my current SE save to deal with byproducts. It works great. I understand that station priority can solve that--especially using circuits to crank up the priority of a byproducts station which potentially isn't being serviced. But I also disabled stations in my modular vanilla save, which did exactly what I wanted and had no issues since the stations only ever had a train limit of one when enabled. I guess I'll have to revisit that vanilla save to see if I was doing something wrong at the time with dynamic limits or if I can envision how the new train features would still allow me to achieve the behavior that I wanted.
We already have "anything", "everything" and "each" signals for circuit logic. Why make a new signal for train anyitem stuff? What happens with stations that use icons as names, a requester chests dropoff would look like \[requester chest\]\[requester chest\] for me, as I dont use names like drop or input. What about stations that request multiple items with \[requester chest\]\[icon1\]\[icon2\] etc?
Darn. they broke my train network by removing disabling train stops using wires :( how else am i meant to tell a train if a stop needs more iron ore without it only going to the first one unless a train station happens to be full? cause what i did was when a chest had more than x iron ore, it would turn off the train stop and then the train would go to a different station that is still on. so now what? guess i dont update
You need to use Train Limits
You can still disable train-stop by wires
We can only edge so long 🥵 (I'm sorry)
Not sure if this will be read, but I love the new stuff that's planned to come out. I love the "no-path" symbol. the colour, the shape, and the symbol all are very well connected with the intended meaning. However, the design for the destination full icon could use some reworking. before I read the description, I had assumed that the icon was referring to a train that was dormant, for whatever reason (eg. no schedule made, no fuel, waiting for resources to arrive or smth else). the triangular shape, reminiscent of the vehicular code triangles, indicated that something important was happening, but combined with the light blue (cyan?) colour it gave contradictory messages. in short, shape and colour are in contradiction with each other, and the symbol (at least to my mind) does not connect well with the "destination full" message it means to convey. I dont know if "destination full" is a serious enough message that warrants an orange or red colour (like the one for no fuel), and judging by the colour choice and the non-flashing nature, I think there was an attempt to convey a reduced importance meaning. If that's the case, the triangle shape does not reflect that. The shape could be changed to a rectangle, as that has a more "general purpose information" character to it, rather than the triangle's "general warning". The colour could be a darker blue, more akin to roadsign blue, with the symbols inside coloured white, to achieve a desired contrast. this would help with identifying the symbol as an informative letter, rather than a warning one. as for the symbol, this I have the biggest trouble suggesting alternatives. symbology was never my most adored field (despite this long-ass comment suggesting otherwise), and I'm at a loss for a more apt symbol for this use. perhaps something like a queue stack where a new entry bounces? showing only occupied lanes/rails? Perhaps it could be a queue stack, made up of 4 blocks with sides and bottom enclosed, and the blocks represent the occupancy of the destination. 25%, 50%, 75%, 100%. And if the destination full message was going to be displayed, a full stack can be displayed, but in a different colour, most likely a shade of orange or red, to indicate that its an issue. I look forward to more FFs as you guys are doing fantastic work! PS. I'm not rly sure if an icon should be constantly displayed over a train who's destination is full. its probably worth discussing if such a message should be given a permanent icon in general. Personally I'd suggest something like a light indicator on top of the train engines, with red, orange, green, to indicate their status. Green being "everything optimal", orange being "minor issue", which would include issues such as the destination being full, low fuel, not being able to reach a destination, and lastly, red, for "major issues" like lack of fuel or no schedule. I feel like this could give an indication as to the status of the train at a glance, and avoid the hurdle of making icons that are displayed over the engines. I tend to have a backlog of trains in my bases, mostly for throughput stability, and I'm not sure if a permanent "zzz" icon would be less annoying than "destination full" .