Hello,
if we have any circuit lovers reading, this is another dose of facts for you.
It might be useful sometimes, to send circuit signals over long distances. I personally never used it for anything, but when we were playtesting a while ago, Boskid insisted that we include circuit wires into our rail blueprints, because you never know when it might be useful.
I felt uneasy about it, because it goes against the coding principle of "write it when you need it", as it adds a bloat for something which might not even be useful later. But I understand, that if it actually becomes needed, it would be way harder to fix later.
This is how our rail system looked "just in case".
To avoid this dilemma, we added a long requested feature of wireless circuit transmission using Radars.
There are a lot of ways to do it, but we wanted to keep it simple. So we decided that there is just a single radar channel for each surface (still separated between red and green). This means, you don't have to configure anything, you just connect the wire and you are ready to go. If the radar loses power the circuit connection is severed.
Since all of the circuit network improvements have motivated me to use it more these days, I got annoyed more and more by this problem:
I want to move the bottom set of combinators, but if I do it with cut/paste, all the wires between the 2 parts will be lost, and I have to re-wire it.
It became so annoying, that I just had to add this quality of life feature: to make it so the blueprint remembers the outside circuit wire connections, and tries to reconnect them if possible. To minimize problems, these connections are only remembered when using the cut tool, and are not (and cannot) ever be transferred into the blueprint library or blueprint export string.
There's no such thing as "too fast" in Factorio. From the first machine placed, everything is about making them faster. Faster belts, faster inserters, faster assembling machines and speed modules to make them even faster. But that's not enough. Next you add beacons with speed modules, and then another and another.
But it's still not enough. It's never enough. Mods push the numbers even more and run into the limits of what the engine itself can handle.
It has been reported a 'few' times (69490 107571 60136) and every time we (I) said roughly the same thing: "crazy numbers get crazy results", "unless base game runs into this, we don't want to make the crafting logic more complex/fragile", "just don't do that, 1 craft per tick is fast enough".
But then Space Age happened with its legendary speed modules and all of a sudden it's a base game problem and it was time for me to "eat crow" and find a solution.
Conceptually it's a simple fix: loop the crafting logic if it needs to run faster than 1 craft per tick. But things are never that simple code-wise. Years of optimizations and features around assembling machines meant any changes done had a high likelihood of breaking something if I didn't fully understand what each line of code was supposed to be doing, and what it was actually doing.
After about 2 days of looking over the code, re-arranging, and writing comments explaining parts to myself, I had a plan for how I was going to make it work. The final changes to make everything function correctly took about 1 hour to write, and worked correctly the first try. That's not supposed to happen and left me with doubts. Several extra tests later, and asking Boskid to try to break it, it was confirmed to be correct.
The 2 days of analyzing and understanding the existing code paid off!
A legendary foundry crafting at a swift +2500% speed, completing 4.33 crafts per tick.
The underlying issue has been fixed and (as far as I can tell) the only limit on how fast they can craft now is how many ingredients the machine has and how much space is available in the output slots.
As always, wirelessly transmit your thoughts to us at the usual places.
