Balancing for consumed tools

[gammaprime]

I have a plan for a mod that involves "tooling" to make certain items. The tooling can be consumed/damaged by the process.

It seems like the way to do it is have a recipe something like either:

• (1 tool + X ingredients -> Y% tool + Z products). This is how it works for Angels Bio wood: 1 saw blade + 1 tree -> 6-8 wood + 90% saw blade. IMO that's balanced a bit towards over-use of iron (1 blade worn to nothing for 60-80 wood is some hard wood), but iron is cheap (we all have enough iron, right? right?), so whatever.

• (1 tool + X ingredients -> 1 damaged tool + Z products). This is like slag slurry -> mineral sludge in Angels, which needs the filters to be reconditioned, but the filter frames are infinitely reuseable. You could have the reconditioning process occasionally swallow a broken tool in addition to whatever material is consumed by the reconditioning process (e.g. coal in the coal filter example).

As far as I know if you do (1 tool + X ingredients -> y% damaged tool + Y% tool + Z products), where y + Y <= 100%, there is the occasional chance of it generating both a damaged and undamaged tool from a single input. On average you don't get free tooling since sometimes you get nothing from your input,but it'd be a quirky mechanic. Not so bad, but not ideal.

My problem: I want to have very expensive tools, that take a lot of ingredients, complexity and time to produce. Orders of magnitude more than what they are used to produce.

If the recipes aren't heavily skewed like (1 tool + 1000 ingredients -> 1 damaged tool + 1000 products), you might need a lot of tools in circulation between these machines and wherever the tools are fixed to keep the machines tooled up. For example for Angel's trees, you need to have a saw blade available for every single tree that comes along. That's not so bad when the blade is not damaged, as you might be able to cleverly filter insert. If the resulting tool is damaged, however, it has to head off somewhere to be fixed, so you need a new one on hand while that happens. If your fixing station is far away (maybe a train ride), you need a lot of very expensive tools in the system. Not only is this a lot of resources, but you need to oversize the tool production lines to build out the factory that uses the tools, but then the flow to keep the system "topped up" by replacing broken tools is hugely smaller.

However, skewing the recipes this way is a bit ugly as it multiplies both the input buffer size of the machine as well as the crafting time by N, and then dumps N products all at once. For any kind of "realistic" tool life (thousands of products), it makes a huge mess.

I have considered "burning" tools as special fuel, very slowly, but then there's no tool fixing mechanic. And it's a hack and is inflexible. I have no idea if Prototype/Tool can be used somehow, but in the end, unless there's some extra magic somewhere to return a damaged tool when exhausted, it's basically like burning as fuel.

Are there any other ways to balance this out a bit? What I'd ideally see is a relatively slow, but pretty consistent flow, perhaps bidirectional, of expensive tools alongside a much higher, but still consistent throughput of much cheaper products. Ideally it would not tend to produce static solid belts of tools representing wasted resources and tool manufacture capacity.

[Deadlock989]

I had similar thoughts and gave up in the end, decided it was out of scope for what the engine provides.

Some mods have used the "special fuel" mechanic for miners specifically, where it works better than it does for assembly, e.g. "drill heads". You can balance it by sinking electricity or other work into the process that makes the drill head. But I agree, it's a hack. And it's an ugly solution outside of mining in my view, it feels wrong with assemblers. The closest I got was having a catalyst product (something in both input and output which is excluded from production stats) returned with 0.99 probability or whatever. This latter is a nice balance option for the mod creator but I have questioned whether it's actually fun for players since there's no control over whether a non-used catalyst isn't spat out and has to be reinserted, it's boring to set up repeatedly.

Prototype/Tool is basically science packs, and labs are the only entity that burns them. Labs don't even use recipes.

There may be things I've missed but I gave up looking.

[gammaprime]

Yeah, it's a pity, as it would open quite a lot of more realistic "multi-rate" processes (e.g. you need to feed an assembly line with (say) 1k iron per minute, but only 1 tool per minute.

It seems to me that if only an assembler which has the same item in input and output could automatically shuttle that item back into the input slots in preference to the output slots, it would just work for the saw-blade style (your catalyst product) where the returned item isn't damaged, just consumed with X% chance. I suppose there are corner cases: e.g. what if input slots are full. Are the game prototypes modifiable (inheritable or something), or are they part of the engine that can't be reached by mods?

Another possibility occurs, which is to break down the tool into "service packs", which are consumed at a rate similar to the ingredients. For example, a tool (or a recipe of several different tools) might break down to, say, 1000 service packs, then you have several options:

• Packs consumed entirely in the assembler, for tools that "burn up" like Angel's saw blades

