I posted a pull request to implement a new feature: specifying biomes for a template to spawn in by type instead of (or in addition to) by name. Forge has a BiomeDictionary in which every biome is assigned zero or more somewhat-descriptive "types" from the following list: hot, cold, sparse, dense, wet, dry, savanna, coniferous, jungle, spooky, dead, lush, nether, end, mushroom, magical, rare, ocean, river, water, mesa, forest, plains, mountain, hills, swamp, sandy, snowy, wasteland, beach, and void. These types can also be applied to modded biomes (as Biomes O' Plenty does, for example); Forge even makes an attempt to guess appropriate types for new biomes even if a mod's author doesn't.
I find this a lot more convenient than creating long biomesToSpawnIn lists and focuses more on the "theme" associated with a template. The new template variable is biomeTypesToSpawnIn, and for a forest-y kind of template, for example, can replace all of this...
It also has the advantage of picking up modded biomes without having to explicitly list them. If you run with Biomes O' Plenty, the example above will also catch BOP's alps_foothills, bamboo_forest, bog, boreal_forest, cherry_blossom_grove, coniferous_forest, dead_forest, eucalyptus_forest, fen, grove, land_of_lakes, maple_woods, meadow, mountain, mountain_foothills, mystic_grove, ominous_woods, orchard, origin_island, rainforest, redwood_forest, sacred_springs, seasonal_forest, shield, snowy_coniferous_forest, snowy_forest, temperate_rainforest, wetland, and woodland biomes, since they're all tagged with the "forest" type.
You can specify multiple types; every biome assigned at least one of those types will be a spawn candidate. So, if you consider jungles to be sufficiently forest-y for the purposes of your template, you might use...
biomeTypesToSpawnIn=forest,jungle
...to include all the jungle-type biomes, too, like jungle, jungle_hills, mutated_jungle, and mutated_jungle_edge (plus BOP's oasis, overgrown_cliffs, tropical_island, and tropical_rainforest, if you've got that going on). You can also still specify biomesToSpawnIn if you want to explicitly list some biomes by name for whatever reason--maybe the theme you're going for doesn't fit neatly in the type scheme. Note that biomesToSpawnIn are always spawn candidate biomes, regardless of whether or not they match any biomeTypesToSpawnIn.
Two other new template variables--biomesToNotSpawnIn and biomeTypesToNotSpawnIn--allow you to exclude certain biomes or biome types, respectively, from consideration via biomeTypesToSpawnIn. For example...
...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.
@quarteranimal I was hoping for something like that, as perceived compatibility hinges on being able to populate all the areas on a given map, and it should even remove the need to reload Ruins after adding biome mods to an instance.
What you suggest makes it so much easier to get complete coverage in any given world, and has the effect of having several specific generic folders for a more refined layout than what can be obtained with the generic folder. It can be used like the boardgame "guess-who" where you can specify all jungles that are also wet, as some mods add in jungles that are also deserts, which was surprising when pressing F3 to read jungle while standing on a huge stretch of sand.
Oh, I've refined my implementation of the grid free-rotation, and can rotate the entire range of 0 to +-45 degrees at exactly the correct scale with only a single generation attempt per block (or column), which eliminates all potential duped blocks, but there is still some overlapping blocks that make omitted data occur. All with no overhead or any special calculations, just the transformation calculation itself which is exactly as fast as the simple rough calculation.
...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.
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?
I really think it's best to leave biomesToSpawnIn (and now biomeTypesToSpawnIn, biomesToNotSpawnIn, and biomeTypesToNotSpawnIn) empty for templates in the generic/ folder. When a template spawns as a generic, all of those variables are irrelevant--setting them won't have any impact at all on which biomes are eligible for spawning. The only way to affect biome selection for generics is by setting the specific_xxx configuration parameters, and that doesn't help if you're looking for per-template control.
If you do specify biomesToSpawnIn or biomeTypesToSpawnIn in a generic/ folder template, that template can spawn as both a generic in any biome AND a specific in the designated biome(s). biomesToNotSpawnIn and biomeTypesToNotSpawnIn can then be used to modify its specific spawning, but not its generic spawning. That's just confusing, though. Don't do that.
I had dumped all of the contents of optional into generic, yes.
Maybe if a structure is in generic, but has biomes specified for it, it will only spawn in those biomes anyways? I did not feel like sifting through all of the optional structures.
...you can specify all jungles that are also wet, as some mods add in jungles that are also deserts...
Well, actually you couldn't do that originally--"biomeTypesToSpawnIn=jungle,wet" gives you all jungle biomes and all wet biomes, so you'd still pick up the freakish jungle desert, too (mmm...delicious jungle dessert). But things change, and there's already a new pull request to add some simple boolean shenanigans to biome type specifications, because heavens forbid this thing is too easy to use. Where's the fun in that? If that pull goes through, you can specify "biomeTypesToSpawnIn=jungle+wet" to only catch biomes that are both jungle AND wet. Take that, jungle deserts!
Yay! That's even more extensive than I imagined! (I was just thinking of a simple list of the *types* so I'd at least know which ones I could choose from, but this is even better, by far!)
Now with that list, I can't help but wonder what the intended definitions are for some of those terms. For instance, Volcanic Island is both Water and Dry. Hmm. Twilight Lake and Twilight Stream are both Water, but unlike Twilight Swamp, neither of them is WET. I notice there's a "Coniferous" but not a "Deciduous," so perhaps that just signals the presence of podzol in terrain generation, rather than having anything to do with the trees, per se? Well, I guess the important thing is just that if I have some specific biomes in mind, I can look this up to see if they happen to share any types in common, and I could make the SpawnIn list a WHOLE lot shorter.
Balancing Level of Control vs Coverage, that sounds like the kind of puzzles we like to play with! and having this level of coverage is going to be extremely useful.
Now with that list, I can't help but wonder what the intended definitions are for some of those terms. For instance, Volcanic Island is both Water and Dry. Hmm. Twilight Lake and Twilight Stream are both Water, but unlike Twilight Swamp, neither of them is WET. I notice there's a "Coniferous" but not a "Deciduous," so perhaps that just signals the presence of podzol in terrain generation, rather than having anything to do with the trees, per se? Well, I guess the important thing is just that if I have some specific biomes in mind, I can look this up to see if they happen to share any types in common, and I could make the SpawnIn list a WHOLE lot shorter.
I think "Wet" and "Dry" are probably keyed to the climate humidity zones. In any case, "Wet" seems to suggest wet land, while "Water" suggests either a water or a water-adjacent biome (thus islands & beaches). I concur that "Coniferous" probably is related to podzol, though I'm not sure -- IIRC, BoP's Coniferous Forest doesn't have podzol, just big firs. "Sandy" may be meant similarly. I note with dismay that at least one of BoP's biomes has both "Lush" and "Sparse", so I'm not so sure what those are meant for.
And thanks to Quarteranimal for the info on how to use the biome folders effectively; to recap, anything that's not meant to be "anywhere" goes in a biome folder. I'll note that Blocks[Not]ToSpawnOn (sp?) probably still works for constraining Nether/End spawns, ice/water, and such. I do hope that JP, Gilly, and other writers (Perhaps even AS? ) will start distributing their files with constraints and arranged into suitable biome folders, so that we can drop them in without going through all the templates to figure out what folders they should go on, and edit their placement starting with an "author's intention" setup.
Rollback Post to RevisionRollBack
I did some CraftTweaker scripts for Mystical Agriculture. They fill in a couple of small gaps in MA, and also let you make or duplicate not only vanilla plants, but the blocks, plants and wood from Quark and Biomes O'Plenty. Also spawn eggs for most vanilla mobs! The scripts are here on Github.
... I do hope that JP, Gilly, and other writers (Perhaps even AS? ) will start distributing ... into suitable biome folders...
We've been sorting work among the biome folders for the past 3 years or so (!), even extensively patching for versions where those specific functionalities were broken, and lots of fine-tuned calibrations, and things which may contain chocolate.
As for the newly revealed features that would allow for absolute complete coverage for the first time, regardless of unforeseen biome additions in future mods. We are behind the scenes sifting through and crunching all the delicious mathematical morsels.
We've been sorting work among the biome folders for the past 3 years or so (!), even extensively patching for versions where those specific functionalities were broken, and lots of fine-tuned calibrations, and things which may contain chocolate.
Excellent, and thank you!
Rollback Post to RevisionRollBack
I did some CraftTweaker scripts for Mystical Agriculture. They fill in a couple of small gaps in MA, and also let you make or duplicate not only vanilla plants, but the blocks, plants and wood from Quark and Biomes O'Plenty. Also spawn eggs for most vanilla mobs! The scripts are here on Github.
There have been some changes to the new biomeTypesToSpawnIn template parameter. It now accepts full-blown logical expressions rather than just a glorified list. As a result, the proposed new biomeTypesToNotSpawnIn parameter is no longer necessary and has been eliminated. Here's a brief primer:
First, to make things really clear and simple, let's pretend there are only three biome types--HOT, RARE, and WET--and only eight biomes:
plains -> []
desert -> [HOT]
swampland -> [WET]
jungle -> [HOT, WET]
mutated_plains -> [RARE]
mutated_desert -> [HOT, RARE]
mutated_swampland -> [RARE, WET]
mutated_jungle -> [HOT, RARE, WET]
You can specify you want a template to spawn in a particular type of biome by setting biomeTypesToSpawnIn to that type:
biomeTypesToSpawnIn=HOT
This allows the template to spawn in any biome assigned the HOT type; namely, desert, jungle, mutated_desert, and mutated_jungle. Suppose you want the template to spawn only in biomes that don't have HOT type. Use a minus sign - in front of the type:
biomeTypesToSpawnIn=-HOT
Read the minus as "not," so this expression means "not HOT," thus selecting the plains, swampland, mutated_plains, and mutated_swampland biomes.
As an aside, I'll note these expressions support arbitrary whitespace between biome types and operators, as well as comments--a number sign # and anything after it to the end of the line is ignored. This only applies (for now) to the expression itself; that is, everything after the equals sign =. Text preceding the equals sign and all other lines in the template, however, follow the same whitespace-averse syntax as always. You may choose to use spaces and comments in your expressions or not, but I'm going to use them here for clarity. The last expression, for example, could be written as:
The number sign and the explanatory text after it has no effect whatsoever on how the expression is evaluated. Also worth noting: biome types are now all uppercase, and they are case-sensitive. This is a change from my earlier posts.
If you want the template to spawn only in biomes that are both HOT and WET, use a plus sign + between them:
Deserts are HOT, but they're not WET; swampland is WET, but it's not HOT. A biome has to be both to meet this criterion. Read the plus as "AND" (HOT and WET"). You're not limited to just two types:
Mutated_jungle is the only biome (in this primer) with all three types: HOT and WET and RARE.
If you use different operators--plus and minus, say--in the same expression, you should be aware of the notion of precedence. There's a sort of priority ranking among operators defining the order in which they are applied. The NOT operator (a minus sign before a biome type) has higher precedence than the AND operator (a plus sign between two biome types), so the following expression:
means "not HOT, and also WET" rather than "not both HOT and WET" because the NOT is applied before the AND, according to precedence. This expression is identical to:
Sometimes, though, you want a template to spawn in ANY of several biome types, not necessarily ALL of them. Separate biome types with commas to indicate OR:
Read this as "HOT or WET." Deserts are HOT, swampland is WET, and jungles are both. The OR operator has an even lower precedence than AND, so observe the following:
Remember, spaces don't matter in an expression, but I personally like to put them after commas to emphasize their lower precedence. You do you.
Finally, you can create subexpressions within an expression--and within other subexpressions--by enclosing them in ( parentheses ). A subexpression can go anywhere a biome type goes, and the guts of a subexpression are always evaluated before anything outside it. This can be used to manipulate the order of operator evaluation if precedence doesn't get you where you want to be. For example:
The biomesToSpawnIn parameter works the same as before--it's a simple list of biomes IDs, and the template will spawn in those biomes regardless of biomeTypesToSpawnIn and biomesToNotSpawnIn settings. The biomesToNotSpawnIn parameter is still there, and it too is a simple list of biomes IDs, filtering out any specific biomes you want to exclude even if they meet the biomeTypesToSpawnIn criterion.
Another new template parameter was added, requiredMods, allowing you to declare any mods that need to be present for the template to load, but...
There's a twist, though--the value isn't a list, it's a logical expression...like biomeTypesToSpawnIn, but with mod IDs instead of biome types. If a template uses, for example, blocks from the Quark and Biomes O' Plenty mods, and places chests with items added by Blood Magic, you might specify:
requiredMods= quark+biomesoplenty+bloodmagic
to indicate ALL three mods must be present. Or maybe the template doesn't contain mod-specific blocks, but is intended only to be used in the presence of certain mods. A template for bonus iron deposits, for example, to make life easier when playing with iron-hungry tech mods, like Tinkers' Construct, the Thermal series, or Galacticraft, might set:
to indicate ANY one or more of those mods should be present (because of the commas, as opposed to ALL must be, with the pluses). Or maybe a template should only be used if a particular mod is absent, like a template providing an overworld source for quartz that isn't needed if you're playing with Roguelike Dungeons:
requiredMods= -roguelike
See the logical expression primer above for more details about the syntax.
There have been some changes to the new biomeTypesToSpawnIn template parameter.
Whoa. Yeah, it looks like I've got a lot of work cut out for me. I'll see about using this for my template set, and maybe now I can simplify my 1.12 collection a bit. Thanks so much for adding this new functionality!
Hey, I'm using Ruins 17.1 for MC 1.12 (I'm guessing I need to do an update with the new changes to biome logic and such?), and I've noticed that when I use /parseruin, it's no longer capturing the teBlock information (and creating teBlock rules) for wall_banner and flower_pot blocks. I tried editing the ruins.txt config to add "wall_banner" and "flower_pot" to the blocks that require teBlock data, but that didn't seem to do the trick: When I use /parseruin on a structure containing either, I just get a rule that has "flower_pot-0" (regardless of the flower in it), or "wall_banner-x" (where "x" is dependent upon facing), so bringing the structure back via /testruin results in a building with empty flower pots and black banners.
Fortunately, there's a workaround of sorts. I was able to use A1c3e5's trick for getting teBlock data by positioning myself over the block and then typing "/blockdata ~ ~-1 ~ {}" in order to get an error message that would feed me the data I needed.
(The primary changes would be the insertion of "teBlock" before the block ID, then a semicolon and the returned block data in braces {}, followed up by the dash and the original data value. In this case, I get a pink banner without any special details. The returned data will have X, Y, and Z values, but I can safely just replace them with zeroes -- though it seems I DO still have to have SOME value for each field, in order.)
Alas, my original structure was going to have magenta AND pink wall banners, and a couple of different types of flowers in flower pots (specifically placed), but the /parseruin routine treats all the flower pots the same, and any wall banners facing the same direction (regardless of what color/symbol might be on them in the original structure). So, if I want more than that for now, I'll have to manually add in some more rules and edit the layer grids -- or make use of placeholders.
Hey, I'm using Ruins 17.1 for MC 1.12 ... and I've noticed that when I use /parseruin, it's no longer capturing the teBlock information (and creating teBlock rules) for wall_banner and flower_pot blocks. I tried editing the ruins.txt config to add "wall_banner" and "flower_pot" to the blocks that require teBlock data, but that didn't seem to do the trick
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.
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.)
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.
Nice catch! Seems like this was an issue with /parseruin since forever, but no more. I am so submitting a pull to fix this in 17.2.
Calling all ruins experts, does anyone have any alien nest/spires type structures I could use in a modpack I'm developing?
What mods are you using? I can't help but think that for an "alien nest" or "alien spire," it'd probably have to be made out of some sort of mod-specific block (e.g., some sort of "alien egg" block that hatches a mob when you get too close, some sort of creepy organic-material block for alien growths). I suppose Biomes o' Plenty and Chisel might have a few Nether blocks that could work for an "alien organic" look, but it wouldn't be "functional" in any way.
I posted a pull request to implement a new feature: specifying biomes for a template to spawn in by type instead of (or in addition to) by name. Forge has a BiomeDictionary in which every biome is assigned zero or more somewhat-descriptive "types" from the following list: hot, cold, sparse, dense, wet, dry, savanna, coniferous, jungle, spooky, dead, lush, nether, end, mushroom, magical, rare, ocean, river, water, mesa, forest, plains, mountain, hills, swamp, sandy, snowy, wasteland, beach, and void. These types can also be applied to modded biomes (as Biomes O' Plenty does, for example); Forge even makes an attempt to guess appropriate types for new biomes even if a mod's author doesn't.
I find this a lot more convenient than creating long biomesToSpawnIn lists and focuses more on the "theme" associated with a template. The new template variable is biomeTypesToSpawnIn, and for a forest-y kind of template, for example, can replace all of this...
biomesToSpawnIn=forest,taiga,forest_hills,taiga_hills,jungle_edge,birch_forest,birch_forest_hills,roofed_forest,taiga_cold,taiga_cold_hills,redwood_taiga,redwood_taiga_hills,extreme_hills_with_trees,mutated_forest,mutated_taiga,mutated_birch_forest,mutated_birch_forest_hills,mutated_roofed_forest,mutated_taiga_cold,mutated_redwood_taiga,mutated_redwood_taiga_hills
...with this...
biomeTypesToSpawnIn=forest
It also has the advantage of picking up modded biomes without having to explicitly list them. If you run with Biomes O' Plenty, the example above will also catch BOP's alps_foothills, bamboo_forest, bog, boreal_forest, cherry_blossom_grove, coniferous_forest, dead_forest, eucalyptus_forest, fen, grove, land_of_lakes, maple_woods, meadow, mountain, mountain_foothills, mystic_grove, ominous_woods, orchard, origin_island, rainforest, redwood_forest, sacred_springs, seasonal_forest, shield, snowy_coniferous_forest, snowy_forest, temperate_rainforest, wetland, and woodland biomes, since they're all tagged with the "forest" type.
You can specify multiple types; every biome assigned at least one of those types will be a spawn candidate. So, if you consider jungles to be sufficiently forest-y for the purposes of your template, you might use...
biomeTypesToSpawnIn=forest,jungle
...to include all the jungle-type biomes, too, like jungle, jungle_hills, mutated_jungle, and mutated_jungle_edge (plus BOP's oasis, overgrown_cliffs, tropical_island, and tropical_rainforest, if you've got that going on). You can also still specify biomesToSpawnIn if you want to explicitly list some biomes by name for whatever reason--maybe the theme you're going for doesn't fit neatly in the type scheme. Note that biomesToSpawnIn are always spawn candidate biomes, regardless of whether or not they match any biomeTypesToSpawnIn.
Two other new template variables--biomesToNotSpawnIn and biomeTypesToNotSpawnIn--allow you to exclude certain biomes or biome types, respectively, from consideration via biomeTypesToSpawnIn. For example...
biomesToSpawnIn=mutated_forest,mutated_birch_forest
biomeTypesToSpawnIn=forest,jungle
biomesToNotSpawnIn=redwood_taiga,redwood_taiga_hills,mutated_redwood_taiga,mutated_redwood_taiga_hills,redwood_forest
biomeTypesToNotSpawnIn=hills,mountain
...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.
@quarteranimal I was hoping for something like that, as perceived compatibility hinges on being able to populate all the areas on a given map, and it should even remove the need to reload Ruins after adding biome mods to an instance.
What you suggest makes it so much easier to get complete coverage in any given world, and has the effect of having several specific generic folders for a more refined layout than what can be obtained with the generic folder. It can be used like the boardgame "guess-who" where you can specify all jungles that are also wet, as some mods add in jungles that are also deserts, which was surprising when pressing F3 to read jungle while standing on a huge stretch of sand.
Oh, I've refined my implementation of the grid free-rotation, and can rotate the entire range of 0 to +-45 degrees at exactly the correct scale with only a single generation attempt per block (or column), which eliminates all potential duped blocks, but there is still some overlapping blocks that make omitted data occur. All with no overhead or any special calculations, just the transformation calculation itself which is exactly as fast as the simple rough calculation.
Gillymoth Structures for Ruins <<< Folder containing my Structure-sets for Ruins mod.
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.
--- Jordan's & Kujaku10's UNOFFICIAL Custom Templates:
Greywolf's Minecraft Ruins (MC versions 1.7.10-1.12.2; requires AtomicStryker's "Ruins" mod)
Latest Updates: v1.7 (May 2018) * v1.8 (Jun 2016) * v1.9 (Sep 2016) * v1.10 (Jan 2017) * v1.11 (Apr 2018) * v1.12.* (Dec 2018)
I really think it's best to leave biomesToSpawnIn (and now biomeTypesToSpawnIn, biomesToNotSpawnIn, and biomeTypesToNotSpawnIn) empty for templates in the generic/ folder. When a template spawns as a generic, all of those variables are irrelevant--setting them won't have any impact at all on which biomes are eligible for spawning. The only way to affect biome selection for generics is by setting the specific_xxx configuration parameters, and that doesn't help if you're looking for per-template control.
If you do specify biomesToSpawnIn or biomeTypesToSpawnIn in a generic/ folder template, that template can spawn as both a generic in any biome AND a specific in the designated biome(s). biomesToNotSpawnIn and biomeTypesToNotSpawnIn can then be used to modify its specific spawning, but not its generic spawning. That's just confusing, though. Don't do that.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI had dumped all of the contents of optional into generic, yes.
Maybe if a structure is in generic, but has biomes specified for it, it will only spawn in those biomes anyways? I did not feel like sifting through all of the optional structures.
Well, actually you couldn't do that originally--"biomeTypesToSpawnIn=jungle,wet" gives you all jungle biomes and all wet biomes, so you'd still pick up the freakish jungle desert, too (mmm...delicious jungle dessert). But things change, and there's already a new pull request to add some simple boolean shenanigans to biome type specifications, because heavens forbid this thing is too easy to use. Where's the fun in that? If that pull goes through, you can specify "biomeTypesToSpawnIn=jungle+wet" to only catch biomes that are both jungle AND wet. Take that, jungle deserts!
You mean something like this?
From vanilla Minecraft:
beaches -> [BEACH]
birch_forest -> [FOREST]
birch_forest_hills -> [FOREST, HILLS]
cold_beach -> [BEACH, COLD, SNOWY]
deep_ocean -> [OCEAN, WATER]
desert -> [DRY, HOT, SANDY]
desert_hills -> [DRY, HILLS, HOT, SANDY]
extreme_hills -> [HILLS, MOUNTAIN]
extreme_hills_with_trees -> [FOREST, MOUNTAIN, SPARSE]
forest -> [FOREST]
forest_hills -> [FOREST, HILLS]
frozen_ocean -> [COLD, OCEAN, SNOWY, WATER]
frozen_river -> [COLD, RIVER, SNOWY, WATER]
hell -> [DRY, HOT, NETHER]
ice_flats -> [COLD, SNOWY, WASTELAND]
ice_mountains -> [COLD, MOUNTAIN, SNOWY]
jungle -> [DENSE, HOT, JUNGLE, WET]
jungle_edge -> [FOREST, HOT, JUNGLE, RARE, WET]
jungle_hills -> [DENSE, HILLS, HOT, JUNGLE, WET]
mesa -> [MESA, SANDY]
mesa_clear_rock -> [MESA, SANDY]
mesa_rock -> [MESA, SANDY, SPARSE]
mushroom_island -> [MUSHROOM, RARE]
mushroom_island_shore -> [BEACH, MUSHROOM, RARE]
mutated_birch_forest -> [DENSE, FOREST, HILLS, RARE]
mutated_birch_forest_hills -> [DENSE, FOREST, MOUNTAIN, RARE]
mutated_desert -> [DRY, HOT, RARE, SANDY]
mutated_extreme_hills -> [MOUNTAIN, RARE, SPARSE]
mutated_extreme_hills_with_trees -> [MOUNTAIN, RARE, SPARSE]
mutated_forest -> [FOREST, HILLS, RARE]
mutated_ice_flats -> [COLD, HILLS, RARE, SNOWY]
mutated_jungle -> [DENSE, HOT, JUNGLE, MOUNTAIN, RARE, WET]
mutated_jungle_edge -> [HILLS, HOT, JUNGLE, RARE, SPARSE]
mutated_mesa -> [DRY, HOT, MOUNTAIN, RARE, SAVANNA, SPARSE]
mutated_mesa_clear_rock -> [DRY, HOT, MOUNTAIN, RARE, SAVANNA, SPARSE]
mutated_mesa_rock -> [DRY, HILLS, HOT, RARE, SPARSE]
mutated_plains -> [PLAINS, RARE]
mutated_redwood_taiga -> [DENSE, FOREST, RARE]
mutated_redwood_taiga_hills -> [DENSE, FOREST, HILLS, RARE]
mutated_roofed_forest -> [DENSE, FOREST, MOUNTAIN, RARE, SPOOKY]
mutated_savanna -> [DRY, HOT, MOUNTAIN, RARE, SAVANNA, SPARSE]
mutated_savanna_rock -> [DRY, HILLS, HOT, RARE, SAVANNA, SPARSE]
mutated_swampland -> [HILLS, RARE, SWAMP, WET]
mutated_taiga -> [COLD, CONIFEROUS, FOREST, MOUNTAIN, RARE]
mutated_taiga_cold -> [COLD, CONIFEROUS, FOREST, MOUNTAIN, RARE, SNOWY]
ocean -> [OCEAN, WATER]
plains -> [PLAINS]
redwood_taiga -> [COLD, CONIFEROUS, FOREST]
redwood_taiga_hills -> [COLD, CONIFEROUS, FOREST, HILLS]
river -> [RIVER, WATER]
roofed_forest -> [DENSE, FOREST, SPOOKY]
savanna -> [HOT, PLAINS, SAVANNA, SPARSE]
savanna_rock -> [HOT, PLAINS, RARE, SAVANNA, SPARSE]
sky -> [COLD, DRY, END]
smaller_extreme_hills -> [MOUNTAIN]
stone_beach -> [BEACH]
swampland -> [SWAMP, WET]
taiga -> [COLD, CONIFEROUS, FOREST]
taiga_cold -> [COLD, CONIFEROUS, FOREST, SNOWY]
taiga_cold_hills -> [COLD, CONIFEROUS, FOREST, HILLS, SNOWY]
taiga_hills -> [COLD, CONIFEROUS, FOREST, HILLS]
void -> [VOID]
From Biomes O' Plenty:
alps -> [COLD, DRY, MOUNTAIN, SNOWY]
alps_foothills -> [COLD, DRY, FOREST, MOUNTAIN, SNOWY, SPARSE]
bamboo_forest -> [DENSE, FOREST, JUNGLE, WET]
bayou -> [DENSE, HOT, SWAMP, WET]
bog -> [COLD, FOREST, SWAMP, WET]
boreal_forest -> [COLD, CONIFEROUS, DENSE, FOREST, HILLS]
brushland -> [DRY, HOT, SAVANNA, SPARSE]
chaparral -> [DRY, PLAINS]
cherry_blossom_grove -> [DENSE, FOREST, LUSH, MAGICAL, WET]
cold_desert -> [COLD, DRY, SNOWY]
coniferous_forest -> [COLD, CONIFEROUS, DENSE, FOREST]
coral_reef -> [OCEAN, WATER]
corrupted_sands -> [DENSE, DRY, HOT, NETHER, SANDY]
crag -> [COLD, DRY, HILLS, MAGICAL, MOUNTAIN, WASTELAND]
dead_forest -> [COLD, DEAD, DRY, FOREST, SPARSE]
dead_swamp -> [COLD, DEAD, SPARSE, SPOOKY, SWAMP, WET]
eucalyptus_forest -> [DENSE, FOREST, JUNGLE, LUSH, WET]
fen -> [COLD, DEAD, DENSE, FOREST, SWAMP, WET]
flower_field -> [LUSH, PLAINS]
flower_island -> [DENSE, LUSH, MAGICAL, PLAINS, WATER]
fungi_forest -> [DENSE, HOT, MUSHROOM, NETHER]
glacier -> [COLD, SNOWY, WASTELAND]
grassland -> [HILLS, PLAINS, WET]
gravel_beach -> [BEACH]
grove -> [FOREST, LUSH, PLAINS, SPARSE, WET]
highland -> [HILLS, MOUNTAIN, WET]
kelp_forest -> [OCEAN, WATER]
land_of_lakes -> [DENSE, FOREST, SWAMP, WET]
lavender_fields -> [LUSH, MAGICAL, PLAINS]
lush_desert -> [DRY, HOT, LUSH, SANDY, SAVANNA, SPARSE]
lush_swamp -> [DENSE, LUSH, SWAMP, WET]
mangrove -> [DENSE, LUSH, SWAMP, WATER, WET]
maple_woods -> [COLD, CONIFEROUS, DENSE, FOREST]
marsh -> [LUSH, SWAMP, WET]
meadow -> [COLD, FOREST, LUSH, PLAINS, SPARSE, WET]
moor -> [HILLS, SWAMP, WET]
mountain -> [DRY, FOREST, MOUNTAIN, SPARSE]
mountain_foothills -> [DRY, FOREST, HILLS, MOUNTAIN, SPARSE]
mystic_grove -> [DENSE, FOREST, LUSH, MAGICAL, RARE, WET]
oasis -> [HOT, JUNGLE, LUSH, SANDY, SPARSE, WET]
ominous_woods -> [DEAD, DENSE, FOREST, MAGICAL, RARE, SPOOKY, WET]
orchard -> [DENSE, FOREST, LUSH, PLAINS]
origin_beach -> [BEACH, RARE]
origin_island -> [FOREST, RARE, WATER]
outback -> [DRY, HOT, SANDY, SAVANNA, SPARSE]
overgrown_cliffs -> [DENSE, HILLS, JUNGLE, LUSH, MOUNTAIN, WET]
pasture -> [DRY, PLAINS, SPARSE]
phantasmagoric_inferno -> [DRY, HOT, MAGICAL, NETHER, SPOOKY, WASTELAND]
prairie -> [DRY, PLAINS, SPARSE]
quagmire -> [DEAD, SWAMP, WASTELAND, WET]
rainforest -> [DENSE, FOREST, HILLS, JUNGLE, LUSH, WET]
redwood_forest -> [DENSE, FOREST]
sacred_springs -> [DENSE, FOREST, JUNGLE, LUSH, MAGICAL, RARE, WET]
seasonal_forest -> [COLD, DENSE, FOREST]
shield -> [COLD, DENSE, FOREST, WET]
shrubland -> [DRY, PLAINS, SPARSE]
snowy_coniferous_forest -> [COLD, CONIFEROUS, DENSE, FOREST, SNOWY]
snowy_forest -> [COLD, FOREST, SNOWY, SPARSE, WET]
steppe -> [DRY, PLAINS, SANDY]
temperate_rainforest -> [DENSE, FOREST, LUSH, WET]
tropical_island -> [DENSE, JUNGLE, LUSH, WATER, WET]
tropical_rainforest -> [DENSE, HOT, JUNGLE, LUSH, WET]
tundra -> [COLD, DEAD, DRY, SPARSE, WASTELAND]
undergarden -> [HOT, LUSH, NETHER]
visceral_heap -> [HOT, NETHER, WET]
volcanic_island -> [DEAD, DRY, HOT, MOUNTAIN, WASTELAND, WATER]
wasteland -> [DEAD, DRY, SPARSE, WASTELAND]
wetland -> [DENSE, FOREST, LUSH, SWAMP, WET]
white_beach -> [BEACH]
woodland -> [DENSE, DRY, FOREST]
xeric_shrubland -> [DRY, HOT, LUSH, SANDY, SAVANNA, SPARSE]
From Defiled Lands:
desert_defiled -> [DRY, HOT, SANDY, SPOOKY]
forest_tenebra -> [FOREST, SPOOKY]
forest_vilespine -> [FOREST, SPOOKY]
hills_defiled -> [HILLS, MOUNTAIN, SPOOKY]
ice_plains_defiled -> [COLD, SNOWY, SPOOKY, WASTELAND]
plains_defiled -> [PLAINS, SPOOKY]
swamp_defiled -> [SPOOKY, SWAMP, WET]
From Galacticraft:
outer space -> [DEAD, DRY, SPARSE, SPOOKY]
outer space 1 -> [DEAD, DRY, HOT, SANDY]
outer space 2 -> [DEAD, DRY, HOT, SANDY]
From The Twilight Forest:
dark_forest -> [DENSE, FOREST, SPOOKY]
dark_forest_center -> [DENSE, FOREST, MAGICAL, SPOOKY]
deep_mushroom_forest -> [FOREST, MUSHROOM]
dense_twilight_forest -> [DENSE, FOREST]
enchanted_forest -> [FOREST, MAGICAL]
fire_swamp -> [HOT, SWAMP, WASTELAND]
firefly_forest -> [FOREST, LUSH]
highlands_center -> [DEAD, DRY, MESA, WASTELAND]
mushroom_forest -> [FOREST, MUSHROOM]
oak_savannah -> [FOREST, SPARSE]
snowy_forest -> [COLD, CONIFEROUS, FOREST, SNOWY]
thornlands -> [DEAD, DRY, HILLS, WASTELAND]
twilight_clearing -> [PLAINS, SPARSE]
twilight_forest -> [FOREST]
twilight_glacier -> [COLD, SNOWY, WASTELAND]
twilight_highlands -> [CONIFEROUS, FOREST, MOUNTAIN]
twilight_lake -> [OCEAN, WATER]
twilight_stream -> [RIVER, WATER]
twilight_swamp -> [SWAMP, WET]
@QuarterAnimal:
(replying to big long list of biomes AND types):
\O/
Yay! That's even more extensive than I imagined! (I was just thinking of a simple list of the *types* so I'd at least know which ones I could choose from, but this is even better, by far!)
Now with that list, I can't help but wonder what the intended definitions are for some of those terms. For instance, Volcanic Island is both Water and Dry. Hmm. Twilight Lake and Twilight Stream are both Water, but unlike Twilight Swamp, neither of them is WET. I notice there's a "Coniferous" but not a "Deciduous," so perhaps that just signals the presence of podzol in terrain generation, rather than having anything to do with the trees, per se? Well, I guess the important thing is just that if I have some specific biomes in mind, I can look this up to see if they happen to share any types in common, and I could make the SpawnIn list a WHOLE lot shorter.
--- Jordan's & Kujaku10's UNOFFICIAL Custom Templates:
Greywolf's Minecraft Ruins (MC versions 1.7.10-1.12.2; requires AtomicStryker's "Ruins" mod)
Latest Updates: v1.7 (May 2018) * v1.8 (Jun 2016) * v1.9 (Sep 2016) * v1.10 (Jan 2017) * v1.11 (Apr 2018) * v1.12.* (Dec 2018)
Ty so much Quarteranimal~
Balancing Level of Control vs Coverage, that sounds like the kind of puzzles we like to play with! and having this level of coverage is going to be extremely useful.
Gillymoth Structures for Ruins <<< Folder containing my Structure-sets for Ruins mod.
I think "Wet" and "Dry" are probably keyed to the climate humidity zones. In any case, "Wet" seems to suggest wet land, while "Water" suggests either a water or a water-adjacent biome (thus islands & beaches). I concur that "Coniferous" probably is related to podzol, though I'm not sure -- IIRC, BoP's Coniferous Forest doesn't have podzol, just big firs. "Sandy" may be meant similarly. I note with dismay that at least one of BoP's biomes has both "Lush" and "Sparse", so I'm not so sure what those are meant for.
And thanks to Quarteranimal for the info on how to use the biome folders effectively; to recap, anything that's not meant to be "anywhere" goes in a biome folder. I'll note that Blocks[Not]ToSpawnOn (sp?) probably still works for constraining Nether/End spawns, ice/water, and such. I do hope that JP, Gilly, and other writers (Perhaps even AS?
) will start distributing their files with constraints and arranged into suitable biome folders, so that we can drop them in without going through all the templates to figure out what folders they should go on, and edit their placement starting with an "author's intention" setup.
We've been sorting work among the biome folders for the past 3 years or so (!), even extensively patching for versions where those specific functionalities were broken, and lots of fine-tuned calibrations, and things which may contain chocolate.
As for the newly revealed features that would allow for absolute complete coverage for the first time, regardless of unforeseen biome additions in future mods. We are behind the scenes sifting through and crunching all the delicious mathematical morsels.
Gillymoth Structures for Ruins <<< Folder containing my Structure-sets for Ruins mod.
Excellent, and thank you!
There have been some changes to the new biomeTypesToSpawnIn template parameter. It now accepts full-blown logical expressions rather than just a glorified list. As a result, the proposed new biomeTypesToNotSpawnIn parameter is no longer necessary and has been eliminated. Here's a brief primer:
First, to make things really clear and simple, let's pretend there are only three biome types--HOT, RARE, and WET--and only eight biomes:
plains -> []
desert -> [HOT]
swampland -> [WET]
jungle -> [HOT, WET]
mutated_plains -> [RARE]
mutated_desert -> [HOT, RARE]
mutated_swampland -> [RARE, WET]
mutated_jungle -> [HOT, RARE, WET]
You can specify you want a template to spawn in a particular type of biome by setting biomeTypesToSpawnIn to that type:
biomeTypesToSpawnIn=HOT
This allows the template to spawn in any biome assigned the HOT type; namely, desert, jungle, mutated_desert, and mutated_jungle. Suppose you want the template to spawn only in biomes that don't have HOT type. Use a minus sign - in front of the type:
biomeTypesToSpawnIn=-HOT
Read the minus as "not," so this expression means "not HOT," thus selecting the plains, swampland, mutated_plains, and mutated_swampland biomes.
As an aside, I'll note these expressions support arbitrary whitespace between biome types and operators, as well as comments--a number sign # and anything after it to the end of the line is ignored. This only applies (for now) to the expression itself; that is, everything after the equals sign =. Text preceding the equals sign and all other lines in the template, however, follow the same whitespace-averse syntax as always. You may choose to use spaces and comments in your expressions or not, but I'm going to use them here for clarity. The last expression, for example, could be written as:
biomeTypesToSpawnIn= -HOT # plains, swampland, mutated_plains, mutated_swampland
The number sign and the explanatory text after it has no effect whatsoever on how the expression is evaluated. Also worth noting: biome types are now all uppercase, and they are case-sensitive. This is a change from my earlier posts.
If you want the template to spawn only in biomes that are both HOT and WET, use a plus sign + between them:
biomeTypesToSpawnIn= HOT+WET # jungle, mutated_jungle
Deserts are HOT, but they're not WET; swampland is WET, but it's not HOT. A biome has to be both to meet this criterion. Read the plus as "AND" (HOT and WET"). You're not limited to just two types:
biomeTypesToSpawnIn= HOT+WET+RARE # mutated_jungle
Mutated_jungle is the only biome (in this primer) with all three types: HOT and WET and RARE.
If you use different operators--plus and minus, say--in the same expression, you should be aware of the notion of precedence. There's a sort of priority ranking among operators defining the order in which they are applied. The NOT operator (a minus sign before a biome type) has higher precedence than the AND operator (a plus sign between two biome types), so the following expression:
biomeTypesToSpawnIn= -HOT+WET # swampland, mutated_swampland
means "not HOT, and also WET" rather than "not both HOT and WET" because the NOT is applied before the AND, according to precedence. This expression is identical to:
biomeTypesToSpawnIn= WET+-HOT # swampland, mutated_swampland
but not the same as:
biomeTypesToSpawnIn= -WET+HOT # desert, mutated_desert
You may use just a minus sign between two types instead of +- as shorthand for "AND NOT" if you like:
biomeTypesToSpawnIn= WET-HOT # swampland, mutated_swampland
biomeTypesToSpawnIn= HOT-WET # desert, mutated_desert
Sometimes, though, you want a template to spawn in ANY of several biome types, not necessarily ALL of them. Separate biome types with commas to indicate OR:
biomeTypesToSpawnIn= HOT, WET # desert, swampland, jungle, mutated_desert, mutated_swampland, mutated_jungle
Read this as "HOT or WET." Deserts are HOT, swampland is WET, and jungles are both. The OR operator has an even lower precedence than AND, so observe the following:
biomeTypesToSpawnIn= HOT+WET, RARE # jungle, mutated_plains, mutated_desert, mutated_swampland, mutated_jungle
biomeTypesToSpawnIn= HOT, WET+RARE # desert, jungle, mutated_desert, mutated_swampland, mutated_jungle
Remember, spaces don't matter in an expression, but I personally like to put them after commas to emphasize their lower precedence. You do you.
Finally, you can create subexpressions within an expression--and within other subexpressions--by enclosing them in ( parentheses ). A subexpression can go anywhere a biome type goes, and the guts of a subexpression are always evaluated before anything outside it. This can be used to manipulate the order of operator evaluation if precedence doesn't get you where you want to be. For example:
biomeTypesToSpawnIn= -(HOT+WET) # plains, desert, swampland, mutated_plains, mutated_desert, mutated_swampland
biomeTypesToSpawnIn= (HOT, WET)+RARE # mutated_desert, mutated_swampland, mutated_jungle
Simple as that!
The biomesToSpawnIn parameter works the same as before--it's a simple list of biomes IDs, and the template will spawn in those biomes regardless of biomeTypesToSpawnIn and biomesToNotSpawnIn settings. The biomesToNotSpawnIn parameter is still there, and it too is a simple list of biomes IDs, filtering out any specific biomes you want to exclude even if they meet the biomeTypesToSpawnIn criterion.
Another new template parameter was added, requiredMods, allowing you to declare any mods that need to be present for the template to load, but...
There's a twist, though--the value isn't a list, it's a logical expression...like biomeTypesToSpawnIn, but with mod IDs instead of biome types. If a template uses, for example, blocks from the Quark and Biomes O' Plenty mods, and places chests with items added by Blood Magic, you might specify:
requiredMods= quark+biomesoplenty+bloodmagic
to indicate ALL three mods must be present. Or maybe the template doesn't contain mod-specific blocks, but is intended only to be used in the presence of certain mods. A template for bonus iron deposits, for example, to make life easier when playing with iron-hungry tech mods, like Tinkers' Construct, the Thermal series, or Galacticraft, might set:
requiredMods= tconstruct, thermalfoundation, galacticraftcore
to indicate ANY one or more of those mods should be present (because of the commas, as opposed to ALL must be, with the pluses). Or maybe a template should only be used if a particular mod is absent, like a template providing an overworld source for quartz that isn't needed if you're playing with Roguelike Dungeons:
requiredMods= -roguelike
See the logical expression primer above for more details about the syntax.
Whoa. Yeah, it looks like I've got a lot of work cut out for me. I'll see about using this for my template set, and maybe now I can simplify my 1.12 collection a bit. Thanks so much for adding this new functionality!
--- Jordan's & Kujaku10's UNOFFICIAL Custom Templates:
Greywolf's Minecraft Ruins (MC versions 1.7.10-1.12.2; requires AtomicStryker's "Ruins" mod)
Latest Updates: v1.7 (May 2018) * v1.8 (Jun 2016) * v1.9 (Sep 2016) * v1.10 (Jan 2017) * v1.11 (Apr 2018) * v1.12.* (Dec 2018)
Hey, I'm using Ruins 17.1 for MC 1.12 (I'm guessing I need to do an update with the new changes to biome logic and such?), and I've noticed that when I use /parseruin, it's no longer capturing the teBlock information (and creating teBlock rules) for wall_banner and flower_pot blocks. I tried editing the ruins.txt config to add "wall_banner" and "flower_pot" to the blocks that require teBlock data, but that didn't seem to do the trick: When I use /parseruin on a structure containing either, I just get a rule that has "flower_pot-0" (regardless of the flower in it), or "wall_banner-x" (where "x" is dependent upon facing), so bringing the structure back via /testruin results in a building with empty flower pots and black banners.
Fortunately, there's a workaround of sorts. I was able to use A1c3e5's trick for getting teBlock data by positioning myself over the block and then typing "/blockdata ~ ~-1 ~ {}" in order to get an error message that would feed me the data I needed.
So, /parseruin might give me the following rule:
rule15=0,100,minecraft:wall_banner-3
... but I could change it to:
rule15=0,100,teBlock;minecraft:wall_banner;{x:0,y:0,z:0,id:"minecraft:banner",Base:9}-3
(The primary changes would be the insertion of "teBlock" before the block ID, then a semicolon and the returned block data in braces {}, followed up by the dash and the original data value. In this case, I get a pink banner without any special details. The returned data will have X, Y, and Z values, but I can safely just replace them with zeroes -- though it seems I DO still have to have SOME value for each field, in order.)
Alas, my original structure was going to have magenta AND pink wall banners, and a couple of different types of flowers in flower pots (specifically placed), but the /parseruin routine treats all the flower pots the same, and any wall banners facing the same direction (regardless of what color/symbol might be on them in the original structure). So, if I want more than that for now, I'll have to manually add in some more rules and edit the layer grids -- or make use of placeholders.
--- Jordan's & Kujaku10's UNOFFICIAL Custom Templates:
Greywolf's Minecraft Ruins (MC versions 1.7.10-1.12.2; requires AtomicStryker's "Ruins" mod)
Latest Updates: v1.7 (May 2018) * v1.8 (Jun 2016) * v1.9 (Sep 2016) * v1.10 (Jan 2017) * v1.11 (Apr 2018) * v1.12.* (Dec 2018)
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.
Many of these kinds of blocks will no longer be tile entities in 1.13, this includes note-blocks, flowerpots, and the default types of mob skulls.
Gillymoth Structures for Ruins <<< Folder containing my Structure-sets for Ruins mod.
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.)
--- Jordan's & Kujaku10's UNOFFICIAL Custom Templates:
Greywolf's Minecraft Ruins (MC versions 1.7.10-1.12.2; requires AtomicStryker's "Ruins" mod)
Latest Updates: v1.7 (May 2018) * v1.8 (Jun 2016) * v1.9 (Sep 2016) * v1.10 (Jan 2017) * v1.11 (Apr 2018) * v1.12.* (Dec 2018)
Nice catch! Seems like this was an issue with /parseruin since forever, but no more. I am so submitting a pull to fix this in 17.2.
Calling all ruins experts, does anyone have any alien nest/spires type structures I could use in a modpack I'm developing?
What mods are you using? I can't help but think that for an "alien nest" or "alien spire," it'd probably have to be made out of some sort of mod-specific block (e.g., some sort of "alien egg" block that hatches a mob when you get too close, some sort of creepy organic-material block for alien growths). I suppose Biomes o' Plenty and Chisel might have a few Nether blocks that could work for an "alien organic" look, but it wouldn't be "functional" in any way.
--- Jordan's & Kujaku10's UNOFFICIAL Custom Templates:
Greywolf's Minecraft Ruins (MC versions 1.7.10-1.12.2; requires AtomicStryker's "Ruins" mod)
Latest Updates: v1.7 (May 2018) * v1.8 (Jun 2016) * v1.9 (Sep 2016) * v1.10 (Jan 2017) * v1.11 (Apr 2018) * v1.12.* (Dec 2018)