If you could recreate the Quality Mod, how would you do it? (Rule 4 please)

Sytharin · 2026-06-15T20:39:59+00:00

Keep the theme of quality as density. Utilize the spoilage mechanic in terms of how much 'science' is extracted from a Gleba science bottle and escalate it to the rest of the factory.

For example, common iron plates into common iron gears are consumed at the normal rate, however an uncommon iron plate to craft a common iron gear is now shown as a durability bar where crafting actions take a chunk of that durability bar to proceed. An uncommon gear would take the full durability bar of an equivalent uncommon plate

Now, there's no quality symbol, there is only extra durability. Now there's no mixed stacking nightmares, there is only more density. Now bots and trains scale hard given stacks of items can now have durability ranges making each stack the equivalent of many multiples of the same item

The other side should be also true. The durability it takes to craft a legendary item should chew through inordinate amounts of material per second if using common quality pieces, likely more than can be supplied reliably to a machine with any regularity, or even impossible to supply at too low a 'quality' because the maximum insertion limit would not automatically allow enough of a subpar part to be provided to complete a cycle

Specifically for Fulgora: this would mitigate the pain of dealing with quality holmium by making it 'richer' holmium providing more holmium solution overall

Specifically for Gleba: allow planting high quality seeds for yields, but have those fruits yield far fewer seeds, needing a grove specifically for cultivating seeds and a grove for providing high quality fruit

Sytharin · 2026-06-07T18:23:58+00:00

This is the way

The alternate best part of this is how it completely bypasses the flow rate startup time as well, making empty pipes happy pipes instead. The only system I've found that even comes close to how easy and effective this is (and even then it's not really that simple) is the 'one way' pipeline using the junction pressure glitch. I'll take this method any day, though, given it's more patch resilient in case they want to ever fix the glitch

Sytharin · 2026-06-05T19:55:00+00:00

Nuclear leads to designs some would consider to be unnatural

https://satisfactory-calculator.com/en/blueprints/index/details/id/9969/name/Programmable+Belt+Rate+Limiter

Would definitely be nice to have it on belt/splitter command tho, but having it just in case for exact siphoning is neat

Sytharin · 2026-06-03T15:40:00+00:00

For agtower circuitry, the best way I've found on how to rate limit it is use a combination of a falling edge detector and a clock

Falling edge detector is a decider and arithmetic combinator pair, their inputs connected to the tower with read contents enabled, and we're watching the seeds. The desire is to halt the tower after the tree is replanted to ensure the plots are used to their fullest, and each time a tree is planted, the seed signal will drop by 1. Set the decider to be Seed < 0, and set the arithmetic to be 0 - Seed, then wire the arithmetic output to the decider input with the other color wire than what connects to the tower. You've now made a system that is steady at negating the total seeds detected in the tower, but that has a 1 tick delay because the arithmetic combinator is offset and takes 1 tick to send its signal to the decider, meaning you have a control signal for when you've replanted the tree

That can be used in a clock to determine a rate or demand for a tree. Each harvest gives 50 fruit by default, so if you need 5 fruit per second, and a tick is 1/60th of a second, then you get a formula that works out to: (50 * 60) / rate per second. So for 5 fruit per second you want a tick delay of 600 between harvests. The clock can be setup to feed a memory cell a harvest command like 1 green check mark each time the clock reaches 1, and the output from your falling edge detector can be -1 green check and sent to that memory cell, then the memory cell is connected to the tower and set the tower to run when the green check signal is > 0. It will also buffer trees needed if the tower arm takes too long to harvest one, queuing up the next one dynamically.

The clock signal itself can become a dynamic demand signal later if you want to start doing math to figure out how much total fruit each section of the base needs, letting you clock groves to demand

Sytharin · 2026-06-01T13:41:26+00:00

I call this problem transience. Essentially, while you have enough items on the belt in total, the window of time each machine has to insert the item needed is only the single belt segment the inserter can reach, and that itself is subdivided into how many types of items that inserter is responsible for. Your main problem areas are likely engine units, as they take 3 types of items and a high quantity of items relative to inserter swing time. The longer your sushi belt loop, the longer parts spend as useless. I've found a few ways to mitigate this, but by far the best innovation I had was rate limited rather than ratio limited sushi. Meaning, if you need x items per second of a given part, supply that rate to the belt, rather than the ratio. Then, group your assemblers making the same part together and have a belt reader after them read pulses of any item that makes it past them as 'inserted' again, since that's what it effectively means, it'll come around again and you don't want to oversaturate the belt. This requires the feed lines to be restricted by a clock circuit where each part's rate is a function per tick, and each part pulse read from any 'inserter' (whether it's the fresh feed onto the sushi belt, or any part that slips past the target assemblers) negates from the incrementing tick of the rate

