[SUGGESTION] Allow players to define their own rooms for this mod

Not sure if this is already in, as I only recently managed to overcome a nasty issue I had with 1.15.2, but would it be possible to allow players to create and define their own rooms for this mod's dungeons?

I'll consider it. Writing a config file is high on my TODO list. I might be able to work something into the config file such as a list of additional structures to use from another datapack.

HOWEVER - would you consider first building the rooms, and then submitting them to me (perhaps as a pull request) for inclusion in the main mod instead? I'll give you credit for your rooms, and you can hide oak signs out of bounds stuff like that. I don't expect many people to want to design rooms, and the rooms themselves have to meet very specific criteria. If your rooms use non-vanilla blocks then I can just disable those rooms if the parent mod isn't present.

Regardless, here is how to get started building your own rooms. Start with a superflat creative world. Turn on chunk boundaries with F3+G. Place a Structure Block in the corner of the chunk. Load the structure dimdungeons:basic_template. That should give you a lot of info right there. All of my rooms are a consistent height, have a consistent roof, semi-consistent walls, and consistent doorways. Be sure to save your rooms always facing the same direction and with the same offsets. Try not to leave redstone on the outside of the structure. (I've broken my own rule but I try to avoid it.) Try not to let fire or explosions 'escape' a room. You can use the 5 blocks of sandstone 'below' a room to make a room feel deep or you can use it to hide redstone. Make sure your room works in 1.15 or 1.16. (It's okay if it has to be excluded from 1.14.)

Thank you for your interest!

HOWEVER - would you consider first building the rooms, and then submitting them to me (perhaps as a pull request) for inclusion in the main mod instead? ... and the rooms themselves have to meet very specific criteria. If your rooms use non-vanilla blocks then I can just disable those rooms if the parent mod isn't present.

Frankly? No.

To elaborate however, I say no because I would not want to be making rooms for everyone instead of making them for myself or my packs. There are certainly people who would be willing to make rooms for little to no reason, but most people would be making custom rooms for their own reasons. Whether that be because they want to, because it is to craft a very specific type of experience or something else, I can't say.

I can, however, explain how I would use it. I like developing packs, and I tend to go down the deep end instead of just balancing stuff. While this mod is interesting on its own, it'd be like dropping Dimensional Doors into a pack and not doing anything with it. It'd be a neat gimmick but ultimately pointless, and I'd likely just cut the fat so to speak than keep it in and risk destabilizing the experience I was building towards.

If I could make custom rooms it'd be specifically for progression reasons, because this mod fits well in the sense that you can't just mine your way or place blocks around every problem. You'd be forced into the pace the packdev sets if they can remove all default rooms and craft their own dungeon entirely. Hidden rooms, pitfalls, custom loot, etc. It'd work well together with something like GameStages because you could lock recipes behind consumable items to let players learn them individually (or globally). You could also just dump various loot, that has been made uncraftable, within it too so you get that fancy kinda-one-of-a-kind loot.

You can't, however, make custom rooms or revamp the entire thing by disabling all default rooms or anything of its like.

And while letting people add rooms to the mod, for everyone, is all fine and dandy. It won't work, even if you disable rooms if the host is missing some of the parent mods of a room.

Say you have a room made out of blocks from seven different mods, and one of those mods are contenttweaker. Some of the blocks and more importantly, the loot, are all custom made through contenttweaker. The host will meet the mod requirement criteria, and the room will spawn, empty and possibly missing some blocks. What then? Do you simply stop any rooms from spawning if they contain items or blocks from contenttweaker or similar custom-content-creation mods?

What if a room contains blocks from a mod the host has, but in this specific build it causes everyone who loads the area to crash if they load it. Do you create a stupidly complex detection system to check each and every possibility?

And what will you do if the room is specifically made for progression within a tightly controlled pack out of completely vanilla content, but it makes no sense and only seems stupid outside of that pack? If not that, then what if someone makes a room that is either culturally disgusting to a small subset of people, a giant meme, filled with lots of racist shit, or other such things? Do you curate all the rooms manually to check? And if the issue is not immediately apparent, but is months down the line, do you take the blame? You curated it after all.

And that's not even mentioning all the absolutely completely unnecessary bloat that'd cause over time!

It is simply unfeasible in the long run. And you really don't want that responsibility either.

