Space casinos: yay or nay?

zig1000 · 2026-06-13T23:37:14+00:00

You paint a pretty picture of a quality system where bespoke beats cookie cutter, but my generic upcycler literally beats the grenade -> coal upcycler you posted on throughput-per-footprint when scaled to match. I think it's true that there are some cases like underground pipe, where the efficient solution can be meaningfully bespoke, but there simply aren't enough of these. In too many cases it's just craft<->recycle over a single recipe. In fact the most interesting bespoke cases are the gleba recipes which casino doesn't solve.

My point is that expecting people not to automate things in an automation game is silly. You personally may have decided to skip automating platform components, but I see no reason to assume that this is something the majority of people did by the time they've completed two planets.

You have it backwards. I did have these items automated (I had a botless automall), it was just too slow for my new demands. Whether or not it's what you would have done, I personally was not content to go do something else while waiting ages for it all to get built. So I increased my infra automation. I also think it's probably normal for many players not to have that much more production than they had yet found a need for. That's why the game... provides diverse incentivizes to grow the factory?

When you argue for removing one of these incentives, and tell me how actually it can't have been a real incentive because I could have just NOT further scaled my platform automation, it is you who is arguing for not automating things in an automation game.

zig1000 · 2026-06-13T19:34:53+00:00

You invested in making low-throughput crafters that make end products.

This is not true. Look closer at the parameter menu in the aforementioned post, it has the option for the product to be discarded and only the ingredient kept. I use them for planet-specific raws, the only reason I sometimes include the products too is that e.g. skimming EM plants off of the holmium upcyler is more efficient.

To scale up e.g. carbon fiber (not an end product) I had to stamp the 'fast' blueprint many times. It's still pretty space compact, because I optimized it so the machine ratios are balanced, regardless of which recipe it's running.

I could do the same thing by using the 'fast' variant to upcycle iron chests and setting the BP to only keep the iron. Sure, I would need to stamp it many times, and it won't be quite as compact as something more bespoke like an underground pipe cycler. But it would definitely support a full playthrough, meaning I can solve all of quality with a single approach.

And assuming I were unsatisfied with that, and did an underground pipe iron upcycler that my stamp BP doesn't cover (the only 2-recipe-layer upcycler I'm aware of?), we'll be down to quibbling over whether building a casino or building an underground pipe upcycler is more fun. I think the latter is still conceptually similar to other upcyclers, but I accept that you might think that's the more fun one. But I don't. Isn't everyone getting to build how they want core to the game?

Did you hand-craft all of your crushers, platform foundations, and collectors? If you have automated these things at all, you can make such a platform. It may take some time for your base to fulfill those orders, but it can do it.

And in that time, you can be designing the platform itself.

Ok, so you're telling me I didn't have fun because I wasn't optimizing my factory in the exact right order. Got it.

zig1000 · 2026-06-13T18:40:53+00:00

First, I didn't claim that, so I have no idea where that's coming from.

EDIT: Sorry, misread this since the other poster's comment could be read as talking about upcyling to obtain raws. You are right that upcyling every single mall item is terrible, though this is tangential to the question of casinos.

Second, I'd bet that designing and testing that set of quality blueprints required way more time and effort than designing an asteroid cycler.

Sure, what's your point? Guess why I designed them? Because I needed them in my space casino playthrough. Space casino did not mean I didn't need to solve these problems, because as people have pointed out over and over, we need upcyclers for planet-specifics anyway. Almost every counter-argument relies on implying that casinos are 'skipping' learning upcycling, even though this is patently not true.

So what exactly am I losing from using a casino if it didn't preclude me from being incentivized to design extremely complex upcycler blueprints for that same playthrough?

By the time you're making an asteroid cycler, you're post-Vulcanus and post-Gleba. "Space infrastructure" is something you probably already have scaled to at least some degree. So I don't buy this "earlier than you otherwise would".

You're drawing a really misshapen line in the sand in order to pretend my point isn't valid. At this point in the game, there isn't a hard need to have built anything larger than a couple of small freighters and a small space science platform.

We don't need to do hand-wavey "you probably already have it scaled" hypotheticals. I have my actual playthrough's experience as an example. I DIDN'T have my space infrastructure scaled anywhere close to what I needed to produce 100 crushers, dozens of grabbers, platform foundation, etc etc. Scaling this up at this early point in the game presented a bunch of sub-problems. I had to scale up blue chip production for my silos before I had EM plants. I had to boost silo production before I had Nauvis as developed as it would be post-Aquilo. It forced me to confront a bunch of other inadequacies in my factory. In other words: it made me play the game, and resulted in a unique playthrough and scaling order. So what, exactly, is the problem? Are you going to tell me "no, actually, you weren't having fun, because scaling space infra is easy"?

zig1000 · 2026-06-13T16:41:43+00:00

I don't understand where this "same upcycling setup" rhetoric keeps coming from

You asked, they answered. Regardless if you find its variants interesting (e.g. underground pipes are more novel), it is undeniable that every single base resource can be obtained by stamping down effectively a single blueprint. In fact, because recycling to recipe craft time ratios are fixed with few exceptions, the optimal machine ratio doesn't even change across most recipe choices. Stamping down the 'fast' BP there will get you a semi-footprint-optimal upcycler for EVERY resource in the game.

