Gt-new-horizons-modpack: [RFC] need interesting game mechanics

[0lafe]

Which modpack version are you using?

2.0.9.0

What do you suggest instead/what changes do you propose?

Something I've noticed in NH is that a lot of EV+ content isn't super interesting, and doesn't offer much new to the game mechanically. While I could list many and many of these (VM, naqs, ++ multis, etc) I'd rather focus on the positives. I think they better display what could be possible, as opposed to focusing on what we shouldn't do.

Lots of these new additions are presented as challenges for the player to overcome. Novel introductions that allow you to progress as an NH player, as opposed to simply tiering up. Things like multis in general are a good example of this. While you've been using the ebf/vac+ for a while now, those are fairly simple machines. Things like PAs, more intensive LCRing, large turbines, and of course the assembly line, all do a wonderful job in introducing you to a lot of depth. These are primarily in impediments towards the player, or rather, "challenges". There's a lot of depth to good utilization of these machines, and pretty much all of it is new. Good manual/automatic crafting will get you doing some cool inventive things, as will spin up/downs.

The ic2 nuke, while with it's issues, is a good example here. First off, if you're making your own design, good luck. That's a rabbit hole in and of itself. If you do vac cooling that will give you some automation challenges you probably haven't seen, and promote some interesting solutions to these challenges. Fuel acquisition can also be interesting, depending how you handle it.

Now something that all these things have in common, would be that they aren't "difficult" in the sense that is commonly applied in NH. They aren't really gated by tier in a big way, they aren't super grindey to produce, but rather their challenge is different. While doing well with these will make you progress in the game sense, you will have done more than just that. These provide a depth of understanding to be had by the player, which is in incentivised through gameplay.