• Converted to a "used service pack", which must be collected and reconstituted:
  • Reconstituted to a new tool, where you need 1001 used service packs to make a new tool, representing a "sink" for new tools, but at a 0.1% loss rate relative to products. This case can also use inputs to the reconstitution like, e.g. coal for coal filters. Can also have byproducts, e.g. carbide dust or slag or e-waste.
  • Reconstituted to a damaged tool (either 1000 for a no-loss scenario, or >1000 for a lossy one), which is sent away for repair by more specialised facilities, but don't require shipping a quantity of tooling similar to the quantity of product, which is unwieldy if you're catalysing a high-throughput process, or if the tooling is extremely expensive.

The granularity of service packs makes it easier to "smooth" the demand, as you're not blipping expensive tools out of existence, but burning though them in 0.1% increments and reconstituting them at almost exactly the same rate. If the tool-pack ratio is high enough, you may only need one extra tool to take up the slack. Edit: you also don't need to prime the assembly line with N tools for N machines up-front: 1 tool can feed several machines right away, so the tool production capacity never needs to be higher than that required to replenish the steady-state losses.

Balance is easy, because you have multiple places to adjust ratios and quantities.

It's not super realistic, but the protagonist is carrying an entire oil refinery around, belts work by harnessing zero-point energy and magic unmanned buildings automatically drink coloured fluid made of gears and inserters packaged into "packs" to invent things, so maybe a conceptual "service pack" isn't too off-the-wall.

[gammaprime]

The closest I got was having a catalyst product...

And using the keyword catalyst, I found viewtopic.php?t=69070, which is very related.

[Deadlock989]

And using the keyword catalyst, I found viewtopic.php?t=69070, which is very related.

Yes, I would have liked "consumables" or modules-with-durability or something like it, although to be honest it would still be awkward and/or wasteful for the player to supply machines with high value consumables given that assembling machines have no circuit connections; c.f. the number of mods that take scripted measures to extend module copying/insertion and the automated maintenance of modules in general. Modules and beacons are a funny thing anyway, the way that entities can only be limited by effects, and individual modules can only be limited by a list of recipes, and not all entities that use them even have recipes, all makes them pretty awkward to customise beyond the vanilla set-up. But I think it's very late in the day now and what we have is what we have.

[gammaprime]

I suppose the service pack concept at least allows you to avoid too much waste by allowing you to amortise tool "capital" across machines and time.

It's then on the player to generate and distribute tools and packs effectively and not, say, end up spending a million ores and MWhs filling chests and belts with precision tools and consumables when they only needed a very few per hour.

Making them ingredients rather then some durable module-ish might be a little bit of a hack but it at least would work naturally with things like Helmod and Bottleneck.

You can also have recipes that don't take service packs, with a penalty of some sort. This gives options to not be blocked by some convoluted tool manufacture, but still have an incentive to get it sorted eventually. It would have to be a bit inventive to not just emulate modules or higher tier assemblers though. Perhaps instead of just, say, making crafts faster or more efficient or productive with tools present, have annoying waste products or defective products without them. Or even a small random chance to damage the assembler (a major incentive pre-bots), or seize up the machine somehow and require manual clearance (a pain even with bots).

[Ranakastrasz]

If you use the tool as long lasting fuel, then you can use the same effect nuclear fuel doea to return the broken tool.

That does prevent (I think) you from using electrical or other energy types however.

[Deadlock989]

If you use the tool as long lasting fuel, then you can use the same effect nuclear fuel doea to return the broken tool.

That does prevent (I think) you from using electrical or other energy types however.

Yes. It also means you have a spanner worth 100GJ in your inventory.

[Ranakastrasz]

Yes. It also means you have a spanner worth 100GJ in your inventory.

Minor detail at best.

Of course, if you use antimatter to liberate the energy tied up in said spanner, that is probably accurate..... But at that point you realize something has gone silly.

[Deadlock989]

But it's not really workable for common products. Every assembler in the game that can process your fuel-spanners now has to be cut off from the electric network because technically they are all now burner assemblers. Plus you have a ton of entities "powered" by spanners made of fuel, that show up in every fuel-related tooltip in the game as fuel. It might work for some people or it might be a niche solution for a couple of rare features in a mod but as a general solution it's not to my taste.

Antimatter fuel would likely be measured in terajoules per gram.

[gammaprime]

If you did this, wouldn't you also set 'fuel_category' to be 'spanner' or something, so that normal entities like boilers and stone furnaces (with fuel_category=chemical) can't burn spanners? E.g. pyCoalProc uses 'drill' for the drill head "fuel".

