Working with trains is a pain in the..

Post your ideas and suggestions how to improve the game.

Moderator: ickputzdirwech

User avatar
Ghoulish
Filter Inserter
Filter Inserter
Posts: 461
Joined: Fri Oct 16, 2015 8:40 am

Working with trains is a pain in the..

Post by Ghoulish »

.. behind! And here's a few ideas I feel would help.

I'm torn when in comes to working with trains. On the one hand working out an optimum design that still has a visual appeal or symmetry is such a fun thing to do and iterate on, that I have lost whole nights to designing a single main base offload. Good ideas are expanded on and the bad ones cut out. I love working on trains and track!

But when it comes to actually doing the work and ordering my happily fed minions to lay the 10,11,12,13,14,15,16th - X version of the stacker, the FPS/UPS tries to go negative on me much like my daily bank balance, and I have >5 UPS. I know what's happening, each track might be giving a new route or change an existing one, so a calculation has to be made, all those tracks and signals, so many possibilities all of a sudden. Less than 5 UPS until the bots have it all laid down and the train pathing is worked out. FFS! I hate working on trains and track!

The solution is something vanilla doesn't have. The ability to stop/start all your trains at once. The Fat Controller MOD facilitates this. Great now there is no train pathfinding going as they're all stopped! So messing about with track is pain free and fast. The catch of course is that the trains coast for a bit before stopping, so they run up as yet complete T junctions and similar. So stopping the trains usually ends up with one wondering somewhere it shouldn't, and gridlock. I will raise this with Choumiko, perhaps a stop-dead option could be easily added?

However this is a feature that is not in vanilla. The UPS when working on a reasonably sized train system... it's such a chore - whilst all the trains are running and pathfinding. Being able to stop all the trains (in a manner whereby their original path is taken under breaking and they honour chain signals with their final stopping point) Would, should and must be added.

Which leads me on to another must have option that even MODs don't cater too. The ability to change the value of all trains with a specific stop. For example change every trains wait time whilst at the offload from 30s to 60s, or delete every trains second stop and replace it with X, and similar.(edit: I would guess there to be massive layers of complexity the more options you could change in this manner, but an option to change en masse.. Sooo useful. Make whatever available to the MOD authors, maybe, can they anyway? The upcoming windows for MODs etc etc..).

And the final must have train tool, is the ability to switch between automatic and manual with a key press & mouse hover. Please Wube, God dam it, pretty please guys. *Please*
See the daily™ struggles with my Factory! :D https://www.twitch.tv/repetitivebeats

User avatar
BlueTemplar
Smart Inserter
Smart Inserter
Posts: 2420
Joined: Fri Jun 08, 2018 2:16 pm
Contact:

Re: Working with trains is a pain in the..

Post by BlueTemplar »

Maybe stupid question, but have you considered to lay down your new system as disconnected from the main one, and only connect it afterwards, when it has been completely laid down by the bots ?
BobDiggity (mod-scenario-pack)

User avatar
Ghoulish
Filter Inserter
Filter Inserter
Posts: 461
Joined: Fri Oct 16, 2015 8:40 am

Re: Working with trains is a pain in the..

Post by Ghoulish »

Any track laid down has the ups hit, even if I stamped down an 8 lane 4 way totally isolated, the ups would hit, as (I assume) The game still has to know what it connects to? It doesn't know it's isolated. Surgically severing the train path, say the 4 north and south bound routes leading into a T junction, even after doing that (no train can get to that section any more..) It still has the ups hit (edit, assumptions making the mother of all... but again, how does the game know you didnt just reconnect something to the previously severed network? And weren't just messing with isolated stuff? - it has to run (perhaps many) Calculations to know.
See the daily™ struggles with my Factory! :D https://www.twitch.tv/repetitivebeats

User avatar
BlueTemplar
Smart Inserter
Smart Inserter
Posts: 2420
Joined: Fri Jun 08, 2018 2:16 pm
Contact:

Re: Working with trains is a pain in the..

Post by BlueTemplar »

Try it out... I doubt that pathfinding is considering disconnected networks ?
BobDiggity (mod-scenario-pack)

Koub
Global Moderator
Global Moderator
Posts: 7198
Joined: Fri May 30, 2014 8:54 am
Contact:

Re: Working with trains is a pain in the..

Post by Koub »

It would be easier if you did one suggestion by topic, but I'll try to answer :

1) Stop/start all trains at once
Couldn't find that exact same suggestion, but if the idea I linked for 2) was implemented, it could be embedded with it.

