Dungeon Generation (Like Mineshaft)

Yeah, jigsaw blocks are kind of overrated. They're useful, but very limited in how they can function. I also came across the idea of using world features instead of structures, and using modded blocks to place them post instead of pre generation- I also recently finished overhauling mineshafts! Hopefully I can help out a bit, MCreator sounds like a great teaching resource. Here's an example of an early generation test, using modded blocks to randomly select halls/rooms, and then randomly place furniture, cobwebs, rubble, etc.

Looks kind of messy, but the basic idea is similar to what you came up with- there's a large central room, and then it generates hallways and rooms in a grid pattern, with the rooms randomly being a dead end, corner, t-junction, or shaft; and the halls randomly being a straight hallway, stairway, or split stairway. In order to avoid worrying about y-axis intersections, the central room is always at the bottom, and the shafts and stairways always lead upwards.

There's still the problem of making sure a hallway or room doesn't accidentally generate where there's already a room or hallway. As long as you're doing this post generation, (so a world feature that places your modded block, instead of an actual structure), you can use a recursive procedure to check a box for a block. (There's even a 'check for block in 6*6*6 box procedure template that explains the idea pretty well.) Each of the hallway-selector blocks checks for wooden planks directly adjacent to it to determine the rotation and offset of the hallway, and also checks in a rectangular box in that direction for wooden planks, or other obstructions. (Such as lava, or sky access, indicating the mineshaft is too close to the surface.) If it finds an obstruction, it generates a dead end hallway instead that cuts off immediately. 

Some other issues I ran into:

• It's tricky (but not impossible) to determine whether a room/hall is underground or in a cave. To avoid making even more random structure variants, These ones work either way, and have additional generator-blocks that use recursion to randomly place support beams above or below them if they're in air. 
• Aquifers are also a nuisance. I used a custom generator block that vanishes and then simply replaces adjacent fluid blocks with cobblestone, and then used those on all the ceilings and walls.
• ...And of course this will generate totally out of control if you don't have an end condition. I made an invisible marker entity that spawns in the central room, and despawns after 20 ticks or so, depending on the amount of tick delay you have on your generators. The likelihood of choosing a hallway or junction instead of a dead end is determined by how far away the generator block is from the nearest marker entity, and immediately hits zero when no entity is found. (So the mineshaft is densest nearer to the center.) 

Anyways, good luck with the teaching! I've been working on this procedural structure idea for way too long now, and it's as fun as it is frustrating. Minecraft is a great tool just by virtue of how accessible it is, but it can quickly become troublesome just by how complicated modding can become, both as a result of how old the game is, and how many volunteer-run third party tools you need to mod it... but best wishes! Maybe consider looking into Gamemaker Studio too, it's another great free game-design tool with decent teaching value and accessibility.

You've got the right idea! I'd just give a couple of pointers:

• Don't use a global variable for the center timer, otherwise you're going to run into problems if multiple dungeons try to generate at the same time. You can spawn an invisible entity in the dungeon's center, and then have your procedures check if such an entity exists in a certain radius. This has the added bonus of letting you always be able to use the center of the dungeon and the distance from the center to determine the dungeon's generation.
• In terms of your problem, I think you need to change the way you're generating each section of the structure. Here's the basic idea:

(Oops, the bottom left corner is supposed to be N/E, forgot to change it!)

• You can build your generator blocks into your structures, like so, and then use which corner they're in to determine where to generate the next structure, and with what offset/rotation. If you always place a block on the left hand side of where you want the path to continue, then there will only ever be four possible configurations it can be in. (You can use the adjacent cobblestone blocks to determine which corner the generator is in.) 
• In order for this to be a bit easier, I recommend making a gamerule that determines whether or not your generator blocks do anything on update tick. This way you can turn it on and off while in the game, depending on whether you're building with them, or testing the generation, and you can have one world where the generator blocks don't do anything, (so that you can build with them), and another where they do, (so you can test that they're working.) It took me an embarrassingly long time to do this, before which I was just manually disabling the code every time I wanted to test anything.
• Your other issue is that your structures are overriding each other. Each time a segment of your dungeon generates, it replaces each of the adjacent four spaces with a new room- including the room that it generated from. This will be partly fixed by having the blocks built into the structure, but there's still the chance that a hallway winds all the way back around and cuts through existing rooms. For this, I recommend using a modified version of the 'check for block in 6*6*6 box' procedure template to check for cobblestone where the structure is trying to generate, then only generate the structure if cobblestone isn't found in that box. This should prevent your pathways from intersecting.
• And lastly, use more procedures! Usually my advice is to try to condense things as much as possible, but in the case of something like this, with a lot of moving parts, it's easier to fix and edit things if you have a separate procedure for each step of the process. (Also, at least in older versions, MCreator slows down when you reference a lot of structure files in one procedure. I don't know why, but it's annoying.) In your case, you could have a separate procedure whose sole purpose is to randomly choose from a list of structures and place them in the world; or multiple, different procedures for different room types, rotations, etc. (This way you don't have big bulky sections of code in your generation procedure devoted to picking structures, and you can also edit the chances of each structure being chosen without having to worry about messing with the larger scale generation.)

