Factorio Forums

Unless you did something very very specific a better fluid system wouldn't break any base or it wouldn't be a better fluid system because :
a - The adding of some kind of pressure or network-like flow would only increase throughput
b - The removing of build order preference would affect build who took it in consideration and unless you build big you don't really need to get into those considiration and if you do build big in most case you don't bother to build manually to favor one side over the other( a side that need to be favored).
And if you do take it into consideration and do build manually in most case you still would be happy with a new fluid system that as better throughput at longer distance and have a repartition more "predictable"/less dependent on build order and the amount of toothpaste you used the third day of the second week you changed your rail system to use 2-52 train instead of 1-8

and also if you are playing factorio isn't fixing thing that doesn't work the reason why you play?

And to finish even if it would break a lot of save and you don't like to fix your factory they wouldn't patch it silently and it wouldn't be in a small patch it would be a minor update and if you want to keep your factory that only work with the old fluid sytem you would just need to not update.

And I know I know that "just don't update then" is not really a valid argument but the positive of a new better fluid system way outweigh the negative it could have (or at least in my opinion) so I highly doubt the dev would not do it because it can possibly break the saves of some peoples

Olacken wrote: Wed Jan 29, 2020 10:31 am Unless you did something very very specific a better fluid system wouldn't break any base or it wouldn't be a better fluid system because...

I remember reading somewhere, that the new fluid system (as planned a year ago) would make underground pipes behave just as normal pipes of equivalent length. Therefore 2 undergrounds spanning for 10 tiles would count as 10 pipe segments, not 2 (as they do now). Such change alone has a potential of breaking everything you've done previously, especially nuclear power. I'm obviously assuming that this new fluid system would still reduce throughput for longer pipelines, but maybe it wouldn't - in that case it would indeed be hard to imagine it breaking something. Hard to tell, we are all speculating about something that may as well never happen /;

However please note that you don't need to convince me about the benefits of the potential new system (; I'm all in favor of changing the current (broken) one, even if it breaks some existing designs. However it's just my point of view and I'm very afraid that the devs (or their managers) may have a completely opposite stance, which will be even harder once 1.0 is released. It's just how software is developed - some people put a lot of effort in maintaining backward compatibility, even if this means that you are stuck with a broken feature, and there is almost nothing that can convince them to change their mind, with the only exception of >=51% of people considering to buy the game. It may sound hard, but you and I - we already bought the game, Wube most likely will _NOT_ earn any more cash from us (not that they do a bad job or something - I already bought this game, don't need another copy...). If the feature has low potential of attracting _NEW_ buyers, it has low potential of being implemented /;

Generally the biggest obstacle in the way of implementing new fluid system is that the current one "just works" for the "basic game" - as long as you don't build something big (beaconed & moduled refineries) or 10 nuclear reactors or something heavily optimized (with no significant overproduction), then you will most likely not notice the problem /;

Freddie Chopin wrote: Wed Jan 29, 2020 11:01 am I remember reading somewhere, that the new fluid system (as planned a year ago) would make underground ...

True I explained myself poorly and wasn't really making the right point.

As of today I don't recall the devs scrape an idea because it wouldn't increase new player income and that would benefit more experienced player (for the reason of not increasing the new player income) or at least for the idea that were scrapped that we know of .

And yes it could change with the fact that the game is released.

They have polished the game so much over those past 3 year that I don't think they would let such a glaring issue stay and if you look at recent update and fff's you can see it.

Also be mindfull of the wording

Right now it isn't included in our plans for 1.0.

It's precised that it isn't planed for 1.0 which let think it isn't out of question just not for 1.0

Things in this regard could change, especially if things go smoothly and one of the team has some spare time.

It further the point that it's planed or at least is in a todo list as a medium to high priority

I think the main reason why they don't plan to release a new fluid system before launch is because they had one started it wasn't working as they wanted so they scrapped it but they still have a deadline to meet to lauch the game the 25th of september and a new fluid system is something really chuncky so since they already have stuff planned they can't make promisses they know they will hardly be able to fit it in the 1.0 release.