2) Reroute all trains from one stop to another
This would be trivial should this suggestion be implemented : viewtopic.php?f=6&t=53473

3) Key binding to switch Manual/Auto mode :
Related : viewtopic.php?f=6&t=46308
Koub - Please consider English is not my native language.

slippycheeze
Filter Inserter
Filter Inserter
Posts: 587
Joined: Sun Jun 09, 2019 10:40 pm
Contact:

Re: Working with trains is a pain in the..

Post by slippycheeze »

BlueTemplar wrote:
Tue Aug 20, 2019 3:03 pm
Try it out... I doubt that pathfinding is considering disconnected networks ?
Train pathfinding, per the wiki, is A*, so no -- it'll start at the location of the train, and then grow outwards through the connected rails until it reaches the destination. A disconnected rail can't ever be reached, so it'll be impossible for it to cost anything for pathfinding. (I understand from elsewhere that bug pathing is also A*, so we also have a second reason than just "Bilka is competent" to believe this to be the case.)

It'll be more costly to have multiple paths to a destination, and every turn is going to potentially cost. Especially as it involves a weighted graph, with each rail segment having different costs when stations, signals, other trains, etc, etc, are in the mix.
Ghoulish wrote:
Tue Aug 20, 2019 2:46 pm
Any track laid down has the ups hit, even if I stamped down an 8 lane 4 way totally isolated, the ups would hit, as (I assume) The game still has to know what it connects to?
This is a property of the entity: https://lua-api.factorio.com/latest/Lua ... cted_rails -- now, it could dynamically calculate that every time you asked (and the pathfinder asked) but that would be silly: the C++ core knows 100 percent reliably when a rail is built or destroyed, and the Wube developers know that their pathfinder needs to anwer "what is connected to this rail (block)" very frequently, so I'm 110 percent confident this is a representation of the internal C++ data.

So ... yes, it does need to know what the rail connects to, but....
Ghoulish wrote:
Tue Aug 20, 2019 2:46 pm
It doesn't know it's isolated.
...first, it calculates this once and saves the data forever, but second, even if it didn't save it forever, it'd *still* know the rail segment is disconnected, because it needs to work out exactly that in order to navigate. Trains definitely repath around destroyed or removed track segments, so they clearly take connectivity into account, just in case you had any doubts.

