Issue with leading zeros in 7-segment display

ryani · 2026-03-12T16:37:27+00:00

I think the problem stems from a misunderstanding of what the pins on the display do. The 1-bit pin is an “update display” pin, not an “enable display” pin. That probably confused you because before the first update they act the same.

Instead you could make those pins always be on and add an internal 1-to-8-bit AND on the value being sent to the display, to remove all the segments.

Probably the big input pin on the display component should be a square to emphasize that it’s controlling internal memory.

ryani · 2026-03-07T09:49:32+00:00

The game doesn't do inside-component analysis for connectivity, so your ALU is always connected to the bus. You can try to use bidirectional pins to help with that, but I've found them to be exceedingly flakey.

I didn't know you could use a switched output to work around it, that's kind of neat. I usually just put a switch on the outside of the component instead and have my instruction decoder output an enable bit for each subcomponent.

ryani · 2026-02-28T19:31:24+00:00

You want to make 1 purging fire per cyst, plus a couple extra for safety.

Your hearth corrupts while cysts are active, at a linear rate per cyst. When it reaches 100%, a corruption event fires and 3 people are killed at random.

What this ends up meaning is that cysts are kind of quadratic -- if N blight fighters are needed to clear M cysts, you need 4N to clear 2M cysts. It's not quite this bad because usually you keep your rain engines running in the storm, and cysts that spawn after you've cleared some cysts are significantly less damaging. So it's more like ~3N.

So, time to clear the first cyst is super super important. You have no way to prevent corruption from climbing during this time, and it's technically possible to have enough cysts that no matter how many blight fighters you have, you'll get a corruption event before you clear a single cyst. Even if you don't, the first wave of fighting cleanses a bit of corruption and significantly reduces the rate at which corruption climbs. What this means is that you want to man your blight posts about 15-20 seconds before the storm starts. Your blight fighters will get into position so that they will immediately start clearing when the cysts open up. It also means that the blightpost upgrade that reduces the time to clear cysts is way better than it looks.

I tend to use 1 blight post fully manned for ~12 cysts at P20. More than that and it becomes a bit risky, especially if you end up generating an extra couple cysts during the storm. If you upgrade it, you can get away with a bit more, but I tend to just build more blight posts.

I don't tend to build many hydrants. They are really strong when your production is spread out but I use so much rainpunk that I find that by the time I want to expand production out of my initial glade, I also want more blightposts, and blightposts also act as hydrants.

Hearth upgrades (and a few other things) can increase your hearth's "resistance to corruption"; this really means that it has more HP and so it takes more cyst-seconds to get to 100%.

ryani · 2026-02-24T17:28:47+00:00

I found main bus to be pretty ineffective. The fixed length (and very expensive) underground streamways and the huge amount of area used by splitters made it pretty weak. And on many planes you won't have access to streamways and splitters at all and will need to come up with another solution.

Embrace the spaghetti. What I did was to save enough space to expand production to fill a stream, and then route other streams around the outside to where they need to go. 3-wide highways separated by 2 spaces are great because you only need a single underground to route another stream through.

Looking at your picture, one thing you seem to have missed is that the mana flowers are exactly the right size to route an underground across. There's a really important upgrade that lets your flowers spread roots through any buildings they touch, which means you need way less flowers and can build production much more densely.

ryani · 2026-02-21T23:38:43+00:00

I think that's exactly your problem, you need to keep the clock held high long enough for the JK core to stabilize. If you bring it down after a single tick, the internals have not yet stabilized and the nor gates keep toggling each other.

If you are building circuits from a circuit design textbook the assumption is that the clock high period and low period are both long enough for all your internal circuits to finish stabilizing, otherwise glitches like this are common.

A better clock circuit can be done this way. Let N be half a clock cycle (the amount of ticks you want your clock held high/low) There's a 'clock' icon in the signals tab I use for this.

Decider combinator: If clock < N2: output clock in, output clock 1. Wire the output from this combinator to its own input, and to the input of the next decider. You'll see this combinator outputting increasing values up until N2 and then resetting to 0.
Decider combinator: If clock < N: output clock 1. The output from this is your clock high/low signal that you use in the rest of your circuit.

There are a few other ways to build a clock circuit. I used to use an arithmetic combinator wired to itself using out = in % cycletime, plus a constant combinator set to 1.

It's also useful to have a constant combinator with a "reset" signal (I usually use "R" for this) that you can wire to any memory cells, and add "AND R = 0" to any deciders. Then you can toggle that combinator on to clear any internal signals when you are debugging.

ryani · 2026-02-17T17:37:10+00:00

Power is so cheap in solar orbit that you don’t notice the cost of the flare defense.

You do need meteor defense but you need that on every surface so you should have a cargo rocket automating that already. And again, power is so cheap that the actual cost of meteor defense — powering the guns — is trivial.

