When placing inserters and power poles in a line, I am experiencing mysterious extra power poles being placed on some occasions. In this scenario I am placing inserters and then using my hotkey to change what I am building without letting go of the mouse button, and then sometimes letting go of the ...

When the factory is low on power, inserters are behaving very strangely. In this clip, the inserter is struggling to rotate back to pickup position in a way that is not expected. The pickup location has a belt that is filled sparsely with coal due to power being low. While the inserter is rotating ...

Create a new blueprint of landmines and only landmines in any configuration and set the blueprint to snap to grid with absolute positioning.

When placing the blueprint, the blueprint grid is rendered but not respected.

kovarex wrote: Thu Feb 11, 2021 7:42 pm Thanks for the report, it is now fixed for the next version.

YES!!111!!!

I never thought this was a bug, just a sort of limitation of copy/paste not being supported in the editor, so I never thought to report it. But this is a much loved bugfix from me!

I don't know if skipping concrete jobs entirely if concrete wasn't found is as straightforward as that. A single tile of concrete could be under two different roboport construction areas, and each area may or may not have concrete. If you want to short circuit all the concrete attempts, you'll have ...

I didn't want to get into complex solutioning as Rseding and other developers at Wube have demonstrated extraordinary skillsets and success in this area. I still would like this suggesting to be the simple idea of increasing the basic number of attempts per tick. I know that strikes most developers ...

I posted a suggestion to increase the processing rate for the construction bot job queue here: https://forums.factorio.com/viewtopic.php?f=6&t=94208

Even though this issue has been considered not a bug for a long time, I still think it's worth mentioning that some improvements are still viable ...

I have a suggestion to increase the processing rate for the construciton bot queue here (https://forums.factorio.com/viewtopic.php?f=6&t=94208). I wasn't thinking it was a bug so I created a feature request to change the rate at which it processes jobs in order to reduce the latency of the ...

Per tick performance right now is just checking one job for potential matches (bots available and item available). If you check 10 jobs for potential matches each tick, it'll probably be 10 times more.

My testing showed that performance is not entirely dependent on the number of failures. More jobs ...

Failed attempts are more costly because you have to try it again. Each construction bot job has inevitably 1 successful attempt and N failed attempts. When you have all the materials in the game and the bots can build anything at any time, the processing power required is minimal. When you place ...

Well, the thing about tweaking the scheduling algorithm is that the solutions presented are talking about determining whether or not a certain item has a certain trait or piece of data about it (little hope of being built). As far as I know, this doesn't actually exist. If you want to treat items ...

I did not have a similar experience as you ssilk. Poles and roboports were not prioritized and this is why players place skeleton blueprints that have only poles and roboports in 100% speedruns prior to placing all other entities.

Last night I did a test in my 100% planning practice. I changed the ...

Thue is correct in that it is between 1 and 3. I mistakenly added 1+3 assuming that it could have 1 failure and 3 successes in a single tick. But instead it is just 1 failure or up to 3 successes, but not both. Thue is also correct in regards to the failures being the main problem. If it stayed at 3 ...

I really appreciate this Kovarex. I can't even put it into words. I'm glad we can have the honor to continue to surprise you with new ways we can play

From my testing, I changed max_failed_attempts_per_tick_per_construction_queue to 200 and max_successful_attemps_per_tick_per_construction_queue to 200. Game update went from approximately 0.900ms to 1.00ms. I changed it from 200 back to 1, and it went back to 0.900ms. I then painted a large chunk ...

If increasing the bot queue causes significant performance, then I'm okay with not making the change. If we believe it *might* impact performance, but there is no actual evidence to support that, then I still push for it to be considered.

The thing about performance of the bot queue is...
* If you ...

"That would be one step closer to the "blueprint spraying" and so it is not going to happen"

IRT just the poles or the follow up recommendation of treating all buildings as "built" for the sake of placement of anything?

I am thinking the dragging of poles is a different case. It already takes into ...

Ah yes, the link Anti posted is the same issue. I thought I'd make a bug for it as it happens every time I play for years and hasn't been changed but since it is already reported and in the won't fix category, we can probably remove this one.

When placing undergrounds belts, it is sometimes the case that the player is left with their placement cursor being in the wrong orientation. Dragging an underground belt and then placing belts after is a common practice but in some cases the dragged belts are going the wrong way, leaving the user ...

In the current version, the system checks 10 (EDIT: CORRECTION, it checks between 1 and 3 by default depending on successes or failures) ghosted entities per tick to see if a construction bot is able to perform the job of building that entity. In many games players will have 1000s of ghosted ...