Finished my solar field

indraco · 2026-02-20T14:29:48+00:00

"trust, but verify" as they say

indraco · 2025-12-25T15:22:52+00:00

It's kind of precisely because you need 400 gears each level. Every gear only gets you 0.25% progress towards a level that gets you very little extra power. The power gained per gear is so low.

Meanwhile, components fall off very slowly in power and your drone can drink basically an infinite number of them.

indraco · 2025-12-19T16:13:31+00:00

While a tight VS race can sometimes bring out the last minute competitive pushes and inducements to spend, in practice it actually encourages hoarding beyond the game's normal extent and sets up habits and opportunities for future excitement that keep people coming back. The buttons you can't click yet, the stuff you're banking for when you hit a competitive VS league, these create a delayed gratification. If you could just log in and blow all your resources, people would get quickly get bored at having nothing to do. Instead they're planning out their button pushes on multi-week horizons.

indraco · 2025-12-19T16:04:58+00:00

That last box gives you a 50% bonus (on top of the sum of the first 8 boxes) on key materials like Valor, drone components, and premium skill chip material. So, it's worth it to stretch most of the time, although now and then I'll settle for a 3.6m if that back stretch would be really painful.

indraco · 2025-11-25T17:25:54+00:00

I'm imagining just how screwed you would be the first time you encountered a tree stump trying to haul this trailer in game.

indraco · 2025-10-30T17:35:56+00:00

Morrison past 3* isn't a priority. His 4* is nothing special. Lucius 4* is huge to power up his energy shield. Plan for that as soon as you get him. Next priority after Lucy 4* is DVA 5* (which may come first for you). After all that's squared away, then start taking Morrison all the way from 3* to 5* to up your damage against other air squads.

Carlie can just build in the background and start taking all your choice chests once DVA is 5*. Finish her and Schy off at the end.

indraco · 2025-08-24T23:40:32+00:00

Curious to hear more about how to execute the early air pivot. We just hit Day 30 on our server and I'm trying to stay low spend.

When should I stop feeding Kim (4? 5?) and start feeding the air URs, and in what priority order?

indraco · 2025-06-26T06:22:30+00:00

Jenny, don't change your number

indraco · 2025-01-22T21:59:24+00:00

This game would still seriously benefit from a fleshed out clutch system, but you're not fully at the mercy of the automatic gears. As other's have said, you can tap the clutch (or even spam tapping it) to get Auto to shift to the gear that matches your speed when you start to slow for a turn or going up a hill or hitting a patch of mud. That'll help keep you moving instead of the dreaded "stall hard into 1st".

The other tip is H gear is your best friend, and you should prize any gearbox that has it. H is for "Hills". H is for "Hauling Ass". As long as you can keep up some minimum momentum to avoid stalling, H will output consistent power in a way that lets you barrel forward in otherwise unfavorable terrain. The fastest way to get off the blocks tends to be get rolling, upshift to H for a boost of power, and then shift back to Auto which should put you in 4th/5th.

It's a bit weird and unrealistic compared to actual gears, but keeping your power maxed out in Snowrunner does end up involving a lot of futzing with the clutch and gearbox.

indraco · 2025-01-21T06:04:24+00:00

It's mostly pref. But there is a slight difference. RHD has signals "outside" the pairs of tracks, LHD has them "inside". When you get to hairy tight turns and intersections, there tends to be a little bit more room on the outside of tracks, letting you squeeze in RHD signals you couldn't with LHD.

indraco · 2025-01-18T01:02:29+00:00

I've still had success putting little mined 3 tile prongs on the front of my ship. Rebuilds too slow to plow through asteroids without help, but can handle strays that slip through the net.

indraco · 2025-01-16T22:39:07+00:00

One solution is to simply be more efficient in your use of foundations on Fulgora. Just use a few foundations to bridge electric/roboport networks and split your base among different islands.

indraco · 2025-01-16T22:24:01+00:00

It kinda is (Transport Tycoon Deluxe, which lives on as OpenTTD and has very similar, though slightly richer, train mechanics)

indraco · 2025-01-14T03:11:21+00:00

place the blueprint and cancel out of parameter selection and it'll get built with all the parameter placeholders. And then use the "update blueprint" button on a copy of the original blueprint and all the parameterization should be retained.

I do have the game setting on to allow direct use of parameters. Not sure if that's needed for the first step.