Good luck, it looks like you've made a lot of progress already! I could also send examples of my generation code, if that would be helpful?

Sure thing. Here's some examples of the actual structures:

The first one has structure voids turned on, just to demonstrate that these will work underground or above ground. The orange floating blocks are structure voids, (they assume the form of whatever was already there), blue floating blocks are air, and the red ones are a block of my own design, which becomes solid if there's water or lava adjacent. (To prevent leaks.) The generator blocks are kind of hard to tell apart, but the ones on the pillars continue the pillars up or down if there's air above them, the one under the rail in the first image generates a room in the direction it's facing, and the ones with the pink blocks behind them in the second image generate a hall. (The pink block is just to simplify determining which direction the block is facing, it's replaced with oak planks once the hallway generates.) The rooms and hallways are also a very specific size so that everything lines up properly in a grid. (You don't have to worry about this if your dungeon is all box-shaped rooms, but keep in mind, as long as the paths line up, you could make more complex arrangements with halls, larger rooms, etc.) 

This is the first, (well, technically the second) procedure run by the first generator block. The entire structure is saved as a single block, which is generated underground. (There's another procedure that gives the block an update tick when the world feature generates, since naturally generated blocks don't tick by default, but this is the first important procedure.) If the gamerule is true, (it can be disabled so I can build using the generator blocks), it first replaces the original generator block, then checks for another gamerule. (I use this one so that players can configure the likelihood of different structures.)

If both pass, it waits a random amount of time before calling the build procedure.  Since I don't want two mineshafts generating nearby, I need to check the surrounding area for other mineshafts- I randomize the delay before checking so that if two mineshafts generate next to each other, one is likely to generate first and prevent the other one from generating. Not an ideal method, but works most of the time. (Also not something you need to worry about if you don't want your dungeons to generate naturally.)

This is the second procedure, which the first procedure calls. It again makes sure the gamerule is enabled, then calls 'mini-village-scanner,' which runs a larger check in the nearby area and on the surface for other structures. (Again, to prevent structures from generating nearby.) If we've determined there aren't any structures nearby, I then do a sort of 'tolerance check' to determine whether the nearby area is suitable for a mineshaft. (And not, say, the middle of a lava lake.) This uses the 'check for block in 6*6*6 box' procedure template I mentioned, but modified for a 30*16*30 area, roughly the size of the mineshaft center. It increases a local variable every time a location in that box is lava, tagged as 'structure blockable,' or exposed to the sky, and then only allows the mineshaft to generate if the variable is below a certain number.

...That's all mostly related to determining whether or not it should generate, which probably isn't your main concern, but useful if you're planning on it at some point.

Once we know the mineshaft is going to generate, we choose the type of mineshaft based on the biome, (there's three different types for warm, cold, and temperate biomes), set a local number variable to a random number to determine which variant of the mineshaft center to generate. (this is the same thing as the random chance you use, it's just easier to keep track of probability.)

...And that's about it. Everything else is the individual generator blocks in each section of the mineshaft deciding whether or not to add another room, what type of room to add, and how to rotate it. They use a check that looks something like this:

Which is basically just the 'check for block in 6*6*6 box' procedure template again. This is what determines whether or not a new room/hall is added, or a dead end is added. You do, however, either need multiple versions of this depending on which direction you need to check; or need to call this with an offset each time you check. In this case the box size is 16*12*16, the size of the room/hall structures.

From then on, if this returns true, there's a bunch of additional procedures that just randomly choose which structure to place. I've locked each of them and made duplicates set to slightly different directions and offsets, and then just call the correct room-selector procedure depending on the type of room and direction to generate it.

Hope some of this is helpful!

BTW, I've been doing some experimenting with 2023.4, and updating will very much break structures generated in this manner. It is still possible to lock the mod elements and manually return them to their previous versions, (I've also been looking into using entities in true structures instead, as these will tick even when naturally generated), but just a heads up if you plan on updating, might be a bit of an extra headache.

This Was Insanely Helpful even to me Thank you for Making this forum post , you all are life savers!!!!

Code copied from stuff compiled in the previous version will still work in the latest version of MCreator, but you then need to edit the Java code directly- you can also sort of do the same thing with world features in the latest version. I've been told a more effective method in the latest version of MCreator is to use an entity to begin the structure generation process, since these tick by default, but haven't tried it myself. I've just been copying a template 'custom structure block that schedules an update tick of itself' from the older version of the mod, and then just doing the actual code editing on the block itself.