Letting people make their own custom rooms, and managing them themselves, solves essentially all these problems and is ultimately much easier to maintain in the long run.

I love that you're adding new rooms to use modded blocks, and especially that you plan to use it to implement progression. I've thought about the kinds of rooms I'd make with Botania or Immersive Engineering if I 'could'. (I can.) And the idea of adding rooms that require progression from other mods seems just awesome to me. I've always intended DimDungeons to be used in modpacks first, and played stand alone second.

Please advertise your modpack either here and/or on my CurseForge comments. I don't know what you have planned exactly? But if you're willing to go this in depth with a progression modpack then that's exactly the type of modpack I'm interested in.

1.16 has been challenging with world gen changes. I have a custom chunk generator working again, but 1.16.2 basically removed structures and features from the game. I've been struggling with workarounds to get my custom "structures" to work with the new worldgen and I'm still very stuck. I think I'm going to have to redesign the mod to do something like build the dungeon at the moment the key is inserted. Not to mention other issues like how I've lost my primary means of preventing players from breaking blocks in 1.16.

Something I wanted to add for myself is a config file for room frequency. Because the more rooms I add, the less likely the keyhole rooms with the level 2 keys are. And I want to make other rooms more rare and more special too. 1.16 has already been a total rewrite of the mod except for the dungeon generation logic. So when I get to this part I'll consider what you're asking for.

The best part about this mod is the fact that dungeons are themselves in a form of adventure mode, so I can really go all out without being worried about giving players free stuff and breaking progression. Like Mekanism laser traps, hidden rooms using pistons or other 'ghost' type blocks, etc.

I'd honestly love it if I could make entire custom dungeons instead of being able to just modify the default and advanced one, because then I'd be able to make dungeons themed to one (or multiple) mods/experiences at the same time. Like an entire dungeon made out of blocks similar to Dimensional Door's Fabric of Reality, with occasional structures with light sources and treasure, all while being hunted by something like the Grue.

Because of that, I do wish room sizes weren't so restrictive. It would have been funny to add a secret room that's more or less just the lair of an Ice and Fire dragon- where the door locks behind you until you kill it, which can be made through various mods or just command blocks. It'd also be fun to be able to make pitfall rooms, so the entrance is defined in the roof with structure blocks or something, it'd make it easy to make horrible murder traps, like a room full of death worms or something.

Something I wanted to add for myself is a config file for room frequency.

Please do. That'd make it more reasonable to make 'legendary' hidden rooms with greater loot or something.

Please advertise your modpack either here and/or on my CurseForge comments. I don't know what you have planned exactly? But if you're willing to go this in depth with a progression modpack then that's exactly the type of modpack I'm interested in.

If I ever get around to publicly releasing it, I'll try to remember giving you a heads up.

1.16 has been challenging with world gen changes.

I'm currently putting the pack mostly together in 1.15 because Create is not on 1.16 yet, and Crossroads MC is too, so I can't say it is currently a huge issue for me. I do have plans to move up to 1.16 eventually, mostly because if I understood the Terraqueous dev correctly, they added translucent clouds in 1.16 which is dope and I hope I can use it to re-create this to some degree.

Regardless, good luck! I hope you manage to figure out a solution eventually without burning yourself out.

On that note, I once made a rough concept on how worldgen could work to allow a different type of structures. It was for 1.8, so Vanilla implementations changed a lot since, but it's a complete overhaul anyway, and one that would probably be worth a coremod, so I'll just mention it in case someone (could be any coder, really) feels like putting in the time and effort. Or, if you feel like completely overriding worldgen for your dimension, I think this concept would fit your needs very well.

So, the approach heavily ties in with a concept for a template based structure system, strongly inspired by the TML format from Ruins but with a system for multi-room structures, as well as some other improvements. There would be 2 types of templates: The individual rooms, so-called structure modules, and the structures themselves.

Structure templates contain the data that holds the structure together: Some basic information such as the biomes it spawns in or whether it fully generates earlier than caves (thus being torn apart by cave generation), the module generation starts from, and the modules that can be appended onto it.