So: connectivity calculation is around O(1) for each rail entity placed, and we can assume the data is stored in a way that makes A* efficient, since Wube are kinda into that sort of performance, y'know?
Ghoulish wrote:
Tue Aug 20, 2019 2:46 pm
Surgically severing the train path, say the 4 north and south bound routes leading into a T junction, even after doing that (no train can get to that section any more..) It still has the ups hit (edit, assumptions making the mother of all... but again, how does the game know you didnt just reconnect something to the previously severed network? And weren't just messing with isolated stuff? - it has to run (perhaps many) Calculations to know.
So, cutting a network will have a brief, but large, spike of activity. Every train that crossed the segment in a path needs to repath now. Once that is done, though, it'll be back to the same degree of efficiency: never considered, because the pathfinder specifically never considers anything but the neighbours of a rail that a train can reach, and a disconnected rail can never be reached.

slippycheeze
Filter Inserter
Filter Inserter
Posts: 587
Joined: Sun Jun 09, 2019 10:40 pm
Contact:

Re: Working with trains is a pain in the..

Post by slippycheeze »

Ghoulish wrote:
Tue Aug 20, 2019 1:59 pm
.. behind! And here's a few ideas I feel would help.

I'm torn when in comes to working with trains. On the one hand working out an optimum design that still has a visual appeal or symmetry is such a fun thing to do and iterate on, that I have lost whole nights to designing a single main base offload. Good ideas are expanded on and the bad ones cut out. I love working on trains and track!

But when it comes to actually doing the work and ordering my happily fed minions to lay the 10,11,12,13,14,15,16th - X version of the stacker, the FPS/UPS tries to go negative on me much like my daily bank balance, and I have >5 UPS. I know what's happening, each track might be giving a new route or change an existing one, so a calculation has to be made, all those tracks and signals, so many possibilities all of a sudden. Less than 5 UPS until the bots have it all laid down and the train pathing is worked out. FFS! I hate working on trains and track!

The solution is something vanilla doesn't have. The ability to stop/start all your trains at once.
A better solution might be to ask for the train repathing system to spread the work over multiple ticks, so that it took longer, but was less of an instant hit due to repathing. (Pathing is, indeed, expensive, and immune to some optimizations like JPS because it is a weighted graph with both directed and undirected edges.)

I'd think that was a reasonable choice, within reason, since the risk that an "idiot train hit the end of the line you were deconstructing" annoys you vs the risk the UPS hit annoys is ... y'know.
Ghoulish wrote:
Tue Aug 20, 2019 2:46 pm
The Fat Controller MOD facilitates this. Great now there is no train pathfinding going as they're all stopped! So messing about with track is pain free and fast. The catch of course is that the trains coast for a bit before stopping, so they run up as yet complete T junctions and similar. So stopping the trains usually ends up with one wondering somewhere it shouldn't, and gridlock. I will raise this with Choumiko, perhaps a stop-dead option could be easily added?
The only way to dead-stop a train is to do horrible things, like running into the end of train line, or some destroyable object with enough HP, or scripting. None of which are very nice. FWIW.
Ghoulish wrote:
Tue Aug 20, 2019 2:46 pm
However this is a feature that is not in vanilla. The UPS when working on a reasonably sized train system... it's such a chore - whilst all the trains are running and pathfinding. Being able to stop all the trains (in a manner whereby their original path is taken under breaking and they honour chain signals with their final stopping point) Would, should and must be added.
I repeat myself from another thread, but your definition of "reasonably sized" is probably not closely related to efficient operation of train networks -- either for throughput, or for performance as you build. You should think about using more, smaller, train networks, and more transshipping points, so that you don't have nearly as much dynamic pathing. It'll help with a lot of things, throughput included.
Ghoulish wrote:
Tue Aug 20, 2019 2:46 pm
Which leads me on to another must have option that even MODs don't cater too. The ability to change the value of all trains with a specific stop. For example change every trains wait time whilst at the offload from 30s to 60s, or delete every trains second stop and replace it with X, and similar.(edit: I would guess there to be massive layers of complexity the more options you could change in this manner, but an option to change en masse.. Sooo useful. Make whatever available to the MOD authors, maybe, can they anyway? The upcoming windows for MODs etc etc..).
Are you sure? Because LTN certainly allows those changes, as far as I can tell, and I'm pretty sure others do. In fact, isn't the peer to Fat Controller line-based?

Ghoulish wrote:
Tue Aug 20, 2019 2:46 pm
And the final must have train tool, is the ability to switch between automatic and manual with a key press & mouse hover.
Much nicer is having the train automatically switch to manual mode when you hit a movement key while you are in it. Anyway, mods. Plenty of them do this already for you.

User avatar
ssilk
Global Moderator
Global Moderator
Posts: 12888
Joined: Tue Apr 16, 2013 10:35 pm
Contact:

Re: Working with trains is a pain in the..

Post by ssilk »

What the OP points to, is that if you have many trains waiting, laying new tracks becomes a pain. Because I don’t have that problem ... even with 200 running trains, in a 300 Kilometer large train network, I can use the trainlayer mod without seeing a difference in ups. It’s only the waiting trains, that make this problem.

So this problem is a special case and a quite simple solution would be to have a mod, that turns off all trains, that are currently waiting. It could be smart: when the player puts a track or signal into the hand (or enter raillayer train), and the number of waiting trains is above some limit, the mod can begin to stop the trains. When he puts the tracks out of hand it can restart the trains. Doesn’t look very complicated.
Cool suggestion: Eatable MOUSE-pointers.
Have you used the Advanced Search today?
Need help, question? FAQ - Wiki - Forum help
I still like small signatures...

User avatar
Ghoulish
Filter Inserter
Filter Inserter
Posts: 461
Joined: Fri Oct 16, 2015 8:40 am

Re: Working with trains is a pain in the..

Post by Ghoulish »

The reality of working with trains is not as others have stated here.

So I went and made a 3 min video for you all to watch as a case in point. In it I deconstruct a train junction - it is totally isolated. And then rebuild the junction with undo. And then stop all the trains and deconstruct again.. Watch the UPS.

"Try it out... I doubt that pathfinding is considering disconnected networks ?" (really, you think I am making it up?)

"So, cutting a network will have a brief, but large, spike of activity. Every train that crossed the segment in a path needs to re-path now. Once that is done, though, it'll be back to the same degree of efficiency: never considered, because the pathfinder specifically never considers anything but the neighbours of a rail that a train can reach, and a disconnected rail can never be reached."

I know a few people who replied to me know far more than I on the inner workings of the game. But the reality of the situation is not as you say. It truly is not, and I would like to get to the bottom of it and find out why - at the very least highlight the issue in the hope the devs can do something to lessen the impact. I should mention that I do have a couple of MODs, but none change the trains beyond the faster ones from bobs and the different designs from yuoki (edit: FARL and Fat Controller too) No LTN and the like, or even combinators controlling trains. The issue might be something my end, after all if you all do not get this behaviour.. Then clearly..

http://www.mediafire.com/file/4xn7qvakx ... 2.mp4/file

ps. Didn't mean to have the caps lock on


Ghoulish wrote:
Tue Aug 20, 2019 2:46 pm
And the final must have train tool, is the ability to switch between automatic and manual with a key press & mouse hover.
Much nicer is having the train automatically switch to manual mode when you hit a movement key while you are in it. Anyway, mods. Plenty of them do this already for you.
Don't see how having to get a train first and then having a key is of much use? Let's say I stop 10 trains in a stacker, with your way I would have to get in to each train one by one and start them (which would be slower than the current method) If you could hover the mouse and hit a key however the player would hardly even have to move. Which is simpler and faster?
Last edited by Ghoulish on Mon Aug 26, 2019 1:14 pm, edited 2 times in total.
See the daily™ struggles with my Factory! :D https://www.twitch.tv/repetitivebeats

mrvn
Smart Inserter
Smart Inserter
Posts: 5696
Joined: Mon Sep 05, 2016 9:10 am
Contact:

Re: Working with trains is a pain in the..

Post by mrvn »

Ghoulish wrote:
Mon Aug 26, 2019 11:01 am
Don't see how having to get a train first and then having a key is of much use? Let's say I stop 10 trains in a stacker, with your way I would have to get in to each train one by one and start them, if you could hover the mouse and hit a key however the player would hardly even have to move. Which is simpler and faster?
I think he means hopping on a train and when it stops at a station you toggle it to manual and hop of. Do some fixing of a problem. Then you hop back on and turn it back to automatic again.

I think it would be better to have a temporary stop with "wait 5 seconds and player present".

User avatar
Ghoulish
Filter Inserter
Filter Inserter
Posts: 461
Joined: Fri Oct 16, 2015 8:40 am

Re: Working with trains is a pain in the..

Post by Ghoulish »

I think he means hopping on a train and when it stops at a station you toggle it to manual and hop of. Do some fixing of a problem. Then you hop back on and turn it back to automatic again.
I think it would be better to have a temporary stop with "wait 5 seconds and player present".
Ahh, understood.
See the daily™ struggles with my Factory! :D https://www.twitch.tv/repetitivebeats

mrvn
Smart Inserter
Smart Inserter
Posts: 5696
Joined: Mon Sep 05, 2016 9:10 am
Contact:

Re: Working with trains is a pain in the..

Post by mrvn »

ssilk wrote:
Sat Aug 24, 2019 7:09 am
What the OP points to, is that if you have many trains waiting, laying new tracks becomes a pain. Because I don’t have that problem ... even with 200 running trains, in a 300 Kilometer large train network, I can use the trainlayer mod without seeing a difference in ups. It’s only the waiting trains, that make this problem.

So this problem is a special case and a quite simple solution would be to have a mod, that turns off all trains, that are currently waiting. It could be smart: when the player puts a track or signal into the hand (or enter raillayer train), and the number of waiting trains is above some limit, the mod can begin to stop the trains. When he puts the tracks out of hand it can restart the trains. Doesn’t look very complicated.
Does the train system have separate networks for tracks that aren't connected? If so then:

1) train networks could be spread across multiple cores since they can't interact with each other. Are they?

