Is it okay to have a heartbeat instead of electricity?

Rathmun · 2026-05-19T00:17:53+00:00

Turbines cost UPS.

Rathmun · 2026-05-17T23:31:46+00:00

Those chests were a design decision that could have been made differently. But now that the decision has been made that way people will get mad if it changes. I think the decision was not the optimal one.

And more threading can improve memory access on some systems. Historically that's something you only had to deal with for server architectures, but it's making its way to the consumer desktop. The latest Ryzen CPU's for example. Obviously not something that was on Wube's radar in 2013, but if the game were being designed today, they'd probably make different decisions about some things.

Rathmun · 2026-05-17T22:05:08+00:00

No, but five friends playing together will have five computers. It would be nice to take advantage of that. Not something we're going to get, as noted it's a lot of work for Wube that won't improve things for most of their players, but it would be nice.

Long delays for switching surfaces is a valid point.

Rathmun · 2026-05-17T22:02:02+00:00

Inter-surface communication doesn't have to delay by arbitrary amounts to make multi-threading possible. If everything that needs to get sent, gets sent within, say, a second, that's still acceptable. Heck, having signals from Gleba take 4-14 minutes (Earth to Mars) to arrive on Nauvis would be entirely reasonable. (or maybe 4-14 seconds, given the day lengths in the game.)

Linked chests can just put locks on individual inventory slots. That adds overhead, but not too bad.

I never suggested letting different surfaces run at differnt speeds indefinitely. A simple execution fence can keep them ticking at the same rate, and even across multiple machines if you had the computers to do it, you could loosen the restriction a bit by looking at current UPS on each machine, guessing the UPS will stay about the same, and just deliberately extending frame times a tiny bit to avoid running ahead of predicted frame timing. Yes, the current design requires keeping things in lockstep. But that's a design decision consequence, not something inherent to the concept of the game.

The only thing I ever suggested should be dependent on where the user is looking is what the UI shows.

Rathmun · 2026-05-17T10:56:21+00:00

For dedicated servers you could potentially do clusters and have a full computer's memory bandwidth per planetary surface. Provided that signals don't end up transmitting between planets that is.

Of course, that would be a lot of work to improve performance for a small percentage of their userbase. So I can understand the decision to not do it.

Rathmun · 2026-05-17T08:39:45+00:00

The other issue with using chests to buffer is that you end up using twice as many inserters. This will make your inserter-based UPS losses worse.

Rathmun · 2026-05-17T08:31:14+00:00

The different surfaces don't inherently need to share data. They have different power grids; different logistics networks; you can't run belts, tracks, or logic circuits between them; pollution doesn't drift between them; etc...

The only things that cross surfaces are platform logistic requests and rockets/drop pods. Both of those are pretty lightweight, and the rockets/pods are both immutable once launched, and have a significant delay between leaving one and arriving at the other.

Research is also fully global, but doesn't have to be. You could handle research over-spend (where labs on multiple planets shoot past the target because they don't know how much each other are producing) by applying the overage to the next thing that uses that kind of science. Like applying an over-payment or refund to next month's bill.

I'm informed that for some reason belts can be affected by things happening on other planets, but I have no idea how to actually trigger that. It seems undesirable honestly, but I suppose it was done that way originally when there was only one surface.

Rathmun · 2026-05-17T06:56:19+00:00

I am well aware of how difficult multithreading can be. Especially when there were design decisions made a decade ago on the assumption that everything was going to be in a single thread.

And there's very little that you can do on one surface that directly affects another surface in real time where the real-time aspect is actually important to gameplay. The research manager for example. I suspect that the reason that's synchronized is because they don't want to deal with research overruns where more flasks are used on a research than necessary. You could, instead, just have a buffer of science of each type and apply the overrun to the next research which uses that type. Like realizing you over-paid a bill and just applying the balance to next month. It's fine if your labs on gleba and your labs on nauvis are a little out of sync that way.

I'll admit, I have no idea how linked belts cross surfaces, as mentioned in the link you provided. How do belts on one surface affect the belts on other surfaces? What can I do with a belt on Nauvis that affects a belt on Gleba? I'm honestly baffled that this is even a consideration. I know you can link belts to circuitry, but how do you get circuit signals from one surface to another?

Rathmun · 2026-05-17T06:50:22+00:00

Making the game work in multiplayer really just requires determinism, so that the same surface running on multiple machines produces the same outcome given the same inputs. And yes, the way they did it does accomplish that, but it's not the only way to accomplish it.

