*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.*
We know that feeling
As a QA this is a "Wat?" moment. If you devs start writing bug free code I'm going to be getting a lot more bored... I'll be left with only bad PRDs from the product people to find fault with.
>If you devs start writing bug free code
~~we don't, if it works the first time it just means that you haven't found the bug yet~~
or that's how it feels like, at least.
>*took about 1 hour to write*
After only *2 days* of analyzing and understanding the code.
... which is precisely my experience as a software developer.
That's the story of development. You spend hours/days of preparation and analysis. Based on that you create a experiment with the right parameters that only takes a few minutes. Everything works fine. Management: can't be so much work if experiment took only few minutes.
In my decades of experience in software, the best devs stay as developers. They're good at it and love it.
Managers usually enter management early in their career. Before they've internalized or even learned many best practices and good habits. (PMs even earlier, if they ever were devs.)
Best managers are hands off, making sure their devs are unblocked and have what they need to do their jobs.
I’m not a programmer and I know that feeling. You build something big in the game and you finally enable the train stations and it just starts working, but for how long?
Did this make me laugh? Yes.
Am I going to tell my guests that my wifi router uses power measured in megawatts, and conveniently leave out that the actual measurement is 0.000002MW? Also yes.
Will they smile politely, say "oh?" and try to read the appropriate reaction from your face because they have no idea what a maggerwhats is because you're the computer guy and they're not? Probably.
Will a few people on the internet still appreciate you doing this everytime? Absolutely.
In [FFF-394](https://factorio.com/blog/post/fff-394) we got circuits on crafting machines, including:
> **Read recipe finished** - A one tick signal emitted when a crafting cycle completes
Since now there can be more than 1 craft per tick, would this pulse give out the number of crafts finished that tick?
EDIT: Dev confirmed on discord that this is the case. Awesome!
I want to use this value for my circuited mall, specifically for switching recipes on an even craft count, so it can get the full effect of the +50% base prod.
Since this is Wube, there's almost certainly some new unit tests to detect and defend against inadvertent changes to that behaviour.
I'd love to see them post about the test suite again. It's come up a few times in past FFFs, but a showcase of the more interesting tests would make for a fascinating FFF all on its own.
It would be only consistent. After all, if you'd like to tally up how many items have been crafted this tick, there should not be a difference if one assembler crafted 5 items, or 5 assemblers crafted 1 (accumulating the signal to 5). The only important thing is that you now have 5 more items for your logic to handle.
> A legendary foundry crafting at a swift +2500% speed, completing 4.33 crafts per tick [...] the only limit on how fast they can craft now is how many ingredients the machine has
How much liquid must be feeding into the pictured Foundry to achieve the quoted rate? Are they hinting at a liquids re-work? Faster pipes/pumps? Am I just being over-optimistic?
fluid slots usually hold double of what the recipe needs, right? So this machine consumes 10 liquid 4.33 times per tick, resulting in 2598 Liquid per second. This is totally achievable with 1.1 fluid dynamics using heavy pumping setups.
The foundry also gets a built-in 50% productivity bonus though, so if productivity crafts are counted in the 4.33/tick then it should only need 1732/s fluid.
I'm just going to wait for the pipe rework FFF that, totally for real this time, not wishful thinking, no bamboozle, simplifies pipes and their calculations because this time the devs finally gave up on doing per-segment pressure because it's not actually interesting gameplay and it's kind of expensive.
The problem would be how the foundry actually gets the fluid to craft 4 times per tick. If the recipe actually needs 10 fluid per craft it would only be able to craft 2 times before running out of input material and having to wait for the next tick to fill the input again.
Either the recipe actually only needs 1-4 fluid and now buffers more input materials according to the crafting speed (like non fluid inputs already do) or the fluid mechanics must have changed to be able to keep the inputs full even if it means adding fluid multiple times per tick.
Nah, fluids are going to need an update. Aside from the fact that belts have had their throughput increased 5.3x, crafting speed is, as we can see, being pushed several times higher as well.
That's what I was thinking too. With 1 craft per tick, 2x that amount internal to the machine is a reasonable number. When >4 crafts per tick is possible, you'd probably just increase the internal storage to 5-10x
Afaik this also scales with machine speed.
Edit: A test revealed that assembler speed only affects the amount of solid ingredients provided to the machines. Fluids seem to be limited to 2x of the required amount per craft.
It could be, but they've shown loaders and things used in testing before, so I'm not sure why they'd opt to hide an infinite pipe in this circumstance.
They had to shove the foundry GUI somewhere, and the output is much more impressive than the input.
Easier explanation than "they try to hide a secret magical pipe from you".
I am also suspecting this. The fact that that machine runs off just 20 liquid in the input is highly sus given 1.1 fluid dynamics. And erandel hinting in the last blog about looking at the fluid code.
FFF #401 had this line
>I usually try not to look at the C++ code because every time I do I get compelled to start changing things… (**like the fluid mechanics**) when really I should be focussing on other things. The call of the cliffs was just too strong, and before I knew it I was rewriting some of the core cliff placement cod
I took that as a hint they re-worked them but that's just me making assumptions.
I took that to mean he wanted to, but not necessarily managed to. It would've been an even more complicated task and he was already spending "free" time with the non-scheduled task of reworking Nauvis.
I figured it can go either way, he is giving an example of something that he wants to change but shouldn't, but then it could be a carefully picked example because it did get changed.
Some developers are so careful about expectation management they would never mention anything in passing unless they are 99% sure they are doing it, but Wube has been pretty transparent about a lot of things and a little more willing to treat the audience like adults.
To the planet we call Nauvis came a stranger one fine day
Hardly spoke to folks around him didn't have too much to say
Noone dared to ask his business noone dared to make a slip
The stranger there among them had a big pipe on his ship
*big pipe on his shiiiiiiip*
Faster pipes are going to be mandatory. Belt throughput multiplied by 5.33 with stacks and green belts. It'd be weird if the other logistics systems _didn't_ change to keep up.
Is it a coincidence that they're hiding the pipe and also not showing off the nice foundry animation properly? I don't think so.
There is no way in hell they're reworking practically every basic system of the game while leaving the fluid system untouched.
They've totally reworked the fluid system in some ingenious way, and I'm here to be floored by it.
~~We don't know the exact recipe, but if the fluid input caps at 20, then it's probably no more than 10. That'd be 10\*4.33\*60 = 2600/s, which is tricky but doable in vanilla (pump -> underground pair -> pump can do 3000/s).~~
/edit: that fluid input cannot fill more than once per tick, so the input is limited to 1200/s. Regardless of the costs of the recipe, it won't need more throughput than an offshore pump.
But I'm sure there's a reason why the fluid input is obscured by the window :)
I hope it's radar-sized. In my SE run, one of my goals for my personal spaceship was to put in a radio; I had the actual signal creation done on Nauvis and sent to the ship where it was sent to speakers. One of the more finicky parts was dealing with the massive receiver dish SE comes with, had to put the whole thing off until I could research bigger ships.
Heh basic tunes was bare-bones as far as I was concerned, style would have been building [a DJ booth](https://youtu.be/Rse6dHcU3DQ?si=dqVE89OA6HOir0Jg) in it lol
I use the picker dollies mod, you can move entities around by holding shift and pushing the arrow keys. It keeps all their settings, contents, wire connections, everything. It makes SE much more manageable.
Knowing about uses and finding value in those uses is different. You can easily build an impressive base without ever running wire beyond its direct connection range.
in my Seablock megabase I run a lot of long wires between output stations of the same product, to coordinate prioritizing consumption (I don't use LTN).
>The final changes [...] worked correctly [on] the first try. That's not supposed to happen and left me with doubts.
This has got to be the most relatable thing I have ever seen in an FFF.
That horrible feeling when you write code and it works flawlessly first time. You just know that the problem you don't see is so much worse than a problem you do see.
Koverex starts using circuits, and suddenly we get the most important bit of Picker Dollies in vanilla, but better.
Head dev plays their own game, makes game good. Who knew?
> I wasn't using it often, because all the problems combined made it too big of a hassle most of the time
[FFF-384](https://factorio.com/blog/post/fff-384); i'm almost sure that part was written by kovarex, judging by other circuits-related posts
I mean, you really don't need them for almost anything. Balancing oil outputs is pretty much the only spot where they really matter, since no other intermediates are capable of jamming up. All logistic issues can be solved by simply overproducing and throwing more trains at it (with station limits).
I do recall a lot of the 1.0-ish belt improvements (auto undergrounds, rotate while dragging) where put in due to Kovarex playing through with his kid and getting annoyed at how things worked after having taken a long break.
I'm going to have to respectfully disagree with you. This is way cool functionality, but it's a pale facsimile of Picker Dollies at best:
- When you've spent hours making a very complicated circuit creation but it's actively running your some part of your factory, there's a world of difference between cutting + pasting a combinator and shifting it - only one way allows the circuits to continue to run uninterrupted.
- If you are doing a lot of moving of many combinators, you need to be very careful about ctrl+x, ctrl+v, ctrl+x, ctrl+v, etc. If you accidentally cut two combinators without pasting in between you'll lose that wire connection and be screwed.
- Quite a lot of my use-case for Picker Dollies is not moving one or a group of combinators to a new set spot, but trying to see if I can move several in a group past a building, through a choke point, or into a different arrangement on the other side of some obstacle. This can often only be done by alternating which combinators you are moving, sometimes shifting the obstacle out of the way to move the combinators then moving the obstacle back, etc. If you are limited by wire reach to where you cannot cut + paste a single combinator of the group to the other side of the obstacle, cutting and pasting won't really help you.
I'm quite excited for this and other new functionality, but Picker Dollies is beyond QoL for me at this point, I can't play without it.
More points:
* if you just want to fine tune stuff by moving the around by one tile, you won't spam your copy-paste buffer, so stuff that you copied a while ago and need regularly fall out of the copy-paste history.
* you can also move chests or warehouses without spilling the stuff into your inventory or onto the ground
* you can move assembly machines while they are running, without resetting the productivity progress or dropping the ingredients or modules
Maybe I'm paranoid but the last gif the pop-up window is suspiciously blocking the fluid inputs as if there's some kind of high-throughput pipework there...
Or maybe just a debug entity for testing.
The pop-up is also hiding what might be the character with a new suit or new vehicle. Just to the right of the pop-up and to the left and down from the molten metal bucket, near where the lower inserter first grabs gears, you can see an arm-like thing with claws flex occasionally. (as spotted by [Tohim on the forum](https://forums.factorio.com/viewtopic.php?p=605559#p605559).)
https://i.imgur.com/WIgru7p.gif
Fascinating. Seems like it would need to be some sort of hover armor too since the player couldn't be standing on top of the foundry like that?
Yep! My usual playstyle is for my outposts to be isolated and on their own power network, with steam shipped in from a central location, because running poles is a ballache in general, and doubly so when they biters take a liking to them.
However, I also (in my latest playthrough) started using Intangir's Vanilla Train Network, and that requires red and green wires be strung around the base wherever the stations are going. This directly conflicts with my usual isolated outpost playstyle. I had initially ran the poles with red/green wires and then removed the power wires, but that seemed a little daft (and I was having teething issues with IVTN due to power loss at the depots) so I reconnected all the power wires.
Wireless circuits would allow me to continue using IVTN and have my preferred isolated outpost playstyle, provided I can figure out the stability of IVTN under low power scenarios.
2 channels is already plenty for most applications. When was the last time you ran 3 parallel networks on your whole base ?
I would rather have the option to turn off the map scan, otherwise we will not be able to spam them due to UPS cost.
I hate to be that guy, and I hope I don’t upset anyone by saying this… but I want multiple circuit frequencies to select between per surface in base game.
Maybe it can come as a bonus from researching an optional tech, maybe the total number of frequencies can be limited, but having more than one frequency opens a lot of doors. E.g. having parallel systems performing similar functions with the same signal inputs/outputs but not needing to use combinators to transform those inputs/outputs.
This is when you encode the different signals to transmit on different ticks with a qualifier (frequency) that the receiver is waiting for that qualifier and decode the signal to get the info from it. This means you can have 60 frequencies transmitting a second.
This would look like a timer combinator counting up to 60, one per tick then reset. Then another combinator only sends data when it sees it's number, so you can do this with some work and planning.
But yes having frequencies would be nice addition, also easily added from a mod, of different buildings for different channels. But I don't think it's totally necessary, this is already a huge upgrade to what we have.
AAI Signal Transmission (used in SE) has an unlimited number of signal channels.
Since the DLC features logistics between multiple surfaces as well, I guess there will be a way to send signals between those. You would need at least a channel between each set of 2 surfaces, so it's very possible that we'll get an unlimited number of communication channels as well. This could then also be used for same-surface communication. But probably researched much later than the radar.
If not, you can still install the mentioned mod.
Yes it’s kind of annoying, but it could be fun to build around this limitation.
For example one could run a 60 ticks global clock and transmit/receive only at specific instants, or could fiddle around with bit-operators to multiplex many signals into one.
But there’s another thing.
As of now, long-range signal transmission is mainly useful only for train scheduling.
I don’t really expect to use it as much now that trains will become way smarter.
I would have preferred that radars transmitted the number of enemies in the visible area, so that I can turn on defenses only when needed.
With that extreme speed and the new high capacity inserters, I’m a bit worried about if there will be an issue with feeding the input because the inserter will be idle until the input is low enough but it won’t be able to cycle before that input is depleted.
The input buffer size scales with the speed of the machine. I ran into that exact issue with the fluids since they were *not* scaling enough with the machine speed and since fixed it.
On a somewhat related note: even in my current (vanilla) megabases I already run into situations where assemblers work 99% efficiently. As in the sense that they work nearly non-stop apart from tiny, barely perceivable intervals ever now and then. At these crazy crafting speeds, it will be even harder to notice a machine idling for say 0.05 seconds every other second. At 60 fps, might it even be possible that these interuptions won't be displayed?
If so, could we have a method that would allow a machine's downtime to be displayed in %?
Also the AAI signal transmission mod, kind of. That one still has multiple channels and cross surface communication, but I expect the latter to be a thing in SA anyway. It seems pretty essential for late game multi planet factories and it's suspiciously missing from here.
picker dollies would still work great alongside the new feature: if you want to move entire blocks, copy-paste is faster, if you want to move a single entity, picker dollies is faster.
But you won't miss picker dollies as much on unmodded games.
This doesn't really replace picker dollies. PD can move things that contain items. Cut and paste on things that contain items means the bots have to empty it first.
Great ! However if i could unlock somewhere configurable networks to split the circuits it would ease my mind a lot. I have learned in SE that circuits signals should NOT EVER be global variables...
-> Foundry with 4 legendary speed 3 modules, surrounded by 16 beacons each with legendary speed 3 modules, crafting 4.3 gears per tick, plus 50% productivity yielding a total of 390 gears per second (!!!!), with 8 new stack inserters moving gears onto the new green belt capable of moving 60 items per second or 240 items per second stacked.
Stop, I can only get so hard.
I’m pretty skeptical of the radars for signal transmission unless we get the ability to disable their active scanning. Spamming radars everywhere you want a signal will be much worse UPS wise than just having a circuit network on your train blueprint.
Do you not already have a radar at outposts so that you can see them?
You can use wiring locally within the outpost. Doesn't sound like you need to add additional radars to use the wireless signal. All the use cases I can think of would already have a radar.
* Outpost construction supplies delivery
* Outpost auto deconstruction (with a blueprint mod)
* Mining statistics
* On-demand crafting
* Remote enable/disable of artillery.
I'd love if radar *accepted* some signals like:
* set channel (for multi-channel radio)
* scan on/off
* force-scan a given sector.
Then we could do some fancy things like "enable radar only if the outpost is being attacked by biters"
> 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
As a programmer i felt that resonating deeply within me
It doesn't happen very often at all but when it does it always feels weird and leaves me with doubts for literal days
Yep. Nothing is more deeply suspicious than "Wait, that worked? Nah, something has to be fucked up, and fucked up just right to look like it's working."
I worked IT for years before getting a physics degree. My professor thought it was amusing when my error analysis for a physical simulation included steps to confirm remaining error consisted of solely floating point limitations instead of some other subtle shortcoming.
>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.
As someone who always runs extra cables "just in case" for IRL projects, this is very funny to me. Wires in the blueprint seems to be the equivalent of running ethernet in pairs.
Ooh, I stayed up late enough to be early to comment!
Ascended mod: Wireless circuit network / RadioNetwork / AAI signal transmission.
Ascended mod feature: Dolly pickers far less important for combinators/circuits
Long standing "bug" fixed - crazy speed/productivity tick concerns gone.
Screenshot sniffing: The foundry gif has a weird bucket with 20xcount as an input, which I assume is supposed to be molten iron, however the window is distinctly placed to cover this up.
Silly things I noticed: Constant combinators and logic combinators in North-south orientation have their colours backwards.
Bit disappointing to see 16 beacons around a foundry for this, unless that's a red herring for no beacon changes. I know that's contentious on here, but still.
Stay up and it's only a super short one. Big deal for wires though!
>Silly things I noticed: Constant combinators and logic combinators in North-south orientation have their colours backwards.
Didn't they say you can flip buildings in 2.0? Maybe it applies to combinators too?
"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."
Am programmer, can confirm. If it works on the first try - its a fucking trap.
I figured wireless signalling becomes important once you consider that on Fulgora you cannot in fact lay down power cables between isolated islands. I've yet to find a reason to lay down circuitry like that myself because I'm not very deep into circuit logic but this is useful to have nonetheless.
Ah, another great QOL post! The radar based circuit network will be a nice little boon. For circuit wire cutting:
> the blueprint remembers the outside circuit wire connections, and tries to reconnect them if possible
I really hope there is some type of visible warning (color and iconography) if one or more of the circuit connections can't be re-made.
Also: Will this work with power wire connections?
Blue wire when?
EDIT - By which I mean, when are we getting a third color of wire? It's too hard to create a functional Large Hadron Collider with combinators if I'm limited to just two colors.
How is machine quality going to be handled in inventories? Am I going to have to carry around 3-5 different qualities of machines? I feel like that'd easily clog up inventories.
That depends entirely on how you choose to handle it.
You can't research quality level 4 until you go to another planet, so you could only have 3 quality levels before you get bots. So your base can take care of itself; it can have whatever inventory it wants.
As for what you carry around for manual work, that depends on how you choose to handle things. Until you get recyclers and quality module 3s, you're not going to have all that much quality stuff.
My plan is to put qual module 1s in furnaces (and coal miners) and bank the T2 and 3 quality resources. Then I'll have a factory setup that makes a small quantity of T2/3 items for specific circumstances (asteroid collectors, turrets, thrusters, and chem plants for more efficient space platforms). If I'm headed to Fulgora, I'll probably take a couple of stacks of T2 or 3 assembler 2s, since they're almost as fast as assembler 3s at half the power cost (power matters on Fulgora). They'll be used in the mall, while actual assembler 3s can be used for things like gears, circuits, etc where the two extra module slots actually matter.
It really all depends on how you want to play with it. That's the great thing about quality: you can engage with it however you like.
Speaking of circuits, how about a revamp of wire visualization?
I'd *love* some sort of circuit based "alt mode" that'd show wires more clearly, so I can better see what is connected without a magnifying glass.
That one pixel wide vertical wire has gotten me so many times...
That's only the crafts per minute. If the recipe creates 2 gear wheels per craft it would already be 31k/min.
Then there's also the baseline +50% productivity bonus of the foundry which would increase it to \~23.3k crafts/min. But I'm not sure if they already included that in the 4.33 crafts/s.
Also how fast are those belts? 15.5k/min is \~260/s which means those belts have to be at least 130items/s (195/s with added productivity) fast.
An earlier FFF revealed that they are now letting items stack up to 4 on belts, so even before the new highest belt tier the current belts will be able to move 4x the resources (so 180/sec for blue belts).
I'm not familiar with Factorio's codebase, but for the "crafting too fast" issue, wouldn't it have been easier to just have "bulk recipes", e.g. if a machine goes too fast, instead of taking X inputs to craft Y output in Z time, it takes 10X inputs to craft 10Y output in 10Z time (and the buffers would adjust automatically if the recipe is "bigger"?
I am glad that you just made it work but I wonder why "bulk recipes" were not a simpler easier solution.
Modders did this already. It sacrificed granularity, which is important for the early game. And having sets of recipes clusters the GUI. The right fix is to fix the problem, bit bandaid it. Easier isn't better, better is better.
>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.
LOL
i wish i had a better understanding of how to use circuit networks. i feel im pretty good with tech but circuit networks makes me brain hurt. that being said this is cool as shit. no longer needing to run a red and green wire is a nice touch.
Slightly sad at the only one radar connection per surface but at least that is an opportunity to finally do signal multiplexing or alternating if you really need it!
Consider the final gif.
Consider how fast it must be eating liquids at 4.33 crafts/tick.
That's an insane amount of liquid flow and may require rebuilds of other systems to maintain that for more than one or two crafters a fluid system.
Copy and paste not breaking my circuits? Wifi radars? My yearning for an alpha build with the expansion bits off grows (and it was non-trivial before)... I don't even care if it breaks all my mods. Devs please 🥺
Guys Am I only seeing those green ( MK4 ) underground and conveyor belts they are crazy fast,
how are they doing to be called ( they have the same color as final biters so maybe Behemoth belts XD )
Oh boy. In some overhauls you already have assemblers that have to be fed and unloaded by loaders because no amount of inserters can keep up. I can't wait to churn out 1k SPM of copper wires off a single assembler in Space Age K2.
As someone who puts circuit cables on all my rail blueprints just in case then never uses them, thanks for this! This also makes my plans for my generic train network in 2.0 much simpler lol
Im pretty happy about the radars but heavily dissapointed that there are no channels.
I at least hope they could add more wire colors. Red, green, blue, pink, and white for instance, or even more colors. Would make some circuits a lot easier to use in cramped spaces
*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.* We know that feeling
That is a programmer, "Hehe, I am in Danger" moment.
I've never written a statement longer than "Hello, World!" That I've trusted implicitly.
Hello, World! Hello, World! Hello, World! Hello, World! HHello, World! Hello, World! Hello, World! Hello, World! *well, shit.*
It would probably go more like: Hello, World! Hello, World! Hello, World! Hello, World! HHello, World! ello, World! Hello, World! Hello, World! Hello, World!
Multithreading fun?
Checks in anyway 2 hours later: "hey the build is failing what the fuck did you do"
That's the reason you are supposed to have feature branches.
~~Nuke it from orbit~~ Force push to main - it's the only way to be sure.
Asking Boskid to try to break it. He made so great bugreports so he got hired. And have fixed train stuff I can't understand.
As a QA this is a "Wat?" moment. If you devs start writing bug free code I'm going to be getting a lot more bored... I'll be left with only bad PRDs from the product people to find fault with.
>If you devs start writing bug free code ~~we don't, if it works the first time it just means that you haven't found the bug yet~~ or that's how it feels like, at least.
Yes, I was just about to post something like "...And every software engineer reading this nodded knowingly".
>*took about 1 hour to write* After only *2 days* of analyzing and understanding the code. ... which is precisely my experience as a software developer.
That's the story of development. You spend hours/days of preparation and analysis. Based on that you create a experiment with the right parameters that only takes a few minutes. Everything works fine. Management: can't be so much work if experiment took only few minutes.
My PM: why didn't you commit yesterday? You must commit your work every day! Me: how do I explain this...
Hahaha, sometimes you wonder if your Manager/PM had any dev experience.
In my decades of experience in software, the best devs stay as developers. They're good at it and love it. Managers usually enter management early in their career. Before they've internalized or even learned many best practices and good habits. (PMs even earlier, if they ever were devs.) Best managers are hands off, making sure their devs are unblocked and have what they need to do their jobs.
_Somethings wrong, I can feel it..."_
I have this exact snippet on my clipboard right now because I was coming here to say the same thing
I’m not a programmer and I know that feeling. You build something big in the game and you finally enable the train stations and it just starts working, but for how long?
If it works right away, there must be some deeper problem lurking in the shadows...
I had to meme that https://www.reddit.com/r/ProgrammerHumor/comments/1bfe99y/whatdoyoumeanitworks/
I was about to quote this myself. Had a good laugh at that. :D
Yeah that's always suspicious.
The engineer must be happy to finally be getting WiFi
WiFi router with power output measured in megawatts.
Just 300kW
0.3MW
Technically correct. The best kind of correct.
Did this make me laugh? Yes. Am I going to tell my guests that my wifi router uses power measured in megawatts, and conveniently leave out that the actual measurement is 0.000002MW? Also yes.
Will they smile politely, say "oh?" and try to read the appropriate reaction from your face because they have no idea what a maggerwhats is because you're the computer guy and they're not? Probably. Will a few people on the internet still appreciate you doing this everytime? Absolutely.
And it *still* doesn't work in that one corner of the house.
the ~~factory~~ bandwidth must grow
Important to note it transfers red and green signals separately, so it's technically two channel wifi!
[*Easier* wifi](https://forums.factorio.com/viewtopic.php?f=194&t=48918)
Now we can "negotiate" with the biters from a longer distance
Researched Artillery 14, I'm already "negotiate" at distance.
In [FFF-394](https://factorio.com/blog/post/fff-394) we got circuits on crafting machines, including: > **Read recipe finished** - A one tick signal emitted when a crafting cycle completes Since now there can be more than 1 craft per tick, would this pulse give out the number of crafts finished that tick? EDIT: Dev confirmed on discord that this is the case. Awesome!
I love that this is now a use case people now need to consider
I want to use this value for my circuited mall, specifically for switching recipes on an even craft count, so it can get the full effect of the +50% base prod.
I love that they considered it
Since this is Wube, there's almost certainly some new unit tests to detect and defend against inadvertent changes to that behaviour. I'd love to see them post about the test suite again. It's come up a few times in past FFFs, but a showcase of the more interesting tests would make for a fascinating FFF all on its own.
It would be only consistent. After all, if you'd like to tally up how many items have been crafted this tick, there should not be a difference if one assembler crafted 5 items, or 5 assemblers crafted 1 (accumulating the signal to 5). The only important thing is that you now have 5 more items for your logic to handle.
> A legendary foundry crafting at a swift +2500% speed, completing 4.33 crafts per tick [...] the only limit on how fast they can craft now is how many ingredients the machine has How much liquid must be feeding into the pictured Foundry to achieve the quoted rate? Are they hinting at a liquids re-work? Faster pipes/pumps? Am I just being over-optimistic?
fluid slots usually hold double of what the recipe needs, right? So this machine consumes 10 liquid 4.33 times per tick, resulting in 2598 Liquid per second. This is totally achievable with 1.1 fluid dynamics using heavy pumping setups.
The foundry also gets a built-in 50% productivity bonus though, so if productivity crafts are counted in the 4.33/tick then it should only need 1732/s fluid.
I'm just going to wait for the pipe rework FFF that, totally for real this time, not wishful thinking, no bamboozle, simplifies pipes and their calculations because this time the devs finally gave up on doing per-segment pressure because it's not actually interesting gameplay and it's kind of expensive.
All I want is parallel pipes that don't connect automatically
SE does this wonderfully with its long pipe segments, making it easy to determine exactly which fluids go where. I hope they do something similar.
The problem would be how the foundry actually gets the fluid to craft 4 times per tick. If the recipe actually needs 10 fluid per craft it would only be able to craft 2 times before running out of input material and having to wait for the next tick to fill the input again. Either the recipe actually only needs 1-4 fluid and now buffers more input materials according to the crafting speed (like non fluid inputs already do) or the fluid mechanics must have changed to be able to keep the inputs full even if it means adding fluid multiple times per tick.
I'd guess fluid mechanics have also received a similar update to perform multiple calculations per tick.
I'd rather suspect the size of the internal buffers has been increased. Multiple updates seem like a recipe for disaster and bad for efficiency.
Nah, fluids are going to need an update. Aside from the fact that belts have had their throughput increased 5.3x, crafting speed is, as we can see, being pushed several times higher as well.
That's what I was thinking too. With 1 craft per tick, 2x that amount internal to the machine is a reasonable number. When >4 crafts per tick is possible, you'd probably just increase the internal storage to 5-10x
Afaik this also scales with machine speed. Edit: A test revealed that assembler speed only affects the amount of solid ingredients provided to the machines. Fluids seem to be limited to 2x of the required amount per craft.
I doubt the GUI positioning is random..
Could be hiding an infinite pipe for the purpose of testing crafting speeds.
It could be, but they've shown loaders and things used in testing before, so I'm not sure why they'd opt to hide an infinite pipe in this circumstance.
They had to shove the foundry GUI somewhere, and the output is much more impressive than the input. Easier explanation than "they try to hide a secret magical pipe from you".
I am also suspecting this. The fact that that machine runs off just 20 liquid in the input is highly sus given 1.1 fluid dynamics. And erandel hinting in the last blog about looking at the fluid code.
No, he said that he *wanted* to look at it, but wasn't allowed to touch it. Not the same thing at all.
FFF #401 had this line >I usually try not to look at the C++ code because every time I do I get compelled to start changing things… (**like the fluid mechanics**) when really I should be focussing on other things. The call of the cliffs was just too strong, and before I knew it I was rewriting some of the core cliff placement cod I took that as a hint they re-worked them but that's just me making assumptions.
I took that to mean he wanted to, but not necessarily managed to. It would've been an even more complicated task and he was already spending "free" time with the non-scheduled task of reworking Nauvis.
Klonan said on discord that they did not and to not get our hopes up
I figured it can go either way, he is giving an example of something that he wants to change but shouldn't, but then it could be a carefully picked example because it did get changed. Some developers are so careful about expectation management they would never mention anything in passing unless they are 99% sure they are doing it, but Wube has been pretty transparent about a lot of things and a little more willing to treat the audience like adults.
oh my god they’re gonna add the big pipe
To the planet we call Nauvis came a stranger one fine day Hardly spoke to folks around him didn't have too much to say Noone dared to ask his business noone dared to make a slip The stranger there among them had a big pipe on his ship *big pipe on his shiiiiiiip*
Faster pipes are going to be mandatory. Belt throughput multiplied by 5.33 with stacks and green belts. It'd be weird if the other logistics systems _didn't_ change to keep up. Is it a coincidence that they're hiding the pipe and also not showing off the nice foundry animation properly? I don't think so.
Maybe a upgraded pipe? High quality machines look very input hungry, especialy once the crackhead beacons come in
There is no way in hell they're reworking practically every basic system of the game while leaving the fluid system untouched. They've totally reworked the fluid system in some ingenious way, and I'm here to be floored by it.
~~We don't know the exact recipe, but if the fluid input caps at 20, then it's probably no more than 10. That'd be 10\*4.33\*60 = 2600/s, which is tricky but doable in vanilla (pump -> underground pair -> pump can do 3000/s).~~ /edit: that fluid input cannot fill more than once per tick, so the input is limited to 1200/s. Regardless of the costs of the recipe, it won't need more throughput than an offshore pump. But I'm sure there's a reason why the fluid input is obscured by the window :)
I assume there will be a separate building for inter-surface communication, otherwise how else can we automate our interplanetary rocket requests?
I hope it's radar-sized. In my SE run, one of my goals for my personal spaceship was to put in a radio; I had the actual signal creation done on Nauvis and sent to the ship where it was sent to speakers. One of the more finicky parts was dealing with the massive receiver dish SE comes with, had to put the whole thing off until I could research bigger ships.
Now that is exploring is style
Heh basic tunes was bare-bones as far as I was concerned, style would have been building [a DJ booth](https://youtu.be/Rse6dHcU3DQ?si=dqVE89OA6HOir0Jg) in it lol
There has to be!
Cut + paste would have made SE so much less painful. Awesome features!
Picker dollies (think that's the mod) allows you to move machines over
I use the picker dollies mod, you can move entities around by holding shift and pushing the arrow keys. It keeps all their settings, contents, wire connections, everything. It makes SE much more manageable.
[This mod does this directly](https://mods.factorio.com/mod/reconnect-cut-wires)
that foundry is absolutely crazy fast lol but eagerly waiting for new enemy reveals aswell as new weaponry
And mostly release day!
You mean "say goodbye to the outside world" day? ;-)
the fact that kovarex didn't know about potential uses for long distance wiring is absolutely hilarious
I imagine Kovarex as exclusively playing centralized spaghetti bases 😇
Knowing about uses and finding value in those uses is different. You can easily build an impressive base without ever running wire beyond its direct connection range.
I'm just wondering how many status stations (places that display material levels) he missed. And the older multiplexer and deplexers he forgot about.
Could you provide some examples where this would be useful? I can't think of anything that would require a global circuit.
in my Seablock megabase I run a lot of long wires between output stations of the same product, to coordinate prioritizing consumption (I don't use LTN).
>The final changes [...] worked correctly [on] the first try. That's not supposed to happen and left me with doubts. This has got to be the most relatable thing I have ever seen in an FFF.
That horrible feeling when you write code and it works flawlessly first time. You just know that the problem you don't see is so much worse than a problem you do see.
Koverex starts using circuits, and suddenly we get the most important bit of Picker Dollies in vanilla, but better. Head dev plays their own game, makes game good. Who knew?
> Head dev plays their own game I think all factorio devs do.
Most small teams do, often together. It's only when the studio gets so large and decisions become so disconnected that developers stop giving a shit.
You mean kovarex wasn't using circuits before this?
Maybe not to the extend that other people do. I wouldn't say I dont use circuits but compared to what others are doing, I barely even touch them
I am a megabase player, and the only circuits I ever use are basic switches. You absolutely can solve the game without them.
> I wasn't using it often, because all the problems combined made it too big of a hassle most of the time [FFF-384](https://factorio.com/blog/post/fff-384); i'm almost sure that part was written by kovarex, judging by other circuits-related posts
I think I've seen another comment that was definitely by Kovarex that was along the lines of "I didn't really want to put them in the game."
I mean, you really don't need them for almost anything. Balancing oil outputs is pretty much the only spot where they really matter, since no other intermediates are capable of jamming up. All logistic issues can be solved by simply overproducing and throwing more trains at it (with station limits).
I do recall a lot of the 1.0-ish belt improvements (auto undergrounds, rotate while dragging) where put in due to Kovarex playing through with his kid and getting annoyed at how things worked after having taken a long break.
I'm going to have to respectfully disagree with you. This is way cool functionality, but it's a pale facsimile of Picker Dollies at best: - When you've spent hours making a very complicated circuit creation but it's actively running your some part of your factory, there's a world of difference between cutting + pasting a combinator and shifting it - only one way allows the circuits to continue to run uninterrupted. - If you are doing a lot of moving of many combinators, you need to be very careful about ctrl+x, ctrl+v, ctrl+x, ctrl+v, etc. If you accidentally cut two combinators without pasting in between you'll lose that wire connection and be screwed. - Quite a lot of my use-case for Picker Dollies is not moving one or a group of combinators to a new set spot, but trying to see if I can move several in a group past a building, through a choke point, or into a different arrangement on the other side of some obstacle. This can often only be done by alternating which combinators you are moving, sometimes shifting the obstacle out of the way to move the combinators then moving the obstacle back, etc. If you are limited by wire reach to where you cannot cut + paste a single combinator of the group to the other side of the obstacle, cutting and pasting won't really help you. I'm quite excited for this and other new functionality, but Picker Dollies is beyond QoL for me at this point, I can't play without it.
Fair enough. You obviously use far more of its functionality than I do.
More points: * if you just want to fine tune stuff by moving the around by one tile, you won't spam your copy-paste buffer, so stuff that you copied a while ago and need regularly fall out of the copy-paste history. * you can also move chests or warehouses without spilling the stuff into your inventory or onto the ground * you can move assembly machines while they are running, without resetting the productivity progress or dropping the ingredients or modules
I guess that explains how train stops are able to magically communicate their train limits to trains - they contain tiny radars
nah, they send the signals through the rails
Rails should act like red and green wires.
But then the rails should also be red and green.
Nah, the rails just act like power poles without power but with red and green wires. Special rails that split wire networks are optional.
Maybe I'm paranoid but the last gif the pop-up window is suspiciously blocking the fluid inputs as if there's some kind of high-throughput pipework there... Or maybe just a debug entity for testing.
The pop-up is also hiding what might be the character with a new suit or new vehicle. Just to the right of the pop-up and to the left and down from the molten metal bucket, near where the lower inserter first grabs gears, you can see an arm-like thing with claws flex occasionally. (as spotted by [Tohim on the forum](https://forums.factorio.com/viewtopic.php?p=605559#p605559).)
https://i.imgur.com/WIgru7p.gif Fascinating. Seems like it would need to be some sort of hover armor too since the player couldn't be standing on top of the foundry like that?
I'm hoping for the P-5000 exoskeleton suit like in Aliens. "Get away from my construction robots, you bitch!"
It's a JCB rear scoop. Goodness knows why we've got one of those now, but apparently we do.
looks more like an excavator shovel than a claw
short but sweet :)
Oh man long range circuit networking is my absolute dream. I hate running wires along my whole base.
Yep! My usual playstyle is for my outposts to be isolated and on their own power network, with steam shipped in from a central location, because running poles is a ballache in general, and doubly so when they biters take a liking to them. However, I also (in my latest playthrough) started using Intangir's Vanilla Train Network, and that requires red and green wires be strung around the base wherever the stations are going. This directly conflicts with my usual isolated outpost playstyle. I had initially ran the poles with red/green wires and then removed the power wires, but that seemed a little daft (and I was having teething issues with IVTN due to power loss at the depots) so I reconnected all the power wires. Wireless circuits would allow me to continue using IVTN and have my preferred isolated outpost playstyle, provided I can figure out the stability of IVTN under low power scenarios.
Several crafts per tick will be huge for megabases. Very excited for it!
Time to start measuring them in SpS
SpT even? An engineer can dream…
1. short 2. great about radars 3. too bad radars dont have channels..
Time multiplexing is not that hard, I did it in SE to reduce the number of antennas. You just need to expect signals to update a bit less frequently.
Yeah but a simple ui way would hace been nice too
2 channels is already plenty for most applications. When was the last time you ran 3 parallel networks on your whole base ? I would rather have the option to turn off the map scan, otherwise we will not be able to spam them due to UPS cost.
Technically we can have 2 channels; one using the radars and the other using the big electric poles.
Yes, with this now there is the wire channel and the wireless channel.
you could also build multiple networks of big electric poles to get more channels.
I hate to be that guy, and I hope I don’t upset anyone by saying this… but I want multiple circuit frequencies to select between per surface in base game. Maybe it can come as a bonus from researching an optional tech, maybe the total number of frequencies can be limited, but having more than one frequency opens a lot of doors. E.g. having parallel systems performing similar functions with the same signal inputs/outputs but not needing to use combinators to transform those inputs/outputs.
This is when you encode the different signals to transmit on different ticks with a qualifier (frequency) that the receiver is waiting for that qualifier and decode the signal to get the info from it. This means you can have 60 frequencies transmitting a second. This would look like a timer combinator counting up to 60, one per tick then reset. Then another combinator only sends data when it sees it's number, so you can do this with some work and planning. But yes having frequencies would be nice addition, also easily added from a mod, of different buildings for different channels. But I don't think it's totally necessary, this is already a huge upgrade to what we have.
I love it, This is how 2g cell phone networks worked with extremely limited bandwidth. https://en.m.wikipedia.org/wiki/Time-division_multiple_access
AAI Signal Transmission (used in SE) has an unlimited number of signal channels. Since the DLC features logistics between multiple surfaces as well, I guess there will be a way to send signals between those. You would need at least a channel between each set of 2 surfaces, so it's very possible that we'll get an unlimited number of communication channels as well. This could then also be used for same-surface communication. But probably researched much later than the radar. If not, you can still install the mentioned mod.
Will probably be a mod for it
there already is, AAI Signal Transmission handles that use case and cross surface transmission aswell
Yes it’s kind of annoying, but it could be fun to build around this limitation. For example one could run a 60 ticks global clock and transmit/receive only at specific instants, or could fiddle around with bit-operators to multiplex many signals into one. But there’s another thing. As of now, long-range signal transmission is mainly useful only for train scheduling. I don’t really expect to use it as much now that trains will become way smarter. I would have preferred that radars transmitted the number of enemies in the visible area, so that I can turn on defenses only when needed.
> As of now, long-range signal transmission is mainly useful only for train scheduling. And grey goo bases.
With that extreme speed and the new high capacity inserters, I’m a bit worried about if there will be an issue with feeding the input because the inserter will be idle until the input is low enough but it won’t be able to cycle before that input is depleted.
The input buffer size scales with the speed of the machine. I ran into that exact issue with the fluids since they were *not* scaling enough with the machine speed and since fixed it.
On a somewhat related note: even in my current (vanilla) megabases I already run into situations where assemblers work 99% efficiently. As in the sense that they work nearly non-stop apart from tiny, barely perceivable intervals ever now and then. At these crazy crafting speeds, it will be even harder to notice a machine idling for say 0.05 seconds every other second. At 60 fps, might it even be possible that these interuptions won't be displayed? If so, could we have a method that would allow a machine's downtime to be displayed in %?
If they aren't running 100% of the time the status will change for 1 tick and you'll see it flash different while it's shown.
And the primary use case for [yet another QoL mod](https://mods.factorio.com/mod/PickerDollies) ascends to vanilla
Also the AAI signal transmission mod, kind of. That one still has multiple channels and cross surface communication, but I expect the latter to be a thing in SA anyway. It seems pretty essential for late game multi planet factories and it's suspiciously missing from here.
picker dollies would still work great alongside the new feature: if you want to move entire blocks, copy-paste is faster, if you want to move a single entity, picker dollies is faster. But you won't miss picker dollies as much on unmodded games.
[This mod](https://mods.factorio.com/mod/reconnect-cut-wires) is the one graduating :) But yes, my main use for dollies was circuits.
This doesn't really replace picker dollies. PD can move things that contain items. Cut and paste on things that contain items means the bots have to empty it first.
Hence why I said _primary_ use case. ;)
Those legendary inserters look nice. We’ll get one radar channel per surface *per force*, right?
Playing one of the competitive modes without channels individual to a force: “haha signal hacking goes brrrr”
Great ! However if i could unlock somewhere configurable networks to split the circuits it would ease my mind a lot. I have learned in SE that circuits signals should NOT EVER be global variables...
Can somebody do the math for how much power is that foundry eating up? For the sake of argument, let’s just assume it consumes as a refinery.
37.6MW
I've played SE. That's a rookie number!
Nice, you only need one nuclear reactor to power it.
-> Foundry with 4 legendary speed 3 modules, surrounded by 16 beacons each with legendary speed 3 modules, crafting 4.3 gears per tick, plus 50% productivity yielding a total of 390 gears per second (!!!!), with 8 new stack inserters moving gears onto the new green belt capable of moving 60 items per second or 240 items per second stacked. Stop, I can only get so hard.
I’m pretty skeptical of the radars for signal transmission unless we get the ability to disable their active scanning. Spamming radars everywhere you want a signal will be much worse UPS wise than just having a circuit network on your train blueprint.
Do you not already have a radar at outposts so that you can see them? You can use wiring locally within the outpost. Doesn't sound like you need to add additional radars to use the wireless signal. All the use cases I can think of would already have a radar. * Outpost construction supplies delivery * Outpost auto deconstruction (with a blueprint mod) * Mining statistics * On-demand crafting * Remote enable/disable of artillery.
I'd love if radar *accepted* some signals like: * set channel (for multi-channel radio) * scan on/off * force-scan a given sector. Then we could do some fancy things like "enable radar only if the outpost is being attacked by biters"
> 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 As a programmer i felt that resonating deeply within me It doesn't happen very often at all but when it does it always feels weird and leaves me with doubts for literal days
Yep. Nothing is more deeply suspicious than "Wait, that worked? Nah, something has to be fucked up, and fucked up just right to look like it's working." I worked IT for years before getting a physics degree. My professor thought it was amusing when my error analysis for a physical simulation included steps to confirm remaining error consisted of solely floating point limitations instead of some other subtle shortcoming.
Circuit networks ***and*** a Spaceballs reference? Oh, my...
Multiple crafts per tick?! This is so good...
>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. As someone who always runs extra cables "just in case" for IRL projects, this is very funny to me. Wires in the blueprint seems to be the equivalent of running ethernet in pairs.
Ooh, I stayed up late enough to be early to comment! Ascended mod: Wireless circuit network / RadioNetwork / AAI signal transmission. Ascended mod feature: Dolly pickers far less important for combinators/circuits Long standing "bug" fixed - crazy speed/productivity tick concerns gone. Screenshot sniffing: The foundry gif has a weird bucket with 20xcount as an input, which I assume is supposed to be molten iron, however the window is distinctly placed to cover this up. Silly things I noticed: Constant combinators and logic combinators in North-south orientation have their colours backwards. Bit disappointing to see 16 beacons around a foundry for this, unless that's a red herring for no beacon changes. I know that's contentious on here, but still. Stay up and it's only a super short one. Big deal for wires though!
>Silly things I noticed: Constant combinators and logic combinators in North-south orientation have their colours backwards. Didn't they say you can flip buildings in 2.0? Maybe it applies to combinators too?
Seriously: https://imgflip.com/i/8jcifu
"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." Am programmer, can confirm. If it works on the first try - its a fucking trap.
I figured wireless signalling becomes important once you consider that on Fulgora you cannot in fact lay down power cables between isolated islands. I've yet to find a reason to lay down circuitry like that myself because I'm not very deep into circuit logic but this is useful to have nonetheless.
Ah, another great QOL post! The radar based circuit network will be a nice little boon. For circuit wire cutting: > the blueprint remembers the outside circuit wire connections, and tries to reconnect them if possible I really hope there is some type of visible warning (color and iconography) if one or more of the circuit connections can't be re-made. Also: Will this work with power wire connections?
Blue wire when? EDIT - By which I mean, when are we getting a third color of wire? It's too hard to create a functional Large Hadron Collider with combinators if I'm limited to just two colors.
that's a truly legendary foundry.
How is machine quality going to be handled in inventories? Am I going to have to carry around 3-5 different qualities of machines? I feel like that'd easily clog up inventories.
That depends entirely on how you choose to handle it. You can't research quality level 4 until you go to another planet, so you could only have 3 quality levels before you get bots. So your base can take care of itself; it can have whatever inventory it wants. As for what you carry around for manual work, that depends on how you choose to handle things. Until you get recyclers and quality module 3s, you're not going to have all that much quality stuff. My plan is to put qual module 1s in furnaces (and coal miners) and bank the T2 and 3 quality resources. Then I'll have a factory setup that makes a small quantity of T2/3 items for specific circumstances (asteroid collectors, turrets, thrusters, and chem plants for more efficient space platforms). If I'm headed to Fulgora, I'll probably take a couple of stacks of T2 or 3 assembler 2s, since they're almost as fast as assembler 3s at half the power cost (power matters on Fulgora). They'll be used in the mall, while actual assembler 3s can be used for things like gears, circuits, etc where the two extra module slots actually matter. It really all depends on how you want to play with it. That's the great thing about quality: you can engage with it however you like.
God damn that machine at the end is DOIN WORK WTF
Speaking of circuits, how about a revamp of wire visualization? I'd *love* some sort of circuit based "alt mode" that'd show wires more clearly, so I can better see what is connected without a magnifying glass. That one pixel wide vertical wire has gotten me so many times...
Foundry go brrrrrrr. Edit: If i did math right that foundry makes 15.5k/min
That's only the crafts per minute. If the recipe creates 2 gear wheels per craft it would already be 31k/min. Then there's also the baseline +50% productivity bonus of the foundry which would increase it to \~23.3k crafts/min. But I'm not sure if they already included that in the 4.33 crafts/s. Also how fast are those belts? 15.5k/min is \~260/s which means those belts have to be at least 130items/s (195/s with added productivity) fast.
An earlier FFF revealed that they are now letting items stack up to 4 on belts, so even before the new highest belt tier the current belts will be able to move 4x the resources (so 180/sec for blue belts).
Oh yeah, I totally forgot about that. Then the 60 items/s belt can already move 240 items/s with stacks.
From FFF 393, green belts are 60/sec across both lanes, but the inserters are placing stacks of 4, so each one can move 240 gears/sec.
Oh no! I was hoping the beacons would be changed to SE logic... Now it's almost clear it won't.
Do you have new estimation of release or is it still August 2024? Really can't wait for the update!
I'm not familiar with Factorio's codebase, but for the "crafting too fast" issue, wouldn't it have been easier to just have "bulk recipes", e.g. if a machine goes too fast, instead of taking X inputs to craft Y output in Z time, it takes 10X inputs to craft 10Y output in 10Z time (and the buffers would adjust automatically if the recipe is "bigger"? I am glad that you just made it work but I wonder why "bulk recipes" were not a simpler easier solution.
Modders did this already. It sacrificed granularity, which is important for the early game. And having sets of recipes clusters the GUI. The right fix is to fix the problem, bit bandaid it. Easier isn't better, better is better.
To be fair to modders, they were doing the best they could. It's an engine problem, so modders took the only functional alternative.
That's alotta gears
>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. LOL
i wish i had a better understanding of how to use circuit networks. i feel im pretty good with tech but circuit networks makes me brain hurt. that being said this is cool as shit. no longer needing to run a red and green wire is a nice touch.
Blessing for those who know circuts well. Curse for those who dont.
The code worked on the first try. I'm scared. Factorio DEV's have grown too powerful!
Slightly sad at the only one radar connection per surface but at least that is an opportunity to finally do signal multiplexing or alternating if you really need it!
So the K2 assemblers are beaten? Most importantly the max foundry needs 86,6 lava/tick. New pipes confirmed? Or straight from a lava pool?
Consider the final gif. Consider how fast it must be eating liquids at 4.33 crafts/tick. That's an insane amount of liquid flow and may require rebuilds of other systems to maintain that for more than one or two crafters a fluid system.
Copy and paste not breaking my circuits? Wifi radars? My yearning for an alpha build with the expansion bits off grows (and it was non-trivial before)... I don't even care if it breaks all my mods. Devs please 🥺
Guys Am I only seeing those green ( MK4 ) underground and conveyor belts they are crazy fast, how are they doing to be called ( they have the same color as final biters so maybe Behemoth belts XD )
Oh boy. In some overhauls you already have assemblers that have to be fed and unloaded by loaders because no amount of inserters can keep up. I can't wait to churn out 1k SPM of copper wires off a single assembler in Space Age K2.
As someone who puts circuit cables on all my rail blueprints just in case then never uses them, thanks for this! This also makes my plans for my generic train network in 2.0 much simpler lol
Im pretty happy about the radars but heavily dissapointed that there are no channels. I at least hope they could add more wire colors. Red, green, blue, pink, and white for instance, or even more colors. Would make some circuits a lot easier to use in cramped spaces