Friday Facts #148 - Optimizations for 0.14

[Engimage]

Nice to see optimizations, always a good stuff!

But as already mentioned - fluid handling is a really wanted feature. I sincerely hope you got enough time to implement it at least in 0.14

[kinnom]

Nice to see optimizations, always a good stuff!

But as already mentioned - fluid handling is a really wanted feature. I sincerely hope you got enough time to implement it at least in 0.14

might want to take a look at the concept art shown in FFF 146

[RobertTerwilliger]

Another thought about belt segments: you'll have to have some limit on segment length, finding "golden middle" between maximum performance gain from merging belts into segments at one hand, and on other hand, not having big lags when editing segments (as you probably know, we already have to split looong rails into segments with signals even for single train - because otherwise building such line becomes too laggy per edit - any rail added/removed - this is what we'll get if belt segment will be all the belt long)

[Gouada]

Is it me or have we not gotten FFF #149 yet? This might be the first time in ~1.5 years that we get a SaturdayFF

[vedrit]

Is it me or have we not gotten FFF #149 yet? This might be the first time in ~1.5 years that we get a SaturdayFF

They still have an hour, but... yeah, I don't think it'll be a Friday Fact this week

[madpav3l]

Well it's 3 minutes past midnight in Czech Republic and no FFF... I wonder when they will post it

[Blubberbub]

Another speed improvement could be (if you are not yet doing it) to make the belts not tick update when they are not needed.