Now the idea of this ticket is try to gather some ideas for possible novel mechanics. Something that will make the player think in a new way, and tackle a challenge that hadn't been seen before. So far I've seen some good suggestions from others, and I'm curious what else we can come up with. None of this is necessarily being pitched as is, so don't feel the need to entirely sus out every detail. Considering these are probably semi game changing, they would end up having their own RFC's + revisions later on. Ideally this isn't just new recipes, unless they force an extreme resource that itself can create some unique content (we don't have much witchery automation incentive for example). Feel free to get creative ;)

One idea I had was something along the lines of this. Overhaul LuV+ power gen to rely entirely upon a super conductor. This would need to be fed cooling fluid at a rate proportional to the load on the wire, with negative effects for over/under filling it.

[Cleista]

Forcing power gen change probably will not be popular but I'm not against the idea of an additional generator that's efficient but requires good automation to maximize output. I'll mention some of the ideas I wanted to see materialized to start off.

Multi-stage Steam Turbine

Real-life steam turbines look something like this. So why not a multiblock that functions similarly?

• Controller front center
• 3-16 total length
• 1-12x Steam Input Hatch on the frontmost slice, replacing outermost ring of casings
• 1x ULV Input Bus per slice (for turbine item - the same turbine material cannot be used in multiple slices and all turbines must be the same size)
• 1x Output Hatch per slice
• 1x Dynamo Hatch at the tail end (maybe support TecTech dynamo hatches?)

Calculations:
When controller ticks, calculate each turbine slice in order from front to back as follows:

1. Attempt to fill the output hatch in that slice with as much steam from the inputs as possible. (So if the inputs contain 100000L steam and the output hatch has 31923/32000L steam, it would drain 77L steam to fill the output hatch and leave 99923L steam in the inputs.
2. If any steam is remaining, consume an amount of steam equal to 100% * (1 / number of slices remaining) * amount of steam left in input hatches. So for a 10-long turbine, the first slice would drain 10% of the remaining steam, the second slice would drain 11.11% of the remaining steam, etc. Based on the amount of steam drained, calculate EU gain based on normal tight fit turbine efficiency calculations.
3. Once all slices have been ticked, sum all the EU gains, then multiply it by the ratio of actual EU/t : max EU/t of each slice (so if one of your slices was running at 90% efficiency because you didn't give it optimal flow, it would also cause a -10% overall penalty to the power output of the whole multiblock - and this'll stack multiplicatively for multiple slices not properly regulated). Then, multiply overall output by 100% + 20% per slice [this is to encourage building it as large as possible].

Rationale for adding:
This is a lot more complex than regular turbines which consists of running your preferred highest efficiency turbine material into the spreadsheet and putting a number into one fluid regulator.

Here, you are encouraged to use a mix of turbine materials as well as carefully fluid regulating the output of each slice (by emptying the output hatches at controlled rates) so that every single slice has to run at optimal efficiency. The more different turbines you can chain together, the more efficient the multi gets.

Why would I build this?
You can get theoretically 380% more power per steam than otherwise possible. Of course, you can't only use high efficiency high throughput turbines due to the multi's inherent restriction on no repeated turbine materials - so the actual gain will be less. Input buses for turbines also mean easy turbine refilling.

Plus it looks a lot cooler than a wall of texture-overlapping regular turbines, no?

Quantum Infinity Hatch

Input hatch that only takes Molten Infinity, but can have contents extracted. Can be added to any multiblock.

The hatch requests an amount of Molten Infinity between 1L and 15L. This amount is output as a redstone signal. If the hatch contains the correct amount of Molten Infinity (i.e. exactly the requested amount) when the attached multiblock attempts to start an operation, it consumes 1L of Molten Infinity from itself per second to speed up the operation by a factor of 16x. If the amount of Molten Infinity is incorrect at any point in time (i.e. it does not get refilled within one second), the machine halts and voids the output.

Once an operation is completed, the amount of Molten Infinity requested by the hatch updates to another random number between 1L and 15L.

Quantum Replicator

3x3x3 Multiblock.

• Controller Front Center
• 1-8x Energy Hatch
• 1x HV+ Input Bus
• 1x Input Hatch (for UUM)
• 1x Output Bus (optional)
• 1x Output Hatch (optional)

Functions as a replicator that overclocks perfectly and performs up to 64 parallels at once. Input bus must be filled with 16 unique data orbs (i.e. no two of the same element).

The replicator outputs a redstone signal between 0 and 15 - this is the slot # it will read the data orb from. Once the replicator receives enough UUM to perform at least one craft of that material and is Enabled, it will try to craft as many parallels of that material as possible, overclock perfectly as much as it can - then voids the rest of the UUM in the input hatch.

After each craft, the slot # it crafts from is randomized again.

Hydroelectric Dam

Square multiblock, variable size 3x3 to 16x16 (hollow), variable height, 4-200 blocks

1x Controller (top layer)
1-12x Dynamo Hatch (bottom layer)
1-12x ULV Input Bus (for turbines, directly above dynamo hatches)
1-48x Output Hatch (bottom layer)

The Hydroelectric Dam fills with water during rain at a rate proportional to its cross-section area. If it is activated, the turbines will spin, generating power and draining water in the process. EU/t is proportional to total amount of water remaining inside the dam, but turbine damage is constant.

If the dam is at least 3/4 full of water, it starts to leak (place flowing water outside its walls). Upon reaching 100% full, the dam explodes with force proportional to its height. To prevent this, drain the output hatches - the dam will empty the water inside it into the output hatches.

Naquadah Reactor Multiblock

IIRC the Russian pack had something for this? If it's complex enough, might be a good candidate to add.

Black Hole Generator

Unfinished in-game, not sure what the plan is. But this could be a nice automation test depending on how its EU/t and input are calculated.

[0lafe]

I'm not sure I entirely understand the steam turbine, but it seems cool. Does a slice pull from the output hatch of the input hatch?

I feel like this isn't that interesting of a mechanic with stuff like sfm existing. I like that it's not a multi itself, but that seems kinda crazy effect. Personally I'd rather see the redstone mechanic on something like fusion, or an already established boring multi. 16x seems kinda OP

Random choice with set fluid quantities is kinda cool. I'd be curious if there's a way to do it without defining every state. Not sure if it warrants perfect OC, but who knows.

I think I like this one, but I'm a little lost on the function. Does it pull water from the output hatch when turned on? Slightly more involved spinups is cool. One thought I have that could make it a little more unique. If there's a way to make water appear in the structure as it fills, if the water output is unreadable, it could be fun. Needing a way to measure the fill level in world hasn't been done before I don't think.

Their naq is more visual and based on chem chains from what I've seen. Looks cool for sure, but I think it's just difficult recipes, but simple inputs. Iirc it's their fusion reactor, and they removed normal fusion. Tryna avoid things that are just another multi with another set of recipes that don't do anything.

I like the idea of more complex multis. Redstone output strength can be a fun definer. One idea I had, was an in world nuke. Something like a big reactor, but you place the fuel rods in the structure itself. We don't have a ton of in world logistics, and that could be kinda unique.

[Cleista]

Giant turbine - The idea is that current steam capacity = sum of steam in all the input hatches in the frontmost slice (you can put multiple since you might need more capacity for bigger turbines).

There's an optional output hatch in each slice to remove excess steam - so let's say by the time you get to Slice 3 in a 10-slice turbine (so 8 slices left = drain 1/8 remaining steam), and there's 33000L steam left but optimal flow was 4000L, you can use some form of fluid logistics to remove exactly 1000L steam from Slice #3 output hatch to bring the total down to 32000L.

---

Inf. Hatch - Re: 16x being OP, you're basically paying 1L to save 15 seconds of processing time - or save 36 minutes on a single machine with 1 infinity ingot. Would this really be that OP lategame, considering how difficult it is to craft each ingot? Maybe @GTNH-Colen could pitch in regarding value of each infinity ingot and what practical use cases he sees for this?

---

Hydro - Having a way to measure fill level in-world was the idea - it would be kinda boring if you could just use a fluid detector cover. The multi still has to form, so if we go aggressive with requirements and demand the entire center be water or air, you wouldn't be able to put anything inside (so no annihilation plane fluid meter for instance). One obvious way is detecting the leaks to know it's over 3/4 full, though there might be other more novel ways of measuring fill level that don't rely on it (like tracking the position of a floating entity in it, somehow checking for water through the wall, etc.).

A spin-up sounds cool in principle, since it'll encourage having logic to run it for continuous cycles to drain some amount of water instead of the constant on/off you see with non-breeder nukes. The output hatches are more like overflow valves - since the multi explodes if it's 100% full, if you can't drain the water fast enough from normal generation (say, your warp is too high and it's constantly thunderstorming) you have to get rid of the water somehow.

---

In world nuke - I had the idea of having one slot per nuke block, then have it calculate pulses/heat transfer in all 3 dimensions. This would theoretically give you more efficiency (since each rod now emits pulses in all 6 directions) but you'd have to do much more complex heat transfer calculations and have logistics to deliver rods/coolant cells to every relevant block. You could also scale the size up to pretty fun amounts.

As an encouragement factor we can replace the nuke explosion (everyone just enclosed it in fused quartz anyway) and simply have overheated reactor blocks turn into molten corium - highly radioactive sludge you cannot just place a block on to replace (like higher tier taint fluid) that you'll have to deal with somehow.

[Prometheus0000]

I didn't really read 95% of this, but maybe you guys could stick with realistic changes until bart and the rest make up? Unless you want to volunteer to program these changes yourself or something.

[GTNH-Colen]

Inf. Hatch - Re: 16x being OP, you're basically paying 1L to save 15 seconds of processing time - or save 36 minutes on a single machine with 1 infinity ingot. Would this really be that OP lategame, considering how difficult it is to craft each ingot? Maybe @GTNH-Colen could pitch in regarding value of each infinity ingot and what practical use cases he sees for this?

The main use of this I think would be for really long assline recipes (Such as like 21600s for 1 void miner), I can't see myself using it for Nt smelting or anything. Each ingot at UV with radon would take around 20L of infinity to run its recipe, not worth it imo. Might be other cases but that's what I can think of off the top of my head, would be nice to have the option though if we really need speed for something. While the EU content of an inf ingot isn't necessarily high they still take a while to make so the use case for this would be quite niche.

I didn't really read 95% of this, but maybe you guys could stick with realistic changes until bart and the rest make up? Unless you want to volunteer to program these changes yourself or something.

If they make up, not when.

[draknyte1]

At least three of your ideas @Cleista already exist in 98% functional states. 😂🤦🏻‍♀️

[GTNH-Colen]

At least three of your ideas @Cleista already exist in 98% functional states. 😂🤦🏻‍♀️

When you actually fix your matter CPU we can talk about your replicatior multiblock 👀

[redmage17]

Have Alk finish half the stuff she is coding, the GT nuclear reactor from Kektech looks interesting. I've also stated we need to add some form of mega projects to galacticraft. Such as plant crackers, massive solar microwave transmitters, etc

[0lafe]

I'd strongly disagree @draknyte1. The idea here is less to have something that functions like as a large steam turbine, or replicator, but rather the interesting logistics proposed to make them run. While your multis 'exist' their function isn't really unique in that way, which is what I'm strongly trying to avoid.

Would this really be that OP lategame, considering how difficult it is to craft each ingot?

Thing is it isn't hard at all in the sense I'm trying to reach with this ticket. It's expensive, not difficult, which isn't really the point. The difficulty in that idea is more the redstone req idea, but I don't think that's difficult enough to be If tier. Maybe the idea could be applied to a lower tier multi? Like an EV/IV multi that heavily benefits from an optional random input? Could see some fun thaum integration we could use here to boost maybe like a multi miners output?

For the in world nuke, 3d is definitely cooler, and more complex, but not quite as difficult as I was intended. I mean you need to physically place a block in the middle of it with fuel, and swapping fuel/cooling is done through in world interactions. Not a GUI with base item logistics. Think big reactors but you place filled fuel rods and need to remove empty ones, and it doesn't have a GUI for any of it.

The ideas im tryna get are less for things that can be considered useful, and rather semi intense challenges we can force upon the player. Unless it's using a recipe or inputs that are so extreme that it forces its own mechanics through interesting production challenges, I wouldn't consider it super great in this regard.

In world water level detection with no items allowed in the structure could be pretty cool. If we really wanted we could go the route of adding a rain detector that will give you rough rain/time rates, which you can use to aprox when it would be filled with varying usages. That's some complexity there I guess

[Cleista]

The logistics of placing a real block isn't too bad when there's stuff like block placer/breakers and annihilation/formation planes as well as a single block BUD - it's cool to think about, but in terms of automation it's probably not going to be more complex than moving items into a gui unless you heavily reward using fewer non-reactor blocks to accomplish the task (which could be a nice microoptimization challenge assuming there isn't a trivial 0 block solution with teleposers or some shit).

[DuskNite]

Idea for ultra end-game (UHV+) ore processing. The idea is to have a machine that can process stupid amounts of ores quickly (from void miners) but also have options to massively increase your yield if you do optional stuff.
(THE NUMBERS IN THE IDEA ARE PLACEHOLDERS)

New Multi
machine efficiency (E, or can use another variable if needed) starts at 1% when machine is started, and caps at 500 (or whatever value you think is appropriate)
Requires 10 seconds per operation.
Consumes 2eu/t per ore processed per operation
For each operation

• processes E^2 (rounded up) ores into E^2 dust, then increment E by 0.1.
• If there are less than E^2 ores, process all ores into dust, decrement E by 0.5 instead.

Machine will request for (E)mb fluid A, B or C at the start of every operation.
At the start of the next operation

• If there is a wrong fluid, void all fluids and ores, then decrement E by 1
• If there is the exact amount of the correct fluid, quad output, increment E by additional 0.2.
• If there is enough of the correct fluid, double output
• If there is no fluids or has not enough of the correct fluid, do nothing (process as usual, no bonus, no penalty)

Additionally, output is doubled for each condition that is true below

• There is exactly E^2 ores in input bus. If this is true, increment E by 0.2 as well.
• E is 40% of max.
• E is at max.
• Any more stupid ideas here.

If you only flood the input with ores, at max efficiency, you can process ~250k ores into 1 million dust per operation.
With all additional options listed now, you can potentially get 64 dust per ore, or more with more additional conditions.

[GTNH-Colen]

Mega ore thingy.

If this was to be done then we need a way to remove items from quantum chests and also export them directly to them, there is no way to handle this output quantity otherwise even with the extremely laggy super buses.

[DuskNite]

I'm not too sure how exactly infinity chests work (in code, and ingame, need a few more weeks to get there i think) but maybe we can make a custom input/output that works like that?

Instead of a standard input/output bus.
The input is a custom block/chest that can hold 2^31 ores per slot, with an amount of slots equal to infinity chest (but it can only hold ores), and essentially just works like a chest.
The output is bascially the same thing but holds dust instead, and it does not need to automatically output like standard output busses do.

It only needs to do 1 operation every 10 seconds, so definitely not as many operations as an array of processing arrays, but considering how large each process may potentially be, I don't know if the game can process it

Also 10s/op means you have plenty of time to pull stuff out of the output if needed too, and if the output could be that big, you can also potentially just storage bus it.