Stopping the machine using electrical power is a bit of a weird one, but as Deadlock said, you can address that by investing the appropriate energy in the spanner when you make it, though it certainly has effects like power draw heavily decoupled spatially and temporally from production, since you invest the energy where and when you make the spanner, but get your end products at some time in the future and possibly on the other side of the factory.

It also makes it a bit odd in that you directly couple the energy requirements of the end process to how quickly it uses spanners. It's not necessarily true that a process that needs 2 spanners/min uses twice the energy as one that uses 1 spanner/min.

Aside: antimatter fuel would be a pretty fun thing, but it would need you to basically build CERN and then some to manufacture. Would be interesting if the magnetic bottles needed to be kept charged in some kind of building and if they discharged while left out on a belt or in a chest for too long, they annihilated themselves and everything nearby.

[Deadlock989]

If you did this, wouldn't you also set 'fuel_category' to be 'spanner' or something, so that normal entities like boilers and stone furnaces (with fuel_category=chemical) can't burn spanners? E.g. pyCoalProc uses 'drill' for the drill head "fuel".

Yes, but it's still a fuel category. Its intended use is for categories of fuel. The game displays it the way it displays other fuels. Everywhere in the game, it will behave like a fuel called "spanners". It wouldn't even be displayed as a requirement within the recipe to make the items. The player would only find out that your Highly Tooled Unobtainium Nuggets need Not Really Fuel Fuel Spanners when they get around to building the assembling machine that runs on spanners. So you're having to add contextual info to every localised recipe description as well and it all just looks a mess.

So it can be balanced to "work" in the sense that it achieves the goal of having item X be used up gradually over exactly 1000 processes to make item Y. But for me personally it's confusing to the user in a way that stops it being a viable option for general use. And the whole non-electric thing is enough of a no-go in itself. Like I said earlier, I think the way Py uses it for miners is OK - I could maybe accept having just miners isolated from the electric grid. But not for stuff that's in the heart of the factory.

[gammaprime]

I'm in total agreement that it's not really a practical way forward for the general case.

I like the "service pack" concept rather more, as it provides a lot of options for various workflows (e.g. total tool loss, tool calibration, cleaning, wear rates etc), allows multiple recipe pathways and shows up as ingredient requirements. For "boring" operations, you can make the SPs just burn up, so you don't have to always be always setting up tool reclamation systems, instead reserving those for the high-value interesting targets. Plus at least it is conceptually similar to science packs which represent a portion of a process too.

I think you'd make your tools and/or service packs 'allow_decomposition=false' to prevent them clogging your end product recipes with the (possibly very many) ingredients for the tools.

[Honktown]

Interesting idea, so excuse me if some of this sounds like rambling:

Pouring over the wiki page for ideas, I came up with a rather simple one for the wearing: ask the devs to introduce "%" as an amount for a recipe. Requires the recipe item to be of the tool category (and maybe not infinite... maybe).

Polishing/repair is an entirely different beast. There's no automation that feeds back to inventory. If instead you made 100 items and consumed 1 at a time, the items are split-able, if they can be held in inventory or grabbed by inserters. As a fluid it would be pipe-able, which is even worse.

A recipe could be made to consume a tool and make a fresh one, but a recipe has no variability or relative-mode output. In addition, we want to limit polishing to 100% - a machine could have an inventory-output limit, so you can't gain magical extra tools by repairing a 100 count tool, but again, using item count as a percent has issues.

Going over even crazier things:
As a module, modules last indefinitely. If a module had a cycle-lifetime, then a machine could have a module slot for different tools, and they'd wear-out on a per-cycle basis. Repairing has the same problems as others.

No recipe heals health, so an item-with-entity-data isn't really applicable as a "tool".

There are some strange control phase things that could be done. One of those things that's so ridiculous it gets a spoiler:

If used to craft an entity: as part of the recipe category, a "machine wear" item could be made, and inserted into a hidden box by a 254-stack filter inserter, while normal things are filtered out by loader. Check the box every so often and damage the unrepairable machine. When the machine dies from this special damage, replace it with a worn-out machine that has a crafting speed of like 1000x less. Maintenance equipment could go on a separate loader, and feeds into a hidden single-slot box that heals the machine accordingly, or machines are left as-is (worn out, no repair), and can be re-crafted into a new machine. Problem with this one is there's no auto-recrafting/placement of worn machines (*unless* one auto upgrades worn machines, via construction bot, with new machines). No auto-replacing may be desired: don't let your machine wear-out or use better tools! Requires cleaning the hidden/embedded entities on mining or destruction.

Edit: how does insertion/removal work for entities jammed inside eachother? Hmmm... idea may be nearly completely useless (can check output inventory of machine for "wear" items... but they'd be removable. A fluidbox has to be outside the entity collision box, and therefore is accessible.