Modules, meanwhile, make up the geometry of a structure. First, they have a bounding box and a ground height (with -1 designating that the ground level can be anywhere outside the module's bounds).

Next up is the layout of the module. Much like in Ruins TML, the block placements are abstracted into rules. Besides a simple hard-baked block, a rule can also be a list of blocks that will be randomized from, as well as a conditional. A conditional is basically a kind of if blockList.contains(blockAt(position)) then rule1 else rule2 and comes in 2 variants - regular conditionals check the block that was originally there, while postconditionals check the result of the structure generation. (This needs dependency checks for block positions, since postconditionals would be delayed until their checked block is resolved, and in particular some check that stops generation early if there's recursive postconditionals. Ruins only supports a slightly simpler version of postconditionals, by the way.) And there's references to other rules - while rather pointless directly in the rule list, they can be used to remove redundancy from conditionals by referring to a complex rule instead of copying it into another complex rule. Then follow the layers, either top to bottom or bottom to top, that simply point to the rule that's to be applied at the respective position.

The final section of a module are the connectors. Those are subareas of a module's bounding box and, as the name implies, define how modules connect with each other. Here, and only here, are modules allowed to overlap - and only with connectors that are both compatible AND belong to modules of the same structure. (Organic structures, such as caves, can freely overlap module-based structures.) Besides their span within the bounding box of the module, they have a type ID (which can be any string literal, but I had a convention of lowercase alphanumeric with hyphens as separators in mind) and a whitelist of type IDs they can connect to. Plus, some flags for whether they can be left unconnected, whether they can overlap with just a part of a connector, and whether they can overlap with multiple connectors at the same time.

World gen itself is divided into a bunch of steps:

Determining biome borders and POI positions.
Determining ground heights.
Computing modular structure layout.
Generating the non-structure blocks.
Resolving before-cave modular structures.
Resolving organic structures.
Resolving after-cave modular structures.

Step 1 through 3 would be performed earlier and on a notably wider radius than the rest, in order to give the structures some room to expand. Anyway, all those who kept reading up to this point are apparently quite interested in this, so maybe someone could imagine to try and put this into code? (Honestly, I failed at locating where to even put the code so that it properly replaces 1.8's generation algorithm. Somewhere in net.minecraft.world.gen all of the relevant stuff comes together, that's all I found out, and even that might be different for later versions.)

Version 1.09 offers a start to data driven rooms. In the common config there are a bunch of arrays of arrays of strings which can be used to add structures from other namespaces, as well as tweak their relative weights (by simply listing rooms multiple times).

I won't close this ticket yet. But there is something usable done.

Thank you for the time and effort you're putting into this :)

is there a wiki post related to this? I didn't see anything related to making custom rooms, and I'd very much like to be able to do so also. But I'm worried about the uniformity of the rooms and their shapes and whether it'd be possible to make them link to each other using basically a "room -> hallways -> room" sort of chain.

Where rooms could be designed in such a way that theres always atleast a 5x5 (3x3 inside) exit/entrance points to each room, and then additional corridors of different shapes and sizes would be attached to those instead.

I need to make wiki pages for this, like many other things. But many people have figured it out and I answer questions in my Discord, here, and on CurseForge. I designed it to be as easy as possible.

First, I assume you're comfortable with structure blocks. Place one and summon the structure dimdungeons:basic_template. This 16x13x16 structure explains everything.

Longer explanation:

If you turn on chunk boundaries and travel through any dungeon you'll notice that the doorways are always 3x2, and always in the center of each wall. That's the secret to how they always line up.

As for creating and saving your rooms, I recommend looking at other rooms. Unzip the jar file, navigate to the dimdungeons/data/structures folder, and check out all those nbt files. Each is a 16x13x16 room that you can load with a structure block, modify, and save.

While doing this you'll see certain conventions that I follow. Dead ends are always saved with the lone door facing south. Entrance rooms also have a specific, consistent rotation. Hallways are saved north-south. And corners are saved south-east. Also I use special data blocks just like Mojang does. My most common ones are "EntrancePortal", "ReturnPortal", "SummonEnemy1", "SummonEnemy2", "ChestLoot1", and "ChestLoot2". (Place the latter two above a chest.)

There are two steps to adding a new room that you have built. First add it to a new datapack, just like vanilla. Except then instead of making your new structure spawn in a biome or something, add it to the dimdungeons common config. And that's it!

From this point it is probably easier to answer your questions than to give more instructions.

AllenSeitz / DimDungeons

[SUGGESTION] Allow players to define their own rooms for this mod #11