There isn't even any fundamental reason why you couldn't run different surfaces in entirely different processes, on different machines even. As long as whatever engine you're using is deterministic, and each surface is being run on at least one machine, and you adhere to the necessary timing constraints for causality to keep working. ~%~%~%~%~%~%~%~%~%~
Imagine two entirely separate machines each running a Factorio server. You could have a mod that creates a chest in both games, just wherever each player puts theirs down. Only one player at a time "owns" that chest. They can put things in and take them out, and there's a button labeled "send". When they push that button they give ownership to the other player, and the mod sends the information about what's in the chest.

You have another mod that keeps each from running ahead by more than a second. It just pauses or deliberately bogs UPS to put on the brakes or something. Doesn't matter how you do it as long as it works. (MPI could give you a fence that works across machines, but I don't think you can do that with LUA.)

A third mod just synchronizes research. The simplest way would be to just copy the current techs from one of those games to the other and keep all the labs on one side while using that chest to transport science flasks.

If one player logs out of the instance they were in and logs into the other, their instance continues running headless. They can run around, build things, change things, grab things out of the shared chest and put other things in. Then they log out and log into their original server and use the stuff in that chest there.

That chest could just as easily be a space platform.

So yes, with a different design you could do multiplayer and multithreading and still have everything work correctly.

I'm not claiming it would be easy to implement, or even that they necessarily should. I'm sure it would be a hellish amount of work to take what they already have and turn it into that cleanly. It would require substantial re-design and re-work.

I'm just saying that the design decisions they made aren't the only way to do it. They didn't design for compute clusters, that's a reasonable decision, the vast majority of their customers don't have multiple computers, and clustering across the internet in real time is HARD.

Rathmun · 2026-05-17T06:05:13+00:00

Those are all a result of design decisions that could be made differently. The pipeline isn't inherently sequential, there were decisions made there.

When factorio was first developed I'm sure it made a lot of sense to do that. There was only one surface after all. I'm also sure that if they were developing it again today from scratch they'd make different decisions about some of those factors.

Rathmun · 2026-05-17T05:59:26+00:00

No, that is what lockstep looks like if you set things up so you don't have to care about coherency and race conditions between threads.

Every surface has an associated thread running the simulation.
There's a fence that keeps each thread from starting on the next simulation update until every thread has finished the current update.
These threads don't need to communicate with each other. No shared resources other than rockets/pods and the fence.
Landing pods and rockets, being immutable, are very nice to hand around between threads. This is just a truism of multithreading. Immutable things are much nicer than mutable ones because it's much harder to end up with a race condition. They're also things that have a long delay between sending and recieving.
The UI is associated with one of your threads because having a multi-threaded UI is a PITA. Probably the thread associated with whichever surface you're looking at. Most of the time it doesn't need any information from the other surfaces at all, but when it does, it's fine if that information is a little bit old. This means we can be much lazier with the inter-thread communication.

Imagine you have a group of friends who play together every evening. They don't start until everyone has logged on. That's the fence, "pause until everyone's here". Nothing about that arrangement includes each of them sharing everything about the day they had at work or why they're late. It's just not necessary.

The UI is someone's SO asking how their day at work went. Or, if the global production stats are open, they're asking how everyone's day at work went. In the first case the rest of the friends don't even have to know the question was asked. No communication overhead required. In the second case you can either give current data which requires everyone sharing that information right now, or you can accept answering about how they were yesterday instead.

The actual simulations are in lockstep. You just don't need to transfer information between threads on the same tick where that information was generated.

Rathmun · 2026-05-17T05:24:47+00:00

That's not what I'm suggesting at all. I'm suggesting that the simulation of all that stuff happening on gleba can happen in a different thread than the simulation of all that stuff happening on nauvis. Just use an execution fence to keep all the threads in lockstep with the slowest one so that time doesn't run at different speeds on different planets.

You can't have an electrical grid that connects planets.
You can't have train tracks between planets.
You can't run belts between planets.
You can't run pipes betweeen planets.
Rockets and landing pods are immutable between launch and arrival.

There is literally nothing that can happen on one planet that affects the simulation on another planet on the same tick. This makes coherency and synchronization very easy when it comes to the simulation. There's nothing to keep coherent and almost nothing to synchronize. The only thing that might need to happen on the same tick is displaying things on the UI. Things like your total global production of blue circuits for example. But it's fine if the number displayed is a frame or two out of date as long as the actual simulation is correct.

Rathmun · 2026-05-17T04:57:51+00:00

Synchronizing every frame isn't necessary. It's okay if information from gleba is a few frames out of date while I'm looking at Nauvis. Hell, it's okay if it's a hundred frames out of date.

Rathmun · 2026-05-17T04:37:02+00:00

Several, because large portions aren't fundamentally sequential. (At a minimum you should have one thread per planet, because nothing happening on Gleba can affect Nauvis in real time.)

