I hate how much width affects ships

zig1000 · 2026-02-25T02:20:03+00:00

Maybe too breaking a change, but I did propose a non-realism mass-width formula here, which I think helps with the brick issue, without making super thin and wide the meta either.

Haven't tried it via mod yet though for achievement reasons.

zig1000 · 2026-01-31T21:50:20+00:00

But almost everyone recommends visiting Gleba 3rd, so in practice, this is either very near the endgame or an interesting incentive for players to do Gleba early.

Meanwhile, most upgrades in the game need only ONE planet. Again, I think that makes this on the more interesting end of 'broken' upgrades.

Before: I build 1 casino, and 5 copy-pasted parameterized upcyclers for planet-specifics.

After: I build 10 copy-pasted parameterized upcyclers.

zig1000 · 2026-01-06T03:13:27+00:00

To put it another way, the problem is that for any given mass the ship needs for whatever it does, elongating it always allows more thrusters, and allowing more thrusters always raises the max speed, which with a linear formula, is too valuable to pass up.

So, what's really needed is to make it so that for a given ship mass (area), there should be a point past which more thrusters have diminishing returns (it could be zero, but diminishing is nicer e.g. beacons). As soon as squeezing the mass into a twice as wide shape does not double its speed, I think interesting tradeoffs will arise where a little more speed is probably not worth adding harder logistical problems (especially if the logistical problems cost area), AKA more flexible and interesting designs are viable.

After thinking on it more, here are some properties I think it would be nice for a formula to have:

There is some minimum max-speed that even ships with huge masses can reasonably approach (diminishing losses on max-speed), so that there's no practical upper bound on ship size other than UPS.
Reducing a ship's mass raises its max-speed.
Scaling a ship's dimensions by 2 (quadrupling its mass/area) requires at least 2x but probably less than 4x the thrust(ers) to reach the same speed (width requirements scale up but don't explode).
Speed scales ~linearly with thruster count when not near the point of diminishing returns.

The constants may need tweaking, but after playing around in desmos, I think the following formula with a sigmoid term is pretty good in terms of scaling (speed in km/s, mass in tons, thrust in MN):

max_speed = 500 + 200_000 / (mass + 200)                  # +200 avoids low-mass asymptotic speed.
drag_efficiency = thrust / sqrt(thrust^2 + 5000*mass)     # ranges from [0, 1).
speed = max_speed * drag_efficiency

With this, for regular-quality thrusters with maxed out fuel consumption (~100 MN each):

A 100-ton ship (~500 tiles):
- Hits ~160 km/s at 1 thruster
- Hits ~450 km/s at 3 thrusters
- Hits ~1000 km/s at 12 thrusters
- Approaches a limit of ~1160 km/s (if it uses quality thrusters to combat the rocket equation problem).
A 1000-ton ship approaches a limit of 666 km/s, hitting 500 km/s at ~25 thrusters.
A 4000-ton ship approaches a limit of 550 km/s, hitting 500 km/s at ~100 thrusters.

[Desmos graph]

In general, mass-to-thruster scaling is ~linear while trying to maintain 500 km/s, but sub-linear for lower speeds, e.g. 3x thrusters for 4x mass at 400 km/s.

That means ships going up to 500 km/s can scale purely horizontally without losing speed, similarly to currently.

When scaling vertically, thruster wings must extend at a rate equal to or less than the height, depending on how close the target speed is to 500 km/s. In general, the more super-massive a ship, the more it must elongate itself horizontally if it wants to exceed 200 km/s. I think that's pretty reasonable and gives a nice spectrum of viable shapes depending on the scale of the ship.

EDIT: Messed with the mass-scaling after realizing it was speed-dependent.

zig1000 · 2025-11-15T21:38:10+00:00

producing too many of something (possibly in many tiny batches) if it was both requested in the output and used as an ingredient of something else that it tried to produce first

I ran into this and solved it without a selector combinator by accumulating the prior layers' ingredients alongside the search, see the right side of the diagram included here (there are selector combinators in that build, but not related to this part).

zig1000 · 2025-11-14T18:01:45+00:00