2) building a stacker disconnected from everything should not trigger any train for anything since they would be in a different train network than the anything involved in the building.

3) finally connecting the stacker (or any two tracks from different networks) would cause a big spike because all waiting trains would have to check if they now have a path available. Unavoidable.

4) connecting 2 train networks where one does hold no stations (any train is targeting) can't open up new paths.

5) when connecting 2 train networks it might be beneficial to change the network ID on the network with fewer trains (often one has 0).

Further does laying down sequentially improve things? Because when you extend a block by one track there is no need to re-path anything. Only when 2 blocks are connected is there a possibility of new paths opening up.

User avatar
BlueTemplar
Smart Inserter
Smart Inserter
Posts: 2420
Joined: Fri Jun 08, 2018 2:16 pm
Contact:

Re: Working with trains is a pain in the..

Post by BlueTemplar »

Huh. Disconnected slowdown indeed. Maybe you found a bug ?
Could you try removing as many mods as possible, especially the train-related ones ?
Could you please share this intersection as a blueprint string (and details about your bots) so that others can also try laying it out ?
BobDiggity (mod-scenario-pack)

slippycheeze
Filter Inserter
Filter Inserter
Posts: 587
Joined: Sun Jun 09, 2019 10:40 pm
Contact:

Re: Working with trains is a pain in the..