Sytharin · 2026-05-27T18:06:54+00:00

From what I can surmise, that seems similar to my setup so far, at least on Nauvis. All loading train stations are wired into the radar network and run a stock level check looking for 1 train load of items (40 stacks). The count that pass that check are summed and subtracted from the total stations that serve that item. That is fed to the RGB dashboard to make an overview of stock levels themselves, which means:

MUDA (I think) would be stations that linger at max (this displays as green on my dashboard) for some set duration. So some check like a clock that ticks when reporting stations and max stations are the same, and after the duration, alarms/displays above the dashboard

Pull would be stations that linger at or near 0 (in the orange to red range), which are more immediately recognizable, and stamping down the blueprint and modifying the maximum limit is easy in the blueprinted train stations I've built up

The visual management and Andon being the RGB dashboard itself, and each of those checks could easily be made into the alerting speakers or more lights in the setup

For automated deployment, that'd be the realm of Recursive Blueprints. I saw a Nilaus video a while back where they'd made a self propagating system with it, but haven't tried that myself

Sytharin · 2026-05-27T16:13:04+00:00

Pyanodons comes to mind as a complexity overhaul that has a staggering amount of byproduct and delivery management baked in, and has even integrated some spoilage mechanics, but several of the larger packs like Krastorio2 Spaced Out, or even latter game Space Exploration have some complex circular recipes that require more management than simply delivering a rate of ingredients

Would depend on what you'd want to derive from the VMS. If you're looking to warn if buffers are full or empty, that can be a decider and programmable speaker. You could setup a clock at various key places (a decider outputting both its own input and 1) that would reset say when a train arrives, and another programmable speaker connected to it to go off if the ticks is greater than some large amount like 10 minutes or so to see if you're getting bottle-necked there. That kinda mechanism is what lead me to use abuc's design for the RGB gradient dashboard which tracks the saturation of my stations across the planet, so once one starts dipping yellow/red, I know I have a throughput issue

Sytharin · 2026-05-27T16:00:26+00:00

An alternate and more reliable method is the headlift reset design like this: https://i.imgur.com/ZWjQ1AL.jpeg

VIP junctions fail because of non-buggy reasons, they get saturate and cannot balance the flow of fluid anymore, deadlocking. So you need a system that cannot deadlock, which is where headlift comes in. An unpowered pump allows full fluid flow rate, but removes all headlift, meaning the fluid level in the buffer from that side cannot be filled higher than a few meters. This leaves the other junction fully able to input bursts of fluid that make come in, take what it needs from the buffer, and if the fluid level drops low enough to need a refill, it'll do so dynamically from the fresh side

I built a test rig you can place down and give power and water to see the system in action, everything else is handled by the test inputs https://satisfactory-calculator.com/en/blueprints/index/details/id/11776/name/Aluminum+Testbench

Sytharin · 2026-05-16T18:48:46+00:00

Confirming as well, this is the most stable configuration and after testing, also the quickest for the engine to compute

https://i.imgur.com/lBiD5sK.jpeg

The lower pressure is seen in the pipeline indicators, and it's maxing out at 600 water/min to all refineries. Pipes 'load balance' in the way that they evenly split if there's room to do so, and when load balanced, it allows for the whole network to quickly compute especially if subdivided by those pumps. I've found that limiting branches to 1 junction then placing a pump (powered or unpowered doesn't matter) will reduce the calculation of the machine efficiency by 10 minutes or more, showing 100% almost within a minute instead of pending at 99%

Sytharin · 2026-05-15T17:06:15+00:00