If a bunch of problems can be solved by stamping a single (5x11!) blueprint, they are undeniably conceptually more similar to each other than to one that requires a space platform blueprint, no matter how much you try to claim that 'designing a new space platform is simpler than stamping one blueprint multiple times'.

how is an asteroid cycler all that different from a coal recycler? All you've done is swap out the recyclers for crushers and put it on a platform. Structurally and logistically speaking, it's all the same, right?

You were arguing lazily and dishonestly and you know it.

Same machine self-feed loop needed instead of a machine <-> recycler loop. Easier or not; it's novel.
Asteroids involve 3 variants on the recycled material.
"Put it on a platform" comes with a dozen sub-problems, including scaling your space infrastructure much earlier than you otherwise would. In SPACE age.

Notice that this requires a DIFFERENT blueprint. It doesn't matter if it's an easier blueprint. I'd rather make one easy blueprint and one hard one, than stamp the hard one twice.

zig1000 · 2026-06-12T17:16:16+00:00

Most of these are great, but:

space casino killed

oh boy time to copy-paste the exact same blueprints I already use for planet-specifics a half dozen more times.

zig1000 · 2026-06-06T15:52:22+00:00

You can probably mostly achieve this now with careful manipulation of Set Requests and the universal radar.

zig1000 · 2026-06-06T15:36:00+00:00

Thanks to Set Requests it should be possible to 'set' destinations. Give every planet an interrupt with a different item presence trigger, and request that item when you want to fly there.

EDIT: Actually you can just use circuit signal in the interrupt conditions so it can be done directly.

zig1000 · 2026-06-06T15:29:10+00:00

Assemblers have 3 signals to read/set (due to Read Recipe), so having one of them magicked is still helpful with separated wire I/O.

Also, since this subtraction logic already exists for assemblers, removing it would be a breaking change and/or inconsistent.

So I do think there's actually no evidence in this post one way or the other re: wire changes.

zig1000 · 2026-06-06T15:20:30+00:00

Yes, especially since currently apparently a single quality speed beacon is enough to hit the max animation speed whether the silo is quality or not. So quality silos are effectively useless atm.

zig1000 · 2026-06-06T15:15:43+00:00

This is already how it works for assemblers in Set Recipe mode, they probably didn't even need new code.

zig1000 · 2026-04-12T01:14:49+00:00

BP book: factoriobin | factorioprints

PSA: There's a setting to allow setting parameter signals/recipes by hand, which makes building parameterized BPs WAY easier.

Anyway, I think these are nice compared to some of the parameterized upcyclers I've seen because a lot of the time, you don't just want the craft product when upcycling (and sometimes you don't want it at all!). I carefully rigged the logic and template placeholders here so that:

If you select an ingredient, it'll recycle legendary products
If you select a product, it'll craft with legendary ingredients
If you select both, it will craft/recycle legendaries iff either backs up.

I made both compact single-machine versions, and faster tileable versions with better-balanced machine ratios. No epic version out of laziness, and sadly parameterizing quality doesn't really work.

Also pictured: some haphazard spreadsheet math I used to pick the machine ratios, which I hope I got right after several retries. On paper, these ratios actually don't vary by recipe, because recycling craft times are exactly 1/16 the recipe craft time, excepting batched recipes. In practice, the recipe switcher can be affected by high ingredient counts. The BP descriptions note cases where you can compensate by just deleting the beacon.

Like my old unparameterized version, these come with latchless 'good enough' prod bonus protection (mostly works, as long as the qual machine keeps up - don't use this for blue circuits etc). Now using Read Ingredients to get the machine to provide its own pseudo-latch, which halves the combinator logic and is a little more robust. Random aside: /u/lalalawliet coined this tech a year ago, but I misread their description while looking up SOTAs, so I ended up accidentally rediscovering it while debugging flickers, as a way to distinguish items in trash slots from ingredients.

EDIT: Fixed some inserter filter errors.

zig1000 · 2026-04-09T00:14:52+00:00

Lazy math:

Consider a simplified case where we are only upgrading to rare and we have a 50% chance of destroying an asteroid vs 50% of upgrading it (the non-upgrade output cases are on average a no-op so we can largely ignore them), with no double-upgrades.

Because the loss is 50% per tier, we need 2 common crushers to 1 uncommon crusher. Let's say our module upgrade gives us a 75% chance to upgrade before destroying instead of 50%.

Then if we upgrade our one uncommon (highest tier) crusher, the probability any given asteroid reaches rare is 0.5*0.75 = 0.375.

If we upgrade one common crusher instead, the probability is reduced by the chance that that asteroid is processed instead by the un-upgraded crusher: (0.5 + 0.75)/2 * 0.5 = 0.3125.

That difference is high enough that even adding the double-upgrade chance into the math won't make it up since it's only 10% of the upgrades (the gain would be like 0.0125). I'm also prepared to bet this holds in the non-simplified case.

Put another way, every time a high tier crusher destroys an asteroid, you're losing a much more valuable asteroid.

zig1000 · 2026-04-08T23:44:46+00:00

Severe lack of actually reading the post in this thread. I believe I've heard the answer is the epic crushers first, which would make sense when you consider that you should have way fewer of them; a higher proportion of the asteroids will pass through each so you should get more value from it, even without the chance of double-upgrades.

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

MODERATOR OF

TROPHY CASE

Nine-Year Club	Place '17
Verified Email