So belt ticks are only requested when there is an update happening, like an inserter taking something from a belt (thereby updating all belts that lead into this one) or an item is added to a belt (the belt with the moving items will have to be kept in a list of conveyors that need ticks, because they are moving.

That would remove all ticks for empty or full belts and only update belts that are actually moving. And the searching for all belts that lead to a point can be made efficient with good data structures.

The optimization would be even easier, if the belts would not be controlled by blocking items, but by belts turning off, when the belt in front is full. Then you would only need to update 1 conveyer when something is taken from a belt and the item movement would propagate slowly through the net.

[kinnom]

Another speed improvement could be (if you are not yet doing it) to make the belts not tick update when they are not needed.

So belt ticks are only requested when there is an update happening, like an inserter taking something from a belt (thereby updating all belts that lead into this one) or an item is added to a belt (the belt with the moving items will have to be kept in a list of conveyors that need ticks, because they are moving.

That would remove all ticks for empty or full belts and only update belts that are actually moving. And the searching for all belts that lead to a point can be made efficient with good data structures.

The optimization would be even easier, if the belts would not be controlled by blocking items, but by belts turning off, when the belt in front is full. Then you would only need to update 1 conveyer when something is taken from a belt and the item movement would propagate slowly through the net.

That's already implemented for quite a while.

[Speiger]

Joined with this topic, cause it is just too special to be a useful suggestion. -- ßilk

Well this is all about this Friday Facts #148 and its more a help idea how to make that maybe improvement better.

Now before i start. I do not know in which language factorio is written (i heared that mods are written in lua) and the only language i am able to use (programming language) is Java... I failed with lua...
But i have a lot of logic ideas which are not bound to any program language xD
Note: I explain it in java lang if that will work with Lua no clue...
Also: I have issues with normal speaking/writing language so please try to ignore the language mistakes...
Edit: Also whenever you see a * symbol that means i added it after reading over the text so if something seem not fitting in text it was added afterwards...

Here is the idea from the Friday fact:

The idea was to simply put the belts int small belt collections and process these these groups instead of the indiviual belts.
But these would cause issues (listed here):
-How is the "other movable" logic meant to be handled for belts and splitters if they aren't going to be updatable
-Right now splitters operate by doing: move items on input lines -> split -> move items on output lines. How will this logic be done when the lines have no knowledge of the splitter or its mechanics?
-Who's responsible for saving transport line data?
-Custom render logic, so the segments draws it items in one go instead of individual items drawing them.
-How is save-load stability going to be maintained for merged transport belts? When a set of belts is merged runtime and then that data is saved how do we ensure the loaded and re-setup belts re-merge in the same way?
-Segment creating/merging/splitting logic. When belts are build/destroyed.
-How will migrations of belts in segment work?
-How will we handle underground belt connection distance changes between save load?
-And many others.

Now here is my idea. Its maybe not the best but it could solve a lot of your other problems you listed.

Instead of making them into 5-8 Belt chain, you could simply make them into a big chain belt.
What do i mean? I mena every belt that is connected to each other (input & output of these belts need to connect) will be added. Things like splitters & underground belts would not be added (underground could technically could be added), they would count as BeltChain Splitters and cause a start & end.
*The Belt chains would act as Local Processers that would only manage these belts and reduce passive calculation to its minium (thats the idea)

Now the Belt Chain does only 1 Thing. It processes the ticks of all the belts inside it, and keeps track of where the belt is stuck. For example: If all belts are full it will do nothing but as soon some drags items from it it will set the maker for where the last stuck position (so that nothing tries to be pushed) to that position where it is stuck. (It would even work with loops because when it is fully stuck in a loop then it would set to a number which is not found in a loop)
And if the belt is not fully stuck it would only try to move from the start position to the end or last stuck position.
*Same goes when all belts are fully empty. Maybe adding a LinkedList of all filled belts & it would iterate only these

Now to the points that werent solved yet:

Who's responsible for saving transport line data?:
There is nothing to be saved in the chain, the chain gets created by the belts when they got loaded/created and they would auto combine.
And since they have only 2 possible directions (simply 2 directions they could look) it would be not to much calculation

Custom render logic, so the segments draws it items in one go instead of individual items drawing them?:
Well the chain has a reference of all bellts in it (i didnt tell i know but that would be obviouse) and even in the right order from start to end (In java that would be a linkedList, that would be even used to check if the stuck last stuck position needs to be updated.) so it has access to all items for each belt & could render them all at once

How is save-load stability going to be maintained for merged transport belts? When a set of belts is merged runtime and then that data is saved how do we ensure the loaded and re-setup belts re-merge in the same way?:
Well since the Chain Logic is only for ticking(*/local Managing) there that means it does not need to save anything so that is not a problem then. And since there is always the same direction they look at that determens on loading the chains.

Segment creating/merging/splitting logic. When belts are build/destroyed.?_
I would also ask when rotated but here is the point i provide with my linked list. When you have a linked list you can simply get the point from where it is and then you have the part before and after and then you split the grids very fast. Same goes from grid combing. You have already 2 linked lists and make a third out of it. which is used for all the belts then.

How will migrations of belts in segment work?:
Well for that i would even require how you do belt movement in the first place but i would say with my idea: You have a lastStuck point (simply a number between -1 & beltchain size) and the movement calls will be called from 0 to lastStuck point (if it is -1) then it wont be. That beeing said: It is not improving the speed of single movements because you still have to call every belt to move its items but you have a lower check draw on each belt & you only call whats nessesary. So you delete a lot of unnessesary calculation while the code is still simple & modular
*Also the knowing if all belts are fully empty would prevent extra iteration through all belts. If you have like a 500 Belt chain it would save a lot of checking.

How will we handle underground belt connection distance changes between save load?:
Well either you handle them seperate from normal belts or you include them as 1 component of the beltchain....

And many others.?:
Well tell them to me. I made this system up when i went to my local store (which is 5 minutes in each direction) and this thing didnt leave me alone because it was something that interested me....
I would like to help a awesome game like this to improve itself...
Also i learned myself a bit of a new system that i can use myself for something...

I know my idea is not the best and it has its flaws but i had fun creating it and when it helps you even better.
My ownly wish is that the devs of it would answer me and give me their honest opinien of that idea.

It may or may not be that i forgot to type some important informations (because i do that without noticeing so if questions are open ask).

Thanks for reading Speiger xD

[cpy]

More speed more factories! YAY! Anyway i always have problem with entities, they cause most load when i check it.