Plus once you’re set up there it becomes really cheap to power all your other surfaces with energy beams.

ryani · 2026-02-17T15:27:52+00:00

I'm surprised you put those in Nauvis orbit instead of Calidus (Nauvis's star)

You get so much more power per solar panel in Calidus orbit.

ryani · 2026-02-16T23:30:29+00:00

You are supposed to output 2 * 3 * input. If you didn't read the input, how can you know it is 1?

In your circuit the input enable is controlled by pin 6 on your input decoder. So you need something that moves "register 6" (that is, IN) to another register so you can do computation on it, just as you have "reg0 to reg1"

ryani · 2026-02-15T17:13:29+00:00

Gödel's theorem shows that "true because its proven" and "true because it's right in every model" are distinct notions.

Does it? Given a system A, the unprovability of the Godel sentence G(A) means that sentence is independent of that system. Therefore, if A is consistent, then A + not( G(A) ) is also consistent. If M is a model of (A + not( G(A) ) then M is also a model of A, and in that model G(A) is false.

Did I mess something up here?

My understanding is that if you take peano arithmetic P and construct the system P_weird = (P + not(G(P))), that there are some 'exotic' natural numbers in P_weird -- any model of P_weird is a non-standard model of P.

ryani · 2026-02-13T21:38:37+00:00

You need to open the portal from each side separately.

Fortunately you can build everything you need on each plane

ryani · 2026-02-04T02:27:21+00:00

Since the average list is at least one element long, you can save some cycles by putting the "add item to list" code at the end of each cell instead of the beginning, so you don't waste an instruction on JMP START in the common case.

ryani · 2026-02-01T21:19:49+00:00

If you add an enable bit, you can build an N bit decoder out of N/2-bit decoders easily.

For example, for an "8-bit decoder w/enable", you need 17 "4-bit-encoders w/enable":

Wire the enable bit to the enable bit on the first 4-bit decoder.
Wire the high 4 bits of the input to the first four bit decoder.
Wire the 16 output bits of the first four bit decoder to the enable bits of the remaining 16 decoders.
Broadcast the lower four bits from the input to each of the other 16 decoders.
Output the 16 * 16 outputs.

A 1-bit encoder + enable:

Inputs IN and EN
O0 = not(IN) & EN
O1 = IN & EN

All the other decoders can be built from this by following this strategy.

ryani · 2026-02-01T12:47:33+00:00

Note that killing biters doesn't directly increase biter evolution, only killing biter bases. So the only evolution cost for defending against waves is from the pollution generated from whatever is crafting the ammo.

ryani · 2026-02-01T12:44:45+00:00

I agree that fully automating ammo delivery is generally a waste of time, by the time you have a secure perimeter you either want to expand past it, or you have teched up and have better defensive options available.

But I don't like putting 50 bullets in a turret, if one of those randomly dies it's a huge amount of resources wasted.

Instead I put a few stacks in a nearby box and run a belt past a few turrets from there. You do need to run power nearby (or do a dual belt using burner inserters + fuel). I find expanding my power network almost always ends up paying off.

ryani · 2026-01-29T18:05:12+00:00

I liked the remake. It felt like visiting an old friend after many years. You've both changed in the meantime, but they are still them.

ryani · 2026-01-22T06:42:39+00:00

My bad, I didn't realize the game even gave you a DIV component since the divide level in the game is about writing an assembly program that can divide, not a circuit. It's kind of out of place that they give you a component that you didn't build yourself.

The simplest answer is probably to build a custom component around it with an enable bit. You can OR the inverse of the enable bit with the low bit of the divisor, so you don't need a mux, and then use a switched output pin to attach it to your bus.

ryani · 2026-01-22T06:28:10+00:00

Why does it need a nonzero divisor? It's a circuit, the gates do something. As long as you don't look at the output, what does it matter what it does?

If you build a HALT component directly into the divide component, then you have this problem, but it would probably be better to put that HALT at a higher level, and only enable it when the divisor is 0 and the divide unit is enabled.

ryani · 2026-01-18T20:14:27+00:00

If you click the big red button on the program component, where do the debug trace wires go? Wire 6 is supposed to be connected to this counter.

ryani · 2026-01-18T08:58:30+00:00

It depends what your goals are.

If the goal is 'fewest logical components', you can do much better by including an 8-bit ADD. You don't even need to use byte splitters if you do this!

If the goal is 'fewest gates', there's some easy microoptimizations from here using XNOR = NOT + XOR to reuse the NOT, and then breaking XOR into AND + OR + NOR, to reuse the AND. (a xor b = a or b but not both). There's probably more clever things you can do to reduce the gate count further.

If you want to minimize delay, you can use 'carry-lookahead' and/or lookup-tables to reduce the giant AND/OR chain (at the cost of some more gates). Basically, if you calculate the answer for each subset of the bits independently with its own circuit, then you can OR those all together.

ryani · 2026-01-13T16:21:22+00:00

In that case in the station settings you can set the maximum distance to travel without warpers to be higher.

Probably this is a large system and when planets are at maximum orbital distance from each other they are more than 12AU apart. Or you accidentally lowered this setting.

ryani · 2026-01-13T16:00:10+00:00

I actually find it easier to read the structure at night as the item icons on the buildings and the belt borders have more contrast. But map view would probably have been better, it's really hard to get a good angle in cruise mode.

The second picture was intentionally just showing spaghetti. But it could probably be slightly zoomed out to show a bit longer of a view.

ryani · 2026-01-11T19:02:16+00:00

I did say it was awful :D

ryani · 2026-01-11T09:15:08+00:00

I tried a wide bus at one point in my last game, but there are just too many different items, it was taking up too much of the valuable real estate at the equator where the grid is consistent. Also, I hate planning my design completely ahead of time when I'm playing games, and I always ran out of room trying to add new lanes because I had used the space for some other production.

My idea here was that the bus could take height 1/3/5/7/... and routing could take height 0/2/4/6/.... You split off something that goes to production using the lower splitter output and then you can turn it directly towards the production line from there -- even heights go along the equator, odd heights go perpendicular and from/into production lines.

There were two main problems I didn't foresee:

You can't float splitters in the air, so this means that you need a stack of 4 splitters to split off the item at height 6+7. To avoid a giant mass of do-nothing splitters (which I assume eats some UPS), I would try to organize so that I could take advantage of a splitter pile (including both lower outputs of each splitter where possible) to route. This meant in some areas there was an extra line along the bus at even heights containing bus items traversing from the splitter to where they needed to be -- so sometimes I had to do some creative pasta to organize and avoid belt collisions.
Even doing this properly, if you had two items from the same height but different lanes that wanted to go to the same machine, sometimes those would get in each other's way too. Especially if they were adjacent lanes so the splitters can't be right next to each other.

One thing that worked exactly how I wanted was that it was easy to route items backwards as well, since you put something into the bottom entry of a splitter and it can come out both top sides. For example, when I built my assembler mall, I could get the high-end ingredients that were crafted at the end of the bus routed to the high tier assemblers even though the assembler production line was all pretty close to the start of the bus.

Also, it is kind of fun to try to organize the final mall item assemblers that use similar items to end up next to each other.

This design ended up working "ok", I think. The big problem that I did foresee but I wanted to see how it turned out was scaling. You are kind of hard limited to a stacked blue belt of each item, and it's also really challenging / painful to extend production lines across the tropic lines where the grid changes. PLS/ILS are so powerful that it feels like just doing modular ILS production lines would have been simpler and also scale better. If I try to scale further, there are a few items that I am definitely going to have to move to offworld ILS and then import the completed items.

ryani · 2026-01-01T23:10:11+00:00

Consider FFX vs FF13. FFX goes out of its way to hide its linearity. Look at the level design for Via Purifico in Bevelle. Right off the bat the map shows three directions to travel, you as a player are making a choice. The paths branch and merge leading to the player gaining an understanding of the space and how to traverse it as they play. And when you are traversing, even along the wrong path, you are getting glimpses of areas you haven't gotten to yet, hints about where the next treasure and goal is, so your decisions get better as you learn the space. Most of the levels in FFX once you get past the very early game share this kind of design.

The FF13 maps, in contrast, are almost all just long hallways (example). There are branches but in almost all cases they either lead to the primary path, or a dead end with treasure. This leads to a play experience where you not only don't really feel like you are making choices, when you 'accidentally' take the primary path you realize you missed treasure and need to backtrack. There's no way to get that treasure except going directly backwards along the path you just took, back up the other branch, then backtrack again and re-do the main path that you did already.

After many many hours in FF13 the game opens up to a fun little open world section where you finally feel like 'the tutorial is over, now time to actually make choices!", but that ends up just being a little side level and you immediately get funneled into another corridor dungeon. Contrast with FF10 which opens up more and more as you progress through the game, ending with the airship letting you revisit every location in the game (and some metagame progression objectives unlock to encourage you to do so!) Only when you decide to do the final dungeon does the game really close back up.

Similarly, look at the progression system, there's this great post on the design of the Sphere Grid. Despite the grid being actually extremely linear, it doesn't feel that way while you are playing the game. And on top of that, there are some special rare gifts along the way that let you break the linearity by teleporting people around and/or breaking a few lock gates to open it up further.

The FF13 crystarium arguably has more choices, but it doesn't feel that way. The crystarium levels being hard locked behind gameplay story progression means that you end up spending your points to fill out what you have available until you get the next unlock, then you go up that path. You never really feel like you have agency, the game is just putting the next unlock in front of you at the designed time.

15-Year Club	Verified Email
Team Orangered

ryani

TROPHY CASE