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]

Self removed

[cpy]

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