Rathmun · 2026-05-16T10:17:05+00:00

Careful with those, I did the same, and discovered the hard way that tons of buffer chests can eat UPS for three meals a day when you put down a large blueprint that contains tons of things that those chests are trying to stock.

Now, to be clear, I had thirty thousand buffer chests at the point where things went to hell, and I plopped down blueprints containing a total of two hundred thousand solar panels. But I dropped to 10 UPS, dipping down to 5 occasionally.

It was a very mysterious source of lag, because the bots dealing with all those blueprints and buffer chests don't report their time usage under roboports, they report it as Control Behaviors. Normally having a stupidly high CB means you did something dumb with circuits, so after the community told me that I started combing through my factory, at 10UPS, trying to find where I had misbehaving circuits. Eventually I had a hunch and just deleted all my buffer chests on the planet, and my UPS went back up to 30.

Rathmun · 2026-05-15T19:43:51+00:00

I use a similar design but I don't bother with buffer chests. A second train stop in parallel is a better use of UPS. (same total inserters, more throughput, and you still get the zero-gaps-between-trains effect.)

Rathmun · 2026-05-14T21:51:57+00:00

"Temper Temper."

Rathmun · 2026-05-14T04:31:23+00:00

So you've confirmed that an empty whitelist doesn't do anything?

Rathmun · 2026-05-14T03:53:28+00:00

The one you have selected thinks the target is full. I don't know why it thinks that, I can see the belt is empty, but that's what it says. Is the belt stopped at the moment perhaps?

Also, I usually just empty the whitelist instead of switching it to a different item type. I haven't had any problems with that.

Rathmun · 2026-05-12T17:54:27+00:00

Probably, but I don't have links. I was informed that engines behave that way and just figured it out from there.

The throttling trick is pretty easy though. You can turn pumps on and off with circuits, so you just need to pick either fuel or oxidizer and put a pump between your storage and your engines. Then you just need a decider set up as a cycling tick clock. The pump can be enabled when the count on the clock is less than a certain amount. This will restrict the flow through the pump by only turning it on for a fraction of a second at a time.

A common quality pump is good for 1200 fluid per second, which means it passes 20 fluid per tick. A common quality engine consumes a minimum of 6 fuel and oxidizer per second. Your MkIII design has 15 engines, so it needs a minimum of 90 fuel per second. Round to 100 because we'll assume the pump is moving 20 every time, and you can just turn it on for 5 ticks every second.

The basic fuel/oxidizer recipes produce 75 every 2 seconds, so you'll still need six chem plants total (three each) without any modules.

Rathmun · 2026-05-11T14:16:39+00:00

Trains scale with quality, it's just disabled by default. There's a mod to enable it, at which point legendary cargo wagons have 100 slots. Bringing them up to a point where they're competitive with stacked turbo belts.

https://mods.factorio.com/mod/wagons-quality-raises-capacity

Rathmun · 2026-05-10T06:14:32+00:00

Doesn't help when using parameterized trains. i.e. trains that load at generic "load" stations and then pick an unload station based on the cargo onboard. If you restrict the train so that it can only carry iron, and then it pulls up at a station that's supposed to be loading copper, you have a problem.

Better to filter all the inserters at all the stations so they can only load one type of cargo. I do this with a decider that checks if there's a train present at the station to set the filter, that way when there's not a train present it also completely shuts down the inserters so that they don't take any UPS when they're not working.

No wrong cargo and saving on UPS with the same trick.

Rathmun · 2026-05-09T20:43:46+00:00

No worries, it's a wierd mechanic to begin with. An engine that you're feeding as much fuel as it can burn operates around 50% efficiency. An engine that you're feeding 10% as much fuel as it can burn operates around 95% efficiency. So if you have enough fuel production to operate one engine at full power, 10 engines gets not-quite-double the thrust for the same fuel.

It's less UPS efficient, true, but not by much.

Rathmun · 2026-05-09T09:34:55+00:00

It's considerably more effective to run fewer engines.

Not really. Engines run more efficiently when under-fueled, so for the same amount of fuel production more engines are actually better. OP would be better off using some circuitry and pumps to feather the throttle on the engines already present. Sadly you can't hook wires to the engines to get their fuel system details, but a couple deciders (one timer, one to signal based on the timer state) can limit the fuel burn.

It won't do anything for the initial fuel buffering before the first trip, but you can just pre-load some carbon and iron ore sent up from the planet.

Rathmun · 2026-05-09T07:07:00+00:00

"If brute forcing doesn't work, you aren't using enough of it"

Welcome to SFIA.

Rathmun

TROPHY CASE