Freddie Chopin wrote: Wed Jan 29, 2020 7:34 am [...] PROOFS [...]

Ah, interesting, what *I* did, was to build the pipes *first* and *only* then turn the pump power on.
This showed issues in 0.16.51, but not in 0.17.79 nor 0.18.2.

But it indeed seems like other build order issues remain. (I get the same issues as you in 0.18.2)

Freddie Chopin wrote: Wed Jan 29, 2020 7:34 am

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.

Oops, my bad, should have explicitly stated that those are scenarios, not saves. (And you have to unzip them first.)

Freddie Chopin wrote: Wed Jan 29, 2020 7:34 am

Freddie Chopin wrote: Tue Jan 28, 2020 8:17 am 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.

Right, not sure why it isn't in yet... since it's a more basic version of what you already see in the pipe graphics and the debug mode ?

Freddie Chopin wrote: Wed Jan 29, 2020 7:34 am 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...

I'm sorry, but imagining that devs will stop even balancing the game after 1.0 is ridiculous.
People will complain anyway, whether it's actually warranted or not,

and I fail to see how your example of people upgrading and downgrading is relevant when not only the game is alpha, but that would also require the player to mess with Steam settings to get access to the "beta".
(And downgrading is not supported, though it might not be clear enough ?)
(And Steams' backup system might be dangerous to use.)
(And they should have properly backed up their files if they cared about them.)
Is this those people's first game ??

You just can't expect software *in general* to never break when changed, this even happens in critical software when people die as a result and all the imaginable steps are taken to prevent stuff from breaking...

Also, if you're particularly paranoid that your base is going to break with an update, you should just put it in a separate install and disable auto-updates.

Olacken wrote: Wed Jan 29, 2020 10:31 am And I know I know that "just don't update then" is not really a valid argument

Why not ?

Freddie Chopin wrote: Wed Jan 29, 2020 11:01 am I remember reading somewhere, that the new fluid system (as planned a year ago) would make underground pipes behave just as normal pipes of equivalent length. Therefore 2 undergrounds spanning for 10 tiles would count as 10 pipe segments, not 2 (as they do now). Such change alone has a potential of breaking everything you've done previously, especially nuclear power. I'm obviously assuming that this new fluid system would still reduce throughput for longer pipelines, but maybe it wouldn't - in that case it would indeed be hard to imagine it breaking something. Hard to tell, we are all speculating about something that may as well never happen /;

That would have been Dominik's "New fluid system (1)".
Parts of which might or might not have been scrapped for TheYeast & Dominik's "New fluid system 2", which improved the "Old fluid system" by instead pretty much keeping the old physics model (?), but fixing the algorithm for the update order issues (by using several passes, as AFAIK is usually done for these simulations), which should have fixed the asymmetry issues. (No idea about build order issues, but hopefully, too.)
And they might have then still "merged in" Dominik's "New fluid system 1" later ?
However, it would seem that correcting the asymmetry might have caused new issues with oscillations ? Not sure why the dampening wasn't enough, what if it was the updated wave speed & viscosity parameters that were the issue ? (As bob found out when modding these values in 0.16-...)

BlueTemplar wrote: Wed Jan 29, 2020 2:51 pm Why not ?

Let me rephrase it is a valid argument not a strong one because even if you accept that not upgrading would mean that you can play with your save now you are put into a dilema between upgrading to have all those new toys and staying on an old version where your old toys still works.

To which you could respond "ofc you need to chose between playing with old toys and new toys" to which I could respond "yes but if that change wasn't made I could play with my old toys and my new toys"

That's why I don't consider it a strong argument, not because I think it's a bad one quite the contrary I'm mostly in the favor of new stuff even if it breaks old stuff just because it give a litlle bit more of probleme solving, but because some people will just respond to you "yes but I wan't to play with my old and new toys" and with those people it's hard to discuss afterward because you made it sounds like forcing them to choose was a valid argument.

BlueTemplar wrote: Wed Jan 29, 2020 2:51 pm Ah, interesting, what *I* did, was to build the pipes *first* and *only* then turn the pump power on.
This showed issues in 0.16.51, but not in 0.17.79 nor 0.18.2.

But it indeed seems like other build order issues remain. (I get the same issues as you in 0.18.2)

Yes, the whole thing is a bit chaotic and hard to reason about - seemingly unimportant changes can have drastic effects, that's why I think it is really broken [;

I'm sorry, but imagining that devs will stop even balancing the game after 1.0 is ridiculous.
People will complain anyway, whether it's actually warranted or not,

Balancing is a minor change. Fixing fluid system is altering the core mechanics of the game. On the other hand this probably boils down to what exactly will such hypothetical "fix" change. I can imagine that it can range from introducing something completely new, with different characteristics, or just fixing all the issues in the current one.

and I fail to see how your example of people upgrading and downgrading is relevant when not only the game is alpha, but that would also require the player to mess with Steam settings to get access to the "beta".
(And downgrading is not supported, though it might not be clear enough ?)
(And Steams' backup system might be dangerous to use.)
(And they should have properly backed up their files if they cared about them.)
Is this those people's first game ??

It's relevant because - as you noted yourself - such complains are just ridiculous (; Yet they appeared even though all of what you wrote is true. Imagine complains which would appear when the user does something "normal" (just upgrade) and finds that a change done _on_ _purpose_ (fixing the fluid system) breaks his precious save he/she has been working on for months. For me fixing it would be very nice. But some other person playing his modded angel-bob-krastorio-rampant-ribbon-pyanodons-ir-ltn-railworld-deathworld-marathon-with-expensive-recipes may don't care about that at all. And he will complain, that his save is ruined. It is a valid complaint... Is fixing the fluid system "the lesser evil" in that case? (;

You just can't expect software *in general* to never break when changed, this even happens in critical software when people die as a result and all the imaginable steps are taken to prevent stuff from breaking...

You're mixing things. Software breaking because of an unintended bug is not the same thing as "breaking on purpose", right? (;

Which one of us will be right is hard to tell now - we will either see the fluid system change sometime in the future or never. The devs don't seem to be interested in these discussions, so all we are left with is wild guessing. Whether the concerns I have (that changing this after 1.0 is much less likely than before) are exaggerated, I hope you cannot deny that they are valid influences on one's decision making. Maybe smaller, maybe bigger, but they are there. Also things like "we'll maybe do it if we have spare time" in programmer-speak means just "never", so - you know... (;

Freddie Chopin wrote: Wed Jan 29, 2020 3:47 pm

You just can't expect software *in general* to never break when changed, this even happens in critical software when people die as a result and all the imaginable steps are taken to prevent stuff from breaking...

You're mixing things. Software breaking because of an unintended bug is not the same thing as "breaking on purpose", right? (;

Olacken wrote: Wed Jan 29, 2020 3:20 pm [...] some people will just respond to you "yes but I wan't to play with my old and new toys" and with those people it's hard to discuss afterward because you made it sounds like forcing them to choose was a valid argument.

And I want my cake and eat it too.
"new toys" imply change. Which might (or might not) break "old toys". The risk is particularly high in simulation-heavy software like Factorio, where things affect other things, and consequences propagate far and wide.

Freddie Chopin wrote: Wed Jan 29, 2020 3:47 pm [...]some other person playing his modded angel-bob-krastorio-rampant-ribbon-pyanodons-ir-ltn-railworld-deathworld-marathon-with-expensive-recipes may don't care about that at all. And he will complain, that his save is ruined. It is a valid complaint... Is fixing the fluid system "the lesser evil" in that case? (;

No, it's not a valid complaint, because he modded his game, and furthermore, modded it heavily. (Which I do for most of my games.)
Any change to vanilla, even one from a minor version, could potentially completely break a heavily modded game that relied on a now removed functionality/quirk/bug. (Modders just *love* to push the game to its limits !)
Example : Rail Bridges. (Note : still during the first 0.17 experimental.)
Though hopefully, these kinds of changes will only happen in major versions after 1.0 ?

Again, I would ask those people if it was their first game experience.
My own experience involves :
- Devs that decided to flat-out remotely delete old saves when declaring the (post-release, post-1.0 !) game as stable, because it would "save on tech support with people that would try to continue games on different versions". (They would have benefited *a lot* from Early Access if it existed already...)
- Devs that upon reaching stable first hid the old saves, then have shown them as "unloadable", then, after pestering from players, and some days/weeks, published a fix that would allow old saves to be loaded (and no promises about stuff potentially breaking).
(And both of these are for games with save lengths in the same order of magnitude as Factorio ! And anyone using mods and complaining would be just "laughed out of the room".)

Freddie Chopin wrote: Wed Jan 29, 2020 3:47 pm [...]Also things like "we'll maybe do it if we have spare time" in programmer-speak means just "never", so - you know... (;

Well, IIRC, Wube has a pretty good track record in eventually implementing "spare time" stuff ?

Freddie Chopin wrote: Wed Jan 29, 2020 3:47 pm Also things like "we'll maybe do it if we have spare time" in programmer-speak means just "never", so - you know... (;

Yes I already know but in that case the "we'll maybe do it if we have spare time" was said about it being done for 1.0 wich make a tone of difference.

And the reason why I believe they will work on the fluid system post 1.0 if they don't do it before is because of how much time they have put on polishing the game and wouldn't let that kind of liquid behavior slideand the reason why it isn't included in 1.0 is because of unforseen event after the deadline was set for the launch.

Yes I do trust them a lot but In 5 years I have followed the develpment of this game they never failed it.

As a follow-up to my previous response to the fluid system *still* not being fixed, and the news that it isn't even planned for 1.0 (which generally means never), I have removed my positive review on Steam, as well as removing it as my favorite game on my profile.

The developers know that the fluid system is wrong, illogical, and fundamentally broken compared to the rest of the game. Ignoring this issue is unacceptable, and my opinion of Wube has greatly diminished.

JCav wrote: Wed Jan 29, 2020 7:38 pm As a follow-up to my previous response to the fluid system *still* not being fixed, and the news that it isn't even planned for 1.0 (which generally means never), I have removed my positive review on Steam, as well as removing it as my favorite game on my profile.

The developers know that the fluid system is wrong, illogical, and fundamentally broken compared to the rest of the game. Ignoring this issue is unacceptable, and my opinion of Wube has greatly diminished.

Which generally are you talking about? Generally Wube or generally game devs because I think there is a big distinction there

I'm concerned with the new (and old) path finding for "Issue 6: the block distance from the start was not updated properly".

First: Why is the last signal on the top bypass red? It should be green like on the lower path. The locomotive seems to be past the next signal, just like in the lower part.

Second: Why isn't the train taking the top straight part? It's shorter.

Decreasing the cost of occupied blocks by the number of blocks means train will take the longest path (by block count) when hitting an occupied block. (Why is this in blocks instead of rails?) I'm think NOT updating the block distance for nodes was the right thing as the distance relevant for the cost should be the shortest path. Taking a detour should not make the identical remaining path cheaper.

This would make the bottom path better as there are more blocks on the shortest path before hitting the occupied block. Even if you measure in rails instead of blocks the bottom still is better. Unless the penalty for being one rail longer is more. It's still a case of taking a detour is better when hitting an occupied block, even if the remaining paths are different in this case.


I know the reasoning behind the decreasing cost is logically sound: Occupied blocks far along the path are less important since they will change before the train gets there. But algorithmically it's totally wrong: Taking longer to reach the same occupied block is better. It's one of those cases where you know the right answer when you look at it but you can't give a formula on how to calculate it properly. We want the train to take the upper path since it's shorter but also the straight part, again because it's shorter.

Maybe the distance should be counted in occupied blocks? If you hit one occupied block already the next one is probably less important. Maybe even the cause for the first block being occupied. With that model both occupied blocks in the example have the same penalty, being the first occupied block and the top path becomes better. Generally the less congested path should get taken. In that model nodes must be updated since a detour can drive around occupied blocks and stop being a detour.

Also occupied isn't equal to occupied. For example a train moving will quickly clear an occupied block. But a train blocked for 3 minutes at a signal will not. Better take the path with a moving train as obstacle rather than the one with a standing train. My suggestion would be to try combining the two. So the cost of a occupied block is determined by how many occupied blocks are on the path already and the time the block has been occupied.

mrvn wrote: Mon Feb 03, 2020 11:39 am First: Why is the last signal on the top bypass red? It should be green like on the lower path. The locomotive seems to be past the next signal, just like in the lower part.

This is correct. Locomotive for which path is computed, occupies block that is behind that signal. This does not prevent it from going through that signal as a red signal here guards other trains from going by it, not the train that is already in that block.

mrvn wrote: Mon Feb 03, 2020 11:39 am Second: Why isn't the train taking the top straight part? It's shorter.

As penalty rule states, going straight gives higher penalty at signal going to middle block with locomotive. Siderail goes through more rail signals, each going to another block and so penalty on same signal will be different when going through siderail. I do not like that penalty rule (it may fail to apply if node under middle locomotive would be expanded before node related to siderail; also it prevents doing reverse pathfind as it contains extra state), but it is here. I would like to simply remove that, it would simplify a lot of trains pathfinder code.

mrvn wrote: Mon Feb 03, 2020 11:39 am Decreasing the cost of occupied blocks by the number of blocks means train will take the longest path (by block count) when hitting an occupied block. (Why is this in blocks instead of rails?) I'm think NOT updating the block distance for nodes was the right thing as the distance relevant for the cost should be the shortest path. Taking a detour should not make the identical remaining path cheaper.

Dunno.

mrvn wrote: Mon Feb 03, 2020 11:39 am Also occupied isn't equal to occupied. For example a train moving will quickly clear an occupied block.

Well, there are limitations on every place. For example, long train may occupy N blocks on its way, other train will see penalty of that train multiple times (once for each signal going into block occupied by that train).

boskid wrote: Mon Feb 03, 2020 12:24 pm

mrvn wrote: Mon Feb 03, 2020 11:39 am First: Why is the last signal on the top bypass red? It should be green like on the lower path. The locomotive seems to be past the next signal, just like in the lower part.

This is correct. Locomotive for which path is computed, occupies block that is behind that signal. This does not prevent it from going through that signal as a red signal here guards other trains from going by it, not the train that is already in that block.

This isn't about the locomotive for which path is computed. It's about the one blocking the path. In both cases (top and bottom) it is in the block after the junction at the same place from the signal. But in the top the previous signal is still red while in the bottom it is green.

It's about why that signal is red in the first place, not why the locomotive can drive through it anyway.

boskid wrote: Mon Feb 03, 2020 12:24 pm

mrvn wrote: Mon Feb 03, 2020 11:39 am Second: Why isn't the train taking the top straight part? It's shorter.

As penalty rule states, going straight gives higher penalty at signal going to middle block with locomotive. Siderail goes through more rail signals, each going to another block and so penalty on same signal will be different when going through siderail. I do not like that penalty rule (it may fail to apply if node under middle locomotive would be expanded before node related to siderail; also it prevents doing reverse pathfind as it contains extra state), but it is here. I would like to simply remove that, it would simplify a lot of trains pathfinder code.

That was more wishful thinking than a real question.

But since you mentioned the locomotive ignoring the red signal as it's already in the block. Does that mean the penalty for a red signal is ignored too or does it still count?

boskid wrote: Mon Feb 03, 2020 12:24 pm

mrvn wrote: Mon Feb 03, 2020 11:39 am Decreasing the cost of occupied blocks by the number of blocks means train will take the longest path (by block count) when hitting an occupied block. (Why is this in blocks instead of rails?) I'm think NOT updating the block distance for nodes was the right thing as the distance relevant for the cost should be the shortest path. Taking a detour should not make the identical remaining path cheaper.

Dunno.

mrvn wrote: Mon Feb 03, 2020 11:39 am Also occupied isn't equal to occupied. For example a train moving will quickly clear an occupied block.

Well, there are limitations on every place. For example, long train may occupy N blocks on its way, other train will see penalty of that train multiple times (once for each signal going into block occupied by that train).

But that's kind of OK since a long train will also take more time to clear the occupied blocks.

mrvn wrote: Mon Feb 03, 2020 12:34 pm This isn't about the locomotive for which path is computed. It's about the one blocking the path. In both cases (top and bottom) it is in the block after the junction at the same place from the signal. But in the top the previous signal is still red while in the bottom it is green.

I did answer that. In top contraption, last signal in bypass goes into block that is occupied by leftmost locomotive (there are no signals on straight path to split rails into blocks). In bottom contraption, last signal in bypass goes into different blocks since straight path is cut. Please excuse crudity of my graphics.

mrvn wrote: Mon Feb 03, 2020 12:34 pm That was more wishful thinking than a real question.

That was exact answer. Pathfinder cares only about penalties. If path is longer but it has lower cost, pathfinder will choose path with lower cost. Pathfinder is a way to find paths with lowest cost. To make pathfinder care about distances it is required to give penalty based on distance and it already exists. There are however other sources of penalties that may overweight decistion based solely on distances. For exactly same reason, train could choose bypass if straight path would be occupied by another train (assuming there would be extra signals on straight path so that train would be in different block)

mrvn wrote: Mon Feb 03, 2020 12:34 pm But since you mentioned the locomotive ignoring the red signal as it's already in the block. Does that mean the penalty for a red signal is ignored too or does it still count?

Technicaly there are no penalties for red signal (unless it is CN closed). Penalty is taken for all trains (except that requesting path) that are inside block after that rail signal if that signal goes into another block. (if on both sides there would be the same block, rail signal would be useless, there would be disco on it and no penalties added). That way of adding penalty is required since there may be multiple transitions inside a rail block (like junctions) and they should not add extra penalties.

This also means that (for example) this penalty rule taken from wiki:

https://wiki.factorio.com/Railway/Train_path_finding wrote:When the path includes a manually controlled stopped train -> Add a penalty of 2000.

Is in some sort, simplified. This penalty will be added as long as path goes through block that has such train. Path may not go anywhere near that train but penalty will be added as long block is the same. Exact rule would be:

"When the path enters a rail block that has a manually controlled stopped train in it -> Add a penalty of 2000."

That would explicitly point that this penalty may be applied multiple times (path may enter and exit same block multiple times) and there is no need for a path to go under that train. This would however raise extra questions and so simplified rule is enough in most cases.

This also explains why multiple trains are not allowed inside single block. Primary reason, block reservations would not work, but secondary, that train would not give penalty for path of other train inside the same block and so collisions would happen. Even worse: in that contraption with siderail, train will choose bypass, but by placing second train in same block, right on the center of straight rail segment (below bypass), left train would go straight (this would be because last signal on bypass would give penalty of that second train and so straight path would be better).

boskid wrote: Mon Feb 03, 2020 12:58 pm

mrvn wrote: Mon Feb 03, 2020 12:34 pm This isn't about the locomotive for which path is computed. It's about the one blocking the path. In both cases (top and bottom) it is in the block after the junction at the same place from the signal. But in the top the previous signal is still red while in the bottom it is green.

I did answer that. In top contraption, last signal in bypass goes into block that is occupied by leftmost locomotive (there are no signals on straight path to split rails into blocks). In bottom contraption, last signal in bypass goes into different blocks since straight path is cut. Please excuse crudity of my graphics.
80410-mrvn-red-signal.png

Ah, stupid me. The signal isn't red because of the other locomotive blocking the block. It's red because the first locomotive is in that block already. I never have a bypass that doesn't have a signal on the straight as well so I just didn't figure that in.

boskid wrote: Mon Feb 03, 2020 1:09 pm

mrvn wrote: Mon Feb 03, 2020 12:34 pm But since you mentioned the locomotive ignoring the red signal as it's already in the block. Does that mean the penalty for a red signal is ignored too or does it still count?

Technicaly there are no penalties for red signal (unless it is CN closed). Penalty is taken for all trains (except that requesting path) that are inside block after that rail signal if that signal goes into another block. (if on both sides there would be the same block, rail signal would be useless, there would be disco on it and no penalties added). That way of adding penalty is required since there may be multiple transitions inside a rail block (like junctions) and they should not add extra penalties.

Yes, but in this case the train is entering a block that is occupied by the locomotive requesting the path. You say "except that requesting path". So entering that red signaled block does not add a penalty then because the train doesn't penalizes itself, right?

boskid wrote: Mon Feb 03, 2020 1:09 pm This also means that (for example) this penalty rule taken from wiki:

https://wiki.factorio.com/Railway/Train_path_finding wrote:When the path includes a manually controlled stopped train -> Add a penalty of 2000.

Is in some sort, simplified. This penalty will be added as long as path goes through block that has such train. Path may not go anywhere near that train but penalty will be added as long block is the same. Exact rule would be:

"When the path enters a rail block that has a manually controlled stopped train in it -> Add a penalty of 2000."

That would explicitly point that this penalty may be applied multiple times (path may enter and exit same block multiple times) and there is no need for a path to go under that train. This would however raise extra questions and so simplified rule is enough in most cases.

This also explains why multiple trains are now allowed inside single block. Primary reason, block reservations would not work, but secondary, that train would not give penalty for path of other train inside the same block and so collisions would happen. Even worse: in that contraption with siderail, train will choose bypass, but by placing second train in same block, right on the center of straight rail segment (below bypass), left train would go straight (this would be because last signal on bypass would give penalty of that second train and so straight path would be better).

I think most sane cases don't have blocks crossing other blocks multiple times. Often a dangerous lack of signals.

Case in point in the above example the train will drive into the bypass. Then the follow up train will come in and block the exit of the bypass. If it also wants to take the bypass then you have a deadlock.

mrvn wrote: Mon Feb 03, 2020 3:37 pm Yes, but in this case the train is entering a block that is occupied by the locomotive requesting the path. You say "except that requesting path". So entering that red signaled block does not add a penalty then because the train doesn't penalizes itself, right?

Yes. Train does not penalize itself. On wiki there is link to some old version of pathfinder code, you will find in it line 213 is doing exactly that.

I am only seeing this discussion now because I have been so busy having great time. Currently in Sri Lanka and can't complain one bit Thank you for your nice wishes and your concern is really moving and heartwarming!

I can understand your desire for deeper insight but that simply can't be done. Imagine you were to publicly talk about how you broke up with your partner. Might have been the nicest break up ever, or might have been bad. But either way no level of detail will be satisfactory enough without exposing every detail of your sex life at the same time.

Sorry I won't shed any light on the fluids either as that is not for me to say.

I, again, appreciate the community - you - for your sensibility. Very little of jumping to conclusions and a lot of calm, thought out evaluations. I wish I were this wise and patient sometimes.

Have no worry, I am great and you did not miss much by not knowing every detail of our office romances Thank you and have a great time with or without Factorio!

Dominik wrote: Mon Feb 10, 2020 4:13 pm I am only seeing this discussion now because I have been so busy having great time. Currently in Sri Lanka and can't complain one bit Thank you for your nice wishes and your concern is really moving and heartwarming!

I can understand your desire for deeper insight but that simply can't be done. Imagine you were to publicly talk about how you broke up with your partner. Might have been the nicest break up ever, or might have been bad. But either way no level of detail will be satisfactory enough without exposing every detail of your sex life at the same time.

Sorry I won't shed any light on the fluids either as that is not for me to say.

I, again, appreciate the community - you - for your sensibility. Very little of jumping to conclusions and a lot of calm, thought out evaluations. I wish I were this wise and patient sometimes.

Have no worry, I am great and you did not miss much by not knowing every detail of our office romances Thank you and have a great time with or without Factorio!

Not to be rude. But what comment are you replying to anyways? This seems very out of place, the above post in page is just people talking about trains.