There should be no reason why a train would be stranded in the wild (at least no new reason, outside currently existing reasons). They only depart as needed. You can set a higher amount of allowed trains if you want to create a buffer area for them.
As to your idea of "only X of those 100 trains are allowed to go to that station", well, I don't exactly know what you mean. If the station has a certain name, and the train has that station name in it's schedule, it should be a viable destination. If it's not, your schedule is wrong and should be changed. If you want to do some crazy magic, you can of course still recreate everything with dozens or hundreds of combinators, arcane mathemagics and blocking of rail signals and disabling of stations.
I was thinking about a situation like this : 3 station called "Iron unload" are opened, each of them accepting 2 trains, so 6 trains are moving; full of iron 2 of them towards each station.
Now 1 train is unloaded and makes 1 station closes because it is full, thus leaving 2 stations opened accepting 2 trains each. Out of the 6 initial trains, 4 are fine going to the station they were going, 1 one them is going back to reload, but there is this 1 last train, that was supposed to reach the station that is now closed.
This last train would be stuck in a weird spot, trying to reach station with the correct name on schedule would be made impossible due to the new rule of "X max number of train allowed" on the 2 remaining "iron unload". but there would be 2 station with correct name opened and the trains would have receive authorisation for transport at one time. I think this is one "new" case of train stranded in the wild.
This can already happens if a station is closed when a train is going to it, the train will freeze on spot when station close[If no other station are opened/in reach on schedule], this behavior could be made more frequent as a consequence of player's mistake with new rules. Or i missed a thing ?
I thought it could force player not using the feature to think about it to prevent interferences with other method of routing trains but the 3 states described seems to solve that part.
From earlier play with LTN,it seems sort of advanced feature, it requires a depot, and some sort of knowledge on "how the finished thing look like when working", it allow behavior that none of my attempt at mathemagics was successful enough to reproduce. To my mind it feels similar to "taxi logic" vs "bus lane logic". The taxi-logic would be when trains don't have "lane" assigned, they can go anywhere from their depot depending on demand, such depot i feel would be required when you describe sliding a gui and trains join/leave a lane. ( i assumed from a depot). Such depot could handle the trains that have no more destination due to the new rule proposed. ( the place where the 80 trains are parked in the previous post).
I wouldn't mind seeing that in the vanilla game, but i feel it represent too complex of a mechanism for it to happen.
If a station close while a train is moving toward it the train just repath toward the next station in schedule
I'd like to add my own data point to the NPE/Campaign conversation. I've been a programmer for decades now and I enjoy the process of finding the way through a tricky problem and having something nice to show for it at the end. When I first saw factorio it immediately called to me as the production-chain simulation looked very compelling.
I found factorio, if I recall correctly, through a YouTube video (probably Katherine of Sky) and bought the game back near the beginning of its Steam early-access (0.12.29 according to my save files). I started a new game but was immediately daunted by the sheer number of options for crafting right at the beginning and the complexity of trying to figure out how I could get from manually mining to launching a rocket while also trying not to get killed by the aggressive wildlife. I enjoy complexity, but being thrown into such a complex system without any direction made the game feel like work rather than fun.
I put the game down for a bit and it may very well have stayed unplayed in my games list, like many others, but the videos I saw still intrigued me. I started the game back up and went into the campaign. The more limited options for crafting and the shorter-term goals felt more possible. Within the first few maps I was hooked.
As I have more than 2500 hours in the game I definitely appreciate any side content that may be added to the game. However, I just want to remind you that at one point we were all new to this game and that the new player experience is how we are introduced to the game. The campaign back in 0.12.29 helped me to find my entrance into this game. I hope that there will still be something there to help guide new players into this wonderful game when we finally hit 1.0.
It seems a mistake to get rid of the campaign going in to releasing 1.0, which presumably is when you want to target new users.
I've played 400 hours now, and I doubt I would have without the campaign in one form or another. Factorio may be straight forward to those of us on the who have played many dozens of hours, but it would be extremely daunting without some form of hand holding to get your started.
To ship it without any sort of tutorial/campaign seems like madness to me.
To ship it without any sort of tutorial/campaign seems like madness to me.
The most recent FFFs have very clearly stated that during the 0.18 release cyle, they will switch back to the introduction tutorial from 0.16 (and before). And that the mini-tutorials will get some love, too. So there will be some handholding for the new players.
Just as feedback : I watched official trailer, bought game, launched sandbox and never played any kind of campaign. Everything was clear from the start.
Mini tutorials for trains were very useful.
If a station close while a train is moving toward it the train just repath toward the next station in schedule
This is the rule, which seems problematic in some cases.
This create situation where train would skip a seemingly opened station, because another one with the same name somewhere else closed, leaving the remaining opened station saturated with train, ( the "max_number_incoming_train" ). ( going from unload => skipping load => unload again ).
Also if you reduce the amount of train a station is allowed to handle on both end of a schedule. A=>B=>A. You had 3 trains allowed to A and 3 to B ( 3 trains total going back and forth) , you reduce the number to 1 and 1. ( 1 train is now "too many" ).
What is the train doing ? It can't be piling up behind any of the station A nor B, since that would not respect the condition, of "max_number_incoming_train", it would hang there not being able to just repath toward the next station in schedule.
This why i assumed some sort of depot where trains goes to park waiting for a call similar to taxi depot ( or LTN depot) , whereas busses would never need this since they would be running non stop and parking only at pick-up or drop-off location.
I've created a thread about the max train discussion in general discussions. I'd appreciate if we took the conversation there and would be eager to hear from boskid as well. Cheers
Came here to see what the drama was behind a teammember leaving. Because, having read posts like this before, it sounded like there was drama. A lot.
Glad there wasn't.
But be aware that mentioning two facts in close proximity implies to the experienced reader of press releases and corporate speech that they between the lines are somehow related. And what's worse: Not giving any more details on the bigger bombshell leads to speculation as the readers try to fill in the blanks of what hasn't been said with "because, it could not be said politely".
I am sad the campaign is canceled. If there is one thing missing in factorio its just a real goal. After you started the rocket once, there is no point expanding further. I can see all the youtube videos about people making crazy stuff and I am happy for them to play the game that way. But I need something striving for, and I always imagined this could be a campaign for me. Just a reason to play.
I also get the impression that you are under some pressure right now, to get everything right. I cant see why you are doing it. You already created a masterpiece, I think you also sold some copies of the game...it seems to me you had a nice team together. The world wont break apart if you release the game with a bad campaign, or a bad character gui...just keep having fun till the end.
I am not at all pleased that fluid improvements have been pushed back again.
Factorio doesn't have very many 'bad' aspects to it, but the fluid system is absolutely one of them.
Dominik said in FFF #274: "This time it is pretty much finished so I can tell you facts instead of just speculations. You will find how the new algorithm will work and some new handy usability features."
Here we are over a year later and still no implementation, while being told it's not even on the table for 1.0. Not cool.
I am not at all pleased that fluid improvements have been pushed back again.
Factorio doesn't have very many 'bad' aspects to it, but the fluid system is absolutely one of them.
Dominik said in FFF #274: "This time it is pretty much finished so I can tell you facts instead of just speculations. You will find how the new algorithm will work and some new handy usability features."
Here we are over a year later and still no implementation, while being told it's not even on the table for 1.0. Not cool.
So we are back to fluids like the power network ingame?
Dominik said in FFF #274: "This time it is pretty much finished so I can tell you facts instead of just speculations. You will find how the new algorithm will work and some new handy usability features."
Here we are over a year later and still no implementation, while being told it's not even on the table for 1.0. Not cool.
Writing here what I also wrote on reddit (minor rephrasing).
This is the most simple demonstration of what I think is wrong with current fluid system. I'm not educated in the field of fluid physics, but I really think that a perfectly symmetric system should behave - well - symmetrically. Or at least "almost symmetrically".
The whole system was build completely when everything was empty, then I added the infinity pipe. Yet after a while the right bottom tank has 4x more water than the left bottom one... And why is that? Only because I've physically built the "right pipes" of the split earlier than the "left pipes"...
With such behavior, a perfectly working setup that you build once (say a big setup of beaconed refineries and chem-plants) may not work again when copy-pasted, even though it is a perfect copy! It would be just because your construction bots decided to put pipes in some other order than you did yourself previously... I could "overproduce" to compensate for it, but you don't need to workaround anything with overproduction when using - for example - belts and splitters. Why should I produce 20000 petroleum gas per minute, when my calculations say that 10000 is enough? This is not a theoretical concern - when designing my modest refining setup (6 refineries with 12 beacons each) I really faced this problem. I build it one way - it works fine. Then I change something - it doesn't work anymore. So I go back to the working setup from a while ago and now it's not working anymore. The only thing you can say then is just "wtf"...
Also a clear indicator of flow through a pipe would be more than welcome, as now debugging the whole thing is just blind guessing.
I know that GUIs and stuff like that are more visible to the users, so fixing, improving, changing, fixing, improving-again, polishing, re-polishing, ... this over and over again may be more appealing, but... You can get used to the GUIs in the game. They may not be perfect from the point of view of today's UX/UI knowledge, but for me they are more than adequate (maybe with the minor exception of the LMB/RMB madness in the blueprint GUI). Maybe train pathing has some minor issues in some strange corner cases, when the train chooses a sub-optimal path even when a better alternative exists. Maybe the train pathing could still work 5% faster and use less CPU/RAM. Maybe this, maybe that. However the fuild system is not just "lacking" or "could work a bit faster" or something like that. It's just broken. To repeat myself - you can change GUI or visuals well after 1.0 is released and it will be perfectly fine, as it's hard to imagine this as a breaking-change (or at least breaking something severely). You can improve game performance after 1.0 and everyone will be more than happy. You can continue fixing non-critical bugs (like train pathing) after the final stable version is released. On the other hand I'm more than certain that once you release 1.0 you will never consider fixing the fluid system, because such change has a potential for quietly modifying behavior of currently existing and working bases (especially if this would be a complete rework with different mechanics, such as described in FFF 274).
I'm afraid that everyone in your dev team considers "fluid system" as something like a "hot potato". You all know that it could be improved, but just no one want's to admit it and face the challenge... So you just say "it works, so don't touch it" and ignore it, explaining lack of love in this aspect with a zillion of required GUI/GFX/sound/performance/... changes that have to be done... I know Dominik - who was working on it - is now gone, but supposedly you had the prototype working and it cannot be that Dominik is the only guy in your office who could deal with fluids. or that he took this code away with him, other people can surely deal with that when given enough time (a week or two to get up-to-speed with current implementation, current problems and the workings of the prototype).
Please reconsider... Even if you won't be able to implement some other things, which are less "core" than the "fluid system"...
Writing here what I also wrote on reddit (minor rephrasing).
Deja vu... Last spring I posted something similar. Why polishing so minor things for years, while here is major issue in core mechanics?
Simmetry and reproducibility. Copy-pasted network must work identically. Multiple pumps connected to one source must split fluid evenly.
Such things are much more important even than throughput.
I know surrounding every pipe junction with pipes, placing buffer tanks everywhere, and controlling all of it with circuit network usually will work, but it's ridiculous. Circuit network is an optimization tool for enthusiasts. Such basic thing as pipe network must be simple and self-sufficient just like conveyors.
EDIT. IMHO, since there is no more fluid mixing, we can refuse per-tile fluid simulation, and work with "pipe blocks", separated with pumps.
Too bad you didn't also "fix" that trains waiting at signals can accumulate infinite penalties.
A simple cap on the waiting penalty would make trains path into stackers a lot more reliable.
I have noticed this behaviour too. Trains waiting at the entrance to a stacker but not pathing to an open lane and constantly trying to path to a lane with a train already in it. In my ignorance I thought it just seemed to take a long time to repath due to low ups, never had the patience to just sit and watch!
It's sad to read that the campaign has been cancelled. I feel like it would have been a promising chance to make factorio appealing to the more casual audience that will probably take a look at the 1.0 release.
I'm fairly new to factorio, got it near the end of 2019 after I stumbled upon the sandstorm and 3D-engine videos, I like it and I clocked quite some hours already. However, I don't really see how it is supposed to attract players without cs, engineering, etc. backgrounds if the sandbox mode remains the only "major" one.
Writing here what I also wrote on reddit (minor rephrasing).
This is the most simple demonstration of what I think is wrong with current fluid system. I'm not educated in the field of fluid physics, but I really think that a perfectly symmetric system should behave - well - symmetrically. Or at least "almost symmetrically".
The whole system was build completely when everything was empty, then I added the infinity pipe. Yet after a while the right bottom tank has 4x more water than the left bottom one... And why is that? Only because I've physically built the "right pipes" of the split earlier than the "left pipes"...
[...]
I'm unable to reproduce this - at least the way you describe it. Building the "left pipes" first still results in the the same scenario of "right tank" being filled first.
However, I can now confirm that there was an issue with the order in which pipes were built... in 0.16 !
(The top fluid, which was built left-to-right doesn't end by catching up... up until the tanks are filled of course.
But I would have expected the bottom line - built right-to-left to have this issue instead ?!?)
(Save too big )
But I guess it was fixed in 0.17.0 ? (Or maybe in 0.17.34.)
So, a part of the "New Fluid System 2" might have already been implemented by 0.17 ? Or was this just a consequence of the new multi-threading ? It would seem that only empty pipes have been fully multithreaded by 0.17.0 ?)
Anyway, are you certain that what you are describing below is still happening in the latest 0.17 or 0.18 ?
With such behavior, a perfectly working setup that you build once (say a big setup of beaconed refineries and chem-plants) may not work again when copy-pasted, even though it is a perfect copy! It would be just because your construction bots decided to put pipes in some other order than you did yourself previously... I could "overproduce" to compensate for it, but you don't need to workaround anything with overproduction when using - for example - belts and splitters. Why should I produce 20000 petroleum gas per minute, when my calculations say that 10000 is enough? This is not a theoretical concern - when designing my modest refining setup (6 refineries with 12 beacons each) I really faced this problem. I build it one way - it works fine. Then I change something - it doesn't work anymore. So I go back to the working setup from a while ago and now it's not working anymore. The only thing you can say then is just "wtf"...
Of course, the assymetry issue is still there, and annoying, but at least it's not as bad as the build order issue !
[...]
On the other hand I'm more than certain that once you release 1.0 you will never consider fixing the fluid system, because such change has a potential for quietly modifying behavior of currently existing and working bases (especially if this would be a complete rework with different mechanics, such as described in FFF 274).
[...]
Why ?
"quietly" ??
Why would they almost completely stop development for the fear of breaking working bases ?
I'm not sure if anyone else has noticed this, but 0.18 zoomed map view has a very muted "snow" effect compared to previous. At first I thought it had gone completely, but it is still there.
Now, it is quite difficult to tell if I'm in the map at all.
The only graphics change made was to reduce saturation a little. My current setting is 80, and I don't remember the original value. Increasing it does make the snow a little more visible (barely), but the resulting overall look is not to my liking.
I'm unable to reproduce this - at least the way you describe it. Building the "left pipes" first still results in the the same scenario of "right tank" being filled first.
Initial state (3 "horizontal pipes missing):
Now put the pipes - first the right one, then the middle one, then the left one. After a while:
(left tank - 4.9k, right tank - 16k, left pump speed - 423, right pump speed - 1289).
Clear it now - delete the pipes, then the tanks, add the tanks again:
(image the same as the first one [; )
Now put the left pipe first, then the middle one, then the right one. After a while:
(left tank - 18k, right tank - 5.6k, left pump speed - 1289, right pump speed - 423).
Actually you don't need the pumps to show this behavior. Replace all of them with pipes and the same thing happens, only the differences are smaller (I've build the horizontal pipes left-to-right):
(left tank - 12k, right tank - 9.5k)
Water_test_0.18_02.zip
Or my own 0.17 and 0.18 tests :
Water_0.17_test_01.zip
Water_test_0.18.zip
Cannot open any of these, as none of them has the "level.dat" file in the zip and Factorio complains.
Anyway, are you certain that what you are describing below is still happening in the latest 0.17 or 0.18 ?
This is the latest stable 0.17 that is there. Check for yourself - here's the save of what I've shown above:
Also a clear indicator of flow through a pipe would be more than welcome, as now debugging the whole thing is just blind guessing.
How else would you show it instead than what the current debug option does ?
As a tooltip when hovering the mouse above a pipe segment. You see the flow for pumps, just exactly the same info for pipes. Just like what was shown in FFF 274 - there was a screenshot with flow info for pipes.
Why ?
"quietly" ??
Why would they almost completely stop development for the fear of breaking working bases ?
They would not stop development, but - at least in my understanding - fixing of fluid system would alter the basic mechanics that currently exist. Can you imagine the devs introducing changes of belt speed and inserter capacity _AFTER_ 1.0 is released? I cannot. And I think that fixing fluid mechanics would be quite similar to a change like modifying belt speed or inserter capacity... People complain on the forums (and in the reviews about everything) - for example someone upgraded to the new experimental, then downgraded back to 0.17 and after that all the blueprints are gone. All of that with the added comment "super mad"... Imagine forum threads like "I had my 1234k SPM base working perfectly, was building the thing for 4321 hours during the last 3 years and now - after the upgrade - it doesn't work! SUPER MAD!". Really bad publicity...
)