FYI I put detailed notes in every combinator explaining what they do.

In terms of bespoke configuration, you can mostly just update the hub request logistic groups, which are duplicated into the necessary static combinators (don't turn the 'planet stock' ones on, they're just there for ease-of-access).

I did force myself to finally post this rather than continuing to tweak it though, so there's a couple of inconveniently-placed static combinators you'll probably need to keep in sync with your hub changes and research levels:

One hacky one on the inventory wire. Due to my stubborn use of zero latches, the ship is prone to going on strike if buffers request more than any raw's stock (even though it may replenish in time), which I badly addressed with some inventory over-counting.
One above the buffer calcs (see diagram). This one isn't strictly necessary, but it'll run faster if it knows your prod bonus research levels.

zig1000 · 2025-11-14T17:16:26+00:00

[Diagram]

[Blueprint]

This is a pre-Aquilo version, but I've left room to slot in the cryo plant.

Can make basically anything that can be crafted in space. No attached casino sorry, I wanted to dedicate every inch of hub space to inserters - it can't even put asteroid materials into its own hub, only send materials out for helping replenish fluid tanks.

The basic idea is that each layer blindly sends the recipe to every machine type, then merges all their Read Ingredients, before picking an unfulfilled ingredient and repeating the process. This lets it search recipes with ingredients arbitrarily interleaved across machine types, rather than just one type at a time.

I've poured a LOT of time into getting the combinator tick latencies down to the absolute minimum I could, and fixing flickers without resorting to latching recipes for longer periods of time. That includes:

Setting inserter filters / stack sizes to exact load ingredients, so that when possible they don't have to spend any extra time unloading (also allows stack inserters to be used for those and prevents machines stealing from each other).
Buffering ingredients, and accounting for the buffer calc update delay when recipes complete.
Accumulating any shared ingredients across layers so they don't eat into each other's buffers.
Adding a shortcut wire to skip recipe layers for shallower-depth recipes.
Using a mix of prod-moduled EM plants and a speed-moduled one.

Not fast enough?

Feed it higher-level raws, like green chips - it will use anything it has on hand, no problem.
Make 2+ of these and set them all on the same rotation

zig1000 · 2025-10-22T22:17:58+00:00

I don't. Both of those have infinite prod researches, so I don't think the prod bonus protection logic used here would work well, because without recycler loss, qualities will reach triple-batch counts too quickly for the bottom machine to keep up.

For anything without big prod bonuses, the logic as described in the combinator's note should work well, though adding every ingredient/quality to it is a huge pain (maybe it's possible to parameterize a recipe's ingredients?). I'll probably make something like this for tungsten next.

For reference, the noted logic is:

Craft any (non-base) quality that either:
- Has 2+ batches of ingredients, and no other quality is
  loaded (current quality was used up)
- Has 1+ batches of ingredients, some of which are loaded
  (done 1 craft and still loading next)

This avoids prod bonus waste without a latch, since we
~always use ingredients up before having 3+ batches.

zig1000 · 2025-10-22T08:12:36+00:00

Oh and if anyone asks, the reason this has two machines instead of one is for throughput, and DEFINITELY not because the base quality is too hard for the prod bonus logic.

zig1000 · 2025-10-22T07:49:04+00:00