Post by slippycheeze »

BlueTemplar wrote:
Mon Aug 26, 2019 3:32 pm
Huh. Disconnected slowdown indeed. Maybe you found a bug ?
Could you try removing as many mods as possible, especially the train-related ones ?
Could you please share this intersection as a blueprint string (and details about your bots) so that others can also try laying it out ?
Well, A* pathfinding should never traverse to disconnected rails, but on the other hand, we also know the developers have made decisions that favour simplicity before such as restarting on any mod change regardless of anything else. It doesn't seem beyond the reach of logic that they might have decided that cutting or joining a train segment simply discards all cached paths and recalculates even when it isn't strictly necessary -- the relative cost of answering "do we need to repath this train" vs the relative cost of repathing them all for most cases isn't really going to be all that different, I'd suspect.

I agree with BlueTemplar: the best bet, at this point, is to post a reproducible case. Perhaps the developers will take interest, as they have before, and it'll be suddenly that bit more efficient. :)

Koub
Global Moderator
Global Moderator
Posts: 7198
Joined: Fri May 30, 2014 8:54 am
Contact:

Re: Working with trains is a pain in the..

Post by Koub »

Ghoulish wrote:
Mon Aug 26, 2019 11:01 am
I know a few people who replied to me know far more than I on the inner workings of the game. But the reality of the situation is not as you say. It truly is not, and I would like to get to the bottom of it and find out why - at the very least highlight the issue in the hope the devs can do something to lessen the impact. I should mention that I do have a couple of MODs, but none change the trains beyond the faster ones from bobs and the different designs from yuoki (edit: FARL and Fat Controller too) No LTN and the like, or even combinators controlling trains. The issue might be something my end, after all if you all do not get this behaviour.. Then clearly..

