Yesterday I looked into what was causing the problem that Bullorg74 was having with certain templates not spawning in the End dimension, so I made a quick ender template from my aztec totem, and tested using the generic folder with acceptable_target_blocks=end_stone, and it spawned as expected.
Then I noticed a few of my new templates weren't showing up in the biome matching the folder they were in, ones I was spawning regularly with /testruin, and I realized that it wasn't caused by biome designations at all, but by something in certain otherwise normal templates.
Anyway, I set up a proxy template and it worked to get Ruins to auto-spawn them.
Also, after spending the last 6 weeks making new structures and "fixing up" pretty much my entire set of houses (as seen in screenshots at the top of this page), and the cities that spawn them, I'm pretty much ready to make another release.
Then I noticed a few of my new templates weren't showing up in the biome matching the folder they were in, ones I was spawning regularly with /testruin, and I realized that it wasn't caused by biome designations at all, but by something in certain otherwise normal templates.
Anyway, I set up a proxy template and it worked to get Ruins to auto-spawn them.
A template should always be a candidate for spawning in the biome corresponding to its folder, unless it's effectively being rejected due to that biome either not supplying acceptable target blocks (e.g., a jungle template that only spawns on podzol) or having intolerably bumpy terrain (i.e., max_leveling and/or allowable_overhang is too restrictive). If you're seeing contrary behavior, that's an error; I'd like to look into it. Do you have an example?
The templates that do this are all my swamp settlement, village, and outpost cores, the files are in my sig on the new release.
In testing I removed all structures from the swamps, except for these specific structures, other structures in swampland were generating fine, but were removed to increase the chance to 100% that a broken file would be used.
For each attempted fix I restarted minecraft and started a new world. I also loaded everything up in a modpack launcher to check the console to see if it would show the errors.
My guess would be an arrant mark somewhere in the file itself, likely something read by the normal spawning routines, maybe from constantly reusing three year old generated template code without generating a fresh file. I ended up taking the easy route by finding a work-around. Hopefully in all my changes to the files I didn't actually manage to fix them properly, so that light can be shed on it.
The other templates in swampland were working fine, and they had the same blocklist as the broken ones. Also I was using Ruins 16.7, so it might not show up in the newest version. I can set up testing again to see if the files are still broken.
This time running only those templates, and two of them spawned close to spawn, so it might be fixed for the ones listed. In troubleshooting I noticed there was at least one header field missing (I think it was missing the allowable overhang field entirely, and that might have been it), and an ancient one that wasn't showing up in new parses (cut-in buffer).
In any case, certain "generator templates" are ones that aren't designed through parsing, and it's likely that some of these files would contain an obsolete configuration, of course, the breaking part would be when it's missing an important directive.
The first thing I checked was if there were spaces at the ends of lines (or other things the cat may have added while visiting the keyboard), but the file ran file with /testruin, so the obsolete configuration is the most likely cause.
As quarteranimal suggested, the field "allowable_overhang" was missing entirely from the template and was the most likely cause. (the next post below correctly describes all the details)
Since I accidentally ended up fixing the error without confirming the exact cause, I'll illustrate the most likely fix:
If a template generates fine with /testruin, but Ruins auto-generation doesn't recognize it, it might be that the file itself is outdated. If this is the case, then comparing the broken template to a newly parsed template and replacing mismatching header directives may be a solution.
Another way to break a file is to add spaces at the end of a line, which are invisible to the viewer, and can be seen by selecting the entire file and looking for highlighted spaces at the end of lines.
I should point out the cause (i'm guessing) is with files from ancient versions of Ruins, so the easiest way to avoid this problem is to use the /parseruin command, as it generates fresh new files. The one place ancient files may still be used is in "technical" files designed to spawn things like cities, and such errors may accumulate over time. It should also be mentioned that if someone were to reverse engineer existing files, they would end up replicating errors such as these.
@Gillymoth: Thanks for the details--I think there's a real problem here that doesn't have anything to do with your templates. I do see spawning of your swamp structures with the latest version of Ruins, but not nearly as much as I should. Preliminary poking around suggests Ruins thinks structures are being built when they're actually not, and it's somehow oddly related to embed_into_distance. That's as much as I can look at it for now, but I'll embed_into it further this weekend.
EDIT: Bug found and squashed; it was indeed an embed_into_distance issue.
I can confirm that the generation density was much higher with just the individual huts before building the cities, and the bug report does explain why templates created a couple years before I started are filled in with max values in allowable_overhang. I can also confirm having seen templates setting down a couple blocks further than they should have, specifically the center landmark in the city settlements, and remembers messing with the numbers until the unseen adjustments cancelled themselves out.
Thanks for the warning about the "space at end of line" issue. I didn't realize that could be a problem. Does that apply to commented-out lines?
@QuarterAnimal:
I found the discussion about the fix interesting, but I was curious about the "(incorrectly, it could be argued)" bit in relation to the allowable_overhang setting when handling "flying" structures. I figured that when I'm doing a flying structure (an airship, sky island, or whatnot), I care little-to-nothing about the constitution of the ground underneath it, to the point where I should have the most generous possible definition of allowable blocks, max leveling, and allowable overhang. After all, the target block could be on the edge of a cliff for all I care. Does the "incorrectness" only apply in the sense that you deem it an unnecessary step, or that the value may be unnecessarily high?
Having a space at the end of the line was only one template about 3 years ago, caused by me being too loose with the format, but I mention it mainly as a good thing to check for with a broken template, as it's invisible and can be overlooked if that happens to be the cause of a break.
The extra space was in the layer code after the last number in a line, I most likely just didn't clean up after myself after making manual adjustments, I'm pretty sure that commented text can have things like extra spaces, up to the place where the file reads the new line directive, which when read in notepad will simply show up as the next line.
Having said that I realize I was checking code to see whether a rule that hangs over to the next line would be truncated because of it, and my preliminary results were inconclusive as I had a rule with twenty or so options, so it ended up being more of a Turing machine than anything else.
I read the term " "incorrect" " (in context in the bug report) as meaning the in-template solutions turned out to be "patches", as the actual correct way to fix it was the change in the code itself. Though by all means safety measures that make things work better in-game are still favorable, exactly because it makes things work better. Of course a new version with the fix will no longer need such safety measures.
Right now I'm flying through a new world looking for anything that I might have missed, and found a couple places to make adjustments, which ended up being unrelated to the above. Mostly that our expanded awareness of some of these details may indeed warrant another pass over our sets so that we can see how they generate with new eyes, and recognize other ways thing can be optimized.
Right now I'm flying through a new world looking for anything that I might have missed, and found a couple places to make adjustments, which ended up being unrelated to the above. Mostly that our expanded awareness of some of these details may indeed warrant another pass over our sets so that we can see how they generate with new eyes, and recognize other ways thing can be optimized.
Well, I think I can thank you and your revelation of the function of "leveling_buffer=-1" as being one of the primary drivers for me going through and optimizing most all of my templates, as it rendered some of my "Command Block seed" exercises needlessly complex (particularly for spawning giant trees), and allowed me a far greater chance of spawning some of my larger-footprint structures in hilly areas -- as long as I went the extra step of giving them proper "basements."
I've been trying to sort out whether or not I could recreate some of my "village" experiments with the adj template rules -- thus allowing more of my experiments to fit into the "no command blocks" category -- though I've found that for SOME (particularly Kujaku10's walled city, where specific facing is a big factor) it would not. Also, with the advent of the /fill command, I've been thinking of seeing if I could use that to create Vanilla-Village-style "roads" (or "paths") along the axis of such a village ... though of course that would totally counteract the benefit of creating a village without Command Blocks. (That is, a /fill replace command that replaces instances of "grass" with either gravel or dirt-path, along a narrow North-South path with a considerable +/- Y variance, and then do the same for East-West. I've thought of repeating the process for the same paths to replace instances of "water" with "wood plank" and "lava" with "cobblestone" to account for pools of water that might be within the bounds of the village.)
The videos previewing new possible world-creation options for 1.13 has me both excited and worried. First, I figure it'll break every single template (even assuming it's possible to upgrade Ruins to even WORK with 1.13 with such major changes to how blocks are handled, and the elimination of data values). But secondly, while I'd love to play with "sky island worlds" or "cave worlds" as seen with the new videos showing new world-gen possibilities, those would likely play havoc with things. (For sky-island worlds, having a building with a deep basement could look pretty weird, if the basement is sticking down through a thin island and hanging out into space. For cave-worlds, I guess I'd have to deploy the same sorts of tricks I've been using for structures in the Nether, if I want anything to spawn on the ground "normally" again.)
@Jordan_Peacock: Conceptually, the allowable_overhang parameter is a bit counter-intuitive. It sounds like an attribute of the structure to be spawned--I'll allow this many blocks of the building to dangle over a cliff edge, for example--but it's actually an attribute of the surface on which the structure is going to spawn. It specifies how many "holes" that surface can have and still be considered a valid spawn site (the definition of "hole" isn't straightforward, either, but that can be the topic of another discussion). Now, in some (many?) situations, the distinction isn't especially one worth making, and if you don't care what's underneath your b'loonz, sure: go ahead and set full overhang and max max_leveling.
But what if it does matter? Maybe my steampunk agronaut roboblimp wants to hover over relatively flat terrain and periodically dust the ground below with bonemeal. I can accomplish that by setting tighter max_leveling constraints, and little or no overhang. Note that, in a sense, the blimp itself is completely "hanging over" the land, but that's not what allowable_overhang refers to. It just means the terrain below can't have holes in it.
Before this latest fix, that wouldn't be possible. The allowable_overhang value would need to cover the entire footprint of a template for a flying structure to spawn at all, so only limited constraints could be applied to the underlying terrain. I hedged by saying "it could be argued" because, while it may be entirely appropriate to overhang as all get-out depending on the application, it's incorrect to think a template necessarily has to be set up that way to work. Well, at least it is now.
Challenge Accepted, oh wait, *dusts off unreleased project folder*
Just a quick PSA: Beetroots only grow to meta-value 3 and higher numbers are invalid, so when making farms, make sure there are no higher numbers for that block or builds end up truncated at that point.
I'm just about ready to release another structure update, and while flying around in the world checking the natural spawns, it seems that in the newest version of Ruins (17.0) the disabled "preserve_plants" feature seems to be turned on for rule-0. This means that the inside of structures that don't explicitly specify air end up getting filled with trees when spawning in forests and jungles. There was another mention of tree-filled houses above, but the cause wasn't outlined.
Isn't that desirable in a sense though? It adds to the structures being "ruins" after all, some of them would have let nature take over...
Rollback Post to RevisionRollBack
How to deal with ignorance (in life, and on forums): The Zen way... Stay cool and polite, treat people as you wish to be treated, rise above your impatience. Everyone is ignorant of something at any point in their lives, including you.
It is tempting to just leave them how they are, since things in plains would be less affected, or to make "gutted" versions of things in forests and places with lots of trees. In jungles it doesn't seem like a bad thing at all, as temples are commonly intermingled with strangler-figs in pretty much every reference photo.
I like plants growing in most structures, as long as there keeps being way to force exclude them from areas that plants definitely shouldn't grow, like intact houses. Preserving plants being the default makes the most sense to me, since most Ruins are, well, ruins. Now that I know about putting =0,100,preserveBlock or =0,100,air in front of my rules list when necessary I've been making lots of use of it, and I like it more than the old preserve_plants system.
I remember when I first started making structures, and thought I needed to have preserve_plants on in order to prevent the structures from spawning on top of trees leaves, the way preserve_water makes things spawn on the seafloor. So, even though I generally don't like change and having to learn a new system was kind of confusing, I don't think it's harder to learn than the old one for anyone just starting out.
... it seems that in the newest version of Ruins (17.0) the disabled "preserve_plants" feature seems to be turned on for rule-0.
Just to clarify, the preserve_plants parameter was removed, not the plant preservation feature itself. Effectively, it's always on; there's no way to turn it off...though you can redefine rule0 to make it non-preserving if you want, as pointed out by ST753Mb. The preserve_plants parameter has been missing at least as far back as Minecraft 1.7.10, though it still lingered (lingers?) in the documentation--e.g., template_rules.txt--and some default templates. Any attempt to enable or disable it is silently and harmlessly ignored. It's been that way for quite a while.
What did change rather recently (around September 2017), however, was the use of (preserving) rule0 in places where (non-preserving) air was used previously: during leveling, for example, or when a conditional rule's condition isn't met. This was meant mainly to inhibit those pesky, unwanted air bubbles that tended to pop up in and around underwater structures, but does also have the effect of letting more plants survive than before. At least when the default rule0 is used.
Keeping it as it is now (in version 17) makes it the most feature-complete anyway, I mostly wanted to point it out just in case something unintended slipped through, but since it's more feature-complete as it is now, I'll have to decide where I want to keep it and where to fix it, although keeping it as it is now actually fixes something I was using a workaround for, so the current mechanics are the optimal state.
Aha. Yes, I've noticed a bunch of trees and cacti and other interesting things popping up inside my structures. Another thing for the to-do list for my "village shops" that *should* be nice on the inside ... but for the dungeons and ruins and such, which *ought* to be overgrown, it just makes it more interesting.
Hey, I just wanted to throw out a big thank you to ST753Mb and Gillymoth. I've been using your structures for a FTB Direwolf20 (1.12) multiplayer server I set up for a while for my friends, and it's been fun to explore the world and get to discover these structures in their "native environment." It's also been a learning process for me to see which of my own structures look a bit ODD.
Technical Question:
I ran into a minor glitch when I tried to edit Gillymoth's boat templates to have a "spawnMinDistance" with values ranging from 600 to 2000 (mostly hovering around 800 or so), alongside the uniqueMinDistance settings, because I didn't want to be swarmed by boats on an Archipelago Biomes o' Plenty world at the entry point. However, this seemed to have the unintended side effect of making the Gilly boats not spawn at all.
Is it possible that if I incorrectly typed "spawnMinDistance," I might cause Ruins to miss the template altogether due to a syntax error? (What happens if I enter in a bogus variable assignment in the template? Like, what if I typed in "minSpawnDistance" instead? Does it just confuse the Ruins parser so it gives up entirely?)
Gillymoth also warned me that a problem might be caused if I entered a space at the end of the line. I don't THINK that was the case, but I didn't exactly check every template by checking the end of every line. (I just would expect that if this was a likelihood, I wouldn't have done it with *every single one* of Gilly's boat templates, since I was typing in the setting manually each time rather than cutting and pasting.)
I ended up "fixing" the problem by just reinstalling Gillymoth's templates as-is, overwriting any of my changes. After that point, Gilly boats started popping up as intended in newly-explored ocean terrain.
Yesterday I looked into what was causing the problem that Bullorg74 was having with certain templates not spawning in the End dimension, so I made a quick ender template from my aztec totem, and tested using the generic folder with acceptable_target_blocks=end_stone, and it spawned as expected.
Then I noticed a few of my new templates weren't showing up in the biome matching the folder they were in, ones I was spawning regularly with /testruin, and I realized that it wasn't caused by biome designations at all, but by something in certain otherwise normal templates.
Anyway, I set up a proxy template and it worked to get Ruins to auto-spawn them.
Also, after spending the last 6 weeks making new structures and "fixing up" pretty much my entire set of houses (as seen in screenshots at the top of this page), and the cities that spawn them, I'm pretty much ready to make another release.
Gillymoth Structures for Ruins <<< Folder containing my Structure-sets for Ruins mod.
A template should always be a candidate for spawning in the biome corresponding to its folder, unless it's effectively being rejected due to that biome either not supplying acceptable target blocks (e.g., a jungle template that only spawns on podzol) or having intolerably bumpy terrain (i.e., max_leveling and/or allowable_overhang is too restrictive). If you're seeing contrary behavior, that's an error; I'd like to look into it. Do you have an example?
The templates that do this are all my swamp settlement, village, and outpost cores, the files are in my sig on the new release.
In testing I removed all structures from the swamps, except for these specific structures, other structures in swampland were generating fine, but were removed to increase the chance to 100% that a broken file would be used.
For each attempted fix I restarted minecraft and started a new world. I also loaded everything up in a modpack launcher to check the console to see if it would show the errors.
My guess would be an arrant mark somewhere in the file itself, likely something read by the normal spawning routines, maybe from constantly reusing three year old generated template code without generating a fresh file. I ended up taking the easy route by finding a work-around. Hopefully in all my changes to the files I didn't actually manage to fix them properly, so that light can be shed on it.
The other templates in swampland were working fine, and they had the same blocklist as the broken ones. Also I was using Ruins 16.7, so it might not show up in the newest version. I can set up testing again to see if the files are still broken.
This time running only those templates, and two of them spawned close to spawn, so it might be fixed for the ones listed. In troubleshooting I noticed there was at least one header field missing (I think it was missing the allowable overhang field entirely, and that might have been it), and an ancient one that wasn't showing up in new parses (cut-in buffer).
In any case, certain "generator templates" are ones that aren't designed through parsing, and it's likely that some of these files would contain an obsolete configuration, of course, the breaking part would be when it's missing an important directive.
The first thing I checked was if there were spaces at the ends of lines (or other things the cat may have added while visiting the keyboard), but the file ran file with /testruin, so the obsolete configuration is the most likely cause.
Gillymoth Structures for Ruins <<< Folder containing my Structure-sets for Ruins mod.
As quarteranimal suggested, the field "allowable_overhang" was missing entirely from the template and was the most likely cause. (the next post below correctly describes all the details)
Since I accidentally ended up fixing the error without confirming the exact cause, I'll illustrate the most likely fix:
If a template generates fine with /testruin, but Ruins auto-generation doesn't recognize it, it might be that the file itself is outdated. If this is the case, then comparing the broken template to a newly parsed template and replacing mismatching header directives may be a solution.
Another way to break a file is to add spaces at the end of a line, which are invisible to the viewer, and can be seen by selecting the entire file and looking for highlighted spaces at the end of lines.
I should point out the cause (i'm guessing) is with files from ancient versions of Ruins, so the easiest way to avoid this problem is to use the /parseruin command, as it generates fresh new files. The one place ancient files may still be used is in "technical" files designed to spawn things like cities, and such errors may accumulate over time. It should also be mentioned that if someone were to reverse engineer existing files, they would end up replicating errors such as these.
Gillymoth Structures for Ruins <<< Folder containing my Structure-sets for Ruins mod.
@Gillymoth: Thanks for the details--I think there's a real problem here that doesn't have anything to do with your templates. I do see spawning of your swamp structures with the latest version of Ruins, but not nearly as much as I should. Preliminary poking around suggests Ruins thinks structures are being built when they're actually not, and it's somehow oddly related to embed_into_distance. That's as much as I can look at it for now, but I'll embed_into it further this weekend.
EDIT: Bug found and squashed; it was indeed an embed_into_distance issue.
I can confirm that the generation density was much higher with just the individual huts before building the cities, and the bug report does explain why templates created a couple years before I started are filled in with max values in allowable_overhang. I can also confirm having seen templates setting down a couple blocks further than they should have, specifically the center landmark in the city settlements, and remembers messing with the numbers until the unseen adjustments cancelled themselves out.
Thank you for finding and fixing this.
Gillymoth Structures for Ruins <<< Folder containing my Structure-sets for Ruins mod.
@Gillymoth:
Thanks for the warning about the "space at end of line" issue. I didn't realize that could be a problem. Does that apply to commented-out lines?
@QuarterAnimal:
I found the discussion about the fix interesting, but I was curious about the "(incorrectly, it could be argued)" bit in relation to the allowable_overhang setting when handling "flying" structures. I figured that when I'm doing a flying structure (an airship, sky island, or whatnot), I care little-to-nothing about the constitution of the ground underneath it, to the point where I should have the most generous possible definition of allowable blocks, max leveling, and allowable overhang. After all, the target block could be on the edge of a cliff for all I care. Does the "incorrectness" only apply in the sense that you deem it an unnecessary step, or that the value may be unnecessarily high?
--- 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)
Having a space at the end of the line was only one template about 3 years ago, caused by me being too loose with the format, but I mention it mainly as a good thing to check for with a broken template, as it's invisible and can be overlooked if that happens to be the cause of a break.
The extra space was in the layer code after the last number in a line, I most likely just didn't clean up after myself after making manual adjustments, I'm pretty sure that commented text can have things like extra spaces, up to the place where the file reads the new line directive, which when read in notepad will simply show up as the next line.
Having said that I realize I was checking code to see whether a rule that hangs over to the next line would be truncated because of it, and my preliminary results were inconclusive as I had a rule with twenty or so options, so it ended up being more of a Turing machine than anything else.
I read the term " "incorrect" " (in context in the bug report) as meaning the in-template solutions turned out to be "patches", as the actual correct way to fix it was the change in the code itself. Though by all means safety measures that make things work better in-game are still favorable, exactly because it makes things work better. Of course a new version with the fix will no longer need such safety measures.
Right now I'm flying through a new world looking for anything that I might have missed, and found a couple places to make adjustments, which ended up being unrelated to the above. Mostly that our expanded awareness of some of these details may indeed warrant another pass over our sets so that we can see how they generate with new eyes, and recognize other ways thing can be optimized.
Gillymoth Structures for Ruins <<< Folder containing my Structure-sets for Ruins mod.
Well, I think I can thank you and your revelation of the function of "leveling_buffer=-1" as being one of the primary drivers for me going through and optimizing most all of my templates, as it rendered some of my "Command Block seed" exercises needlessly complex (particularly for spawning giant trees), and allowed me a far greater chance of spawning some of my larger-footprint structures in hilly areas -- as long as I went the extra step of giving them proper "basements."
I've been trying to sort out whether or not I could recreate some of my "village" experiments with the adj template rules -- thus allowing more of my experiments to fit into the "no command blocks" category -- though I've found that for SOME (particularly Kujaku10's walled city, where specific facing is a big factor) it would not. Also, with the advent of the /fill command, I've been thinking of seeing if I could use that to create Vanilla-Village-style "roads" (or "paths") along the axis of such a village ... though of course that would totally counteract the benefit of creating a village without Command Blocks. (That is, a /fill replace command that replaces instances of "grass" with either gravel or dirt-path, along a narrow North-South path with a considerable +/- Y variance, and then do the same for East-West. I've thought of repeating the process for the same paths to replace instances of "water" with "wood plank" and "lava" with "cobblestone" to account for pools of water that might be within the bounds of the village.)
The videos previewing new possible world-creation options for 1.13 has me both excited and worried. First, I figure it'll break every single template (even assuming it's possible to upgrade Ruins to even WORK with 1.13 with such major changes to how blocks are handled, and the elimination of data values). But secondly, while I'd love to play with "sky island worlds" or "cave worlds" as seen with the new videos showing new world-gen possibilities, those would likely play havoc with things. (For sky-island worlds, having a building with a deep basement could look pretty weird, if the basement is sticking down through a thin island and hanging out into space. For cave-worlds, I guess I'd have to deploy the same sorts of tricks I've been using for structures in the Nether, if I want anything to spawn on the ground "normally" again.)
--- 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)
@Jordan_Peacock: Conceptually, the allowable_overhang parameter is a bit counter-intuitive. It sounds like an attribute of the structure to be spawned--I'll allow this many blocks of the building to dangle over a cliff edge, for example--but it's actually an attribute of the surface on which the structure is going to spawn. It specifies how many "holes" that surface can have and still be considered a valid spawn site (the definition of "hole" isn't straightforward, either, but that can be the topic of another discussion). Now, in some (many?) situations, the distinction isn't especially one worth making, and if you don't care what's underneath your b'loonz, sure: go ahead and set full overhang and max max_leveling.
But what if it does matter? Maybe my steampunk agronaut roboblimp wants to hover over relatively flat terrain and periodically dust the ground below with bonemeal. I can accomplish that by setting tighter max_leveling constraints, and little or no overhang. Note that, in a sense, the blimp itself is completely "hanging over" the land, but that's not what allowable_overhang refers to. It just means the terrain below can't have holes in it.
Before this latest fix, that wouldn't be possible. The allowable_overhang value would need to cover the entire footprint of a template for a flying structure to spawn at all, so only limited constraints could be applied to the underlying terrain. I hedged by saying "it could be argued" because, while it may be entirely appropriate to overhang as all get-out depending on the application, it's incorrect to think a template necessarily has to be set up that way to work. Well, at least it is now.
Hello, new password
Challenge Accepted, oh wait, *dusts off unreleased project folder*
Just a quick PSA: Beetroots only grow to meta-value 3 and higher numbers are invalid, so when making farms, make sure there are no higher numbers for that block or builds end up truncated at that point.
Gillymoth Structures for Ruins <<< Folder containing my Structure-sets for Ruins mod.
I'm just about ready to release another structure update, and while flying around in the world checking the natural spawns, it seems that in the newest version of Ruins (17.0) the disabled "preserve_plants" feature seems to be turned on for rule-0. This means that the inside of structures that don't explicitly specify air end up getting filled with trees when spawning in forests and jungles. There was another mention of tree-filled houses above, but the cause wasn't outlined.
Gillymoth Structures for Ruins <<< Folder containing my Structure-sets for Ruins mod.
Isn't that desirable in a sense though? It adds to the structures being "ruins" after all, some of them would have let nature take over...
How to deal with ignorance (in life, and on forums): The Zen way... Stay cool and polite, treat people as you wish to be treated, rise above your impatience. Everyone is ignorant of something at any point in their lives, including you.
It is tempting to just leave them how they are, since things in plains would be less affected, or to make "gutted" versions of things in forests and places with lots of trees. In jungles it doesn't seem like a bad thing at all, as temples are commonly intermingled with strangler-figs in pretty much every reference photo.
Gillymoth Structures for Ruins <<< Folder containing my Structure-sets for Ruins mod.
I like plants growing in most structures, as long as there keeps being way to force exclude them from areas that plants definitely shouldn't grow, like intact houses. Preserving plants being the default makes the most sense to me, since most Ruins are, well, ruins. Now that I know about putting =0,100,preserveBlock or =0,100,air in front of my rules list when necessary I've been making lots of use of it, and I like it more than the old preserve_plants system.
I remember when I first started making structures, and thought I needed to have preserve_plants on in order to prevent the structures from spawning on top of trees leaves, the way preserve_water makes things spawn on the seafloor. So, even though I generally don't like change and having to learn a new system was kind of confusing, I don't think it's harder to learn than the old one for anyone just starting out.
More Ruins Templates: https://www.dropbox.com/sh/e8gwe4638lqbakd/AAD2nsMtDSBvezUADCYmo2s-a?dl=0 Templates for 1.10.2, 1.11.2, 1.12.2. Updated Dec 7, 2018.
My modpack, ParasCraft: An Exploration-based Pokecube Modpack https://minecraft.curseforge.com/projects/parascube
Just to clarify, the preserve_plants parameter was removed, not the plant preservation feature itself. Effectively, it's always on; there's no way to turn it off...though you can redefine rule0 to make it non-preserving if you want, as pointed out by ST753Mb. The preserve_plants parameter has been missing at least as far back as Minecraft 1.7.10, though it still lingered (lingers?) in the documentation--e.g., template_rules.txt--and some default templates. Any attempt to enable or disable it is silently and harmlessly ignored. It's been that way for quite a while.
What did change rather recently (around September 2017), however, was the use of (preserving) rule0 in places where (non-preserving) air was used previously: during leveling, for example, or when a conditional rule's condition isn't met. This was meant mainly to inhibit those pesky, unwanted air bubbles that tended to pop up in and around underwater structures, but does also have the effect of letting more plants survive than before. At least when the default rule0 is used.
Keeping it as it is now (in version 17) makes it the most feature-complete anyway, I mostly wanted to point it out just in case something unintended slipped through, but since it's more feature-complete as it is now, I'll have to decide where I want to keep it and where to fix it, although keeping it as it is now actually fixes something I was using a workaround for, so the current mechanics are the optimal state.
Gillymoth Structures for Ruins <<< Folder containing my Structure-sets for Ruins mod.
Aha. Yes, I've noticed a bunch of trees and cacti and other interesting things popping up inside my structures. Another thing for the to-do list for my "village shops" that *should* be nice on the inside ... but for the dungeons and ruins and such, which *ought* to be overgrown, it just makes it more interesting.
--- 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 just wanted to throw out a big thank you to ST753Mb and Gillymoth. I've been using your structures for a FTB Direwolf20 (1.12) multiplayer server I set up for a while for my friends, and it's been fun to explore the world and get to discover these structures in their "native environment." It's also been a learning process for me to see which of my own structures look a bit ODD.
Technical Question:
I ran into a minor glitch when I tried to edit Gillymoth's boat templates to have a "spawnMinDistance" with values ranging from 600 to 2000 (mostly hovering around 800 or so), alongside the uniqueMinDistance settings, because I didn't want to be swarmed by boats on an Archipelago Biomes o' Plenty world at the entry point. However, this seemed to have the unintended side effect of making the Gilly boats not spawn at all.
Is it possible that if I incorrectly typed "spawnMinDistance," I might cause Ruins to miss the template altogether due to a syntax error? (What happens if I enter in a bogus variable assignment in the template? Like, what if I typed in "minSpawnDistance" instead? Does it just confuse the Ruins parser so it gives up entirely?)
Gillymoth also warned me that a problem might be caused if I entered a space at the end of the line. I don't THINK that was the case, but I didn't exactly check every template by checking the end of every line. (I just would expect that if this was a likelihood, I wouldn't have done it with *every single one* of Gilly's boat templates, since I was typing in the setting manually each time rather than cutting and pasting.)
I ended up "fixing" the problem by just reinstalling Gillymoth's templates as-is, overwriting any of my changes. After that point, Gilly boats started popping up as intended in newly-explored ocean terrain.
--- 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)