When kovarex asks to add more tests

When twinsen spends a week digging some very rare bug

TheYeast All transport lines have only one exit. It can fork only with splitter. Some lines though may have several inputs (due to side-loading). So almost always it's a linear case, but yeah - there is first a recursion wave to reach the last active transport line, and then it all unwinds to do th...

Cool, I may have contributed to Factorio development. I would love to hear if this made a difference! Yeah, I know that feeling :) community helps a lot. There are many random things going on on forums but every 100th post has something in it that we can use. So keep it up :) Thinking about belt op...

By the way. I was thinking of belt optimizations and multithreading and came up with an idea and I want to share it with you. I was thinking about segmentation of belts, rails etc. And I read about your division of the map into chunks and tries to process them separately with some sync procedures. ...

<10% and 10%-30% are mutually exclusive and not part of the opinion ;). Assuming both numbers are correct, there must be different contexts, I'm just curious about those. 10-30% were with belts threaded. <10% was without belts threaded. in original unmerged form of belts (i.e. before recent FFF). S...

Yes, it's a circular buffer which dynamically grows as needed. std::deque splits everything in packs of like 16 bytes to maintain iterator persistence, so it was not an option (and we don't need iterator persistence here anyway). boost circular_buffer was avoided due to its fixed capacity which woul...

TheYeast A very good algo indeed! :) I was thinking into this thing with two ranges, but I was thinking of it in terms of range0 movable and range1 stationary which gave a problem that each time blocked belt starts moving due to last item leaving to next belt, I would have to iterate every single i...

Robots flying never were an issue, and yeah - apart from that travel prediction they can also be easily threaded when they fly for they hardly interact with anything. They just don't show up in profiler on flying even in single-threaded form. As for polarities - well, I never was pushing multithread...

Rows of chunks were considered at first, but this was declined because they will spread unevenly between threads. also there will be problems like having horizontal stretch of pipes going 1 thread vs. vertical getting into 8 threads, so overaly it will just make threads waiting each other for longer...

On that offset yes - I have logics like this for inserters already, so it may be applied to circuit networks as well. As for slowdowns - I don't think this will ever be an issue. Whenever something slow happens like once in 5 or 10 ticks, it's hardly noticeable. Also automatic merging will not be a...

On that offset yes - I have logics like this for inserters already, so it may be applied to circuit networks as well. As for slowdowns - I don't think this will ever be an issue. Whenever something slow happens like once in 5 or 10 ticks, it's hardly noticeable. Also automatic merging will not be an...

Moving the belt under items is essentially same as adjusting initial/final gap sizes - thing with those yellow lines. For circuits - when it's just reading counts - yes, it can operate on part of the belt. It's just that you have to iterate all previous items to get to that start offset that makes y...

Nican On ring buffer - in previous "slow" belts it was just an array due to at most 4 items per transport line. Updating 4 integers is faster or at least same-speed than doing all that ring-buffer logics for just 4 items. The new implementation has linear ring-buffer. As for turning that ...

I assume one of the big caveats for the performance increase on the belts is that, in order to render, you still have to calculate the absolute position of each item on the belt? That required some pre-sorting effort to keep it O(N) instead of O(N^2), but yeah - it makes me itching at times. one of...

Well, it's not "current" yet :) but better spread them evenly. As for per-surface threading - yes, we would go that way if Factorio would be natural to run multiple surfaces, and all those surfaces having a decent factory. Currently surfaces are only in mods, and main surface is still domi...

You should put that stuff you wrote there in a separate article, possibly even non-FFF one. I'm sure a LOT of people would be interested in reading it but only a few ever see it due to it being hidden in a thread full of mental mastrubation :) Yeah, we're thinking of that. For these questions were ...

A few notes: 1. Number of threads in Factorio options affects only number of prepare-render threads. It has nothing to do with update cycle. So zoom in maximally, better in window, better in like 720p to diminish effect of rendering on ups completely. 2. Ah, I see now that 60 gb/sec comes from quad-...

As for 60 Gb/sec - well, XEON is not common consumer product :) it's server die. They may even have semi-NUMA-alike tricks I mentioned above. 20 Gb/sec is kind of low-end for now, probably I should update my expectations to 30 Gb/sec. But so I need to do about average Ghz of ALU which has shifted fr...

That tool appears to be summing read throughput with write throughput. So it's around 25Gb/sec for read or for write, which is what I meant. As for Win10 task manager - it shows amount of memory used, not throughput :) Which means you have there around 2GB gamestate (1-1.5Gb is taken by DirectX). CP...