http://www.mediafire.com/file/4xn7qvakx ... 2.mp4/file
Have you considered the possibility that despite what your experiment seems to show, the slowing may be a result of a weird interaction between some of your mods (for example the way you robots work show you have a mod altering robot behaviour) ?

I'd like to see this experiment with minimal unknown variable : not mods or maybe just creative mod to help set up the test bed.
Koub - Please consider English is not my native language.

User avatar
Ghoulish
Filter Inserter
Filter Inserter
Posts: 461
Joined: Fri Oct 16, 2015 8:40 am

Re: Working with trains is a pain in the..

Post by Ghoulish »

Thanks for the replies. First point to raise is that I doubt the underlying issue is MOD related as the discerning factor here is whether or not the trains are stopped or started. I did go back and test however. This time using 'mk 1 bots'. A couple of points on this they are bobs - but use vanilla recipes, they are the same as in vanilla, same speed etc. I disabled yuoki, rampant and a few others too.

2 shorter clips, which show the same behaviour as before, check the UPS. They are around 40mb each.

http://www.mediafire.com/file/zl1flyb8p ... 9.mp4/file

http://www.mediafire.com/file/rhlkfpzvs ... 5.mp4/file

Even with disconnected networks, there is a noticeable drop in UPS whenever you construct or deconstruct track, I checked with a blueprint that had no signals and it was the same behaviour.

Here is the blueprint of the junction in question, as asked for :)


I would like to get feedback from others on what happens to their UPS when they deconstruct rail networks. For me to take this forward however I feel we need clarification from one of the devs on what the intended behaviour firstly is, and then if it is something that could be addressed now or in the future. The ideal situation would be to have disconnected train networks not impact UPS, until such a time as they are connected up to the main one.
See the daily™ struggles with my Factory! :D https://www.twitch.tv/repetitivebeats

User avatar
BlueTemplar
Smart Inserter
Smart Inserter
Posts: 2420
Joined: Fri Jun 08, 2018 2:16 pm
Contact:

Re: Working with trains is a pain in the..

Post by BlueTemplar »

I've tried it in vanilla with no noticeable slowdown whatsoever* - but then I only have 1k bots (with only 2.75x speed, and not personal ones), and only 15 trains...

*Holding the blueprint, however, drops FPS in half !
BobDiggity (mod-scenario-pack)

slippycheeze
Filter Inserter
Filter Inserter
Posts: 587
Joined: Sun Jun 09, 2019 10:40 pm
Contact:

Re: Working with trains is a pain in the..

Post by slippycheeze »

Ghoulish wrote:
Wed Aug 28, 2019 5:23 pm
I would like to get feedback from others on what happens to their UPS when they deconstruct rail networks. For me to take this forward however I feel we need clarification from one of the devs on what the intended behaviour firstly is, and then if it is something that could be addressed now or in the future. The ideal situation would be to have disconnected train networks not impact UPS, until such a time as they are connected up to the main one.
Given that changing rail networks is a very rare event, I'm not sure that is actually the right decision. In order to avoid the performance hit the developers would also need to keep a "rail network ID" for each rail entity[1] -- at minimum an extra field in the backing class for LuaEntity. Which, given the Lua API, we can be pretty confident has a very similar "god object" model (or a cluster of related classes similar to it, I guess) in C++. That means the extra data will be carried for every entity in the game, even if not used. (I guess, maybe if they do things with unions internally, possibly shared total space, but still....)


So.... given it seems like this only shows up temporarily, in a very rare (compared to everything else in the game), and human-triggered situation, I'm not sure I'd make the choice to spend extra bytes on this. Especially when the game is known to benefit dramatically from memory bandwidth optimization for maps at scale, and there are no particular reasons to assume any player would have any given number of networks, so I'd bet someone would hit the limit of a 2^16 rail network ID and complain.

