Anuken / Mindustry-Suggestions

Repository for Mindustry suggestions and feedback
131 stars 58 forks source link

Slag Incinerator Rework #5210

Closed SomeonesShade closed 1 month ago

SomeonesShade commented 2 months ago

Describe what you would like changed, and why.

An Incinerator Block, which has the role of deleting items and/or liquids, is useful for systems that needs to deal with clogging, such as payload-constructor transport.

Examples may include incinerating overflow if there is too much being sent of one type, or selectively sending specific items when you are forced to send both. These conditions are usually only seen in payload-constructor transport.

However, this purpose is really limited by the slag requirement attached.

Similar to Slag Heater, viable placements usually only exist as if they are near a slag source. Sure, the possibility of wiring slag is possible, but it is more preferable to wire the overflow directly into the core at that rate, or ... just don't use the transport option in the first place. This restriction is heavy as the block not only has to deal with the rare niche it has, but also being dependent if slag is nearby to begin with. Not great...

As a way to diversify the transport options by improving payload-constructor transport, and to make a Slag Incinerator more useful, Slag Incinerator should at least have a rework due to how much the slag aspect can really restrict.

Describe the changes you want to propose. Include possible alternatives.

(ABC) Categorized arbitrarily (123) Sorted from acceptability/preferability

Main Goal: Screenshot 2024-09-10 131751 BE, Screenshotted on Caldera No more positional dependency!

A. Consumption Behavior Changes

1. Input Slag Once/No Slag Consumption Rate

This is an input once type of block. As long as slag is inputted, it will run. This works as it keeps the slag aspect, while making it versatile on making it a one and done deal.

It isn't bounded by slag location as the core unit, being able to pick up containers or routers, can simply pick up a slag container and deliver where needed. Similar to how the player can pick up ozone containers to feed unit repair towers, or nitro containers for build towers.

It is still annoying if griefed in multiplayer, but I think it's already a vulnerability for the game in general; it shouldn't matter.

2. Really, Really Low Slag Consumption Rate

Just in case if no 1. isn't possible, just lowering the consumption rate and maybe increasing the liquid capacity such that it would last the entire game would suffice.

If it isn't low enough, the player would have to constantly remind themselves if there is enough slag. This defeats the entire purpose, considering the player can just manually remove the clogged item or liquid in the first place. It's back to square one with the placement conditions.

3. Remove the Slag Input Requirement

This is... a lazy solution. It solves the problem and is now unbounded, but it removes on what makes it distinct and unique. I've only included this since it is a possibility, but personally, it's not worth it.

B. Slag Producing Slag Incinerator

Producing slag instead of consuming slag would keep the slag aspect while having the versatility on being able to be placed anywhere. The question is on how it would work and be balanced.

In order for it to be balanced and make slag-less maps stay surge less; it would need an upfront surge cost (probably 5 cost).

For the slag production part, maybe every 15 items it produces exactly 1 liquid unit of slag. Don't produce slag if fed with fluids (or remove that part entirely as putting fluids on the floor is good enough).

Maybe add in a power component to justify on how it can turn items into slag (maybe a low amount at most). 15 item/s for 1 liquid unit/s is a low enough trade to make it a secondary role. It shouldn't be too high, otherwise, map makers lose ways to restrict surge production in their maps, and it makes it unbalanced.

Overall, I think at least one of these options would be satisfactory. I personally prefer A1 as the simple solution while B for giving it a different and unique niche, if wished for anyone to implement.

Edit: Added Images and tweaked slightly

jehosula commented 2 months ago

i prefer B except you can realistically produce some surge with it, becomes super expensive but not practically impossible to make with that, but worse than even serpulo scrap

SomeonesShade commented 2 months ago

Looking at the suggest post again, I think I might’ve made it a bit too big? Hopefullly its understandable/easy to skim over

github-actions[bot] commented 1 month ago

This suggestion is now stale, and will be automatically closed.