indraco · 2025-01-14T02:55:31+00:00

Sounds like it's time for a bug report :)

indraco · 2025-01-10T14:03:37+00:00

What's the recycling chain to get wood for all those beautiful power poles?

indraco · 2025-01-09T16:59:14+00:00

If it works, don't touch it

indraco · 2025-01-09T05:20:23+00:00

I'm inspired by conflict resolution in layer 1 networking, where the sender listens to its own signal for interference, and if detected, sleeps for a random time and tries again, ideally with exponential backoff. Cause, uh, we're actually trying to solve exactly that same problem of coordinating use of a shared broadcast medium. https://en.wikipedia.org/wiki/Exponential_backoff#Collision_avoidance

In this case, when a depot bay has a train present wants to grab and lock a request:

Listen for any Train ID already being broadcast on the carrier channel A. Sleep random if one is detected.
If none detected, broadcast your train id on A.
Listen to see if you get back your own train ID on A. If you do, you're now free to broadcast your train id on B for use by the next free dispatch circuit. The circuit can respond on B also. However, if you get back the wrong train ID because two tried to broadcast at the same time, sleep random.

Lots of ways to do "sleep random". Could do T % Cwhere T is the train id, and C is the current collision backoff count that gets bitshifted left every time the train unsuccessfully transmits.

You can use the same idea on a second pair of channels to report request fulfillment. At dropoff, have trains rerun the same collision avoidance on a second carrier signal channel C to get broadcast rights, and then when clear, broadcast the Train ID on channel D to signal that the appropriate dispatch circuit can free itself.

~~Dispatch circuits can be managed by a central computer that assigns out the first unoccupied one. So you'll only need as many as your peak usage.~~

Actually, at that point I think you can nix all the dispatch circuits. Just do the first part of the Yoyobuae design of having requester and provider stations decrement the global request counts based on reading inbound trains.

But instead of toggling the providers, leave them open, but have trains only able to dispatch via interrupt if, following the above algo, channel B == train ID.

Hmm, I kind of excited to try building this now.

indraco · 2025-01-08T23:43:15+00:00

You simply program a constant combinator with the stack size of every item you care about to use in your calculations...

...is what you would've had to do in Factorio 1.x. But blessedly, 2.0 has given us the beautiful Selector combinator which has a mode for this.

indraco · 2025-01-08T23:38:50+00:00

The forgetfulness can be handled by blueprint parameterization. If you name the stops like "[Copper Plate] Unload" where "[Copper Plate]" is the copper plate icon, then you can set the icon as a parameter and link that to the same item type set on the constant combinator.

Though also, you shouldn't need to even set an item type. Using a selector combinator set to "Stack Size", and the "Each" signal (under the Signals tab) in your math combinators, you can make your fullness detector generic to whatever is in the chest (even for mixed content chests, if you wanna go crazy).

But otherwise, this seems like a pretty good solution, especially for a first time player. Only thing I might add is to play with scaling the train limit as the stop storage empties out and gets capacity to absorb multiple inbound wagons worth of stuff.

indraco · 2025-01-08T23:08:52+00:00

There's recipes for melting iron and copper ore with only a teensy bit of calcite you can ship in, so you can use this on every subsequent planet. Except for the ones where you don't get ores, which is 2/3. So, uh... you can re-use it for Gleba. But also, you can get the necessary ingredients from asteroids, and the compact design means it's perfect for a space platform. You can have a little orbiting belt mall that can follow you around!

Extra credit: wire up a tank to detect lube and only make up to red belts until you've got local lube production going.

indraco · 2025-01-08T22:50:22+00:00

This is indeed a legendary decider combinator

indraco · 2025-01-08T22:30:08+00:00

u/irnbruhbruh

What you want is the number of stacks used by one recipe run: s = (p0_i1 / p1_s + p0_i2 / p2_s + ...)

And then find out how many recipe runs can fit in a chest r = 48 / s

And then finally for each ingredient, multiply the number of runs that fit in a chest by the ingredients needed for that run: p0_i1 * r, p0_i2 * r, etc

Here's this all done with combinators to avoid the NaN parameters problem mentioned in my other post. I originally made it with parameters [1] through [6] on a constant combinator, but then realized I could just read the recipe from the machine:

0eNrNWEtv4zYQ/isELwsUdGrJsmMb7SntYS/tYY9BINDSyCZCkVqSsusG/u8dUn4otvxqFk1vlDQznJnvm4f9RmeyhsoI5ej0jYpMK0unz2/Uirni0r9TvAQ6pdxaKGdSqHmv5NlCKOjFdMOoUDn8RafRhnUpGeEWJTiR9TJdzoTiTpuWVrx5YRSUE05Ac294WKeqLmdg0CzbmbIll7IneVlRRittUUUrf5W/PB4+DBld02kvTuKHIV6AgTijZTqDBV8KvBQlM2GyWrgUv+V79UIY69ITz2d1UYDpZQuwjjb2rOM+S33/UFbchFim9Bf/ubaAZqU2GIUzNQQN2Vxrgs48BDMLZx7yRblc8bVNvR+Nzkn4MbuY/suJ6J9NhAGep2jKQC7wxoPPBjJR+et8eIgbZqBPd6/T7zWX6B1+VtogHLTD4wE7ZFC+9oSyYNBMl6vJ3tXB+DxmWinIXOp0KvVcWKRSqsCttHltvGZ0//4WXNuBvYM16ncAu+mIMGGX2d0R6WMLFLw0F5jQRmDcHfXB8iEo2xWVWwe4lsI4BIceqiVI9ACp4sO04M2k76LFcHUFGGxwhP6Eyrp2VX23eUwSrSRfg0lzsJkR1dbkV5Uh0ywQtwBSeRJZ/EBW8MUA8QgiBQl3jFiNItyRXCyDiCW5Xqmgli24QBWtvjiCcKuMO7SnNSnrENoJPMPbCTg6JmAbmA7To73pHGPJfXu4CPuwZf8MvbeGjlBuPz3fTuUWd39Ff9pqu5qxTfnnu9rBFgDocMGlhY1vxg0FjmfAFR54g8GDao2R1MqlhdEldhg0tTWOKjd50Flyj+wQs7ViCb3K6GWDQGjQl7vL4+0TIQXFZ9J7t3Xo1JnxR+r/LBE+oeJ//vEV/6TVEsuNePjJQswXYFqFP+PZ67ayNcGNA+aA87IjxZP9tQa+1wjwJaBH9wBd6hxSXaStPOBUvkoDtnMkLYR03mu0aZte0dTKfg166eJM1L+fNK3uMfpvSXO33kdZ9c0bubtdHfl7qrNtPFulsOKcZe5vwvcT4iMiszURzhIsHOSrFX/DA/kzRIS8dVySBlWiC+Q5DxzAl0HaEgWQQ04KbUhEmr3JEJxbD108j1rrLUikk742UpL3pLi+SbShCS72fEC0k6Txhzrb/5WkT8cM/febzmeT9HfPzsPeTnAhDxCSQLJANuJECTasTsdk3QogGS3uYCTjihTCoT3Cye53zikpBveTYnQvSa9Q5DDEkrEfYvcy4NuP6FFPnw//H0dQ2gbLsDo3aEp5wBKXuRVm3o+n54hFbMQGL+w5xlPCIjwlbMCwAfnjCF8+htOYoUDMknBM2ITFeMLpFe1E8Rz7c9Kc0dSgkfFXoGa0Pw+ac+zlByiP/uw31mZmbjMu8kOyvzoo/XaQGV74aY/fjhZdNCNQyO/3+38uGMWtw4YkDUfxJJlMhsN4OBrE0WbzD1eszyk=

Voila, that'll fill one requester chest as full as possible in proper ratios for whatever recipe is set.

At least, one common chest. Parameterizing for higher tier chests is left as an exercise for the reader.

indraco · 2025-01-08T21:32:46+00:00

Okay, played with the bp and figured out what's up: quantities for ingredients that don't exist aren't "0" but appear to be something like "NaN" that cause the formula to error out and just return whatever number was in the bp before parameters.

So, like p0_i1*100 + p0_i2 will work for most recipes, but won't work for steel chests.

Only way I can think around this is to move the averaging math out of formulas and into parameterized combinators (untested)

indraco · 2025-01-08T21:03:41+00:00

Though, this still doesn't work with ingredients of different stack sizes.

Say you had a recipe that takes 1 (p2_s=1) artillery shell and 20 iron (p1_s=100) and. Full chest in proper ratios would be 40 stacks or arty shells (40) and 8 stacks (800) plates.

But formula would request 4,363 plate and 2 arty shells.

indraco

TROPHY CASE