• 1

    posted a message on [1.15.2] Ruins (Structure Spawning System)
    Quote from AtomicStryker»

    Yes


    The <condition> part of a rule, in which you could put values like "only spawn if adjoining block exists" or "only spawn if block below exists".

    Mostly used in conjunction with wall torches, signs etc which relied on blocks other than themselves - but the new IBlockStates make that irrelevant. AFAIK blocks should no longer calculate their own status using neighbour blocks. (Pistons maybe?!)


    Okay, but the "ruined" part of Ruins (or the randomization thereof) pretty much depended upon those sorts of relationships. I could have, say, a crumbling wall structure, and randomly take chunks out of it, but in order to make sure that doesn't result in orphaned blocks floating in mid-air, rule #1 was handy for making sure none of those blocks would be placed unless they were supported by something other than air.


    I can still make "ruined" buildings, it seems, but I either make it a static structure (it is ruined in EXACTLY this particular way), or else I just have a few select blocks that might or might not be missing here or there, but there will still be an underlying "skeleton" that will still be intact, to minimize the chance of gravity-defying segments floating about. It's doable, I hope -- just different.


    Anyway, I'm presently working my way through my library of structures and modifying them: removing all "random" elements, converting dungeon chests back to plain empty minecraft:chest objects, disabling any RUINSTRIGGER Command Blocks, zeroing out "embed_into_distance" settings -- and then to replace all instances of "preserveBlock" with a placeholder block, such as stained glass). For now, anything of mine that used Command Blocks to spawn custom one-time monsters (or structures) isn't worth the trouble, since that part isn't working. I'll try experimenting with the adjoining templates, to see if they work.


    I'm curious to see whether any of my customized Mob Spawners might actually work (if they'll be picked up by the parseruin routine); no harm in trying, I suppose.


    My plan is to spawn them all in a superflat 1.12 world to serve as a conversion "workshop" -- one layer of bedrock, one layer of diamond block, and I ought to have a good starting point for base plates to chip away at as needed for parsing in 1.13.


    I guess I'll try converting over the old Ruins-bundle ruins as well.

    Posted in: Minecraft Mods
  • 2

    posted a message on [1.15.2] Ruins (Structure Spawning System)

    i would really like to use this mod to have custom structures generate at random in galacticrafts space dimensions. is this possible? is there a way to choose what dims the structures gen in not just the biome? if not can you ad a way to do this? recurrent complex...is just to complex...


    I know that you CAN whitelist the Galacticraft dimensions, so that Ruins *can* spawn there. You'll need to actually create a Galacticraft world to force Ruins to create the "ruins.txt" config file, and then edit the dimensions list to make sure the dimension numbers assigned to the Galacticraft dimensions are included.


    It's been a long time since I've played with Galacticraft, so I can't remember whether it has its own unique biomes. *IF SO*, under the way Ruins is currently structured, you could control what Ruins spawn in the Galacticraft dimensions:


    1) Remove all templates from the "generic" folder.

    2) Put ruins you want to spawn in Galacticraft biomes into the appropriate biome folders.

    3) Make sure you don't have any Ruins templates in non-Galacticraft biome folders that would still spawn in those biomes.


    Unfortunately, some new features of Ruins would make that harder. The old "BiomesToSpawnIn" field would specify a list of biomes the template CAN spawn in, and if you add some new mod that creates new biomes NOT on that last, then the template just won't spawn there (unless you copy the template and drop it SPECIFICALLY into that new biome folder). HOWEVER, the new version of Ruins allows for "types" of biomes, and so far as I know, the types associated with Galacticraft biomes will still overlap with "normal" Minecraft biomes (e.g., dry, cold, dead, mountain, rare). So you'd need to police for any such settings in templates that might result in a Chalet that was intended for "Extreme Hills" that suddenly ends up on your lunar mountain moonscape because (I'm just making stuff up here) the local biome happened to be "Mountain" and that type was specified in the template.


    (Too bad there isn't, say, a standard "OuterSpace" or "Futuristic" biome type. I could just make a point of being sure that all Kujaku's and my cottages, chalets, castles, etc., specifically EXCLUDE spawning in such biome-types. No Kujaku-cottages in space!)


    A dimension-lock feature for templates would be *nice*, and it's actually something I've wished for, but I have trouble envisioning the best format for it. A field that might list dimensions in the template ("SpawnDimensions=-1,0,1,7,111") would only have utility if those numbers had universal meaning across all mods (but they don't, necessarily). Maybe if there were a dimension-name-assignment in a separate editable config file? (E.g., Overworld = 0, Nether = -1, End = 1, Twilight_Forest = 7, Lost_City = 9...)

    Alas, it'd be another real challenge to account for "open-ended" dimension-generating mods such as Mystcraft. (But then ... I don't know that Mystcraft has been updated for several versions of Minecraft, so that might be a moot point.)

    Posted in: Minecraft Mods
  • 1

    posted a message on [1.15.2] Ruins (Structure Spawning System)
    Quote from QuarterAnimal»

    Is it possible you either misspelled the teblocks parameter (all lowercase, and mind the "s"), or set it in the copy of ruins.txt in the config folder instead of the one in the world folder? It seems to be working fine for me, and the symptoms you describe are exactly those of not having set teblocks to include those particular blocks you're interested in.


    Derp. O_O Yeah, I set it in the config folder rather than the world folder, hence why it didn't take. For some reason, I keep having this idea that I should make my configuration changes to the config folder. ;) Anyway, I changed the ruins.txt file in the world folder and -- voila! -- /parseruin is capturing full teBlock data now, and differentiating between EACH teBlock instance.


    ...


    The weird thing? Now I'm tempted to change it back. Unfortunately, every single instance of flower pot is going to have DIFFERENT data, even if it's the same flower, because the X/Y/Z values are of course going to be different each time. So I get one rule for EACH flower pot (rather than just one rule for "each flower pot with a pink tulip in it"). And when I went overboard hanging banners inside the windows to act as curtains ... well, there's now one rule for each and every banner. So, I guess there are some pros and cons for having Ruins handle this automatically.


    Anyway, thanks for setting me straight. :) Eventually I'll remember these things! (Probably about the time that 1.13 renders everything I already know about Ruins moot.)

    Posted in: Minecraft Mods
  • 1

    posted a message on [1.15.2] Ruins (Structure Spawning System)
    Quote from QuarterAnimal»


    ...means any forest and/or jungle biome that isn't also a redwood, hills, or mountain biome is eligible. However, spawning in both mutated_forest and mutated_birch_forest is allowed, even though they're hills, because they're explicitly listed by name in biomesToSpawnIn. The exclusion lists only apply to biomeTypesToSpawnIn.


    Wowzers! As an added bonus, I wouldn't have to include both "beach" and "beaches," or "extreme hills edge" and "smaller_extreme_hills" while straddling the biome-name change for 1.12 structures (so that I don't have to maintain separate templates for 1.12.0/1 and 1.12.2+ MC installations).


    A question: Would "biomesNotToSpawnIn" be useful for structures otherwise placed in the "Generic" folder (so it becomes "let's put this everywhere EXCEPT here")? Or does being in "Generic" simply bypass all that?

    If such a feature is included, it might be useful to have that list of "types" included in the Ruins documentation somewhere. I'm not sure where I'd look it up, otherwise.

    Posted in: Minecraft Mods
  • 1

    posted a message on [1.15.2] Ruins (Structure Spawning System)
    Quote from QuarterAnimal»


    "?" means "place this block only if the block that's already here is not an ignored block." So, what's an ignored block? Air, mainly, but also snow_layer, web, and almost all plants*, leaves, and logs. This may or may not include blocks added by other mods, depending on how they're implemented. But wait--that's not all! If you set preserve_water=1, you also get flowing_water, ice, and water; if you set preserve_lava=1, you also get flowing_lava and lava.

    The most obvious example of the "?" prefix is one you're probably already very familiar with--the default rule0 is literally "0,100,?air". This is an air block that won't disturb plants, webs, or snow layers (or possibly water and/or lava, depending on preserve settings). Without the question mark, it would replace everything with air.


    "!" means "place this block only if the block that's already here is an ignored block." It's the opposite of the "?" prefix. You might, for example, have a structure perched on long columns of "rule1=0,100,!fence", and an embed_into_distance of, say, 3. The fence "pillars" will extend down to the surface and no further, since they can only replace air (and plants, and yada yada yada). I think that's what you were looking for.


    * There are some curious omissions: brown_mushroom_block, chorus_flower, chorus_plant, cocoa, melon_block, pumpkin, and red_mushroom_block.


    Awesome! This will prompt me to revisit several of my structures (e.g., my ruined quartz columns -- which probably ought to be excluded from any Tinkers' Construct pack anyway) to make sure that they don't needlessly protrude into the ground.

    The "?" rule is interesting, as it seems ideal for stuff like ore or clay deposits, or perhaps some sort of "damage/deterioration" effect.


    Regarding the omissions ... yeah, I had some trouble trying to get structures to spawn in roofed forests. I ended up having to include brown_mushroom_block and red_mushroom_block in unacceptable_target_blocks, and any of my little "mushroom houses" that DO spawn in such a biome only manage to do so by finding a spot not already shadowed by a giant mushroom.


    That brings me to another topic: What is the ideal list of unacceptable_target_blocks as a default?


    I'd like to propose that the templates generated by /parseruin should probably include things such as command_block as an unacceptable target block by default. (If THAT is the target block, something has gone terribly wrong!) I'd be inclined to include a list of various blocks that don't occur naturally (cobblestone, planks, bricks, stone bricks, slabs, stairs, walls, torches) -- and even a few items that aren't in Vanilla (cloud, slime_dirt, slime_grass) so as to avoid sky-island mishaps -- but I worry that if I make the list TOO long, could that significantly slow down the process?


    I have gotten the impression that only the central target block is checked against acceptable_target_blocks, but that it checks all the blocks at the target layer (within the footprint) against unacceptable_target_blocks, so a really long exclusion list could take a while to do all the comparisons. (Am I right or wrong on either point? It'd be useful to know for sure. :) )


    Therefore, while I think it might be a good idea to have a longer exclusion list by default, maybe an optimized list would be a little more "strategic," sticking to the more likely culprits. (E.g, maybe cobblestone and planks to reduce the chance of building atop a village, but not necessarily every single type of stairs.) Since I've got a rather long exclusion list for most of my templates (1.12 versions, anyway) at the moment, it'd be nice to know if that's something I ought to change for the sake of speeding things up, or whether it's something fine to leave as-is.

    Posted in: Minecraft Mods
  • 2

    posted a message on [1.15.2] Ruins (Structure Spawning System)

    @QuarterAnimal:

    (gasp, sputter!) It was already THERE? :U Er, how many versions back has that been implemented? Okay, I've got to try this out. Thanks! So what is the difference between the ! and the ? prefix? (Are there any useful examples of this in action?)


    Okay, a few more wordy wishes for my letter to Santa Claus, since I've had time to mull over it:


    * Feature Examples:

    I would love to see some sample structures that serve as showcases for various of the new features to be included in the pack. Having a list of features is one thing. Seeing it in ACTION is quite another. The template could humble and simple, and might not exist anywhere other than in the \templateparser folder, but it would still be quite valuable, I believe, to demonstrate possibilities. Like, for instance, those !dirt and ?dirt examples and whatnot. :)




    * Nether/Cave World Options:

    TLDR: It'd be nice to have options as to how structures spawn in the Nether or other "cave world" dimensions, but the default should be however things are done right now (cave ceiling). Other options: Limbo (spawn at limbo layer), Cave Floor (spawn on floor of cave), or Overworld (use Overworld despite being in cave world, as in older versions of Ruins).


    Once upon a time, if I spawned structures in the Nether (hell biome, etc.), the top bedrock layer would be treated as the "ground," and any amount of "embedding" could potentially represent a passage carved into that surface, thus permitting the fun spectacle of "stairways to limbo" that would allow characters to pop up on top of the Nether to see the bizarre red sky, the endless flat expanse of bedrock, the occasional clusters of mushrooms, and occasional breaking up of the horizon by rogue Ruins structures (and whatever mobs might spawn on top of those non-bedrock blocks).


    At some point, the logic changed again, and it seems that the target block became the CEILING of any given nether cave -- which MIGHT permit a structure to bump up against (and even break through) the bedrock ceiling, but never to protrude above it. If I wanted any dark towers or huts or anything resembling an upright structure in the Nether, I had to resort to a scheme of Command Blocks, RUINSTRIGGER, and Falling_Sand to spawn a "falling command block" at some arbitrary elevation, HOPING that it would spawn in an open cave, and then letting it become a RUINSTRIGGER Command Block that would eventually fire off when a player stumbled close enough -- causing a TowerOfEeeeevil or NightmareDungeon or GiantSkull or whatnot to suddenly erupt from the spot. That's fun and all, but a bit convoluted.


    Since the normal rules don't seem to apply for structure placement in the Nether, maybe there could be some sort of parameters to specify how structures spawn there? Particularly of interest to Generic structures, perhaps some of them ought to simply never spawn in the Nether (or any other Cave World dimension) at all, if they're not designed for it.


    The main logic options I can see of use would be:

    * Cave Ceiling: Current logic, whatever it is, which I *think* is starting at the bedrock layer, then going down until it hits air (with a chance of failure, I presume, if it never does hit air).


    * Overworld: Spawn the old-fashioned way, looking down from the "sky" and treating the first encountered non-air, non-plant (optionally non-water, optionally non-lava) block as a potential target point. Structures using this rule in a Cave World would necessarily either spawn on top of the bedrock, or some distance underneath (as dictated by embed_into_distance) -- or perhaps above (via negative embed_into_distance).


    * Limbo: Skip the Overworld logic and just start at the upper bedrock layer. No need for level checking or whatnot: Assume it's flat. Acceptable/Unacceptable blocks could be used to protect against "Ruins collision," if that's a concern. I'm taking a wild guess that this ought to be pretty fast, if those other steps can be skipped. (The only reason I could see anyone would want "Overworld" logic would be for stuff like Gillymoth's crazy-awesome city structures that are designed to pile on top of each other, or for generic-folder structures that really *are* intended to spawn in the Nether just as much as in the Overworld.)


    * Cave Floor: Start at bedrock layer, go down until you hit air, THEN keep going until you hit a non-air, non-plant block (and optionally non-lava, non-water, as per preserve_water and preserve_lava rules) with a chance of failure if no such thing exists. The idea is that this would LOOK to explorers as if it were working just like Overworld Ruins placement, but it's inside the Nether cave, not on top of it.



    How to implement in the template? Idea: Maybe a "netherSpawning=#" parameter where each rule is numbered. Default is 1, which is to allow it to spawn in cave worlds (Nether) using current logic (cave ceiling) -- in other words, to behave however it is behaving right now, so templates that do not use this field will continue to behave the same way.


    Setting to 0 would prohibit spawning in Nether/cave-worlds (it just doesn't belong in such wacky settings). Other options would be numbered. The field is ignored when spawning in a non-Nether/cave world.


    (I mean, maybe the "Cave Floor" rule COULD be useful in the Overworld, perhaps for structures that are intended to spawn within caves -- such as a dungeon that's meant to branch off from a cave -- but I guess it would have a high failure rate, and such a thing might "accidentally" spawn in non-cave situations, such as worlds with sky islands or land bridges.)



    * Vanilla Structure Basement Option:

    TLDR: Some option to make "houses" spawn with vanilla-Village-style "foundations" -- whether cobblestone, sandstone, or some other material -- rather than flattening the building area first or requiring a "basement."


    I'm wondering if there is already a mechanism for this in Minecraft that might make this possible. Could it be something easy? Or would it be a big, complex nightmare to implement? I've no idea. But the "short" version is to have some toggle option to spawn "foundations" for structures the same way vanilla Village buildings do (either cobblestone, or else sandstone for desert villages).


    Okay, so in vanilla Minecraft, when a villager building is spawned, the ground underneath it isn't "filled in" or "chopped off" per se the way Ruins levels out the ground, but it looks like cobblestone gets inserted to fill in the gap between the bottom of the structure and when it encounters the ground (or solid blocks) below. This process can get particularly interesting when you have mods that allow villages to spawn outside of Plains/Desert, and you end up with buildings clinging to cliff-sides, with little bitty cottages standing atop tall cliff-facing cobblestone towers. (Watch out for that first step out the front door, villagers -- it's a DOOZY!)

    I saw a similar mechanism in place whenever we were playing in modpacks that included Mystcraft: a recurring feature of Mystcraft dimensions was that these little cobblestone "library" buildings would spawn at intervals, even if that meant the building could be perched atop a "tendril" structure (i.e., "inverse caves" -- the twisty cave logic, but filled with stone or some other material, rather than being air pockets carved out of dirt/stone -- quite a bizarre spectacle). Underneath the building, there would be cobblestone stretching all the way down until it hit some solid surface -- so, in wacky sky-island terrain, or if perched on a thin "tendril," that might mean that the front and back of the structure have cobblestone supports stretching all the way down to some surface far below, whereas the areas right under the structure only went down one or two blocks until they encountered the surface of the little "sky island" patch or "tendril."


    It's not exactly an IDEAL mechanism in those extreme circumstances -- but they just sort of helped to accentuate how it behaved. (I.e., take the bottom layer of the structure, and for each non-air block of it, fill in cobblestone in a straight line down until you hit a non-air block. I believe it was just until it reached "non-air," because in the case of a Water World, I recall there being "floating libraries" that would lack any support underneath the waterline.)


    Anyway, if there's some sort of existing routine that could be used, it would be nice to have an OPTION to generate a "foundation" for a structure to fill in gaps underneath it until it hits solid(-ish) ground, in the fashion of vanilla Villages. A nice extra would be if the fill-in block could be specified (Vanilla examples either use cobblestone -- or else sandstone, for desert villages -- but maybe in this case you could just use the bottom "foundation" layer of the structure, and use whatever block is in that position -- and if that block is AIR or "preserveBlock," then there's no need to draw a foundation support down from that point), and if the foundation could be made to go down to a solid (non-air, non-plant, non-fluid) block, rather than having "floating" structures.


    I don't imagine this getting a ton of use, but it's just something I'm curious about, given the aforementioned observed behavior of the way other mods spawn structures. (Plus, if that "include buildings with normal village generation" thing were even possible, I'd guess this sort of mechanism would be useful so they'd fit in better.)

    Posted in: Minecraft Mods
  • 1

    posted a message on [1.15.2] Ruins (Structure Spawning System)

    @QuarterAnimal:

    Regarding the matter of "rule1" ... "rulefrotz" or whatever, I would prefer that the syntax be that if the grid is going to appear as a bunch of numbers separated by commas, ideally the rules that match up with them should sport those same numbers. If you see "1,1,1,1,1" then if you want to find out what's going to be in that space of "1" it would naturally be that you'd look for "rule1" up above.


    As it is right now, I can get away with goofing up and having "rule1" followed by "rule4" and my template might still work because I MEANT to put "rule2" and I had "2" in the layout. However, that I can get away with that just feels sloppy: in good programming design, I feel as if I'd expect to at least get a hand-slap in a game log file pointing out that there was a glitch in my template, even if the program soldiered on as best as it could to interpret the template anyway. (Because, after all, what if I HAD NOT intended that to be rule2?)


    I'm fine with something like "rule0" being something that can be OPTIONALLY be specified.


    I don't personally see any benefit in being able to name rules things like "rulegrass" or "rulestone" if the layer grid is made up of numbers.


    In an ideal world, whatever happens with 1.13, I would LIKE it if the format is such that converting older (1.12) templates could be as simple as running them through some sort of script, doing some sort of search-and-replace. Maybe all instances of "stonebrick-2" become "stonebrick_cracked" -- or however the new format is going to be -- but otherwise if the structure can remain much as it is now, I'm fine with that. The current setup of: a) list of special parameters and options; B) list of rules; c) 3D "model" of structure represented in layers -- that works for me.


    My immediate concern is "How much work is it for me to convert my existing templates over so they're still usable in 1.13?" The main thing that might overrule that for me would just be if the new format would facilitate new possibilities that simply weren't possible in the old format. (What those possibilities might be -- I don't know.)


    I could come up with a laundry list of new features I'd love to see in Ruins, if they could be implemented with a minimum of fuss, but that's another matter and would be the case regardless of the implications of 1.13.


    Off top of my head, my main wishlist (none of it "essential" by any means) would be:

    1) Adjacent Template supporting an (OPTIONAL!) relative Y coordinate compared to the "root" template.

    2) Adjacent Template offering some degree of randomization (e.g., "choice 1, choice 2, choice 3").

    3) Adjacent Template offering an (OPTIONAL) specification of rotation.


    4) Optional "Keep" placement-logic-rule for blocks: e.g., place this block here only if the space is currently "empty" (allowing for "plants" and things such as "water" to be treated as "empty" depending upon preserve_* settings. (Why? So I can have "supports" for a structure that fill in the gaps between it and the ground, much like vanilla Village buildings, without guaranteeing a basement. Going with a super-deep "basement" doesn't work so well in biomes such as Extreme Hills or Crag where there may be "land bridges" or "sky islands.")


    5) Painting Placement sans Command Blocks: Could there be some mechanism for having a placeholder "block," with facing, that gets replaced with a painting when the structure actually spawns? Right now, I pretty much have to use a Command Block with RUINSTRIGGER to spawn a painting. (And I couldn't even do this in anything before 1.12, because painting entities used to require SPECIFIC X/Y/Z coordinates of the block they were "attached" to, rather than relative ones, when spawned, even though the painting's own /summon coordinates could be relative.)


    6) Critter Summon sans Command Blocks: It would be nice to be able to have a placeholder block that, when we hit that rule, executes a custom /summon command right then and there, so I can place a persistent skeleton with custom gear, a villager with custom trades, or maybe I just want some perfectly ordinary pigs in the pig pen. Yes, I can do the same thing with CBs doing the /summon command. It's just that Command Blocks themselves sometimes pose problems (hence why I divided my templates into CB and no-CB sets).


    7) Village Incorporation. :D Okay, this is really pie-in-the-sky and would probably require an entirely different program, but it would just be so cool if there was some way to add custom buildings to Village generation (using Ruins templates) rather than spawning them in random locations. I know a number of mods add custom village buildings. I have no idea what sort of nightmare would be involved, but it's still a "wish" so I'm listing it for the sake of completion, not expectation that I'm being at all REALISTIC. ;)


    8) Mod-check Enabling. Let's say I want to make a template that uses Chisel blocks. At present, I need to put them in a separate pack, and, yeah, maybe that's the best way to do it. But it'd be NICE if, if there's a template that makes a call for "chisel2:such-and-such" block, the program could be smart enough to go, "Waitaminute -- we don't HAVE Chisel installed, so just skip this template, rather than building the structure halfway and choking on the nonexistent block request." If that's too time-consuming to add a check like that, then perhaps a parameter up front that indicates required mods (or required resource folder that must exist as a prerequisite) in order for the template to be loaded up when Ruins is starting up and populating the biome tables. (If the pre-req isn't met, then leave it off the tables.)


    Of course, my best practice is probably just to segregate my Chisel blocks, etc., in a separate pack, much the way ST753Mb does, rather than bulking out a template pack with templates a user can't use, but it's just a thought.


    ...

    Posted in: Minecraft Mods
  • 1

    posted a message on [1.15.2] Ruins (Structure Spawning System)

    @GeetheBlueSky: Thanks for the report. I should have caught that long ago. I've included a fix for that, along with several other templates that needed tweaking with today's update for my "1.12" Adventure+CB pack.

    Posted in: Minecraft Mods
  • 1

    posted a message on [1.15.2] Ruins (Structure Spawning System)
    Quote from Gillymoth»


    To answer the question meant for kellixon, I've only seen runaway worldgen cascade once, and although the logs said it was FastLeafDecay in my case, It's definitely caused by Mojang's generation system doing what it does with a pile-up of decoration features from several mods at once. And neither FastLeafDecay or MCJty's teleporting block would have caused it by themselves, and the same goes for Ruins.


    Actually, every time I've created a world using the Direwolf20 pack, I got a very similar "causing cascading worldgen lag" error in the log when first generating the starting regions for the Overworld -- and yet things worked pretty normally, near as I could tell. Hence, I'm not entirely sure that the problems reported may be directly related to that message, despite the scary-sounding description.
    Posted in: Minecraft Mods
  • 2

    posted a message on [1.15.2] Ruins (Structure Spawning System)
    Quote from QuarterAnimal»
    I'm curious...do you folks generally make these composite structures using the adjoining_template feature, or with command blocks issuing the /testruin command? If it's the latter, I imagine that's a huge hit on performance, since the template file needs to be read in and parsed, and the template object reconstructed, each and every time. That's wildly expensive! Presumably, /testruin was intended primarily for debugging template files, so while using it for worldgen is clever--and probably necessary, given there's no practical alternative for doing what you're doing--I don't know that it's quite appropriate, especially for large or complex structures. If this is common practice, maybe it'd be useful to introduce a new command (something like, say, /spawnruin) for that purpose, caching templates for repeated use as Ruins worldgen and adjoining_template do to avoid the cost of excessive file I/O and parsing.

    Yes, /testruin is something I've been using for various tricks ever since it was possible to invoke it via Command Blocks. One of my first experiments in that regard was my "War Tower," where the bottom level of the tower would appear, and at the top level, there'd be a trapped chest that would summon in the next layer in such a way that the Command Block would "self-destruct" (i.e., be overwritten by the next layer of the tower). At the time, this was my response to some players on my server boasting that "battle towers" were no particular challenge (and hence not much fun), since they could just "dirt-elevator" up along the outside and go straight to the top. Thus, I attempted to make some sort of a "magical tower" that would only appear in phases, so at the very least the adventurers would have to contend with something at each stage before proceeding (and having the tower materializing RIGHT AROUND the party could certainly make things interesting). (Alas, I couldn't figure out a way to plant one of AtomicStryker's Battletowers Golems at the very top -- or bottom -- or I would have spent a lot more time trying to make "custom battletowers.")

    Then, RUINSTRIGGER was introduced, and I started playing around with the idea of having things spawn from a "seed" box. Originally that was because I didn't know about the "-1" trick, and I had a lot of trouble with large-footprint structures being able to spawn anywhere, so I'd have a tiny, 1x1 column structure find a foothold, stacked up with Command Blocks that would fire off to "build" the dungeon underground, with some sort of access point.

    When AtomicStryker added the "_" feature for the Y coordinate, I was able to use that to make my "cursed village" and "shop village" arrangements, where I was trying to ape normal Village construction, but with some sort of twist. Kujaku10 had the notion of having a little village surrounded by a wall, and with the village shopkeepers safely behind counters so they wouldn't wander out at night and get eaten by zombies, and so built the "modular" structures, while I handled the Command Block trickery to get it all to spawn.

    Somewhere along the way, AtomicStryker introduced the Adjoining Templates feature, but I was entrenched in doing it the way I'd been doing, and it was quite some time before I tried experimenting with it.

    I also use Command Blocks for traps -- but some folks really don't like finding a nice place to build, having to demolish my trap-filled ruins, and then having an unbreakable Command Block in the way. So sometimes I've been using /testruin as a way to execute a "self-destructive" trap, so at the very least there IS a way to get rid of it ... by setting it off. :D (Yeah, TNT is the perfect self-destructive trap, but my friends have gotten a bit tired of that, so I tried to mix it up with silly stuff like potion effects. The trouble is that I can't make a Command Block just deliver its potion effect or summon a monster ONCE upon trigger, and then self-delete.) RUINSTRIGGER at least allowed me to have a way of spawning in persistent custom mobs in a structure (e.g., a villager with special trades, a "boss" monster with special gear). It's also the only way I've been able to conjure up objects such as paintings, and for a while it was my only way to have flower pots with flowers in them (until the "teBlock" coding came along).

    I've been thinking of using it to replace the way my "Cursed Village" and "Shop Village" complexes are generated, so as to minimize the use of Command Blocks firing off to build the layout, but then I lose any randomization factor.

    Adjoining Templates would be *especially* useful, replacing a lot of my /testruin Command Block tricks, if somehow they could allow for one or more of:

    1) Optional forced facing of the template (i.e., EITHER you can leave it to choose facing randomly, OR you can specify 0, 90, 180, or 270 degree rotation as you can with /testruin). Right now, if I want to use Adjoining Template and have stuff face a particular way, I have to do that within the template itself by building it to face the way I want, and preventing rotation.

    2) Optional Y positioning relative to the original target block (so the central template could be, for instance, a set of stairs going from ground level down into a dungeon, and the adjoining templates could be hallways branching off X blocks down, positioned so they'll match up with the bottom of the stairs). Right now, the only way I can do a "dungeon complex" (aside from adopting Gillymoth's clever Escher dungeon arrangement) is to set "embed_into_distance" to such a high number that I am certain that each module is going to be lined up by virtue of running into the minimum world build point.

    3) Some sort of randomization. Like, for Adjoining Template #3, either summon THIS template, THAT template, or THIS OTHER template in this spot. So, for instance, I could either have a village where the buildings will be in positions 1, 2, 3, 4, 5, and 6, but each position will randomly pull from a short list of possible structures (Pig Pen, Large House, Small Cobble House, Church, Farming Plot). Or, for my "dungeon," I'm randomly picking from whether this particular room is going to be the Library, the Lava Room, the Pit Trap, the Crypt, etc.

    But in the meantime, I've been experimenting with trying to see what all I can do with Adjoining Templates as-is, in the hopes of providing some cool places for exploration, but without killing the server response time every time someone goes exploring in a boat, since it SEEMS to be less disruptive than doing the same thing with Command Blocks and RUINSTRIGGER.

    My Limbo Dungeon and Sunken Dungeon are the most overboard of my projects, in an attempt to "quasi-procedurally generate" some dungeons, and at that point a better solution would just be to load up a mod such as Roguelike Dungeons or Twilight Forest, where others have GENUINELY procedurally generated dungeons and have done a better job of it ... but, eh, I like to make stuff, and see what's possible with what I have. :)
    Posted in: Minecraft Mods
  • To post a comment, please .