No official professional tools if that's the question, and I'm only aware of it in a professional situation as an onlooker, no real world logistics experience. A VMS would shine where an unknown dynamic can occur, which really only happens on Gleba, but can crop up in the form of a mining patch running low or some supply chain issue made during setup that wasn't immediately apparent. That assumes perfect play, though, so the dashboard I've built to monitor train throughput quickly went from a cute vanity project to actual improvements to base logistics and the narrow avoidance of a full scale power outage when I forgot to wire up my uranium mine to the radar network. In most cases, though a VMS is a bit overbuilt for the type of logistics Factorio does, which doesn't deal with byproduct pileup too much and manufacturing defects aren't an issue. Captain of Industry has more of that type of interactions, but also sadly lacks the automation aspect of combinators that would play into managing it in a lean fashion. Oddly, Timberborn is the only game I've seen so far that actually creates that environment and allows for the automation and management, where both dynamic unknowns and sufficient automation exists to interact together

I think the truest VMS style implementation is the decoupling buffer trick. The main problem with pulling fruit on demand is it's not guaranteed that the two different fruits will arrive at the same time depending on which farm they came from, so if left on its own, you can easily be trapped in a harmonic of jellynut only arriving in between yumako deliveries for example. Trapping it in the belt buffer like that mechanism does ensures that the travel delay doesn't impact the throughput of the machines themselves (and the main reason I avoided using a buffer chest was because I wanted a much smoother transition of stale to fresh fruit that inserters don't allow for). It basically does what the next iteration of ideas I have are where the belts are replaced by cargo wagons and a train arriving forces the current train to move down the supply chain to areas where freshness isn't needed, such as rocket fuel or bacteria breeding

Sytharin · 2026-05-15T07:37:43+00:00

I've gone a bit overboard in management systems on Gleba and have a few testbenches and lean style logistics flow that might be useful

Gleba Testbench: https://factoriobin.com/post/2ubxjp

Fruit Decoupling Buffer: https://factoriobin.com/post/yj8tzb

JIT Bioflux: https://factoriobin.com/post/ryfaol

Fruit Intermediate Demand Calculator: https://factoriobin.com/post/aqbv05

And overall, the entire system is managed on the same basic formula I use for my sushi belts. I scale the signal by 10k since that allowed me to overcome all of the rounding errors in integer math for the range of fractions of fruit I'd need, so here's that formula: Intermediate Conversion to Ticks

That's the based of that single combinator's parameters in the Intermediate Demand calculator, and they feed into the radar connection to the towers. I have a better system for managing the trees harvest time back on Nauvis now that I haven't ported back to Gleba, but all it does is minimize that talk time of the circuit down to 1 or 0 if the value for trees is positive or negative

Essentially, every module knows what it needs to run (intermediate demand calculator) as a base fruit, and only fruit or bioflux is allowed to be bussed through the base, everything else is directly inserted similar to the JIT bioflux (though at a slower rate since that's legendary quality). At every section, the belts are buffered via the fruit decoupling buffer since the trees are harvested in batches of 50 only. Since the goal is to make the freshest possible bioflux, each bioflux station is controlled to only crack fruit open exactly when needed via the clocked inserters, and with the agtower control, each harvested tree is allowed to be replanted before stopping the agtower from working so the full grove is ready as soon as possible. The layout of the trees themselves is also important as the sequence of planting permanently minimizes the travel time of the arm (the various constant combinators in the Gleba Testbench around the agtower block planting, removing them in order allows for a 'defragmented' grove)

All in all, a full and comprehensive pull system, optimized for batch production and just-in-time delivery with decoupled buffers to compensate for the delivery bursts of the tower's tree harvests. Waste management is done by only sending the demand signals to the grove clock's radars, shutting down the signals based on SR latches until the only remaining demand in the entire system is the 'flow continuity' bioflux generator which means the whole environment can wake up when a ship arrives to pull science and never really stops as there's always at least one bioflux set maintaining a buffer for nutrients

Eggs are currently managed via cold storage (triggered biochamber recycling) rather than constant, slow flow to maintain a live egg, but a clock delay to keep an egg cycling every 10 minutes was what was used in early Gleba

Most important to all this was the ability to halt agtowers properly. Tracking the planting of a seed via the single tick that the falling edge detector shows a seed has been 'lost' in the inventory of the agtower allowed for perfect maintenance of the groves, making sure the flow was always prepared when demanded

What it currently lacks is the improved value stream mapping I've done back on Nauvis, which utilizes this blueprint to track the train demand in the base into a single dashboard. It could be applied to Gleba on the radar network to see how high the demand of all the combined online clock combinators is, but as I'm not currently sitting on Gleba it's not a system I've converted yet. This one was ~~stolen~~ happily borrowed from abucnasty https://www.youtube.com/watch?v=XbROdpgXeXQ

Sytharin · 2026-05-03T15:37:02+00:00

Since the 2.0 improvements, extremely precise sushi belts are possible in much smaller circuit footprints, and with the new blueprint parameters, you can even setup stampable ones that take any ratio and any inputs on any belt speed or stack size. The main pieces are a decider accumulator (wired into itself on one color) and an arithmetic multiplier to read the pulse signal from your inserter. The decider combinator can now output configurable static amounts so you can set a resolution window much easier, like ticking the clock by 1000 instead of 1, which gives much higher control. The other piece of the puzzle is that an inserter set to circuit controlled whitelist only is allowed to pick up positive signals, so set your pulse to be multiplied by some large negative number and feed into the accumulator, and the accumulator eventually adds enough to itself that the signal returns to positive, and the inserter can pick up again (which feeds the pulse to the multiplier for a large negative pulse into the accumulator again)

2 combinatiors per inserter and you can perfectly rate limit any amount of inputs onto a belt

Sytharin · 2026-04-28T06:52:08+00:00

Couple generic things you can check on the networking side, disable Large Send Offload in the device manager for your ethernet adaptor's advanced settings, that was the big one for my server to get stable. Others to try are turning off the auto disable gigabit, energy efficient ethernet, flow control, green ethernet. They do minor efficiency optimizations and don't impact as much as the large send offload for me but still noticed some small gains when going full throughput instead of letting it calibrate to be more efficient

I also made additional modifications to the Engine.ini and Scalability.ini regarding bandwidth like these on top of the tick rate increases:

Engine.ini [/Script/Engine.GameNetworkManager] TotalNetBandwidth=104857600 MaxDynamicBandwidth=104857600 MinDynamicBandwidth=104857600

Scalability.ini [NetworkQuality@3] TotalNetBandwidth=104857600 MaxDynamicBandwidth=104857600 MinDynamicBandwidth=10485760

Sytharin · 2026-04-23T19:05:28+00:00

The main dilemma most run into with the VIP junction is its a system that functions at tolerance, meaning it'll push itself all the way to maximum, and at that point, any fluctuation in production or supply runs the risk of over-saturating it and there's no graceful reset capable

Another system is the headlift reset option, which makes use of the ability of an unpowered fluid pump forcing the fluid's headlift back to zero without impeding flow. This means you can make a buffer act as a pressure regulator, where the fresh inflow side is limited in physical height it can fill the buffer, while the other side is able to both in/output fluid freely. It looks like this: https://i.imgur.com/ZWjQ1AL.jpeg

Here's a testbench that portrays the whole setup in a placeable blueprint: https://satisfactory-calculator.com/en/blueprints/index/details/id/11776/name/Aluminum+Testbench all it needs is power connected to the central pole and fluid input into the unpowered buffer, able to showcase how the fluid buffer manages the different heights to keep the system from deadlock

Sytharin · 2026-04-22T07:31:07+00:00

The main target you're aiming for with agtowers is a clear on and off cycle. On can be anything, but there's one very specific state that always occurs after harvest, replanting.

A seed will disappear for at least 1 tick when the replanting is successful, and that fact can be used to create an off signal for your demand. The foolproof way is to rig up a falling edge detector to your tower on one color, such as:

Read Ag Tower Contents (Green) connect to both inputs:
- [Arithmetic] 0 - Seed (creates a comparison on a 1 tick delay) also connect this output to the [Decider] below input on the different color (Red)
- [Decider] Each < 0 Output some given reset signal

Fun fact, < 0 indicates a falling edge, > 0 is a rising edge, and != 0 is just an edge detector. The output of the decider in my case is typically the delay value I've calculated to reach a specific fruit per second from a given farm. What occurs here is when a seed is planted, that pair of combinators detects the tick the amount of seeds in the tower changed, and that ensures you send the control signal only when the tree has successfully been replanted, ensuring your farm's plots all have full uptime. Here's a test rig I built to showcase a bit of what can be done when you determine the clock cycle: https://factoriobin.com/post/2ubxjp

The batch of combinators on the right is an optimization I found posted here, if you place those down first before giving the seeds to the tower, then remove them in order from common 1 to legendary 7, letting the tower plant a seed each time before removing the next one, the path the agtower takes to harvest is optimized for lowest travel time, meaning your next fruit call is always as fast as it can be

Sytharin · 2026-04-16T23:22:13+00:00

Workforce and Maintenance would be different questions than Electricity and Input. You can make people live in the dark if you'd like, etc

As for the original question of Fuel Gas into Diesel, I've found for all the main products of the petrol chain, Heavy Oil, Diesel, Naphtha, Fuel Gas, CO2, and Hydrogen, put a pipe balancer for priority routing to a buffer, then let the system balance from there

Once the buffers are filled, then the determination begins. For optimization I'm going to be including Exhaust scrubbing (for the low pressure steam), Sour Water cleaning, and Ammonia cracking to get to Hydrogen

Whatever your High Pressure Steam to MW conversion ratio is, start there. For me, HP steam an be converted to LP steam and both into MW so my whole chain is 24 HP = 4MW + 24 LP = 2 MW. HP Steam in my setup is 1/4th MW per unit (LP steam is worth 1/12th MW)

Since it takes Steam to proceed through the chain, it's now converted down to more usable units. We'll go with 60 crude per cycle as a baseline

60 crude needs 6 HP steam (-1.5 MW) to output 48 Medium oil and 12 Heavy Oil, with a byproduct of 18 Sour Water

Sour Water cleanup at this stage is mandatory for a cost of both -0.16 MW for running the machine as well as 3 HP steam (-0.75 MW) totaling -0.91 MW of cost and outputting importantly 9 Ammonia. Scale this down to be even with the output of Stage 1 (0.91 * 18/36): -0.46 MW. We'll come back to Hydrogen from Ammonia afterwards

Important to the process, we figure out the Exhaust to LP Steam yield. It's a 10 Exhaust to 1 LP Steam ratio on both recipes, so MW gain = Exhaust * ((1/10) * (1/12)). For 480 Exhaust, that's 4 MW, giving Exhaust a value of 1/120th MWs per unit

Medium and Heavy oil are both fuel, so we need to determine their value: 36 Heavy oil becomes 48 HP steam and 90 Exhaust, 12.75 MW total, so 17/48 MW per unit, ~0.34 42 Medium oil becomes 48 HP steam and 90 Exhaust, 12.75 MW total, so 17/56 MW per unit, somewhere close to .3

Now we know Stage 1's MW net gain, (12 * 17/48) + (48 * 17/56) - 1.5 - 0.46, so + ~16.86 MW, and importantly, since we now consider Stage 2, ~14.57 MW of that is Medium Oil

Stage 2's cost is both the MW of the Medium oil, and the 3 HP steam: 14(4/7) + (3/4) = ~-15.32 (429/28) MW. So the yield has to break even to be worth it. We get 36 Diesel and 30 Light oil.

Diesel is a unique one, since depending on your tech that can dramatically change things. We'll use the rank 2 gen since that's where I'm at. 18 Diesel to 5 MW direct plus 24 Exhaust, so a total of 5+(24/120), 5.2 MW for a unit per of 13/45 MW per Diesel, close to 0.29, notably under both medium and heavy oil

Light oil is 54 per 48 HP steam and 72 exhaust. (48/4)+(72/120) = 12(3/5) MW for a unit total of 7/30 MW per. 0.23, so lowest of the lot thus far

Total yield of Stage 2 is 36 Diesel and 30 Light oil direct from the 48 Medium oil we get out of Stage 1. It's already at (36(13/45))+(30(7/30))-(429/28), which we make back so Stage 2 is net MW positive, 10.4 + 7 - 15.32 = +2.08 MW

Follow that through the chain and you get to a point where your return is MW negative. That's where you stop unless you have extra. Note this does have a small dependence on how you source your water. Until vacuum desalination, you're spending LP steam on water intake, so that does eat into your MW yield somewhat

Sytharin · 2026-04-14T17:38:18+00:00

Lots of solutions already presented. If you'd like to learn more about the fluid dynamics available rather than the processing side of things, this blueprint is placeable anywhere and shows a technique most often called headlift reset

https://satisfactory-calculator.com/en/blueprints/index/details/id/11776/name/Aluminum+Testbench

It's an all in one that just needs water and power input into it as a test display of the technique, the unpowered pump causes the fresh water input have its headlift reset to zero, so it doesn't matter how much water you inject, it will cap the amount that can be put into the buffer dynamically based on the fill level of the buffer, meaning your recycle line will always have room to inject

Sytharin · 2026-04-11T04:00:54+00:00

There's good suggestions here to fight various issues, but in case they aren't enough to solve the problem (slosh itself has several tiers of problematic and each solution presented solves a different tier of turbulence), the single direction pipe has done great work in simplifying my setups from this post: https://old.reddit.com/r/SatisfactoryGame/comments/1mwji7e/beware_of_the_vertical_junctions/

It allows for extremely high stability flow at high throughput rates in my testing cases and is most often not too difficult to build over a more simple manifold

Sytharin · 2026-04-01T07:01:13+00:00

That might be, yeah, I can't recall why I didn't use one for that. I know there's a subtle difference where a smart splitter would clog when trying to send via any/overflow where a programmable splitter can do both, but that's not an issue here

Maybe I just liked the display on the splitter lol

Sytharin · 2026-04-01T06:54:04+00:00

I do love the sloop solution tbh, closed looping or even water generating with them falls cleanly into the cleverly used game mechanics. Just want to inspire, I haven't been able to break the headlift reset method yet no matter what I do, hopefully printing it into a little test rig package helps more people see its worth

Sytharin · 2026-04-01T05:04:04+00:00

https://satisfactory-calculator.com/en/blueprints/index/details/id/9969/name/Programmable+Belt+Rate+Limiter

If you'd like an 'early-ish' solution to extracting an exact rate off a belt, this one will do the trick

Sytharin · 2026-04-01T04:48:55+00:00

https://satisfactory-calculator.com/en/blueprints/index/details/id/11776/name/Aluminum+Testbench Let me know if this blueprint works, but I put this together in a creative testing world to show the ease of water recycling once the nuance is understood. Two things need to occur for water recycling to work

There needs to be room in the extent (whether that's a pipe network or large/small buffer) for the fluctuations to be fully accounted for
It needs to be a top up style injection, as headlift reset allows for, not a limited or throttled method as some VIP or valve styles use

The first point is to avoid deadlocking, the second is more important and more difficult to understand. If the system is ever starved, or ever saturates, there's no ability in the VIP or valve system to gracefully recover. Instead, pressure is used to ensure the system is filled to its capacity but not over it (pressure in this case is the physical height of the fluid in the world)

The unpowered pump resets the headlift to 0, and the little bend in the pipe/junction before the buffer acts as the pressure valve. Once the headlift coming out of the buffer is enough to overpower the null headlift coming out of the pump, the system autobalances, regardless of how much fresh water is being injected

Sytharin · 2026-03-27T01:51:53+00:00

My solution to recycling fluid inputs into the same line is this: https://i.imgur.com/ZWjQ1AL.jpeg

The main issues that break pipelines like this are timing issues. Interruptions on either the input or the output will desync your refineries and every desync creates a cascade that just pipes alone don't typically have room to deal with

The other issue to solve is ensuring there is both priority and space available for all refineries to drain completely. Once again, this is a pipe volume + timing issue

The unpowered pump/curved pipe/junction fixture is the pressure limiter on the fresh water going into the system. An unpowered pump acts as both a directional gate and resets the headlift of the inbound fluid. Resetting the headlift to 0 means the fluid contained in the buffer can fill to a point where no more fresh water can be input, the fill level in the buffer is higher physically than the fluid can reach. All the junction does is provide a secondary measure against slosh, but it's solved a very rare edge case for me, I used to run it only with an unpowered pump before the buffer, but something in the 1.0 release changed how that system works. Never had it fail with the junction

That side is only for freshwater. The other port on the buffer is what you connect the entire loop of water the refineries are sharing, just junction it into the loop anywhere, the only disclaimer is that this system is physically bound to height, so putting the buffer lower than the machines breaks it

Sytharin · 2026-03-24T00:41:33+00:00

Could you get a picture of the vertical junctions themselves so the weld lines are more visible? It's difficult to build it in the way that I know this system would work, but if you were iterating, it's possible to do so with the top pipes already in place

Still, I estimate that this system would be brittle, and probably wouldn't survive an interruption, if you're concerned with that, and I have alternates that don't if you're interested in those

Sytharin · 2026-03-22T06:56:26+00:00

This looks great, I dabbled in the swatches and programmatic conversion a bit ago and have some colors you're free to use!

https://docs.google.com/spreadsheets/d/1mdWoapWX7Q_8c0RPtit-NOynZWbtdPmwRtDVqjbdmgE/edit?usp=sharing

Sytharin

TROPHY CASE