After all, hard to beat the performance of a two-way track with one train in terms of avoiding things blocking your trains, so a base with nothing but those lines to move things is entirely conceivable. Might even beat out more complicated networks for performance. I should try that high level design some time. :)


[1] If they don't cache the network identity in the rail entity, they would need to walk the rail network when connecting things, which is going to have a cost proportional to the number of rail entities in all newly connected networks. Since your concern is optimizing a behaviour that scales with the size of the network(s)....

quyxkh
Smart Inserter
Smart Inserter
Posts: 1028
Joined: Sun May 08, 2016 9:01 am
Contact:

Re: Working with trains is a pain in the..

Post by quyxkh »

Per the wiki, all trains recheck their paths when you build or destroy a signal. Your video shows you destroying maybe a hundred? signals. Seems to me there's a good argument the game engine would perform better if it batched its responses, so pathing is rebuilt at most once per tick, after all the relevant work for a tick is done.

mrvn
Smart Inserter
Smart Inserter
Posts: 5696
Joined: Mon Sep 05, 2016 9:10 am
Contact:

Re: Working with trains is a pain in the..

Post by mrvn »

slippycheeze wrote:
Wed Aug 28, 2019 7:16 pm
Ghoulish wrote:
Wed Aug 28, 2019 5:23 pm
I would like to get feedback from others on what happens to their UPS when they deconstruct rail networks. For me to take this forward however I feel we need clarification from one of the devs on what the intended behaviour firstly is, and then if it is something that could be addressed now or in the future. The ideal situation would be to have disconnected train networks not impact UPS, until such a time as they are connected up to the main one.
Given that changing rail networks is a very rare event, I'm not sure that is actually the right decision. In order to avoid the performance hit the developers would also need to keep a "rail network ID" for each rail entity[1] -- at minimum an extra field in the backing class for LuaEntity. Which, given the Lua API, we can be pretty confident has a very similar "god object" model (or a cluster of related classes similar to it, I guess) in C++. That means the extra data will be carried for every entity in the game, even if not used. (I guess, maybe if they do things with unions internally, possibly shared total space, but still....)
Pipes have a fluid system ID. So your GOD object already has a space for this. I'm pretty sure there is also a electrical network ID but I've seen modded electrical rails so that one might not be free for use in rails.
slippycheeze wrote:
Wed Aug 28, 2019 7:16 pm
So.... given it seems like this only shows up temporarily, in a very rare (compared to everything else in the game), and human-triggered situation, I'm not sure I'd make the choice to spend extra bytes on this. Especially when the game is known to benefit dramatically from memory bandwidth optimization for maps at scale, and there are no particular reasons to assume any player would have any given number of networks, so I'd bet someone would hit the limit of a 2^16 rail network ID and complain.

After all, hard to beat the performance of a two-way track with one train in terms of avoiding things blocking your trains, so a base with nothing but those lines to move things is entirely conceivable. Might even beat out more complicated networks for performance. I should try that high level design some time. :)


[1] If they don't cache the network identity in the rail entity, they would need to walk the rail network when connecting things, which is going to have a cost proportional to the number of rail entities in all newly connected networks. Since your concern is optimizing a behaviour that scales with the size of the network(s)....
If you don't cache the network identity then the whole idea is pointless. Walking 1000000 rail entities when you add a new rail would kill the game.

Note: Rail network IDs would be quite useful to limit the stations you have to consider in the A*. Only stations with the same network ID as the train are candidates and a train with no candidates can show "No path" without even running A* and go to sleep till the network ID of it or a station changes.

But even besides that special "No path" case it should improve the A*. The algorithm needs a heuristic H(n) which gives a lower bound for distance to reach node n. In this case the distance to the nearest station. The closer that heuristic is to the real distance the better A* performs. Removing unreachable stations from the equation should improve the speed to calculate H(n) as well as improve the quality of H(n) for twice the benefit.

Post Reply

Return to “Ideas and Suggestions”