If you want to keep the Command Block summons and setblocks silent, you can use the following command:
/gamerule commandBlockOutput false
I should probably put that in the "readme" for my ZIP collections. That's a nice idea about including a special message, though -- I should try doing that! (Deliberate messages will still display even with the "silent" setting; it just eliminates the otherwise automated chat messages.)
As the changelog says, unique was scrapped in favor of uniqueMinDistance in 12.9
14.2
+ improved undo command to only save ruin sites BEFORE actually spawning ruins
+ /testruin now also allows to replace the specified y coordinate with "_", which signals Ruins to find a suitable y for given x,z
+ with exactly the same behaviour (flying, underground...) a randomly spawning template would display
+ this y specification may NOT be combined with "~", aka "_~2" will NOT work
As the changelog says, unique was scrapped in favor of uniqueMinDistance in 12.9.
Oops! I was going by template_rules.txt (in subfolder examplesAndDocs) where I've been getting most of my instructions regarding the new features included.
# unique=<yes/no>
# If this is set to 1:
# If the template is generic, it can only ever be generated once per world.
# If the template is biome-specific, it can only ever be generated once in the
# biome per world (so you could duplicate it to other biome folders).
# Defaults to 0 (no).
I hate to ask dumb questions, but where can I find the changelog? In readme.txt, it says "Version: see changelog in mod file" but I haven't been able to figure that out. I've tried opening the .jar file itself in WordPad, but that's not in ASCII, so that doesn't work, either. I've tried looking on the Ruins download site, but I haven't noticed any tabs that indicate a changelog.
I just did a Google search on "Minecraft uniqueMinDistance" and found a page titled "atomicstrykers-minecraft-mods" on code.google.com, which appears to have source information on it.
And regards the changes: HURRAH! And so amazingly fast, too! As soon as I get the chance, I'm going to download the latest version and give this a try. Also, I'll experiment with uniqueMinDistance.
(EDIT: I found a "changelog.txt" on code.google.com and it says:
12.9
+ premature optimization probably made the collision detector not work ... brute force it is
+ added world chunk logging to detect IWorldGenerator.generate being called multiple times
+ scrapped "unique" template setting because it never quite worked right. Use templateInstancesMinDistance
So I guess I should be using templateInstancesMinDistance instead of UniqueMinDistance? I'll try both and see what works.)
I hate to ask dumb questions, but where can I find the changelog? In readme.txt, it says "Version: see changelog in mod file" but I haven't been able to figure that out. I've tried opening the .jar file itself in WordPad, but that's not in ASCII, so that doesn't work, either. I've tried looking on the Ruins download site, but I haven't noticed any tabs that indicate a changelog.
I just did a Google search on "Minecraft uniqueMinDistance" and found a page titled "atomicstrykers-minecraft-mods" on code.google.com, which appears to have source information on it.
You'll need to open the .jar file with something like winrar or 7z to view the contents as that's where the changelog is usually hidden
You'll need to open the .jar file with something like winrar or 7z to view the contents as that's where the changelog is usually hidden
Thanks! I still have a lot to learn about how these mods work.
uniqueMinDistance indeed does the trick, and I've applied it to things like the walled desert village, the great sphinx, etc., and re-uploaded a few of my structure bundles. I found that it's actually mentioned in the template_rules.txt document, further down than the "unique" reference ... right next to the reference about "preventRotation." (Aha! That should be useful for dealing with the double-door flipping problem, too. I'm embarrassed that I didn't notice that earlier.)
/undoruin works again -- yay! There's an odd glitch if the ruin had spawned on a sharp slope with "basement" levels extending outside the slope -- and those layers are still partially present in any area that had been "air" before the /testruin spawn -- but that's a rare situation anyway, so for most cases it works perfectly now.
I've also tested out the "_" feature for /testruin and I've found that it's very handy not only for attempting to build villages. With this feature, I can zoom around in the air in Creative Mode and plant structures beneath me (e.g., /testruin CastleOfDoom ~0 _ ~0) and it'll nicely spawn on the ground BELOW me. This is very useful in cases where using /testruin to spawn something would cause my in-game character to become encased in solid stone or some-such, forcing me to break blocks just to get out again, or if I just want to zoom along and plant several different structures at once in a throwaway test world simply because I want to see what they look like and make comparisons. Convenient!
Okay, my first experiment with the new features in Ruins mod seems to be working reasonably well: "ruins-cursedvillage-1v7v10-2014-11-08.zip" in the Dropbox link in my signature. This requires the latest version of the Ruins mod for Minecraft 1.7.10.
The "meta" structure (which I placed in the "plains" sub-folder) consists of the central village well with a bunch of Command Blocks piled on top, with "RUINSTRIGGER" to set them off once the player gets within range. Then ... the cursed village appears!
The individual structures are based off of the "vanilla" village structures, but with "ruined" touches such as missing blocks, cobwebs, etc. -- plus a few spawners for special villager zombies (and a nasty skeletal watchman) that are persistent and beefed up past the normal profile. Note that in the picture, there is a pool right in the middle of town, near the central well; normally there would be a church/watchtower that spawns there, but the pool made it an invalid building point, so that building simply didn't spawn; the rest continued as normal.
Since this uses the new "_" self-calculating "Y" feature for positioning, it's a lot easier for Ruins to find a valid building spot for the central well (just a footprint of 4x4, after all), and then the surrounding buildings match the terrain (more or less). I couldn't figure out a way to make the gravel roads (that's well beyond the mechanics for Ruins mod, I think), but it IS a ruined village, after all, so I suppose it only makes sense that the roads are overgrown. It sometimes gets a bit wacky when the village spawns in the vicinity of a ravine or a cliff, but I've tried to minimize that by keeping the "biomesToSpawnIn" in relatively shallow-terrain biomes.
Yes, sigh, i'll probably design a feature that allows connected structures. It will probably be a nonunique template line "adjoining_template" which will allow you to specify one template by full name/path and relative xz coordinates, for which ruins will then attempt to find a reasonably matching y (not like vanilla cliff jumping villages) and even check the building site with the usual restrictions. Thus, it won't spawn those adjoins if the terrain doesnt support it.
If you have some more suggestions or wishes, post em, so i can include or reject them in the design.
My first sequentially-revealed "war tower" is finally finished. (Yay!)
Like the Cursed Village, this requires taking the pieces and putting them in their proper folders. (ZIP file contained in Dropbox folder, linked in my signature below.) The WarTower1Base_1v7v10.tml file goes in the Plains biome (or whatever biome you want this thing spawning in), while the remaining templates in this bundle actually go into the templateparser sub-folder. The idea behind this is that an evil sorcerer has a magical tower that doesn't quite exist in the material plane; in order to reach his inner sanctum where he performs experiments to create unnatural life from the elements and living materials, one must advance through the tower, defeating his animated golems along the way. At the top of each segment, a portal is disguised as a humble chest; opening it reveals the next tower segment (and its guardians).
I intended this to be a mini-dungeon for multiple players, though I suppose depending upon what mods you have installed and how well equipped you are, you COULD tackle it alone. (I tested it myself, going solo with diamond equipment, and it was a bit of a challenge just charging in and fighting, so I ended up using various tricks to pigeonhole enemies with blocks so I could take them out at range at my leisure.)
Hi, I'm sorry to be a bother but I can't seem to get any ruins to spawn, or well none of the ones I want, a few spawn, theres and empty barn. Theres a big cobble structure with two chests and zombie spawners under slabs, theres a small cobble thing that's just like I dunno a little corner of cobble, there a smaller cobble building with two zombie spawners and one small chest a weird cross with skulls on it, a weird tower with a furnace under it and a big castle looking thing with two wheat farms
That's all that spawns. I went into the config files and upped the weights but I'm still not getting anytihgn, did I miss a step? Sorry to be such a bother But this is such an awesome mod I'd love to see more of the structures
(Disclaimer: AtomicStryker is of course the expert on these things. I'm only writing here based on my own experience and opinions.)
It sounds as if you have indeed gotten a few structures (empty barn, cobble structure, etc.), but just not particular ones you were hoping for? Which ones are you hoping for in particular?
One thing you could do is that if you are getting structures you DO NOT want in your world, versus the ones you want -- and if you actually know which ones you DO want -- you could go into the appropriate folders and simply remove the unwanted structures, or else disable them by setting their weight to "0." After all, every unwanted structure that spawns represents a place where maybe something you DID want could have spawned there instead.
Structure Testing:
Otherwise, if you are concerned that certain structures you are hoping for are simply NOT SPAWNING AT ALL -- well, testing for that is something I've been doing for my own homemade structures. First, I would create a "superflat" world, and make sure that my desired structures are loaded into the "plains" folder (and that any unwanted ones are out of the picture). This is a pretty good test to make sure that under IDEAL conditions (and a "superflat" is about as ideal as you can hope for) the structure will eventually spawn, if you explore far enough. If you spawn a Superflat world, you might try experimenting with the presets to try a "desert" or "water" world, to change up the biome, to see some of the structures that would not normally spawn in the Plains biome (that a superflat world normally defaults to). This is a fairly fast way to get a "grand tour" if all you want to do is check out structures.
If it shows up, that means that it's at least theoretically possible for it to show up.
If it DOES NOT, then my next step would be to remove ALL other structures (and put them into some sort of temporary holding area), and have ONLY that one structure in the plains folder, and open up another superflat world. (Please note: If you make any changes to the biomes folders, you will need to QUIT the game and then reenter it to see any difference when exploring.) If your desired structure is the ONLY choice and yet it STILL does not spawn, then that means something is wrong with that template, and it will have to be "debugged." (Maybe it has "acceptable_target_blocks" that don't match the terrain, for instance. Or maybe there's an error in it, so it never loads properly.)
/testruin Exploration:
If all you want to do is see what a particular template looks like (to see if it's something you really want spawning in your Minecraft world or not), one way to do it is to grab it from whatever folder it normally appears in, drop it in /templateparser folder, then use the /testruin command in Creative mode to force it to appear. If it fails to spawn right then and there, that's a fair indication that the template is simply broken. Otherwise, it should give you a good idea of what it's like. Note that with /testruin, you can now specify relative coordinates. So in Creative mode, you could fly up into the sky, and type something like "/testruin MagicCastle ~0 _ ~0" -- and this should spawn it somewhere directly beneath you (if, that is, you're high enough!) but at ground level so you can see how it normally spawns in a world. (Otherwise, if you don't specify any dimensions, it will tend to spawn right on top of you, which might mean you have to break your way out of a couple of blocks first before you can take a look at the whole thing.)
Back to Regular Minecraft Terrain:
Now, just because a structure will spawn in a superflat world does not mean that it will necessarily spawn with the same frequency in a regular Minecraft world with normal terrain. I have noticed that even though new changes to the Ruins mod make it a lot easier to get a structure to spawn (for instance, the ability to simply leave out "acceptable_target_blocks" and let it accept ANYTHING -- except water or lava -- by default), but structures with a big "footprint" (large X/Z dimensions) tend to have a harder time finding a valid space to spawn. Structures that have "max_leveling" set to a higher value tend to get a lot more leeway on this, but even then, I find that it's hard to get a large, wide structure to spawn in certain environments such as, say, jungle. Structures with "max_leveling" set to zero seem to have a comparatively hard time finding valid places to spawn, even if I set the acceptable "overhang" to a high number. By contrast, if you have a structure that consists of nothing more than a single column of blocks stretching to some ridiculous height, it'll still be fairly easy for the program to find a valid spot to place it, since there's no slope to worry about.
Some structures WILL spawn eventually, but the Ruins mod just has a rougher time finding a valid building spot for them, so you may not see them until you've explored a LOT of area, or you've just gotten very lucky. Structures that spawn in Plains, Desert or Ocean tend to have a relatively easy time spawning. For wooded areas, structures that have "preserve_plants" set to 1 (or "yes") tend to have an easier time finding a valid place to spawn, but it's still no guarantee. There are some structures that you'll see all over the place on a Superflat world that I've failed to find even once in a pretty widely-explored multi-player server regular-terrain world (because, say, there was no max_leveling set, no preserve_plants, it only spawns in a single specific biome and we've got our server loaded up with a bazillion custom biomes, it has a really big footprint, etc.).
Just made a new ruin for my modded profile. "WBHWineCottage01". Requires Psychedelicraft mod and MrCrayfishFurnitureMod.
Crops are wine and tobacco from the Psychedelicraft mod (plus something a little greener hidden around back). Interior also includes furnishings from MrCrayfishFurnitureMod. 2 chests inside with random loot and 1 chest with one of 4 possible contents, all Psychedelicraft finished items. I spent the rest of the night creating small ruins that use the "one of x treasure chests of your choosing" feature. Buried beach treasure was my next ruin. Weird walls are alternating stairs and upside down stairs, roof is slabs (so that monsters can't spawn on the roof).
The tml contents:
# WBHWineCottage01.tml
# Created by Ruins mod version 14.1 Ingame Parser
# authoring Player: WildBluntHickok
# Requires: Ruins, Psychedelicraft, MrCrayfishFurnitureMod
My first Ruins dungeon meta-structure is more-or-less a success!
The core structure is a mausoleum standing atop a spiral staircase. It has a fairly small footprint, and I specified it to only attempt to spawn in Plains, Savanna, and a few similar biomes, so it should have fairly high chances of spawning successfully. Command Blocks with "RUINSTRIGGER" keys then fire off, attempting to place other (optional) structures to expand the layout. If NOTHING else spawns, at least there's an interesting structure and a few monsters to clobber.
On the surface, a "Graveyard Wall" structure attempts to provide a border to a surface graveyard, though it uses the "supported by" rules so that if part of it spawns on a crevice/pit, or a too-sharp slope, sections of the wall just won't spawn at all (or the wall might not find a valid build point if it's too close to water or lava). A few individual grave stones with randomized features and epitaphs spawn using the "calculated Y" feature, to go along with surface terrain. A couple of trees are spawned as well (if valid build points are found), with twisty root structures that can cut through some of the underground structures' walls for a run-down look.
Individual modular dungeon/catacomb rooms and passages are spawned via more Command Blocks with the RUINSTRIGGER key. These don't use the calculated Y placement, and instead are just relative to the core central structure, so they seem to have better chances of spawning (since they aren't checking for surface blocks and such). Several of the branching passages open onto solid rock, dirt, or whatever material the ground is made of, meaning that there's a chance of a solid stone wall at a dead-end, or perhaps some exposed ore, maybe a flooded passage, a lava flow, or even an opening into a cavern. (I actually ended up with passages going right into caves quite a few times during testing ... bolstering my opinion that there are simply TOO MANY CAVES in vanilla Minecraft. )
If all structures spawn successfully, then there's a simple layout (shown on an all-glass superflat custom world above) with a few traps, custom monster spawners, and treasures. I tried to spruce up the interiors so it's not just some boring collection of cobblestone boxes, but rather a place that I hope is worth checking out for the sights and not just the loot.
Theoretically, another dungeon could be made by taking the same core structure and changing out the command blocks to call the sub-structures in a different arrangement. As with my other "meta" structures, the core structure has to be in the appropriate biomes folder (I put it in "plains"), but the sub-structures have to be in the templateparser folder so they can be called in turn.
Yes, sigh, i'll probably design a feature that allows connected structures. It will probably be a nonunique template line "adjoining_template" which will allow you to specify one template by full name/path and relative xz coordinates, for which ruins will then attempt to find a reasonably matching y (not like vanilla cliff jumping villages) and even check the building site with the usual restrictions. Thus, it won't spawn those adjoins if the terrain doesnt support it.
If you have some more suggestions or wishes, post em, so i can include or reject them in the design.
I've been thinking about this post (i.e., suggestions or wishes to state), and I figured I'd wait until I actually saw some of my projects through to something resembling completion, to see if anything in particular comes up. DISCLAIMER: I am very happy with this mod! This is just a brainstorm of suggestions for things that would be "nice to have" in the future -- not a gripe list. It's amazing what can be done with the Ruins mod already.
Common Point of Origin: Right now, my structures require me to use Command Blocks, and each Command Block can handle only ONE command, and each block has to be in a different position, so all my relativistic ~X ~Y ~Z coordinates have to take into account the varying location of the originating block. I wish there were some way I could get the effect of executing several Command Blocks from ONE location, in sequence (each one being replaced in turn), whether it's to fire off /testruins commands or customized /summon commands or whatever.
---------------------
Formatted Randomized Choices:
I would also find it useful if the template offered a format that made randomized choices legible and easy to work with. Right now, I can put several different options on the same "rule" line, separated by commas. I've had problems before where some of my code would fail because I had a rogue space in the middle of the command line, so apparently I can't just insert "carriage returns" or spacing in order to make things more legible. (Please correct me if I'm wrong on this! I'd check right now to be sure, but I'm in no position to do so at the moment.)
Expanded explanation put behind spoilers, because I tend to ramble:
If I'm populating a city with buildings (or custom villagers!) or making a dungeon layout (where I probably should stick to some sort of modular standard, such as 16x16 segments, for easier mixing and matching), it'd be nice if I could list several options in a readable, easy-to-follow sequence.
E.g. (I'm just making this up -- and I'm assuming that anything in this format will be automatically fired off as per RUINSTRIGGER, and that ":@" is assumed at the end):
Some Way to Make Those Gravel (or other) Roads:
Okay, the thing about the gravel roads that spawn with villages is that the /top layer/ of the existing terrain is replaced with gravel ... unless the top layer happens to be water or lava, that is, and it treats trees like they aren't even there, I think.
Another rambling idea about how this might be done.
I'm just brainstorming here, since I don't know enough to know what's even possible with the existing code, but just for the sake of argument, let's imagine a new template field called "followTerrain" which normally defaults to 0 or false.
If a template is set to "followTerrain=1" (true), then perhaps the mechanics of how the structure is placed change. max_leveling is ignored. acceptable_target_blocks and unacceptable_target_blocks are NOT used to determine whether the template can spawn there at all. Instead, they are used to determine WHICH target blocks are affected within the designated build area.
So, let's imagine a sample "structure" in this form has a layout such as:
... Then, for each X,Z position in this structure, it replaces the top two layers (for this "structure" is two layers deep) as per these rules. So we'd end up with the top layers in all the "1" positions being totally untouched. Lava, water, and pre-existing structures (built of cobblestone, wood planks, etc.) don't have top layers within the "acceptable_target_block" list, so any such spaces simply won't be touched, but the template will carry right along for other, valid spots of the building zone. It's set to preserve_plants=yes, so trees won't have their top layers replaced with gravel or cobblestone. But wherever there's dirt or grass or stone, the top layer (following the terrain) will be gravel, with an underbed of cobblestone.
For any rules with less than 100 percent chance of spawning the block, the existing block is left intact if the replacement block doesn't spawn.
This structure (or something like it -- probably BIGGER -- could be laid down to form the "road" for the heart of a village, likely placed BEFORE the village well or any other buildings are added.
Since the template can be specified, the builder could choose whether to go with traditional gravel (or sandstone for desert villages), or whether this town will be paved with stone slabs or upturned wooden log segments or even GOLD (though that would be terribly cheesy). Or, someone could, on a lark, have a "structure" that just consists of a giant "X" branded on the landscape (following the contours of a hill or even a cliff) with blocks of moldy cobblestone, and perhaps on the bottom-most layer there is a buried chest right at the center.
Anyway, that is just my attempt to imagine how such a solution might work, if it were possible.
------------
Forced Air Blocks:
I was thinking about having a "Sunken Atlantean City" with some breathable spaces inside. This is presently a bit tricky. I have a few ideas for how to do this with Command Blocks, but....
preserve_lava, preserve_water, and preserve_plants are very handy for getting ruins to spawn in places they wouldn't otherwise (buildings in forested areas, sunken shipwrecks, etc.). The trouble is that there are times when I honestly, seriously, want a block to spawn as empty AIR rather than whatever is being "preserved." (Say, an underwater sunken shipwreck, and I want an "air pocket" inside, or a forest house and there are some spots where I DON'T want trees growing right through this particular spot.)
It would be nice to have an "Empty" rule. Say, rule2=0,100,Empty -- and no matter what's being "preserved," this spot is going to be EMPTY (air) once the structure spawns -- not water, not lava, not tree trunk.
Presently, I try to work around this with various "tricks," such as putting string/tripwire, vines, signs, doors, etc., into a space where I don't want water for an "air pocket" in some underwater observatory. Or, I could skip preserve_water and just treat the surface of the water as my target blocks ... but that means my structure is going to be a SPECIFIC number of blocks embed_into_distance regardless of the actual ocean depth in that location. Some sort of specific "Air" rule would be convenient for situations like this (however rare).
------------
Auto-growth Trees & Mushrooms:
I'd like to dot my village, graveyard, faerie ring, ruin, or what-have-you with trees, either for that overgrown ruin look, or just because I'd like some nice shade. I can do that at present by using /parseruin on a complete tree, but in-game it's a whole lot easier to just plant a sapling and apply bonemeal to it, whereas a Ruins structure needs to clear out the surrounding terrain, or find a fairly flat place to build in. I don't want my tree to be based on water or lava, but it really only needs one (or maybe 4) blocks of dirt to base the trunk on -- not the ENTIRE footprint.
I could imagine some new format -- say "rule1=1,100,Ggrow:minecraft:sapling-1" -- that will plant a sapling or mushroom, and then hit it with however many doses of bone meal it takes to get it to grow (IF, that is, it's in a legitimate spot to grow, with enough headroom, light, etc. -- though honestly I wouldn't mind bypassing some of those limitations).
Either that ... or is there a CommandBlock command I could use to apply "bone meal" growth to a particular location?
--------
Required Target Block:
Okay, let's say I want to make a "dock" structure. I set the biomes to something like ocean or beach, or both. For acceptable_target_blocks, well, sand is okay, and water is okay. The trouble is that I don't want my dock built in the middle of a big sandy expanse (nowhere near water) ... and I also don't want it floating in the middle of the ocean. Ideally, I want it touching BOTH.
Hence, a "required_target_blocks" field might be handy. Say, "required_target_blocks=sand,water" tells it that SOMEWHERE in the building zone, there must be AT LEAST one water block, and there must be AT LEAST one sand block. Beyond that, it might be gravel or stone or grass or whatever that still falls under the "acceptable_target_blocks," or maybe I just don't care, but at least this way my odds are greatly improved that the dock will end up somewhere near the shoreline (but not completely upon dry land).
---------
Paintings, Item Frames, Mine Carts, Boats:
I think it's at least theoretically possible to spawn paintings, mine carts, etc., via Command Blocks. That's on my list of things to experiment with. However, any features that might make it easier to add paintings, item frames, and other decorative entities to a structure would be handy -- especially since Command Blocks require specific relative positions, but if the structure gets ROTATED, those relative positions might not make sense anymore. (For this reason, I tend to place Command Blocks either directly below or directly above the target point for whatever's to be summoned or setblocked.)
---------
Flower Pots:
No village is complete without flower pots! ... Or something like that. Presently, /parseruin doesn't seem to quite get it right when I include flower pots as part of a structure. It generates a flower_pot block with a data value that, when spawned, usually ends up with something different from what I started with in the original structure. I think this is because the rules changed at some point for flower_pots, and they use tile entity data now (although the old data values appear to still work for the original possible contents). Either /parseruin needs to at least match up to produce the proper data values (for whatever valid plants are within that range), or else a new "FlowerPot" function (similar to the Skull function) would be handy to allow for specifying the tile entity data to go along with the flower_pot block.
Honestly, this isn't a terribly pressing thing, but Wendy REALLY likes adding lots of colorful flower pots to her structures, so I had to list it.
---
Once again, I'm very happy with the mod's current functionality, and thankful for the continued updates. This is just a list of brainstormed ideas for "nice to have" things for some future iterations.
adjoining_template would take care of your common point of origin problem
i can offer something beyond RUINSTRIGGER, like RUINSAFTERSPAWN, which does not require a player coming near (although, does a tree exist if nobody sees it?)
hmmm you want a template blocks to "fall like snow" onto/into a given landscape ... well i could make a new rule for this i guess (or you could use gravel)
"air" is a perfectly valid block rule you should use
auto-growing trees should be possible with command blocks, or i could loop all growable blocks? hm
required target blocks across area is an unsolved computer science problem and if i had an efficient implementation of this i'd win prices for it
no to everything that involves tile entities or entity data. Use command blocks.
>>> adjoining_template would take care of your common point of origin problem
Yay!
>>> i can offer something beyond RUINSTRIGGER, like RUINSAFTERSPAWN, which does not require a player coming near (although, does a tree exist if nobody sees it?)
Hee! Well, the player would have to at least be close enough to force terrain generation, so it's possible it might be seen in the distance?
By the way -- how does the RUINSTRIGGER work? Or, that is, how close must a player be before it triggers, and is there any sort of time delay involved? Not that it matters that much -- I'm just curious.
>>> hmmm you want a template blocks to "fall like snow" onto/into a given landscape ... well i could make a new rule for this i guess (or you could use gravel)
I tried just spawning gravel in the air, and letting it drop, but the results weren't quite right, since the gravel would just land on TOP of whatever is already there -- not quite like standard village generation.
Maybe a rule would work where the number indicates, "Whatever layer this block is on, spawn it on the top-most layer of the terrain, replacing the top-most non-air block." If the "preserve" rules are used (plants, lava, or water), those blocks are treated as "air" for such purposes, and hence the block won't spawn there. Thus, you could make a single-layer template that specifies the layout for a gravel village road, etc.
Or, another possibility would be a rule that specifies, "Only place this block if it would replace a non-air block." Again, water, lava, and plants would be treated as "air" if the appropriate preserve rules are used. You could make a multi-layer structure of gravel this way to specify a layout, and only the parts that would be replacing dirt/stone would spawn. (On the downside, the gravel road would be a lot thicker than it necessarily needs to be in parts.) This same rule could be useful for doing stuff like spawning custom ore deposits, or replacing a section of ground with, say, a spot of sand, or maybe creating some sort of "comet impact crater."
Related to that last bit, it might be nice to have a rule of "Only place this block if it would replace an AIR block," similar to the "keep" rule for the /setblock command. (And again, lava, water, and plants would be treated as "air" under the appropriate preserve rules.) This would be useful for stuff like where you want to have a boardwalk or other raised platform with supports that go down to ground level, but don't necessarily go down any further than that.
I regret that I don't really know the procedures here, so I don't know what "rules" would be feasible, or which ones would just be a nightmare to program.
>>> "air" is a perfectly valid block rule you should use
Huh. I thought I'd tried that before, but that might have been back in version 1.6.4 (when I would have really been indicating "0" since that was still done in numbers). I will give that another go. Thanks.
>>> auto-growing trees should be possible with command blocks, or i could loop all growable blocks? hm
I can't seem to find any /commands that might apply to this, but after thinking it over, I really could just make a template that consists of JUST a tree, with all "air" blocks in the template replaced by "preserveBlock," and then call it with /testruin.
So I guess the functionality is effectively already there, so long as I put the appropriate template in the /templateparser folder. I should have thought this through more.
>>> required target blocks across area is an unsolved computer science problem and if i had an efficient implementation of this i'd win prices for it
Oops. Okay, I admit, that was a bit pie-in-the-sky anyway.
>>> no to everything that involves tile entities or entity data. Use command blocks.
Fair enough! I will continue experimenting with seeing what I can do with command blocks. I am thinking of seeing if I can spawn a simple house and use the preventRotation rule to keep it the same facing. The funny thing about spawning paintings with Command Blocks is that you can actually specify WHICH painting appears, so once I get past the initial hassle of lining it up with a wall, if I can get this to work, it might actually be preferable to the annoying process of trying to slap paintings onto walls the normal way.
--------------------
By the way, speaking of "pie in the sky" -- is there any way to get a Ruins structure to spawn on "void" space via acceptable_target_block settings or whatever? (Or is that something that might be codeable?) In The End (Sky biome), I've seen some of my structures spawn on the central endstone island, but nothing spawns beyond that point. I had it in mind to have "floating sky islands" that could dot the empty expanse -- perhaps even a "floating sky island" village with bridges connecting the buildings/islands -- but it seems that since there's no solid ground of any sort to build on, the Ruins mod doesn't even try.
Also, I could imagine this being useful if I ever toyed with the Mystcraft mod again, and created a "Void" age (i.e., no ground at all aside from the spawning platform and whatever you build).
Maybe if I could list "void" in acceptable_target_blocks, to indicate that I'm happy for this structure to be spawning in the middle of nowhere. (I'd just have to make sure that "embed_into_distance" has a negative value, of course.) I know there's no such thing as a "void" block, but it would seem to make more sense than listing "air" as a valid target block (since there's already plenty of THAT to go around ).
You could likely get floating islands using a recursive command block thing, since that unlike ruins does not depend on terrain. But i do not consider void worlds a 'target' for Ruins, seeing as there is literally no data to base randomized yet terrain-fitted spawning off of. This probably does add a randomized factor as request for the adjacent ruin function.
@sirtulip
None of my site's links for 164 and higher should point to dropbox anymore .. i checked, ruins downloads all work
Short version: Paintings won't work with Command Blocks as spawned from Ruins structures, because they require SPECIFIC X/Y/Z coordinates for the "supporting block," even if the painting itself can be spawned with relative coordinates.
Longer aimless rambling about the topic:
Apparently I can successfully spawn a painting with a Command Block (I've done so several times now in testing), but there's a catch: I must specify the tags of "TileX" "TileY" and "TileZ," which indicate what block the painting is attached to, and these CANNOT be relative coordinates. This is *in addition to* the X Y Z coordinates I specify for the painting itself. If I specify invalid coordinates (such as trying to use TileX:~0,TileY:~2,TileZ:~0 ), I get a message that the summon was successful (though nothing immediately appears), and then the painting object "pops" out of about the spot where it should have been summoned to.
I can use relative coordinates for the painting itself, but the TileX/TileY/TileZ have to be specified. (This strikes me as especially pointless, since in version 1.8, TileX/TileY/TileZ are changed to be the very location the painting is in, rather than the tile it's attached to, making the values completely redundant.)
Example of a successful command line (although of course it would only be successful if you've got a supporting block in this location and space around it):
... then behavior is as described above: Successful message but no apparent painting, and then the object "pops" out of the air after a moment.
If I were to envision some ideal way that adding a painting could be handled in Ruins format, it would be something like:
rule6=0,100,Painting:3:Pool
Then, execution would be something like temporarily generating a Command Block and building the command line by plugging in the appropriate coordinates (where "3" would be the Direction, "Pool" would be Motive, and the painting coordinates and TileX, TileY and TileZ could be derived from the location of the "block," with the supporting block's location being inferred by Direction).
Direction: 0 is south, 1 is west, 2 is north, and 3 is east
So, to calculate TileX/TileY/TileZ based on X Y Z and the Direction (using "pseudo-code" here because I'm not sure how else to explain it):
TileY := Y {Regardless of facing, elevation is always going to be the same}
If Direction = 0 THEN TileX:=X, TileZ:=Z-1
If Direction = 1 THEN TileX:=X+1, TileZ:=Z
If Direction = 2 THEN TileX:=X, TileZ:=Z+1
If Direction = 3 THEN TileX:=X-1, TileZ:=Z
However, if there's any rotation at all, this all changes. :/
In version 1.8, this will all be moot, because in all cases, TileX = X, Tile Y = Y, and TileZ = Z.
Then, from that data, it'd have to cobble together the command to feed into the Command Block. Maybe if I brush up on Javascript, I could figure out a proper way to write a routine like that.
Unfortunately, I don't presently have any clever way to do calculations in the middle of specifying a command line, so for now it looks like spawning paintings in a Ruins structure via Command Blocks just isn't feasible. Also, item frames have the same problem.
Flower pots, on the other hand ... well, I managed to get those to work with "setblock." (Examples behind spoiler tag:)
# Greenhouse
# MC 1.7.10; 13 Nov 2014
# Created by Ruins mod version 14.2 Ingame Parser
# authoring Player: Jordan_Greywolf
# Note: This is just an experiment to use Command Blocks to generate
# flower pots with additional version 1.7+ flower options.
# (Normally, "minecraft:flower_pot" works with the data value to
# specify contents, but that wouldn't include the new "red_flower"
# types. Plus, a couple of oddball "plants" are possible: grey grass
# and spiderweb.)
In addition to all the new flower types added in 1.7 onward, I experimented with placing other items in the flower pot. Only web and tallgrass seemed to work (beyond the types you could already get just by specifying the data value) -- and in the case of tallgrass, it makes for a strange GRAY sort of plant. At least now I can inform Wendy that, yes, she CAN have a nice colorful selection of flower pots decorating her Ruins houses.
One minor awkward thing about this example is that I can't have a Command Block with RUINSTRIGGER that uses setblock to replace itself, so I had to place all the Command Blocks *above* the desired target point. If I had the Command Blocks *in* the desired location, the resulting block will be ERASED after execution by the RUINSTRIGGER routine. Is there any way to have the same effect as RUINSTRIGGER (i.e., automatically triggered when player gets within range), but DO NOT erase the Command Block's location? (I'd be doing that anyway if I use "setblock" to take the Command Block's place, and I just don't want the resulting block eradicated during cleanup.)
You could likely get floating islands using a recursive command block thing, since that unlike ruins does not depend on terrain. But i do not consider void worlds a 'target' for Ruins, seeing as there is literally no data to base randomized yet terrain-fitted spawning off of. This probably does add a randomized factor as request for the adjacent ruin function.
@sirtulip
None of my site's links for 164 and higher should point to dropbox anymore .. i checked, ruins downloads all work
Thanks for the reply! I see the problem, I was trying to download for 1.6.2 cause i'm still using a few mods from that (some haven't been updated yet). I tried downloading all the ruins mod and all of them downloaded Aside from 1.6.2 and 1.5.2, those that didn't have the dropbox issue. I tried downloading it with chrome. If you're willing/able to post a new 1.6.2 download link, I could try out this mod in 1.7.2 or 1.6.4 and if it's to my fancy, then i could request you post a new 1.6.2 download link. Let me know tho. No worries either way cause i'll get to 1.6.4+ eventually haha
/gamerule commandBlockOutput false
I should probably put that in the "readme" for my ZIP collections. That's a nice idea about including a special message, though -- I should try doing that! (Deliberate messages will still display even with the "silent" setting; it just eliminates the otherwise automated chat messages.)
--- 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)
14.2
+ improved undo command to only save ruin sites BEFORE actually spawning ruins
+ /testruin now also allows to replace the specified y coordinate with "_", which signals Ruins to find a suitable y for given x,z
+ with exactly the same behaviour (flying, underground...) a randomly spawning template would display
+ this y specification may NOT be combined with "~", aka "_~2" will NOT work
Oops! I was going by template_rules.txt (in subfolder examplesAndDocs) where I've been getting most of my instructions regarding the new features included.
I hate to ask dumb questions, but where can I find the changelog? In readme.txt, it says "Version: see changelog in mod file" but I haven't been able to figure that out. I've tried opening the .jar file itself in WordPad, but that's not in ASCII, so that doesn't work, either. I've tried looking on the Ruins download site, but I haven't noticed any tabs that indicate a changelog.
I just did a Google search on "Minecraft uniqueMinDistance" and found a page titled "atomicstrykers-minecraft-mods" on code.google.com, which appears to have source information on it.
And regards the changes: HURRAH! And so amazingly fast, too! As soon as I get the chance, I'm going to download the latest version and give this a try. Also, I'll experiment with uniqueMinDistance.
(EDIT: I found a "changelog.txt" on code.google.com and it says:
12.9
+ premature optimization probably made the collision detector not work ... brute force it is
+ added world chunk logging to detect IWorldGenerator.generate being called multiple times
+ scrapped "unique" template setting because it never quite worked right. Use templateInstancesMinDistance
So I guess I should be using templateInstancesMinDistance instead of UniqueMinDistance? I'll try both and see what works.)
Thanks 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)
You'll need to open the .jar file with something like winrar or 7z to view the contents as that's where the changelog is usually hidden
Facebook Page - http://www.facebook..../Landofdraconis
IRC - http://webchat.esper.net/?channels=TolkienCraftII
Thanks! I still have a lot to learn about how these mods work.
uniqueMinDistance indeed does the trick, and I've applied it to things like the walled desert village, the great sphinx, etc., and re-uploaded a few of my structure bundles. I found that it's actually mentioned in the template_rules.txt document, further down than the "unique" reference ... right next to the reference about "preventRotation." (Aha! That should be useful for dealing with the double-door flipping problem, too. I'm embarrassed that I didn't notice that earlier.)
/undoruin works again -- yay! There's an odd glitch if the ruin had spawned on a sharp slope with "basement" levels extending outside the slope -- and those layers are still partially present in any area that had been "air" before the /testruin spawn -- but that's a rare situation anyway, so for most cases it works perfectly now.
I've also tested out the "_" feature for /testruin and I've found that it's very handy not only for attempting to build villages. With this feature, I can zoom around in the air in Creative Mode and plant structures beneath me (e.g., /testruin CastleOfDoom ~0 _ ~0) and it'll nicely spawn on the ground BELOW me. This is very useful in cases where using /testruin to spawn something would cause my in-game character to become encased in solid stone or some-such, forcing me to break blocks just to get out again, or if I just want to zoom along and plant several different structures at once in a throwaway test world simply because I want to see what they look like and make comparisons. Convenient!
--- 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)
The "meta" structure (which I placed in the "plains" sub-folder) consists of the central village well with a bunch of Command Blocks piled on top, with "RUINSTRIGGER" to set them off once the player gets within range. Then ... the cursed village appears!
The individual structures are based off of the "vanilla" village structures, but with "ruined" touches such as missing blocks, cobwebs, etc. -- plus a few spawners for special villager zombies (and a nasty skeletal watchman) that are persistent and beefed up past the normal profile. Note that in the picture, there is a pool right in the middle of town, near the central well; normally there would be a church/watchtower that spawns there, but the pool made it an invalid building point, so that building simply didn't spawn; the rest continued as normal.
Since this uses the new "_" self-calculating "Y" feature for positioning, it's a lot easier for Ruins to find a valid building spot for the central well (just a footprint of 4x4, after all), and then the surrounding buildings match the terrain (more or less). I couldn't figure out a way to make the gravel roads (that's well beyond the mechanics for Ruins mod, I think), but it IS a ruined village, after all, so I suppose it only makes sense that the roads are overgrown. It sometimes gets a bit wacky when the village spawns in the vicinity of a ravine or a cliff, but I've tried to minimize that by keeping the "biomesToSpawnIn" in relatively shallow-terrain biomes.
--- 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)
If you have some more suggestions or wishes, post em, so i can include or reject them in the design.
Okay nevermind, it didn't generate until I loaded a world first.
Like the Cursed Village, this requires taking the pieces and putting them in their proper folders. (ZIP file contained in Dropbox folder, linked in my signature below.) The WarTower1Base_1v7v10.tml file goes in the Plains biome (or whatever biome you want this thing spawning in), while the remaining templates in this bundle actually go into the templateparser sub-folder. The idea behind this is that an evil sorcerer has a magical tower that doesn't quite exist in the material plane; in order to reach his inner sanctum where he performs experiments to create unnatural life from the elements and living materials, one must advance through the tower, defeating his animated golems along the way. At the top of each segment, a portal is disguised as a humble chest; opening it reveals the next tower segment (and its guardians).
I intended this to be a mini-dungeon for multiple players, though I suppose depending upon what mods you have installed and how well equipped you are, you COULD tackle it alone. (I tested it myself, going solo with diamond equipment, and it was a bit of a challenge just charging in and fighting, so I ended up using various tricks to pigeonhole enemies with blocks so I could take them out at range at my leisure.)
--- 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)
(Disclaimer: AtomicStryker is of course the expert on these things. I'm only writing here based on my own experience and opinions.)
It sounds as if you have indeed gotten a few structures (empty barn, cobble structure, etc.), but just not particular ones you were hoping for? Which ones are you hoping for in particular?
One thing you could do is that if you are getting structures you DO NOT want in your world, versus the ones you want -- and if you actually know which ones you DO want -- you could go into the appropriate folders and simply remove the unwanted structures, or else disable them by setting their weight to "0." After all, every unwanted structure that spawns represents a place where maybe something you DID want could have spawned there instead.
Structure Testing:
Otherwise, if you are concerned that certain structures you are hoping for are simply NOT SPAWNING AT ALL -- well, testing for that is something I've been doing for my own homemade structures. First, I would create a "superflat" world, and make sure that my desired structures are loaded into the "plains" folder (and that any unwanted ones are out of the picture). This is a pretty good test to make sure that under IDEAL conditions (and a "superflat" is about as ideal as you can hope for) the structure will eventually spawn, if you explore far enough. If you spawn a Superflat world, you might try experimenting with the presets to try a "desert" or "water" world, to change up the biome, to see some of the structures that would not normally spawn in the Plains biome (that a superflat world normally defaults to). This is a fairly fast way to get a "grand tour" if all you want to do is check out structures.
If it shows up, that means that it's at least theoretically possible for it to show up.
If it DOES NOT, then my next step would be to remove ALL other structures (and put them into some sort of temporary holding area), and have ONLY that one structure in the plains folder, and open up another superflat world. (Please note: If you make any changes to the biomes folders, you will need to QUIT the game and then reenter it to see any difference when exploring.) If your desired structure is the ONLY choice and yet it STILL does not spawn, then that means something is wrong with that template, and it will have to be "debugged." (Maybe it has "acceptable_target_blocks" that don't match the terrain, for instance. Or maybe there's an error in it, so it never loads properly.)
/testruin Exploration:
If all you want to do is see what a particular template looks like (to see if it's something you really want spawning in your Minecraft world or not), one way to do it is to grab it from whatever folder it normally appears in, drop it in /templateparser folder, then use the /testruin command in Creative mode to force it to appear. If it fails to spawn right then and there, that's a fair indication that the template is simply broken. Otherwise, it should give you a good idea of what it's like. Note that with /testruin, you can now specify relative coordinates. So in Creative mode, you could fly up into the sky, and type something like "/testruin MagicCastle ~0 _ ~0" -- and this should spawn it somewhere directly beneath you (if, that is, you're high enough!) but at ground level so you can see how it normally spawns in a world. (Otherwise, if you don't specify any dimensions, it will tend to spawn right on top of you, which might mean you have to break your way out of a couple of blocks first before you can take a look at the whole thing.)
Back to Regular Minecraft Terrain:
Now, just because a structure will spawn in a superflat world does not mean that it will necessarily spawn with the same frequency in a regular Minecraft world with normal terrain. I have noticed that even though new changes to the Ruins mod make it a lot easier to get a structure to spawn (for instance, the ability to simply leave out "acceptable_target_blocks" and let it accept ANYTHING -- except water or lava -- by default), but structures with a big "footprint" (large X/Z dimensions) tend to have a harder time finding a valid space to spawn. Structures that have "max_leveling" set to a higher value tend to get a lot more leeway on this, but even then, I find that it's hard to get a large, wide structure to spawn in certain environments such as, say, jungle. Structures with "max_leveling" set to zero seem to have a comparatively hard time finding valid places to spawn, even if I set the acceptable "overhang" to a high number. By contrast, if you have a structure that consists of nothing more than a single column of blocks stretching to some ridiculous height, it'll still be fairly easy for the program to find a valid spot to place it, since there's no slope to worry about.
Some structures WILL spawn eventually, but the Ruins mod just has a rougher time finding a valid building spot for them, so you may not see them until you've explored a LOT of area, or you've just gotten very lucky. Structures that spawn in Plains, Desert or Ocean tend to have a relatively easy time spawning. For wooded areas, structures that have "preserve_plants" set to 1 (or "yes") tend to have an easier time finding a valid place to spawn, but it's still no guarantee. There are some structures that you'll see all over the place on a Superflat world that I've failed to find even once in a pretty widely-explored multi-player server regular-terrain world (because, say, there was no max_leveling set, no preserve_plants, it only spawns in a single specific biome and we've got our server loaded up with a bazillion custom biomes, it has a really big footprint, etc.).
--- 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)
Crops are wine and tobacco from the Psychedelicraft mod (plus something a little greener hidden around back). Interior also includes furnishings from MrCrayfishFurnitureMod. 2 chests inside with random loot and 1 chest with one of 4 possible contents, all Psychedelicraft finished items. I spent the rest of the night creating small ruins that use the "one of x treasure chests of your choosing" feature. Buried beach treasure was my next ruin. Weird walls are alternating stairs and upside down stairs, roof is slabs (so that monsters can't spawn on the roof).
The tml contents:
# WBHWineCottage01.tml
# Created by Ruins mod version 14.1 Ingame Parser
# authoring Player: WildBluntHickok
# Requires: Ruins, Psychedelicraft, MrCrayfishFurnitureMod
weight=1
embed_into_distance=1
acceptable_target_blocks=
unacceptable_target_blocks=flowing_water,water,flowing_lava,lava
dimensions=5,22,16
allowable_overhang=2
max_leveling=2
leveling_buffer=0
preserve_water=0
preserve_lava=0
preventRotation=1
rule1=0,100,preserveBlock
rule2=0,100,minecraft:farmland-7
rule3=0,100,minecraft:water-0
rule4=0,100,minecraft:log-8
rule5=0,100,minecraft:quartz_block-0
rule6=0,100,minecraft:crafting_table-0
rule7=0,100,IInventory;minecraft:chest;psychedelicraft:smokingPipe#1#0#0+psychedelicraft:coffeeBeans#8#0#4+psychedelicraft:syringe#1#2#8+psychedelicraft:harmonium#4#0#11+psychedelicraft:psycheWoodenBowl#8#0#13+psychedelicraft:harmonium#2#1#15+psychedelicraft:harmonium#2#10#17+psychedelicraft:peyoteJoint#13#0#18+psychedelicraft:harmonium#3#7#21+psychedelicraft:coffeeBeans#8#0#22+psychedelicraft:harmonium#3#9#23-3,IInventory;minecraft:chest;psychedelicraft:smokingPipe#1#0#0+psychedelicraft:glassChalice#1#0#2+psychedelicraft:juniperBerries#1#0#3+minecraft:sugar#1#0#4+psychedelicraft:juniperBerries#1#0#5+psychedelicraft:driedPeyote#4#0#7+psychedelicraft:harmonium#4#0#11+psychedelicraft:wineGrapes#1#0#12+minecraft:wheat#1#0#13+psychedelicraft:wineGrapes#1#0#14+psychedelicraft:harmonium#2#1#15+psychedelicraft:woodenMug#4#0#16+psychedelicraft:harmonium#2#10#17+psychedelicraft:brownMagicMushrooms#8#0#18+psychedelicraft:redMagicMushrooms#8#0#19+minecraft:planks#1#0#21+minecraft:water_bucket#1#0#22+minecraft:planks#1#0#23+psychedelicraft:driedPeyote#4#0#25-3,IInventory;minecraft:chest;psychedelicraft:smokingPipe#1#0#0+psychedelicraft:cigar#1#0#1+minecraft:wheat#1#0#3+minecraft:wheat#1#0#4+minecraft:wheat#1#0#5+psychedelicraft:harmonium#4#5#6+psychedelicraft:harmonium#2#3#7+psychedelicraft:cigar#1#0#9+psychedelicraft:cigar#1#0#10+psychedelicraft:harmonium#4#0#11+minecraft:wheat#1#0#12+minecraft:wheat#1#0#13+minecraft:wheat#1#0#14+psychedelicraft:harmonium#4#1#15+psychedelicraft:harmonium#8#14#16+psychedelicraft:driedTobacco#4#0#18+minecraft:glowstone_dust#4#0#19+minecraft:dye#4#6#20+minecraft:planks#1#0#21+minecraft:water_bucket#1#0#22+minecraft:planks#1#0#23+psychedelicraft:harmonium#2#13#24+psychedelicraft:harmonium#4#10#25-3,IInventory;minecraft:chest;psychedelicraft:smokingPipe#1#0#0+psychedelicraft:driedPeyote#6#0#4+psychedelicraft:cigar#1#0#8+psychedelicraft:coffeeBeans#12#0#10+psychedelicraft:harmonium#4#0#11+minecraft:bowl#6#0#13+psychedelicraft:harmonium#2#1#15+psychedelicraft:harmonium#2#10#17+psychedelicraft:woodenMug#6#0#19+psychedelicraft:driedPeyote#6#0#22-3
rule8=0,100,psychedelicraft:cannabisPlant-15
rule9=0,100,psychedelicraft:dryingTable-0
rule10=0,100,minecraft:spruce_stairs-0
rule11=0,100,minecraft:spruce_stairs-2
rule12=0,100,minecraft:bed-10
rule13=0,100,minecraft:bed-2
rule14=0,100,minecraft:planks-0
rule15=0,100,ChestGenHook:pyramidDesertyChest:5-3
rule16=0,100,cfm:bedsidecabinet-0
rule17=0,100,cfm:bath1-0
rule18=0,100,cfm:bath2-0
rule19=0,100,minecraft:spruce_stairs-3
rule20=0,100,minecraft:bed-0
rule21=0,100,minecraft:bed-8
rule22=0,100,cfm:basin-0
rule23=0,100,ChestGenHook:dungeonChest:5-4
rule24=0,100,cfm:toilet-0
rule25=0,100,minecraft:wooden_door-2
rule26=0,100,cfm:couchbrown-2
rule27=0,100,minecraft:carpet-4
rule28=0,100,minecraft:carpet-0
rule29=0,100,minecraft:log-0
rule30=0,100,cfm:oven-0
rule31=0,100,cfm:freezer-0
rule32=0,100,minecraft:spruce_stairs-1
rule33=0,100,minecraft:carpet-14
rule34=0,100,psychedelicraft:wineGrapeLattice-8
rule35=0,100,psychedelicraft:tobaccoPlant-14
rule36=0,100,minecraft:spruce_stairs-4
rule37=0,100,minecraft:stained_glass-8
rule38=0,100,minecraft:spruce_stairs-6
rule39=2,100,minecraft:torch-1
rule40=0,100,cfm:blindon-1
rule41=0,100,minecraft:spruce_stairs-7
rule42=0,100,cfm:blindon-2
rule43=2,100,minecraft:torch-4
rule44=2,100,minecraft:torch-3
rule45=0,100,minecraft:wooden_door-8
rule46=0,100,cfm:blindon-0
rule47=2,100,minecraft:torch-2
rule48=0,100,cfm:blindon-3
rule49=0,100,minecraft:wooden_door-9
rule50=0,100,cfm:fridge-0
rule51=0,100,minecraft:spruce_stairs-5
rule52=0,100,psychedelicraft:tobaccoPlant-15
rule53=0,100,psychedelicraft:cannabisPlant-11
rule54=0,100,IInventory;minecraft:furnace;minecraft:rotten_flesh#4#0#0+minecraft:coal#3#0#1-2
rule55=0,100,IInventory;minecraft:furnace;minecraft:rotten_flesh#3#0#0+minecraft:coal#3#0#1-2
rule56=0,100,cfm:cabinet-0
rule57=0,100,preserveBlock
rule58=0,100,minecraft:wooden_slab-1
layer
1,1,1,1,1,1,1,1,2,2,2,2,2,2,2,1
1,1,1,1,1,1,1,1,2,2,2,2,2,2,2,1
1,4,4,4,4,4,4,4,3,3,3,3,3,3,3,1
1,4,5,5,4,4,4,4,4,4,4,4,4,4,4,1
1,4,5,5,4,4,4,4,4,4,4,4,4,4,4,1
1,4,5,5,4,4,4,4,4,4,4,4,4,4,4,1
1,4,4,5,4,4,4,4,4,4,4,4,4,4,4,1
1,4,4,4,4,4,4,4,4,4,4,4,4,4,4,1
1,4,4,6,4,4,4,4,4,4,4,4,4,4,4,1
1,4,4,4,4,4,4,4,4,4,4,4,4,4,4,1
1,4,4,4,4,4,4,4,4,4,4,4,4,4,4,1
1,4,4,4,4,4,4,4,4,4,4,4,4,4,4,1
1,4,4,4,4,4,4,1,1,4,4,4,4,4,4,1
1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
1,1,1,1,1,3,2,2,2,2,3,1,1,1,1,1
1,1,1,1,1,3,2,2,2,2,3,1,1,1,1,1
1,1,1,1,1,3,2,2,2,2,3,1,1,1,1,1
1,1,1,1,1,3,2,2,2,2,3,1,1,1,1,1
1,1,1,1,1,3,2,2,2,2,3,1,1,1,1,1
1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
endlayer
layer
0,0,0,0,0,0,0,0,8,8,8,8,8,8,8,0
0,0,9,0,9,0,0,0,8,8,8,8,8,8,8,0
0,10,10,10,10,10,10,10,10,10,10,10,10,10,10,0
0,19,18,17,14,16,0,0,7,14,0,0,13,12,11,0
0,19,22,0,14,21,20,0,0,14,0,0,0,0,11,0
0,19,24,0,14,0,0,0,15,14,0,0,0,23,11,0
0,19,14,25,14,14,14,25,14,14,14,25,14,14,11,0
0,19,0,0,0,0,0,0,0,0,0,0,0,0,11,0
0,19,29,0,0,0,0,0,0,0,28,27,0,26,11,0
0,19,30,0,0,0,0,0,0,0,28,27,0,26,11,0
0,19,29,0,0,0,0,0,0,0,28,27,0,26,11,0
0,19,31,0,0,0,0,25,25,0,0,0,0,0,11,0
0,32,32,32,32,32,32,33,33,32,32,32,32,32,11,0
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
34,0,34,0,34,0,35,35,35,35,0,34,0,34,0,34
34,0,34,0,34,0,35,35,35,35,0,34,0,34,0,34
34,0,34,0,34,0,35,35,35,35,0,34,0,34,0,34
34,0,34,0,34,0,35,35,35,35,0,34,0,34,0,34
34,0,34,0,34,0,35,35,35,35,0,34,0,34,0,34
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
endlayer
layer
0,0,0,0,0,0,0,0,8,8,8,8,8,8,8,0
0,0,0,0,0,0,0,0,8,8,8,8,8,8,8,0
0,36,36,36,36,36,37,36,36,36,36,36,36,36,36,0
0,41,0,0,14,0,40,39,0,14,0,0,0,0,38,0
0,41,0,44,14,0,0,0,0,14,43,0,0,42,37,0
0,41,0,0,14,0,0,0,0,14,0,0,0,0,38,0
0,41,14,45,14,14,14,45,14,14,14,45,14,14,38,0
0,41,0,0,0,0,39,0,0,0,39,0,39,0,38,0
0,41,0,0,0,0,0,0,0,0,0,0,0,0,38,0
0,37,46,0,0,0,0,0,0,0,0,0,0,42,37,0
0,41,0,0,0,0,0,0,0,0,0,0,0,0,38,0
0,41,50,0,47,48,0,45,49,0,48,47,0,0,38,0
0,41,51,51,51,37,51,0,0,51,37,51,51,51,51,0
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
34,0,34,0,34,0,52,52,52,52,0,34,0,34,0,34
34,0,34,0,34,0,52,52,52,52,0,34,0,34,0,34
34,0,34,0,34,0,52,52,52,52,0,34,0,34,0,34
34,0,34,0,34,0,52,52,52,52,0,34,0,34,0,34
34,0,34,0,34,0,52,52,52,52,0,34,0,34,0,34
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
endlayer
layer
0,0,0,0,0,0,0,0,53,53,53,53,53,53,53,0
0,0,0,0,0,0,0,0,53,53,53,53,53,53,53,0
0,10,10,10,10,10,10,10,10,10,10,10,10,10,10,0
0,19,0,0,14,0,0,0,0,14,0,0,0,0,11,0
0,19,0,0,14,0,0,0,0,14,0,0,0,0,11,0
0,19,0,0,14,0,0,0,0,14,0,0,0,0,11,0
0,19,14,14,14,14,14,14,14,14,14,14,14,14,11,0
0,19,54,39,0,0,0,0,0,0,0,0,0,0,11,0
0,19,55,0,0,0,0,0,0,0,0,0,0,0,11,0
0,19,43,0,0,0,0,0,0,0,0,0,0,44,11,0
0,19,56,0,0,0,0,0,0,0,0,0,0,0,11,0
0,19,56,0,0,0,0,0,0,0,0,0,0,0,11,0
0,32,32,32,32,32,32,32,32,32,32,32,32,32,11,0
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
endlayer
layer
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
0,0,58,58,58,58,58,58,58,58,58,58,58,58,0,0
0,0,58,58,58,58,58,58,58,58,58,58,58,58,0,0
0,0,58,58,58,58,58,58,58,58,58,58,58,58,0,0
0,0,58,58,58,58,58,58,58,58,58,58,58,58,0,0
0,0,58,58,58,58,58,58,58,58,58,58,58,58,0,0
0,0,58,58,58,58,58,58,58,58,58,58,58,58,0,0
0,0,58,58,58,58,58,58,58,58,58,58,58,58,0,0
0,0,58,58,58,58,58,58,58,58,58,58,58,58,0,0
0,0,58,58,58,58,58,58,58,58,58,58,58,58,0,0
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
endlayer
The core structure is a mausoleum standing atop a spiral staircase. It has a fairly small footprint, and I specified it to only attempt to spawn in Plains, Savanna, and a few similar biomes, so it should have fairly high chances of spawning successfully. Command Blocks with "RUINSTRIGGER" keys then fire off, attempting to place other (optional) structures to expand the layout. If NOTHING else spawns, at least there's an interesting structure and a few monsters to clobber.
On the surface, a "Graveyard Wall" structure attempts to provide a border to a surface graveyard, though it uses the "supported by" rules so that if part of it spawns on a crevice/pit, or a too-sharp slope, sections of the wall just won't spawn at all (or the wall might not find a valid build point if it's too close to water or lava). A few individual grave stones with randomized features and epitaphs spawn using the "calculated Y" feature, to go along with surface terrain. A couple of trees are spawned as well (if valid build points are found), with twisty root structures that can cut through some of the underground structures' walls for a run-down look.
Individual modular dungeon/catacomb rooms and passages are spawned via more Command Blocks with the RUINSTRIGGER key. These don't use the calculated Y placement, and instead are just relative to the core central structure, so they seem to have better chances of spawning (since they aren't checking for surface blocks and such). Several of the branching passages open onto solid rock, dirt, or whatever material the ground is made of, meaning that there's a chance of a solid stone wall at a dead-end, or perhaps some exposed ore, maybe a flooded passage, a lava flow, or even an opening into a cavern. (I actually ended up with passages going right into caves quite a few times during testing ... bolstering my opinion that there are simply TOO MANY CAVES in vanilla Minecraft. )
If all structures spawn successfully, then there's a simple layout (shown on an all-glass superflat custom world above) with a few traps, custom monster spawners, and treasures. I tried to spruce up the interiors so it's not just some boring collection of cobblestone boxes, but rather a place that I hope is worth checking out for the sights and not just the loot.
Theoretically, another dungeon could be made by taking the same core structure and changing out the command blocks to call the sub-structures in a different arrangement. As with my other "meta" structures, the core structure has to be in the appropriate biomes folder (I put it in "plains"), but the sub-structures have to be in the templateparser folder so they can be called in turn.
--- 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've been thinking about this post (i.e., suggestions or wishes to state), and I figured I'd wait until I actually saw some of my projects through to something resembling completion, to see if anything in particular comes up. DISCLAIMER: I am very happy with this mod! This is just a brainstorm of suggestions for things that would be "nice to have" in the future -- not a gripe list. It's amazing what can be done with the Ruins mod already.
Common Point of Origin:
Right now, my structures require me to use Command Blocks, and each Command Block can handle only ONE command, and each block has to be in a different position, so all my relativistic ~X ~Y ~Z coordinates have to take into account the varying location of the originating block. I wish there were some way I could get the effect of executing several Command Blocks from ONE location, in sequence (each one being replaced in turn), whether it's to fire off /testruins commands or customized /summon commands or whatever.
---------------------
Formatted Randomized Choices:
I would also find it useful if the template offered a format that made randomized choices legible and easy to work with. Right now, I can put several different options on the same "rule" line, separated by commas. I've had problems before where some of my code would fail because I had a rogue space in the middle of the command line, so apparently I can't just insert "carriage returns" or spacing in order to make things more legible. (Please correct me if I'm wrong on this! I'd check right now to be sure, but I'm in no position to do so at the moment.)
Expanded explanation put behind spoilers, because I tend to ramble:
If I'm populating a city with buildings (or custom villagers!) or making a dungeon layout (where I probably should stick to some sort of modular standard, such as 16x16 segments, for easier mixing and matching), it'd be nice if I could list several options in a readable, easy-to-follow sequence.
E.g. (I'm just making this up -- and I'm assuming that anything in this format will be automatically fired off as per RUINSTRIGGER, and that ":@" is assumed at the end):
START COMMAND1
[Option1:/testruin VillageForge ~12 _ ~12 1]
[Option2:/testruin VillageWatchtower ~14 _ ~14]
[Option3:/testruin VillageChurch ~14 _ ~12]
END COMMAND1
...
----------------
Some Way to Make Those Gravel (or other) Roads:
Okay, the thing about the gravel roads that spawn with villages is that the /top layer/ of the existing terrain is replaced with gravel ... unless the top layer happens to be water or lava, that is, and it treats trees like they aren't even there, I think.
Another rambling idea about how this might be done.
I'm just brainstorming here, since I don't know enough to know what's even possible with the existing code, but just for the sake of argument, let's imagine a new template field called "followTerrain" which normally defaults to 0 or false.
If a template is set to "followTerrain=1" (true), then perhaps the mechanics of how the structure is placed change. max_leveling is ignored. acceptable_target_blocks and unacceptable_target_blocks are NOT used to determine whether the template can spawn there at all. Instead, they are used to determine WHICH target blocks are affected within the designated build area.
So, let's imagine a sample "structure" in this form has a layout such as:
acceptable_target_blocks=dirt,grass,stone,sand,gravel
embed_into_distance=2
preserve_plants=1
rule1=0,100,preserveBlock
rule2=1,100,minecraft:gravel
rule3=1,100,minecraft:cobblestone
layer
1,1,1,1,1,1,2,2,1,1,1,1,1,1
1,1,1,1,1,1,2,2,1,1,1,1,1,1
1,1,1,1,1,1,2,2,1,1,1,1,1,1
2,2,2,2,2,2,2,2,2,2,2,2,2,2
2,2,2,2,2,2,2,2,2,2,2,2,2,2
1,1,1,1,1,1,2,2,1,1,1,1,1,1
1,1,1,1,1,1,2,2,1,1,1,1,1,1
1,1,1,1,1,1,2,2,1,1,1,1,1,1
endlayer
layer
1,1,1,1,1,1,3,3,1,1,1,1,1,1
1,1,1,1,1,1,3,3,1,1,1,1,1,1
1,1,1,1,1,1,3,3,1,1,1,1,1,1
3,3,3,3,3,3,3,3,3,3,3,3,3,3
3,3,3,3,3,3,3,3,3,3,3,3,3,3
1,1,1,1,1,1,3,3,1,1,1,1,1,1
1,1,1,1,1,1,3,3,1,1,1,1,1,1
1,1,1,1,1,1,3,3,1,1,1,1,1,1
endlayer
... Then, for each X,Z position in this structure, it replaces the top two layers (for this "structure" is two layers deep) as per these rules. So we'd end up with the top layers in all the "1" positions being totally untouched. Lava, water, and pre-existing structures (built of cobblestone, wood planks, etc.) don't have top layers within the "acceptable_target_block" list, so any such spaces simply won't be touched, but the template will carry right along for other, valid spots of the building zone. It's set to preserve_plants=yes, so trees won't have their top layers replaced with gravel or cobblestone. But wherever there's dirt or grass or stone, the top layer (following the terrain) will be gravel, with an underbed of cobblestone.
For any rules with less than 100 percent chance of spawning the block, the existing block is left intact if the replacement block doesn't spawn.
This structure (or something like it -- probably BIGGER -- could be laid down to form the "road" for the heart of a village, likely placed BEFORE the village well or any other buildings are added.
Since the template can be specified, the builder could choose whether to go with traditional gravel (or sandstone for desert villages), or whether this town will be paved with stone slabs or upturned wooden log segments or even GOLD (though that would be terribly cheesy). Or, someone could, on a lark, have a "structure" that just consists of a giant "X" branded on the landscape (following the contours of a hill or even a cliff) with blocks of moldy cobblestone, and perhaps on the bottom-most layer there is a buried chest right at the center.
Anyway, that is just my attempt to imagine how such a solution might work, if it were possible.
------------
Forced Air Blocks:
I was thinking about having a "Sunken Atlantean City" with some breathable spaces inside. This is presently a bit tricky. I have a few ideas for how to do this with Command Blocks, but....
preserve_lava, preserve_water, and preserve_plants are very handy for getting ruins to spawn in places they wouldn't otherwise (buildings in forested areas, sunken shipwrecks, etc.). The trouble is that there are times when I honestly, seriously, want a block to spawn as empty AIR rather than whatever is being "preserved." (Say, an underwater sunken shipwreck, and I want an "air pocket" inside, or a forest house and there are some spots where I DON'T want trees growing right through this particular spot.)
It would be nice to have an "Empty" rule. Say, rule2=0,100,Empty -- and no matter what's being "preserved," this spot is going to be EMPTY (air) once the structure spawns -- not water, not lava, not tree trunk.
Presently, I try to work around this with various "tricks," such as putting string/tripwire, vines, signs, doors, etc., into a space where I don't want water for an "air pocket" in some underwater observatory. Or, I could skip preserve_water and just treat the surface of the water as my target blocks ... but that means my structure is going to be a SPECIFIC number of blocks embed_into_distance regardless of the actual ocean depth in that location. Some sort of specific "Air" rule would be convenient for situations like this (however rare).
------------
Auto-growth Trees & Mushrooms:
I'd like to dot my village, graveyard, faerie ring, ruin, or what-have-you with trees, either for that overgrown ruin look, or just because I'd like some nice shade. I can do that at present by using /parseruin on a complete tree, but in-game it's a whole lot easier to just plant a sapling and apply bonemeal to it, whereas a Ruins structure needs to clear out the surrounding terrain, or find a fairly flat place to build in. I don't want my tree to be based on water or lava, but it really only needs one (or maybe 4) blocks of dirt to base the trunk on -- not the ENTIRE footprint.
I could imagine some new format -- say "rule1=1,100,Ggrow:minecraft:sapling-1" -- that will plant a sapling or mushroom, and then hit it with however many doses of bone meal it takes to get it to grow (IF, that is, it's in a legitimate spot to grow, with enough headroom, light, etc. -- though honestly I wouldn't mind bypassing some of those limitations).
Either that ... or is there a CommandBlock command I could use to apply "bone meal" growth to a particular location?
--------
Required Target Block:
Okay, let's say I want to make a "dock" structure. I set the biomes to something like ocean or beach, or both. For acceptable_target_blocks, well, sand is okay, and water is okay. The trouble is that I don't want my dock built in the middle of a big sandy expanse (nowhere near water) ... and I also don't want it floating in the middle of the ocean. Ideally, I want it touching BOTH.
Hence, a "required_target_blocks" field might be handy. Say, "required_target_blocks=sand,water" tells it that SOMEWHERE in the building zone, there must be AT LEAST one water block, and there must be AT LEAST one sand block. Beyond that, it might be gravel or stone or grass or whatever that still falls under the "acceptable_target_blocks," or maybe I just don't care, but at least this way my odds are greatly improved that the dock will end up somewhere near the shoreline (but not completely upon dry land).
---------
Paintings, Item Frames, Mine Carts, Boats:
I think it's at least theoretically possible to spawn paintings, mine carts, etc., via Command Blocks. That's on my list of things to experiment with. However, any features that might make it easier to add paintings, item frames, and other decorative entities to a structure would be handy -- especially since Command Blocks require specific relative positions, but if the structure gets ROTATED, those relative positions might not make sense anymore. (For this reason, I tend to place Command Blocks either directly below or directly above the target point for whatever's to be summoned or setblocked.)
---------
Flower Pots:
No village is complete without flower pots! ... Or something like that. Presently, /parseruin doesn't seem to quite get it right when I include flower pots as part of a structure. It generates a flower_pot block with a data value that, when spawned, usually ends up with something different from what I started with in the original structure. I think this is because the rules changed at some point for flower_pots, and they use tile entity data now (although the old data values appear to still work for the original possible contents). Either /parseruin needs to at least match up to produce the proper data values (for whatever valid plants are within that range), or else a new "FlowerPot" function (similar to the Skull function) would be handy to allow for specifying the tile entity data to go along with the flower_pot block.
Honestly, this isn't a terribly pressing thing, but Wendy REALLY likes adding lots of colorful flower pots to her structures, so I had to list it.
---
Once again, I'm very happy with the mod's current functionality, and thankful for the continued updates. This is just a list of brainstormed ideas for "nice to have" things for some future iterations.
--- 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 can offer something beyond RUINSTRIGGER, like RUINSAFTERSPAWN, which does not require a player coming near (although, does a tree exist if nobody sees it?)
hmmm you want a template blocks to "fall like snow" onto/into a given landscape ... well i could make a new rule for this i guess (or you could use gravel)
"air" is a perfectly valid block rule you should use
auto-growing trees should be possible with command blocks, or i could loop all growable blocks? hm
required target blocks across area is an unsolved computer science problem and if i had an efficient implementation of this i'd win prices for it
no to everything that involves tile entities or entity data. Use command blocks.
Yay!
>>> i can offer something beyond RUINSTRIGGER, like RUINSAFTERSPAWN, which does not require a player coming near (although, does a tree exist if nobody sees it?)
Hee! Well, the player would have to at least be close enough to force terrain generation, so it's possible it might be seen in the distance?
By the way -- how does the RUINSTRIGGER work? Or, that is, how close must a player be before it triggers, and is there any sort of time delay involved? Not that it matters that much -- I'm just curious.
>>> hmmm you want a template blocks to "fall like snow" onto/into a given landscape ... well i could make a new rule for this i guess (or you could use gravel)
I tried just spawning gravel in the air, and letting it drop, but the results weren't quite right, since the gravel would just land on TOP of whatever is already there -- not quite like standard village generation.
Maybe a rule would work where the number indicates, "Whatever layer this block is on, spawn it on the top-most layer of the terrain, replacing the top-most non-air block." If the "preserve" rules are used (plants, lava, or water), those blocks are treated as "air" for such purposes, and hence the block won't spawn there. Thus, you could make a single-layer template that specifies the layout for a gravel village road, etc.
Or, another possibility would be a rule that specifies, "Only place this block if it would replace a non-air block." Again, water, lava, and plants would be treated as "air" if the appropriate preserve rules are used. You could make a multi-layer structure of gravel this way to specify a layout, and only the parts that would be replacing dirt/stone would spawn. (On the downside, the gravel road would be a lot thicker than it necessarily needs to be in parts.) This same rule could be useful for doing stuff like spawning custom ore deposits, or replacing a section of ground with, say, a spot of sand, or maybe creating some sort of "comet impact crater."
Related to that last bit, it might be nice to have a rule of "Only place this block if it would replace an AIR block," similar to the "keep" rule for the /setblock command. (And again, lava, water, and plants would be treated as "air" under the appropriate preserve rules.) This would be useful for stuff like where you want to have a boardwalk or other raised platform with supports that go down to ground level, but don't necessarily go down any further than that.
I regret that I don't really know the procedures here, so I don't know what "rules" would be feasible, or which ones would just be a nightmare to program.
>>> "air" is a perfectly valid block rule you should use
Huh. I thought I'd tried that before, but that might have been back in version 1.6.4 (when I would have really been indicating "0" since that was still done in numbers). I will give that another go. Thanks.
>>> auto-growing trees should be possible with command blocks, or i could loop all growable blocks? hm
I can't seem to find any /commands that might apply to this, but after thinking it over, I really could just make a template that consists of JUST a tree, with all "air" blocks in the template replaced by "preserveBlock," and then call it with /testruin.
So I guess the functionality is effectively already there, so long as I put the appropriate template in the /templateparser folder. I should have thought this through more.
>>> required target blocks across area is an unsolved computer science problem and if i had an efficient implementation of this i'd win prices for it
Oops. Okay, I admit, that was a bit pie-in-the-sky anyway.
>>> no to everything that involves tile entities or entity data. Use command blocks.
Fair enough! I will continue experimenting with seeing what I can do with command blocks. I am thinking of seeing if I can spawn a simple house and use the preventRotation rule to keep it the same facing. The funny thing about spawning paintings with Command Blocks is that you can actually specify WHICH painting appears, so once I get past the initial hassle of lining it up with a wall, if I can get this to work, it might actually be preferable to the annoying process of trying to slap paintings onto walls the normal way.
--------------------
By the way, speaking of "pie in the sky" -- is there any way to get a Ruins structure to spawn on "void" space via acceptable_target_block settings or whatever? (Or is that something that might be codeable?) In The End (Sky biome), I've seen some of my structures spawn on the central endstone island, but nothing spawns beyond that point. I had it in mind to have "floating sky islands" that could dot the empty expanse -- perhaps even a "floating sky island" village with bridges connecting the buildings/islands -- but it seems that since there's no solid ground of any sort to build on, the Ruins mod doesn't even try.
Also, I could imagine this being useful if I ever toyed with the Mystcraft mod again, and created a "Void" age (i.e., no ground at all aside from the spawning platform and whatever you build).
Maybe if I could list "void" in acceptable_target_blocks, to indicate that I'm happy for this structure to be spawning in the middle of nowhere. (I'd just have to make sure that "embed_into_distance" has a negative value, of course.) I know there's no such thing as a "void" block, but it would seem to make more sense than listing "air" as a valid target block (since there's already plenty of THAT to go around ).
--- 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)
"Error (509)
This account's public links are generating too much traffic and have been temporarily disabled!"@sirtulip
None of my site's links for 164 and higher should point to dropbox anymore .. i checked, ruins downloads all work
I'm trying to implement pristine looking Nether Forts and Strongholds, and man would that help.
---
I make modpacks, and am an Esteemed Innovator.
Short version: Paintings won't work with Command Blocks as spawned from Ruins structures, because they require SPECIFIC X/Y/Z coordinates for the "supporting block," even if the painting itself can be spawned with relative coordinates.
Longer aimless rambling about the topic:
Apparently I can successfully spawn a painting with a Command Block (I've done so several times now in testing), but there's a catch: I must specify the tags of "TileX" "TileY" and "TileZ," which indicate what block the painting is attached to, and these CANNOT be relative coordinates. This is *in addition to* the X Y Z coordinates I specify for the painting itself. If I specify invalid coordinates (such as trying to use TileX:~0,TileY:~2,TileZ:~0 ), I get a message that the summon was successful (though nothing immediately appears), and then the painting object "pops" out of about the spot where it should have been summoned to.
I can use relative coordinates for the painting itself, but the TileX/TileY/TileZ have to be specified. (This strikes me as especially pointless, since in version 1.8, TileX/TileY/TileZ are changed to be the very location the painting is in, rather than the tile it's attached to, making the values completely redundant.)
Example of a successful command line (although of course it would only be successful if you've got a supporting block in this location and space around it):
/summon Painting ~0 ~2 ~0 {TileX:19,TileY:68,TileZ:185,Direction:3,Motive:Pool}
If I change this to relative coordinates:
/summon Painting ~0 ~2 ~0 {TileX:~-1,TileY:~2,TileZ:~0,Direction:3,Motive:Pool}
... then behavior is as described above: Successful message but no apparent painting, and then the object "pops" out of the air after a moment.
If I were to envision some ideal way that adding a painting could be handled in Ruins format, it would be something like:
rule6=0,100,Painting:3:Pool
Then, execution would be something like temporarily generating a Command Block and building the command line by plugging in the appropriate coordinates (where "3" would be the Direction, "Pool" would be Motive, and the painting coordinates and TileX, TileY and TileZ could be derived from the location of the "block," with the supporting block's location being inferred by Direction).
Direction: 0 is south, 1 is west, 2 is north, and 3 is east
So, to calculate TileX/TileY/TileZ based on X Y Z and the Direction (using "pseudo-code" here because I'm not sure how else to explain it):
TileY := Y {Regardless of facing, elevation is always going to be the same}
If Direction = 0 THEN TileX:=X, TileZ:=Z-1
If Direction = 1 THEN TileX:=X+1, TileZ:=Z
If Direction = 2 THEN TileX:=X, TileZ:=Z+1
If Direction = 3 THEN TileX:=X-1, TileZ:=Z
However, if there's any rotation at all, this all changes. :/
In version 1.8, this will all be moot, because in all cases, TileX = X, Tile Y = Y, and TileZ = Z.
Then, from that data, it'd have to cobble together the command to feed into the Command Block. Maybe if I brush up on Javascript, I could figure out a proper way to write a routine like that.
Unfortunately, I don't presently have any clever way to do calculations in the middle of specifying a command line, so for now it looks like spawning paintings in a Ruins structure via Command Blocks just isn't feasible. Also, item frames have the same problem.
Flower pots, on the other hand ... well, I managed to get those to work with "setblock." (Examples behind spoiler tag:)
# Greenhouse
# MC 1.7.10; 13 Nov 2014
# Created by Ruins mod version 14.2 Ingame Parser
# authoring Player: Jordan_Greywolf
# Note: This is just an experiment to use Command Blocks to generate
# flower pots with additional version 1.7+ flower options.
# (Normally, "minecraft:flower_pot" works with the data value to
# specify contents, but that wouldn't include the new "red_flower"
# types. Plus, a couple of oddball "plants" are possible: grey grass
# and spiderweb.)
biomesToSpawnIn=plains,sunflower plains,garden,meadow
weight=1
embed_into_distance=1
acceptable_target_blocks=
unacceptable_target_blocks=flowing_water,water,flowing_lava,lava
dimensions=10,12,12
allowable_overhang=0
max_leveling=2
leveling_buffer=0
preserve_water=0
preserve_lava=0
rule1=0,100,minecraft:log-0
rule2=0,100,minecraft:grass-0
rule3=0,100,minecraft:water-0
rule4=0,100,minecraft:glass_pane-0
rule5=0,100,minecraft:wooden_door-2
rule6=0,100,minecraft:double_plant-1
Randomized Flowers
rule7=0,100,minecraft:red_flower-0,minecraft:yellow_flower,minecraft:red_flower-1,minecraft:red_flower-2,minecraft:red_flower-3,minecraft:red_flower-4,minecraft:red_flower-5,minecraft:red_flower-6,minecraft:red_flower-7,minecraft:red_flower-8,minecraft:tallgrass-2
rule8=0,100,minecraft:double_plant-3
rule9=0,100,minecraft:glass-0
rule10=0,100,minecraft:wooden_door-3
rule11=0,100,minecraft:waterlily-0
rule12=0,100,minecraft:wooden_door-1
rule13=0,100,minecraft:double_plant-5
rule14=0,100,minecraft:double_plant-4
rule15=0,100,minecraft:wooden_door-0
rule16=0,100,minecraft:wooden_door-9
rule17=0,100,minecraft:wooden_door-8
rule18=0,100,minecraft:double_plant-11
rule19=0,100,minecraft:fence-0
rule20=0,100,minecraft:double_plant-10
# Flower Pot: Orange Tulip
rule21=0,100,CommandBlock:RUINSTRIGGER /setblock ~0 ~-1 ~0 flower_pot 0 replace {Item:38,Data:5}:@
# Flower Pot: Red Tulip
rule22=0,100,CommandBlock:RUINSTRIGGER /setblock ~0 ~-1 ~0 flower_pot 0 replace {Item:38,Data:4}:@
# Flower Pot: Azure Bluet
rule23=0,100,CommandBlock:RUINSTRIGGER /setblock ~0 ~-1 ~0 flower_pot 0 replace {Item:38,Data:3}:@
# Flower Pot: Allium
rule24=0,100,CommandBlock:RUINSTRIGGER /setblock ~0 ~-1 ~0 flower_pot 0 replace {Item:38,Data:2}:@
# Flower Pot: White Tulip
rule25=0,100,CommandBlock:RUINSTRIGGER /setblock ~0 ~-1 ~0 flower_pot 0 replace {Item:38,Data:6}:@
# Flower Pot: Red Flower / Poppy (original)
rule26=0,100,CommandBlock:RUINSTRIGGER /setblock ~0 ~-1 ~0 flower_pot 0 replace {Item:38,Data:0}:@
# Flower Pot: Pink Tulip
rule27=0,100,CommandBlock:RUINSTRIGGER /setblock ~0 ~-1 ~0 flower_pot 0 replace {Item:38,Data:7}:@
# Flower Pot: Yellow Flower (original)
rule28=0,100,CommandBlock:RUINSTRIGGER /setblock ~0 ~-1 ~0 flower_pot 0 replace {Item:37,Data:0}:@
# Flower Pot: Oxeye Daisy
rule29=0,100,CommandBlock:RUINSTRIGGER /setblock ~0 ~-1 ~0 flower_pot 0 replace {Item:38,Data:8}:@
# Flower Pot: Blue Orchid
rule30=0,100,CommandBlock:RUINSTRIGGER /setblock ~0 ~-1 ~0 flower_pot 0 replace {Item:38,Data:1}:@
# Flower Pot: Cobweb
rule31=0,100,CommandBlock:RUINSTRIGGER /setblock ~0 ~-1 ~0 flower_pot 0 replace {Item:30,Data:0}:@
# Flower Pot: Grey Grass
rule32=0,100,CommandBlock:RUINSTRIGGER /setblock ~0 ~-1 ~0 flower_pot 0 replace {Item:31,Data:1}:@
rule33=0,100,minecraft:double_plant-8
rule34=0,100,minecraft:double_plant-9
rule35=1,100,minecraft:torch-5
layer
1,1,1,1,1,1,1,1,1,1,1,1
1,2,2,2,2,1,1,2,2,2,2,1
1,2,1,1,1,1,1,1,1,1,2,1
1,2,1,2,2,1,1,2,2,1,2,1
1,2,1,2,1,1,1,1,2,1,2,1
1,1,1,1,1,3,3,1,1,1,1,1
1,1,1,1,1,3,3,1,1,1,1,1
1,2,1,2,1,1,1,1,2,1,2,1
1,2,1,2,2,1,1,2,2,1,2,1
1,2,1,1,1,1,1,1,1,1,2,1
1,2,2,2,2,1,1,2,2,2,2,1
1,1,1,1,1,1,1,1,1,1,1,1
endlayer
layer
1,4,4,4,1,5,5,1,4,4,4,1
4,8,7,7,7,0,0,7,7,7,6,4
4,7,0,0,0,0,0,0,0,0,7,4
4,7,0,9,9,0,0,9,9,0,7,4
1,7,0,9,0,0,0,0,9,0,7,1
12,0,0,0,0,11,11,0,0,0,0,10
12,0,0,0,0,11,11,0,0,0,0,10
1,7,0,9,0,0,0,0,9,0,7,1
4,7,0,9,9,0,0,9,9,0,7,4
4,7,0,0,0,0,0,0,0,0,7,4
4,14,7,7,7,0,0,7,7,7,13,4
1,4,4,4,1,15,15,1,4,4,4,1
endlayer
layer
1,4,4,4,1,17,16,1,4,4,4,1
4,20,0,0,19,0,0,19,0,0,18,4
4,0,0,0,0,0,0,0,0,0,0,4
4,0,0,24,23,0,0,22,21,0,0,4
1,19,0,26,0,0,0,0,25,0,19,1
16,0,0,0,0,0,0,0,0,0,0,17
17,0,0,0,0,0,0,0,0,0,0,16
1,19,0,28,0,0,0,0,27,0,19,1
4,0,0,32,31,0,0,30,29,0,0,4
4,0,0,0,0,0,0,0,0,0,0,4
4,34,0,0,19,0,0,19,0,0,33,4
1,4,4,4,1,16,17,1,4,4,4,1
endlayer
layer
1,1,1,1,1,1,1,1,1,1,1,1
1,0,0,0,35,0,0,35,0,0,0,1
1,0,0,0,0,0,0,0,0,0,0,1
1,0,0,0,0,0,0,0,0,0,0,1
1,35,0,0,0,0,0,0,0,0,35,1
1,0,0,0,0,0,0,0,0,0,0,1
1,0,0,0,0,0,0,0,0,0,0,1
1,35,0,0,0,0,0,0,0,0,35,1
1,0,0,0,0,0,0,0,0,0,0,1
1,0,0,0,0,0,0,0,0,0,0,1
1,0,0,0,35,0,0,35,0,0,0,1
1,1,1,1,1,1,1,1,1,1,1,1
endlayer
layer
0,1,0,0,0,0,0,0,0,0,1,0
1,1,9,9,9,9,9,9,9,9,1,1
0,9,0,0,0,0,0,0,0,0,9,0
0,9,0,0,0,0,0,0,0,0,9,0
0,9,0,0,0,0,0,0,0,0,9,0
0,9,0,0,0,0,0,0,0,0,9,0
0,9,0,0,0,0,0,0,0,0,9,0
0,9,0,0,0,0,0,0,0,0,9,0
0,9,0,0,0,0,0,0,0,0,9,0
0,9,0,0,0,0,0,0,0,0,9,0
1,1,9,9,9,9,9,9,9,9,1,1
0,1,0,0,0,0,0,0,0,0,1,0
endlayer
layer
0,0,0,0,0,0,0,0,0,0,0,0
0,1,0,0,0,0,0,0,0,0,1,0
0,0,1,9,9,9,9,9,9,1,0,0
0,0,9,0,0,0,0,0,0,9,0,0
0,0,9,0,0,0,0,0,0,9,0,0
0,0,9,0,0,0,0,0,0,9,0,0
0,0,9,0,0,0,0,0,0,9,0,0
0,0,9,0,0,0,0,0,0,9,0,0
0,0,9,0,0,0,0,0,0,9,0,0
0,0,1,9,9,9,9,9,9,1,0,0
0,1,0,0,0,0,0,0,0,0,1,0
0,0,0,0,0,0,0,0,0,0,0,0
endlayer
layer
0,0,0,0,0,0,0,0,0,0,0,0
0,0,0,0,0,0,0,0,0,0,0,0
0,0,1,0,0,0,0,0,0,1,0,0
0,0,0,1,9,9,9,9,1,0,0,0
0,0,0,9,0,0,0,0,9,0,0,0
0,0,0,9,0,0,0,0,9,0,0,0
0,0,0,9,0,0,0,0,9,0,0,0
0,0,0,9,0,0,0,0,9,0,0,0
0,0,0,1,9,9,9,9,1,0,0,0
0,0,1,0,0,0,0,0,0,1,0,0
0,0,0,0,0,0,0,0,0,0,0,0
0,0,0,0,0,0,0,0,0,0,0,0
endlayer
layer
0,0,0,0,0,0,0,0,0,0,0,0
0,0,0,0,0,0,0,0,0,0,0,0
0,0,0,0,0,0,0,0,0,0,0,0
0,0,0,1,0,0,0,0,1,0,0,0
0,0,0,0,1,9,9,1,0,0,0,0
0,0,0,0,9,0,0,9,0,0,0,0
0,0,0,0,9,0,0,9,0,0,0,0
0,0,0,0,1,9,9,1,0,0,0,0
0,0,0,1,0,0,0,0,1,0,0,0
0,0,0,0,0,0,0,0,0,0,0,0
0,0,0,0,0,0,0,0,0,0,0,0
0,0,0,0,0,0,0,0,0,0,0,0
endlayer
layer
0,0,0,0,0,0,0,0,0,0,0,0
0,0,0,0,0,0,0,0,0,0,0,0
0,0,0,0,0,0,0,0,0,0,0,0
0,0,0,0,0,0,0,0,0,0,0,0
0,0,0,0,1,0,0,1,0,0,0,0
0,0,0,0,0,1,1,0,0,0,0,0
0,0,0,0,0,1,1,0,0,0,0,0
0,0,0,0,1,0,0,1,0,0,0,0
0,0,0,0,0,0,0,0,0,0,0,0
0,0,0,0,0,0,0,0,0,0,0,0
0,0,0,0,0,0,0,0,0,0,0,0
0,0,0,0,0,0,0,0,0,0,0,0
endlayer
layer
0,0,0,0,0,0,0,0,0,0,0,0
0,0,0,0,0,0,0,0,0,0,0,0
0,0,0,0,0,0,0,0,0,0,0,0
0,0,0,0,0,0,0,0,0,0,0,0
0,0,0,0,0,0,0,0,0,0,0,0
0,0,0,0,0,1,1,0,0,0,0,0
0,0,0,0,0,1,1,0,0,0,0,0
0,0,0,0,0,0,0,0,0,0,0,0
0,0,0,0,0,0,0,0,0,0,0,0
0,0,0,0,0,0,0,0,0,0,0,0
0,0,0,0,0,0,0,0,0,0,0,0
0,0,0,0,0,0,0,0,0,0,0,0
endlayer
In addition to all the new flower types added in 1.7 onward, I experimented with placing other items in the flower pot. Only web and tallgrass seemed to work (beyond the types you could already get just by specifying the data value) -- and in the case of tallgrass, it makes for a strange GRAY sort of plant. At least now I can inform Wendy that, yes, she CAN have a nice colorful selection of flower pots decorating her Ruins houses.
One minor awkward thing about this example is that I can't have a Command Block with RUINSTRIGGER that uses setblock to replace itself, so I had to place all the Command Blocks *above* the desired target point. If I had the Command Blocks *in* the desired location, the resulting block will be ERASED after execution by the RUINSTRIGGER routine. Is there any way to have the same effect as RUINSTRIGGER (i.e., automatically triggered when player gets within range), but DO NOT erase the Command Block's location? (I'd be doing that anyway if I use "setblock" to take the Command Block's place, and I just don't want the resulting block eradicated during cleanup.)
--- 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)
Thanks for the reply! I see the problem, I was trying to download for 1.6.2 cause i'm still using a few mods from that (some haven't been updated yet). I tried downloading all the ruins mod and all of them downloaded Aside from 1.6.2 and 1.5.2, those that didn't have the dropbox issue. I tried downloading it with chrome. If you're willing/able to post a new 1.6.2 download link, I could try out this mod in 1.7.2 or 1.6.4 and if it's to my fancy, then i could request you post a new 1.6.2 download link. Let me know tho. No worries either way cause i'll get to 1.6.4+ eventually haha