promotional bannermobile promotional banner

Gregorian Nightmares

Wicked hard "fun", rules-breaking, tech based on MI and Create, aspiring GTNH cousin
item image
item image
item image
item image
item image
item image
item image
some recipes from Pyrotech

some recipes from Pyrotech

item image
item image
item image
item image
item image
(the actual in-game process is both better and worse than what's shown here)

(the actual in-game process is both better and worse than what's shown here)

Description

Too Greggy;Didn't Play

Always read POST-INSTALL.txt that is included, to manually add mods exclusive to modrinth

and check the last part of the description, here below, to read how to properly set Java for this modpack

There is no separate discord for this modpack, but you can come asking in Modern Industrialization official one, under a thread #general > can we make a thread about bad modpack?

And I guess we don't run short of disclaimers: I've never written a single ChatGPT prompt, or used any other alternatives in my whole life. This modpack is 100% free of any AI fingerprint and any fuckup it may contain is of my own manual doing and responsibility. Thank you for your attention to this matter.

 

Roll back time to mid-2022: Minecraft 1.19 was just released, and GregTech was strictly bound to 1.12 and below. The only exception coming close was Modern Industrialization (MI), even if being leaner and much more simplified compared to GregTech. The idea of matching MI with Create was appealing because it would allow starting automation early, replacing the need to manually craft tons of small parts. MI also used vanilla-style ores scattered in small veins around the world, that are perfectly suited for the exploration in Minecraft 1.18+, with its world height expansion and large cave system, while using automated quarries to produce all resources infinitely later on. A Factorio-inspired industrial automation.

My main idea was to build a new positional quarry system, accessible earlier in the progression and expanded through tiers. And port to modern versions some of the most complex production chains, cherry picked across all GregTech versions and less known, specialized modpacks. To add more "bulk content" to MI and justify the time and effort for going all out and fully embrace this type of complexity and logistics.

Versions, currently two active, "Lightspeed" and "Nightmares", because why not:

  • Nightmares: My own main survival test version. Beware that this is HEAVY on the hardware to run. Meaning mainly CPU and memory, not video. It is now otherwise stable, tested for a significant number of hours. Because of the nature of the modpack and the nature of me as a player, it takes tons of time for me to get through it and improve things (and I died over 450 times...). It's a huge collection of mods on fabric side and mods not included in the Lite version are in many cases not yet edited. Therefore the messier "kitchen sink" nature of this version. Scroll down this page for instructions on how to set up Java for this version.
  • Lightspeed: This was built to be easier to run on the hardware, both in processing power and memory usage, and it will have less problems overall as a more lightly modded experience while still retaining the FULL scope of the automation required. The mod count is significantly reduced but progression is the same, with some of the harshest and nasty survival aspects removed.

Gregorian Anagogy, or how the 1.20+ version will be named is now a SUSPENDED project. I currently plan to test progression and balance of the current modpack on 1.19, with the intention of wrapping it up fully, so that it works properly from the beginning to end. The move to 1.21+/neoforge probably won't happen. No plans at the moment, but it's likely I'll go back to 1.7 GT6/HBM/Reika after I'm done with Gregorian Nightmares.

 

This modpack started as a fork of Incremental Industries (after asking permission). Back in 1.18, it was the very first attempt to rearrange the progression and integrate Create and MI, as a lean and tech-only modpack. More recently, StaTech Industry became a very popular and well realized modpack, with an excellent questbook, casting a much wider net and including even some magic mods. On the other hand, Create is mostly optional and mods are tweaked to work well together, but without straying too far from their original recipes and intended progression.

This modpack here is instead a wilder (and much rougher) experiment, made to break things away from their norm and bend the progression in radical ways. It is my own playground to test ideas, without restraints or common sense. I'm NOT trying to be original or creative, my main activity is studying other modpacks, new and old (and very old), to reuse their ideas and reshape them into this giant, misshapen Franken-greg-stein.

What this modpack currently is: it started with scripts and progression from Incremental Industries, with integration between Create and Modern Industrialization ...and a large kitchen sink of mods dumped carelessly on top. I've ported some of the most complex processing chains from GregTech, the works continues on that line. Both MI and Create are now heavily edited in the style of an "expert" pack, including standard vanilla items. The internal progression of the mods has been warped. Therefore the "experimental" nature of the project. Overall goal is easy resources availability and generation, that is offset by convoluted processing and higher costs, to force automation from the very start of the game. Standard rules being broken just for the fun of finding out what's possible. All quite chaotic and mean-spirited, nothing is final. The questbook is in the process of being thoroughly vandalized.

Applied Energistics 2 is included, but available in a limited capacity inspired by Satisfactory game. You can set up early a fully wireless centralized inventory, but you can only export items to it, and only manually pulling items from. This means you can use it as centralized storage, but can't automate anything through it. Proper automation will require proper logistics.

Long term, this is meant as a GregTech-flavored "rolling release" that tries to be the best effort with what's available, pushing HARD against the tide of an ever splintering, divisive community. Proper GT orthodoxy continues on 1.12 and below.

 

Extended description: This modpack started while I was studying the evolution of GregTech from GT2 in 1.4.7, all the way to the modern incarnations. New doesn't equal better, and looking behind is more often than you expect a goldmine of interesting ideas. I began working on this project because there were four foundational concepts that could only be realized here:

  • The new 1.18+ Minecraft world, with the height expansion. MI frequent and varied vanilla-style veins are actually a throwback to those days in 1.4.7 and 1.6.4, exploring a large system of caves and finding plenty of resources to process in useful ways. Common, easy to find resources, but complex processing. In the early game expect to use large amounts of wood, gravel, clay, andesite and quartz.
  • The mod Create is overused in modpacks, but it is the optimal replacement for GT fiddly tools and tedious manual work done on a crafting table. It can introduce automation immediately rather than after a delayed grind. And can remove the repetitive micro-crafting and mining that are common in the early phases of GT. It offsets the grind with automation.
  • Positional quarries for infinite resource production, immediately available but slow, to assist the early game until you can upgrade and rely on them. Scattered around the world especially at different heights, deep in caves.  Where you deal with the challenge of creating autonomous specialized factories around these infinite ore nodes, and then bringing it all together through logistics, whether it is trains, minecarts, or just pipes.
  • Use MI much simplified and leaner internal mechanics to instead push to the limit the complexity of processing chains, and the web of interconnected dependencies they build up to. Faithfully porting recipes from the more hardcore and specialized versions of GT like Technological Journey and now SuperSymmetry. All the while rewriting the questbook so that it's approachable for all players, including those new to automation gameplay, because the most fun phase of GregTech is learning.

These four foundational concepts were meant to fuse the best of Minecraft with the best of Factorio. Force automation early to offset the grind, with slow paced but steady and expansive progression. Gradually introducing new elements of complexity after the player becomes familiar with what came before.

Having well designed and legitimate goals doesn't mean having fulfilled them, though. And this modpack is still rough and untested. That's why the more I worked on it, along the months, the more I realized how much still was missing to turn it into something actually good and satisfying to play. And the more it also needed at a lower technical level to be fully realized. But that becomes personal, because for me working on something isn't determined by the destination. I work on this while and until it continues being an interesting experiment and I enjoy toying with concepts and game design.

Now a year after the project started, there are some hard problems with MI that aren't going to be solved within the mod. This actually requires Java knowledge, will likely never happen and is a major cause of ugly design that cannot be addressed in any other way than forking the mod itself. When I started a year ago I was hoping to get some help along the way, now I know well enough it won't happen. So these are the hard facts that will prevent the modpack to even potentially reach the baseline of what I consider good design. Here's a current list of problems:

  • Original infinite ore idea required the possibility to spawn large ore veins with a single infinite node within. Kubejs cannot do any of this.
  • Machine tiers/hulls are cosmetics in MI without a real function. The support would be there, but the dev refuses to turn it on. Machine upgrades need to be tied to the hull system, otherwise the system is easily exploitable to skip most of the progression if you know what you're doing.
  • Items/fluids can be voided right within the machine just by closing slots, recipes still run. It's also impossible to work with recipe priority to have some interesting mechanics, but that's a side problem.
  • Energy recipes cannot be modified to have byproducts, like spent fuels or things to redirect to chimneys. Or even to combine at the source.
  • Slot filtering would enable a whole lot of new mechanics. Easy to implement, it's just a visual separation of slots, nothing else would change.
  • Being able to set a max to overclock capacity of a machine, to calculate and plan for specific ratios.
  • Restrict hatch tiers on multiblocks to avoid stupid exploits.
  • Many players complain that pipes are unbalanced. Fluid pipes are uncapped, making them the best way by far to transport "energy".
  • All the other parts that prevent meaningful customization: upgrades, cables and pipes are all hardcoded.
  • Distillation towers (and distilleries) don't have item outputs. For distillery one could make a custom machine, but the towers have custom mechanics, and making a separate multiblock would lose the whole behavior.
  • There's no way to fix a mod with no progression. For example, if all fluid tanks have the same function, then in practice only the cheapest to craft exist.
  • It would be nice to be able to use active texture overlays for blocks used in a multiblock, when the machine is turned on.

The official license is MIT because that's what is used in Incremental Industries, as far as I'm concerned you're free to do whatever you want. CF credit system will stay disabled. My goal isn't to be original, but to experiment with interesting ideas. What I'm doing is based on the work of other people before me, therefore just remember that even if you have full permissions on my side, some things might come with their own preceding baggage and licenses.

The progression in the modpack is UNTESTED. Around 170 360 420 450 700 1000+ recipes have been manually added one by one (only counting chemistry and processing chains). Work started using mainly TJ/Gregicality as the base, with occasional recipes from Nomifactory and GTNH, now moving to SuperSymmetry (SUSY) as the main reference and structure. Current content includes:

  • GT6-style ore processing (automated quarry ores)
  • Early gold line (TJ)
  • Full Platinum group (TJ/GTNH recipe parity)
  • Hard Ammonia line (optional in TJ)
  • LV now requires galvanized steel, it's steel coated by liquid zinc (from GT6)
  • Epoxy > redone with current SUSY recipes
  • Petrochem overhaul (will try to keep up to date with SUSY)
  • More complex iron / steel / aluminium / stainless steel / chrome / silver / tungsten / manganese / molybdenum as byproduct (all from SUSY)
  • Complex titanium and tungstensteel (TJ, with fewer skips)
  • Vanadium line (removed from Nomifactory hardmode, preserved here)
  • from Ethylene to PTFE + SUSY tweaks, including sugar/ethanol (replaced MI parts)
  • Long Indium line (TJ)
  • All Naquadah up to Alloy (missing only UHV part). Joined and adapted some parts of Nomi hardmode, so that most of the three separate lines are now part of the same giant process.
  • Polybenzimidazole (TJ & GTNH) > fully redone based on SUSY
  • GTNH Monazite and Bastnasite lines
  • Taranium late-game processing line (TJ, all recipes present, but missing a couple of catalysts and currently detached from progression)
  • Niobium-Tantalum processing line (SUSY, currently detached from the progression)
  • All 8 EBF coils up to Tritanium, updated to CEu 2.8, recipes made somewhat harder compared to other GT versions, waiting for Susy
  • Custom Rhenium line (not currently existing on any public GT version, custom by PCM/Schroedinger, 50 recipes)
  • more...

A few textures for the custom machines are from Jimbno, carelessly picked and poorly edited as placeholders: https://github.com/Jimbno/UU-Tex/

Script for stripping flesh from zombies courtesy of Tazz, of FTB fame. And thanks in general to the whole kubejs discord, despite the frustration involved.

Current version contains a Clay Quarry and related evaporation tank for packed mud, code/scripts/recipes were all done by Rasm.

A final, more personal note. While working on this I've been surprised by the open hostility and toxicity I received, rather than the help or support I actually expected in a collaborative process.

The Bleeding Edge - Java 25 (updated on May 11 2026)

This part is relevant to squeeze as much performance as possible. The new Java versions support ZGC natively, and that's what I'm going to use. ZGC doesn't offer better performance by itself, but it allows allocation of more than 8Gb, so it's very useful in the HEAVY version that due to some mod bloat is VERY memory hungry, especially as you enter a world.

Here is the direct link to the official Oracle Java 25 download for Windows (notice that the version contained gets updated every few months, latest is 25.0.3+9.1, released April 21, 2026): https://download.oracle.com/graalvm/25/latest/graalvm-jdk-25_windows-x64_bin.zip

Other versions and release notes here: https://www.graalvm.org/downloads/

(Oracle recently discontinued GraalVM, but it's still the best version for performance at this moment.)

Using these specific flags to enable ZGC (these only work on Java 24+, due to "compact headers" support):

-XX:+UnlockExperimentalVMOptions -XX:+UseZGC -XX:+UseCompactObjectHeaders -XX:+AlwaysPreTouch -XX:+ExplicitGCInvokesConcurrent -XX:+ClassUnloadingWithConcurrentMark -XX:+UseStringDeduplication -XX:+OptimizeStringConcat -XX:-OmitStackTraceInFastThrow -Dfml.readTimeout=200 -Xlog:gc+init -Dchipped.datafixers=false

ZGC seems now to be working really well at both 8Gb and 12Gb. If you play the LIGHT version, set both min and max memory to 8192 MiB. If you play the HEAVY version try both min and max memory at 12288 MiB.

Remember that if you play the Heavy version and set memory at 12Gb then you should have 32Gb of total system memory. This because the amount you set is the base allocation, and the game will overshoot that by at least 20%. Then you also need space for the OS and other processes. If you have 16Gb of total system memory keep the launcher setting at 8Gb, or maybe do some tests at 9 or 10, but do not exceed that.

When setting up the Java version in a launcher like Prism remember to enable the option "skip Java compatibility checks." Otherwise you'll be limited to Java 17.

The Gregorian Nightmares Team

profile avatar
Owner
  • 1
    Followers
  • 2
    Projects
  • 12.3K
    Downloads

More from enmumne