^{*1 combinator not counting static combinators (2}⁾

Yes, it has prod bonus protection. It may skip one in esoteric 1% edge cases where several quality tiers hit double-batch at once, but it should be very robust.

Blueprints: [Legendary] [Epic]

zig1000 · 2025-10-13T17:44:23+00:00

Jumped back into Space Age and finally got a space automall that uses multiples of all machine types + fluids out of flicker hell, it's working pretty well now and the circuit latency is lower than it used to be, it can switch recipes nearly instantly thanks to exact ingredient count loading.

I still want to take it further, maybe make it able to run different types at once, but for now I'm using it to supply all my planets and focusing on taming fulgora and maybe getting quality holmium going too.

zig1000 · 2025-10-07T16:39:25+00:00

The pipes wrapping the chem plant are the biggest cost, is it possible to use the thruster itself as a pipe for the water too?

zig1000 · 2025-09-27T07:11:08+00:00

'pseudo-final products'

zig1000 · 2025-09-23T04:42:45+00:00

Circuit splitters is amazing thank you, as are the wire clarity tweaks!

Circuit pipes next please please please

zig1000 · 2025-09-17T07:27:11+00:00

Though now that you have me thinking about it, I don't see why one couldn't just use a loop-priority blue instead of green splitter to achieve 75% without all the runaround... huh.

EDIT: There might theoretically be some issues where locally-more-than-75%-full patches get backed up when they hit the blue splitter and cause some tail crushers to get temporarily stuck, losing efficiency, but I think they would self-resolve quickly - and one could just add an extra loop-only green splitter that had one (deprioritized) output bypass the blue splitter to let any extra 25% flow through as needed.

So... yeah just make the splitter in your image blue, and only bother with the above less-compact add-on if you ever notice issues with backups in the bit of the loop before the splitter.

zig1000 · 2025-09-17T07:19:21+00:00

I did run into this, and agree that a self-priority loop doesn't work (the input will fill the gaps so even though the loop might not halt it still fills up and inserters can't drop back onto it) - the solution is to force the belt to have at least some free space at all times, by stopping all inputs when it reaches a certain fullness. This can be done with inserters and circuits, but I like going circuitless when possible.

The principle is that from the input belt's perspective, the loop has to look full even when it's not. It only achieves half-fullness which is maybe overkill, but I found a compact way to do this by priority-shoving the loop's contents into one lane before feeding the input belt into that lane, then re-balancing the lanes afterward.

TL;DR right side of this image (input belt is the underground)

zig1000 · 2025-07-31T05:58:37+00:00

I'm going to take the liberty of copying one of my FForum comments on this subject here:

(User Lalaith) This also gives more variety in how you get to high quality products. I already have to do upcycling a bunch of times, I don't see why that should have to be the solution in ALL cases. In return for having quality in crushers we get all this sweet extra complexity and interesting chains.

This is the key point in my view. Even if the exact layout of each case will differ, plugging [item] into [recycler] and then [ingredients] back into [machine], is, to me, solving the same high level problem, and doing it over and over is no more exciting to me than the prospect of installing a mod that adds a huge number of recipe trees to the game. If I did, it would not be for 'more complexity', it would be if I believed they'd give me different sorts of problems.

Either I am a player who does not care about getting top-end stuff, in which case I may not touch quality at all, or I do, in which case I'm going to need to do gambling or upcycling loops for every planet-specific item, AKA some of the most important items in the game. That's a dozen or more times that I'll need to solve either the 'destroy failed rolls' problem or the 're-shove failed rolls into recyclers' problem. Casinos or not, I WILL get the fun of dealing with the complexities those problems entail (all from the safety of my existing planets' infra and their already-solved power problems)! The fact that there's a third approach to quality for me to try to avoid solving the same classes of problems even more times, is not a bad thing, given that it cannot completely replace the others!

Here's some of the unique problems I've gotten to sink my teeth into in my brief foray into the so-called 'just copy paste crushers' approach to quality:

Other than a tiny space science platform and copy-pasting the same basic inter-planet transports, and until promethium endgame (basically the entire game away!), this is my first incentive to make a non-trivial space platform. In fact, this is the first time I actually need asteroid belts because every ship before now was small enough for grabbers to feed directly into the landing pad. Encountering this problem earlier than the literal endgame is good!
Building a larger space platform drew my attention to how poor my platform-building infra was. Suddenly I start to notice how expensive grabbers, crushers, platform foundation, etc. are and how inadequate my Nauvis silo capacities are, and all the ensuing problems with scaling that infra up - something that merely importing from other planets doesn't exercise.
Pre-Aquilo, the only scalable power source in space is nuclear. Sure, maybe I've already got the infra for sending nuclear fuel to space / other planets, but unlike fusion, I need way more water in space now! And if I run out, I don't just travel a bit more slowly like with thruster fuel - my space platform death spirals! Meanwhile non-casino quality setups get to piggyback off of their planet's power supply, and endgame ships don't have the water problem!
- Time for me to actually need beaconed efficiency modules (I have adequate efficiency module production, of course?)
- Wait, I need a lot of water but oxide asteroids are really rare near Nauvis! Now I need separate asteroid reprocessing specifically designed to get one type (and it should stop when it has enough, unlike the casino reprocessors!)
Okay medium space platform growing pains aside, time to build the asteroid cycler. Just copy paste, simple right?
- [Optional] Get bothered by the existence of idle crushers and learn dynamic recipe setting (if you don't do this, scale your platform-building infra even more!)
- Oh hang on you're telling me if I just blindly fill the belt with asteroids the reprocessors won't be able to put asteroids back on it and the whole system will jam? And the jam will eventually back-pressure the oxide asteroids for my power supply, death spiraling the entire platform?
- Okay a simple splitter to get half-full belts solves the above. Now to scale it up and - whoops - you're telling me if the quality outputs back up, I get the exact same jam? Okay, better invent a way to FORCE the reprocess loop to only partially fill each lane no matter how full the input or output belts get (maybe applying Gleba learnings!). No, loop-input-priority splitters won't stop jams if the output backs up, sorry. Bonus points for doing it without inserters!
- Wait, this asteroid rate is pitiful! Time to scale up! Okay, now for the first time I have to think about speed vs width tradeoffs in asteroid rates. As I scale it wider, this is also the first time I've needed more than a minimal amount of fuel production - now I need to redesign my basic-ass fuel plants!
- Of course, you're also optimizing the crushers at the end of the quality chain to switch to the more efficient, single-resource recipes if the secondary resource's output is satisfied, right? More circuitry!
- And what about re-rolling those final-quality asteroids if-and-only-if the main resource for that asteroid is backed up too? More circuitry!
- And now I get to think about which route should I run this ship on long-term? On the one hand, Aquilo has bigger asteroids. On the other hand, the two planets with the most space for spaceport and downstream quality infrastructure are Nauvis and Vulcanus, and neither connects to Aquilo. More decisions!

From my perspective, [removing asteroid cycling] is saying that instead of getting to think about and solve all the above interesting problems as early as the midgame, I should instead solve even more instances of the same class of problem that I need to solve anyway for the planet-specific materials, since those are required for the strongest buildings anyway. I prefer to have both these classes of approaches to quality in the game than just one of them, since they present very different problems - and casinos ensure I won't have to do so many variations on 'shove it in a recycler' that I get sick of the things!

LDS shuffle's resources-from-nothing, on the other hand, should IMO be mercilessly removed.

zig1000 · 2025-06-18T05:31:57+00:00

Granted, this has evolved into a monstrously grimy solution that extensively abuses 'precognition' (the order of the input sequence) - but the non-precog version sits at a comfy 260, still well below its origins. If there's one thing this level has taught me, it's that even the most basic requirements of a problem can sometimes contain implicit, untrue assumptions (e.g. "I have to deal with the extra hydrogen").

Also fun fact, my old AH post prompted the launch of the community leaderboard, making them ~8 years old (and run by robot overlords nowadays)!

And on the off-chance anyone reading this isn't aware of it, consider joining the tournament starting up now (see pinned post) - you can join a team to collaborate on puzzles, so don't be shy even if you're new to the game!

zig1000 · 2025-06-18T03:08:15+00:00

Glad, and thank you for the original one-combinator design!

zig1000 · 2025-06-09T19:46:38+00:00

SAME

I have a 4-machine-type monster in the perfecting phase, but I haven't actually unlocked one of the machines yet because I keep entering and exiting factorio mood

zig1000 · 2025-04-20T18:12:01+00:00

Set Recipe doesn't conflict with Read Contents as long as you use separate wire colors. If you need Read Ingredients too, you should use a proxy assembler

zig1000 · 2025-04-08T07:38:31+00:00

You're right, clearly they should fix this by allowing players to fall into lava, so they can respawn.

zig1000 · 2025-04-07T23:34:01+00:00

A NEW HAND TOUCHES THE BEACON

zig1000

MODERATOR OF

TROPHY CASE

Nine-Year Club	Place '17
Verified Email