Maybe I am missing it somewhere but can someone tell me how to bring my old ruins into 1.13.2? every time I try to load one to save into new format I get errors loading. I hope I don't have to rebuild them!!!
Here is my process I'm going through (slowly, alas) to get my templates up to 1.13.2:
PART A:
1) Make copies of my 1.12 templates in a new folder tree.
2) Leave out all templates that rely upon Command Blocks using RUINSTRIGGER. (This eliminates most of my big "dungeon" projects, and anything spawning custom villages and mobs, sadly. It also leaves out my more recent experiments with spawning paintings on the walls.)
3) Edit each template to set embed_into_distance and max_leveling to 0.
4) Replace all instances of "preserveBlock" with a placeholder block not used elsewhere in the template. For most of my templates, this is glass; for others (i.e., where I actually AM using glass blocks), I replace it with some shade of stained_glass.
5) For any rules where I employed randomization (e.g., "rule6=1,100,minecraft:stonebrick-0,minecraft:stonebrick-1,minecraft:stonebrick-2" for grey stone brick walls with randomized cracks and moss), strip out the randomization so it's just ONE block. I can reintroduce the randomization later. If I have multiple rules that use different types of randomization, I need to make sure I use a different block type, so that when I re-parse things, there will be a different rule generated for each.
6) Replace anything that might be "unstable" (TNT blocks, lava traps, etc.) with a placeholder.
7) Replace random loot table treasure chests with "minecraft:chest" as a placeholder. Leave any containers with pre-specified contents as-is.
8) Rinse, repeat, until ALL the templates I want to bring over to 1.13 have been "converted in this way."
PART B:
1) Generate a 1.12 superflat world topped with a one-block-thick layer of some sort of solid, durable block that I never use in my structures. (E.g., diamond_block.) For pure minimalism, I could just have one block thick of bedrock and one block thick of diamond_block, and that's it, but the exact elevation doesn't really matter. Make sure the biome is a temperate one (not a cold one), so none of my water blocks end up freezing. (Of course, I could just replace them all with placeholder blocks, too.)
2) Open in Creative.
3) /gamerule doDaylightCycle false (to stop the day-night cycle while I'm working)
4) Use /testruin to spawn each and every template I hope to convert over to 1.13, with some amount of space between each of them.
5) Exit. Save a backup of my world. Move all the templates from the 1.12 template folder into a different folder for backup purposes.
6) Upgrade my world to 1.13.
7) Re-enter. Visit each structure, check to make sure it survived the transition, then dig a "moat" around the base into the layer of diamond_block so that there is now a diamond_block "baseplate" underneath the structure, not connected to any of the other diamond_block comprising the rest of the layer.
8) Use /parseruin to capture the new template for each structure. I don't *necessarily* have to do this all at once, but I might as well.
9) For those particular "unstable" blocks that I have been diligently replacing with "placeholder" blocks, go ahead and create some sort of "dummy" structure that incorporates them all -- TNT, lava (but not NEXT to the TNT!), different types of stone brick, whatever -- then use /parseruin to capture it, so I can reference the generated Rules for a clue as to what the new syntax will be for those blocks.
10) Edit the newly-created 1.13 templates to replace placeholders with the appropriate materials.
11) Reference the old 1.12 versions of the same templates to copy over "biomesToSpawnIn" and other such settings.
12) I'm sure there's some other stuff I'll have to tweak. Allowed and prohibited blocks for spawning will have different syntax, so the corresponding lines can't just be copied-and-pasted over, I assume.
...
And I'm still working my way through "Part A" of this grand plan. That's what I get for making so many templates. I'm going to miss all those mega-dungeons and stuff, but maybe there are other ways I can get the Command Blocks to fire off on their own, what with the later changes. I just have to learn more about the new types of Command Block and their various states.
Also, I'm wondering if some of my custom mob-spawners might actually work if I spawn them into the 1.12 world, and then capture them via /parseruin. Only experimentation will tell, I suppose.
I think before I try to convert all my 1.12 structures en masse, I'm going to try converting over the "vanilla generic" Ruins templates included with the ZIP binders, unless someone beats me to it. They don't have a lot of the stumbling points I'm concerned about, so I suppose they should be much easier to convert (or, if absolutely necessary, rebuild).
Yep, I actually am in the process of creating that template world and have most of my ruins on it. The only thing I had to change was the Embed Into Distance, otherwise the ruins were like five blocks above me head.
It's good to build a new one from scratch, as long-standing development worlds will be littered with versions of builds in various states of evolution.
well I have all of my files saved into a template world. Did my first parse, then tried to test it and no matter what I set Embed command to the ruin always spawns four blocks above the surface on a flat world. anyone have a suggestion?
For some reason in flat maps they don't spawn under y=10. If you want them to reach the ground then raise the ground to them by adding blocks to the flat world (in the starting code) such that the lowest point they spawn fits with their intended placement.. In regular worlds structures can be spawned all the way down to bedrock if needed.
When starting a new world, under superflat there is a customize button.
The next screen shows the layers in the world in blocks. At the lower right is a button called "Presets", press it to go to the next screen.
At the top of that screen it has a box with text in it. That is the world code, and there are videos explaining it in detail. To add more dirt layers change the corresponding number.
The text in the box is a very long line., press ALT and A at the same time to select the entire line, then ALT-C and ALT-V to bring it into a text file so you can see the entire line at once while editing it.
I just now checked all this in 1.13.2, the text box for the world code is just in a slightly different place from where it was in previous versions.
Couple things right off the bat. Firstly, the unfortunately-named dimensions config parameter refers to the size of the structure, not the dimensions in which it spawns. In your case, you should set it as follows:
dimensions=6,9,9
Secondly, the folders are named after biomes, not dimensions, so unless there's a biome named "Beneath" (unlikely, though I'm not familiar with that mod), you'll have to either rename the folder to a biome name, or move the template to an existing biome folder and add to the biomesToSpawnIn list (or add biome types to the biomeTypesToSpawnIn list) so as to include the desired new biome(s).
Thirdly--and this is the tricky one--you have to enable Ruins to work in the mod dimension. It looks like you already determined the dimension ID number (10); this needs to be added to the allowedDimensions list in both config/ruins.txt and world/DIM10/ruins.txt:
allowedDimensions=0,1,-1,10
The "world" folder might not be called "world" in your case, depending on whether you're running single-player, or if you modified level-name in server.properties, so you might have to poke around for that file. In fact, if you're starting a brand new world, it won't exist at all...but if it does, you'll have to modify it.
This is the stuff that should actually be listed in a wiki of some sort...maybe a guide?
The big issue then is that you can't use ruins for mod packs, as the player would name the save game anything they want, meaning I'd never be able to guess what they would call it.
Thanks for the help, but it looks like this mod won't work. IMO this is a truly stupid design.
...you can't use ruins for mod packs, as the player would name the save game anything they want, meaning I'd never be able to guess what they would call it.
There's no guessing. Recall I said you won't have a "world" folder configuration if you're starting a brand new world, and presumably anyone installing a modpack is likely starting a brand new world (or joining a server on which a world was already created, in which case it doesn't matter--Ruins currently has no client-side functionality). You only need to include the one edited configuration file config/ruins.txt in your modpack, just as you would for virtually any other mod. It doesn't matter what the world is eventually called; Ruins automatically installs that included configuration into appropriate folders.
The tricky bit about hunting down the world folder only applies if you're adding Ruins to an already existing world. If you're using a new modpack to play in a world created without it, Ruins is probably going to be the least of your problems.
That makes way more sense. In your explanation, it sounded like you had to do a savegame config as well for it to work at all, which really would be dumb. I'm working in a dev environment so I can remake files, savegames, etc. None of this is tricky, I just need to know why it isn't working, since the instructions are pretty lacking for what I'm trying to do.
Okay, I've watched the videos hyping all the new changes to MC 1.14 - "Village and Pillage" - and I've hardly made much progress on redoing my Ruins templates for 1.13. (I've been traveling for work a lot.) My big question is ... does anyone happen to know whether the 1.14 update represents any major structural updates that will upend Ruins templates made for 1.13 that I need to look forward to? (I might therefore be a bit mindful of certain things I might do in structures that are going to be immediately "undone" in the next version of Ruins, and not spend so much effort in that direction.)
I'm fascinated by the thought of lots of new building blocks (stairs, slabs, walls, new crafting workstations), fun things to do with scaffolding and bamboo, new mobs, etc., and curious to see what new sorts of structures may spawn in the world (and therefore what changes I'll have to make to ensure that the right structures spawn in the new biomes, and what sorts of blocks I need to exclude from viable building points, so as to not have my structures pop up on top of whatever new buildings are added in 1.14).
I'm particularly curious about the implications of the new interface for making maps, and then to "freeze" the information on it by putting a glass pane on it. The implication would seem to be that the data is stored in the map object, and that theoretically if I were to spawn items into existence with custom tags, I could make that "map" look like all sorts of things: in other words, a "frozen" map object could essentially be a way to have a custom painting! Or, that's what I'm supposing. I have no idea if it can actually be exploited in that way.
I'm also wondering about the new "Puzzle" block. From how I heard it described, it sounds as if its purpose involves spawning a cluster of structures in the world, in a manner that sounded similar to the "adjacent templates" feature in Ruins. I wonder if that might open up any new possibilities?
Hi, I'm currently trying to use this mod for my mod pack, and I have to adjust things so they work just right.
Problem is, I am rather new to using the mod, and I keep running into issues where I don't know what to do;
some of it due to a lack of information and having to second guess some functions. It's not a good way to work.
I am using version 1.12.2
I'm using this mod to not only spawn ruins, but also spawn animals and CustomNPC Mod npcs into the world
(this mod, surprisingly, is a lot better at it than some of the official spawn control mods out there.)
So, I have quite a few questions about some confusing things. Let's follow the Templates_rules and go over each one:
weight:
I have some issue with this one; it's acting strange.
When I tested it, I set uniqueMinDistance to 1, which causes ruins to spawn way more and closer together.
Then, for testing purposes, I made 2 ruins, one at weight=1 one at weight=2.
Now, you would think it would spawn mostly #2 and sometimes #1, but that isn't the case;
it spawned Ruin #2 100% of the time. I tested it for a while and covered a lot of distance, and not one #1 ruin ever showed up
(keep in mind the ruins show up closely packed together, so it's easy to tell.)
embed_into_distance:
I understand how this works, but it can be a little hard to pinpoint how deep to put it sometimes. For example, what happens if you put it too deep, like beyond bedrock? The surface isn't always smooth, after all.
Does it stop at bedrock, or will it CUT the ruin in half?
acceptable_target_blocks & unacceptable_target_blocks:
Another one I have some issues with, but first some basic questions.
If I want to add blocks to the list, is this correct?:
By that I mean having the Mod name before the block?
Also, if I don't specify metadata, will it go for EVERY block of that type, or just the first (AKA minecraft:stone 0) only?
(Also, was that the correct metadata? If not, what's the right way?)
What happens if a blockname is misspelled? Does it ignore all blocks, or just that one?
As for the issue I had:
I set acceptable_target_blocks to only stone from a mod, but the ruin still spawned on other blocks (this was in another dimension BTW).
So, I set all the other blocks in unacceptable_target_blocks, and then it did work.
So how do these two functions actualy work? Do I need to specify every block I DON'T want it to spawn on for every ruin?
I thought if you put a block in acceptable_target_blocks, it would only use those, but that doesn't seem to be the case.
Or, was my result just due to a fluke, or some other error on my part?
Since some dimensions share biomes, I rely heavily on block control to make sure ruins don't spawn in the wrong world (the top block is changed per dimension).
unique:
If I understand this correctly, setting it to 1 it will ONLY make it spawn once per biome, right?
If it is in Generic, it should only spawn once in total, right? Not "once per biome".
uniqueMinDistance:
What would be a good Distance, if I used this for spawning animals?
Default is 1500.
If I set it lower, they will spawn closer, but does anyone have any recomendations?
max_leveling:
If I don't want it to remove any blocks, what do I set it to? 0?
preserving air:
I can't seem to find the info for this.
How do I make it so the ruin keeps air or not?
Say I wanted to burry a skeleton dragon and needed the rock to surround the bones, not clear out the blocks when it's created. How do I do that? Does it have to do with the Base block I use?
Ruin distances to OTHER ruins:
I got some special ruins that I don't want showing up too close to each other; they are different types of ruins.
How do I make it so Ruin A wont spawn anywhere near Ruin B?
Any help would really be appreciated, and it would speed up the process.
Sorry if some seem a bit noobish; although I've read the Templates carefully, I'm still unsure of these things I listed.
If anyhting is confusing, just ask and I'll try to clarify it.
weight:
I have some issue with this one; it's acting strange.
When I tested it, I set uniqueMinDistance to 1, which causes ruins to spawn way more and closer together.
Then, for testing purposes, I made 2 ruins, one at weight=1 one at weight=2.
Now, you would think it would spawn mostly #2 and sometimes #1, but that isn't the case;
it spawned Ruin #2 100% of the time. I tested it for a while and covered a lot of distance, and not one #1 ruin ever showed up
(keep in mind the ruins show up closely packed together, so it's easy to tell.)
The "problem" you're seeing has nothing to do with weight; it's a consequence of setting uniqueMinDistance=1. I presume you didn't change the value of anyRuinsMinDistance in the Ruins.txt config file, so it's got its default value of 64. That means a #2 can be just 1 block away from another #2, but a #1 has to be at least 64 blocks away from a #2. Once a #2 is spawned, therefore, Ruins is going to keep picking #2 over and over until there's a gap of 64 blocks with no structures (e.g., a wide ocean, if the structures don't spawn on water) and #1 once again becomes an eligible selection, at which point a new random draw is made (33% chance of #1 or 67% of #2, according to the weight values) and the repetition begins anew.
If you want high-density Ruins, a better way to do it is leave uniqueMinDistance=0 in the template files (which is the default; 0 being a special value indicating the global value of templateInstancesMinDistance should be used), and instead set anyRuinsMinDistance=1 and templateInstancesMinDistance=1 in Ruins.txt. You should then get the result you expect.
In general, the value of uniqueMinDistance (and templateInstancesMinDistance) should be equal to or greater than that of anyRuinsMinDistance. Otherwise, you'll tend to get the homogeneity bias you observed, which is almost certainly undesirable. There may be some esoteric situations warranting violation of this guideline, but I can't think of any.
embed_into_distance:
I understand how this works, but it can be a little hard to pinpoint how deep to put it sometimes. For example, what happens if you put it too deep, like beyond bedrock? The surface isn't always smooth, after all.
Does it stop at bedrock, or will it CUT the ruin in half?
Ruins enforces a floor at Y=8. If you attempt to spawn a structure lower than that (due to, say, embed_into_distance=99999), it will simply spawn at Y=8.
acceptable_target_blocks & unacceptable_target_blocks:
If I want to add blocks to the list, is this correct?:
acceptable_target_blocks=minecraft:stone,galacticraftplanets:mars-1,biomesoplenty:dried_sand
By that I mean having the Mod name before the block?
Yes; that's standard Minecraft syntax. Note you may optionally omit the minecraft: part for vanilla blocks--just specifying stone, for instance, instead of minecraft:stone. Also note the "domain" (i.e., the identifier on the left side of the colon) isn't necessarily the name of the mod introducing that block; it usually is, but there are exceptions. Something to watch out for.
Also, if I don't specify metadata, will it go for EVERY block of that type, or just the first (AKA minecraft:stone 0) only?
(Also, was that the correct metadata? If not, what's the right way?)
What happens if a blockname is misspelled? Does it ignore all blocks, or just that one?
Ruins doesn't support metadata values in this context, so it always matches every block with the specified name. If you attempt to apply a metadata value here, it'll be misinterpreted as part of the name.
If a block name is unrecognized, that name is merely skipped. All valid names on the list will still apply. This allows you to specify blocks from mods which may or may not be installed...kind of. The catch is: if all names are invalid, it counts as an empty list, and an empty acceptable_target_blocks list is interpreted as "all blocks," possibly leading to undesirable behavior. Avoid this by including at least one vanilla block on the list. (The same concern does not apply to unacceptable_target_blocks, however, since an empty list there is interpreted as "no blocks.")
A template should specify either acceptable_target_blocks (i.e., spawn only on these) or unacceptable_target_blocks (spawn on anything but these), or neither (spawn on anything). It should never specify both.
I set acceptable_target_blocks to only stone from a mod, but the ruin still spawned on other blocks (this was in another dimension BTW).
So, I set all the other blocks in unacceptable_target_blocks, and then it did work.
So how do these two functions actualy work? Do I need to specify every block I DON'T want it to spawn on for every ruin?
I thought if you put a block in acceptable_target_blocks, it would only use those, but that doesn't seem to be the case.
Or, was my result just due to a fluke, or some other error on my part?
Since some dimensions share biomes, I rely heavily on block control to make sure ruins don't spawn in the wrong world (the top block is changed per dimension).
I can't say for sure without seeing your template file, but I'd guess in your first attempt, acceptable_target_blocks listed either a misspelled block name or a block name from a mod that wasn't loaded. See the tip above on why this can cause trouble and how to avoid it by including some unlikely vanilla block name on the list (e.g., structure_void).
unique:
If I understand this correctly, setting it to 1 it will ONLY make it spawn once per biome, right?
If it is in Generic, it should only spawn once in total, right? Not "once per biome".
There is no parameter unique. The once-per-biome feature you describe does not currently exist in Ruins.
uniqueMinDistance:
What would be a good Distance, if I used this for spawning animals?
Default is 1500.
If I set it lower, they will spawn closer, but does anyone have any recomendations?
I'm not sure what "spawning animals" refers to. Ruins (currently) only places blocks, not entities. It can, however, place command blocks that spawn entities...is that what you mean?
max_leveling:
If I don't want it to remove any blocks, what do I set it to? 0?
Leveling is a whole other can of worms. If you don't want leveling--and most templates don't--set leveling_buffer=-1. Without leveling, the best way to think of max_leveling is as specifying how flat the terrain surface must be to spawn this template. If max_leveling=0, it must be perfectly flat over the entire footprint of the structure to be spawned; if max_leveling=1, it can deviate up and/or down by at most one block; and so on. The max_leveling parameter has nothing to do with blocks being removed if leveling is disabled.
preserving air:
How do I make it so the ruin keeps air or not?
Say I wanted to burry a skeleton dragon and needed the rock to surround the bones, not clear out the blocks when it's created. How do I do that? Does it have to do with the Base block I use?
There is a special "pseudo-block" you can use in template rules: preserveBlock. This is a directive telling Ruins not to replace the block in that position.
Since you mention base blocks, I suspect you're creating templates via the /parseruin command. If so, your template uses an implicit rule0 to represent air (sort of...this post is long enough without going into a full explanation). If you want your template embedded in a medium like dirt or stone without unsightly air pockets, you can manually edit the parseruin-generated template file to add a new preserveBlock rule onto the end of the rule list, and replace some or all of the 0's in the layers with this new rule. So, instead of...
Ruin distances to OTHER ruins:
I got some special ruins that I don't want showing up too close to each other; they are different types of ruins.
How do I make it so Ruin A wont spawn anywhere near Ruin B?
This isn't currently supported in Ruins, at least not directly. As a workaround, though, you could perhaps create a third template C which simply consists of a single command block that spawns either an A or a B in its place. Move templates A and B to a non-biome folder so they aren't naturally generated on their own. Set C's uniqueMinDistance to some big number, like 4096, and voilà! Your A's and B's are widely separated.
This isn't currently supported in Ruins, at least not directly. As a workaround, though, you could perhaps create a third template C which simply consists of a single command block that spawns either an A or a B in its place. Move templates A and B to a non-biome folder so they aren't naturally generated on their own. Set C's uniqueMinDistance to some big number, like 4096, and voilà! Your A's and B's are widely separated.
That sound like what I tried doing with some of my "inferno dungeon spawners" and such: have a single template that plants a Command_Block that uses RUINTRIGGER to spawn one of several different dungeons, and then the idea is that if I try to reduce the density of "inferno dungeons" by setting a high "uniqueMinDistance," then collectively those dungeons will be rare. I think Gillymoth's templates utilize this sort of approach as well to modulate the spawning frequency of various types of structures.
However, as of Ruins for 1.13, I thought RUINSTRIGGER no longer works? I seem to recall that there was some new type of command block that had a setting to auto-execute, but I'm not sure how to implement that using the Ruins Command_Block functionality. (I guess maybe it would be possible via teBlock?)
The "problem" you're seeing has nothing to do with weight; it's a consequence of setting uniqueMinDistance=1. I presume you didn't change the value of anyRuinsMinDistance in the Ruins.txt config file, so it's got its default value of 64. That means a #2 can be just 1 block away from another #2, but a #1 has to be at least 64 blocks away from a #2. Once a #2 is spawned, therefore, Ruins is going to keep picking #2 over and over until there's a gap of 64 blocks with no structures (e.g., a wide ocean, if the structures don't spawn on water) and #1 once again becomes an eligible selection, at which point a new random draw is made (33% chance of #1 or 67% of #2, according to the weight values) and the repetition begins anew.
If you want high-density Ruins, a better way to do it is leave uniqueMinDistance=0 in the template files (which is the default; 0 being a special value indicating the global value of templateInstancesMinDistance should be used), and instead set anyRuinsMinDistance=1 and templateInstancesMinDistance=1 in Ruins.txt. You should then get the result you expect.
In general, the value of uniqueMinDistance (and templateInstancesMinDistance) should be equal to or greater than that of anyRuinsMinDistance. Otherwise, you'll tend to get the homogeneity bias you observed, which is almost certainly undesirable. There may be some esoteric situations warranting violation of this guideline, but I can't think of any.
I see, that certainly explains it.
One last question regarding Weight:
Ruins are weighed versus each other right?
If I want some ruins to be much rarer, should I UP the normal ruins weight higher?
Say, for an extreme example, I set ALL normal house ruins to 31, and one special castle as 1:
it would significantly lower the chance of the 1 castle ruin, but still allow it to spawn, just at a very very low chance?
Ruins enforces a floor at Y=8. If you attempt to spawn a structure lower than that (due to, say, embed_into_distance=99999), it will simply spawn at Y=8.
Sweet, no worries then.
A template should specify either acceptable_target_blocks (i.e., spawn only on these) or unacceptable_target_blocks (spawn on anything but these), or neither (spawn on anything). It should never specify both.
So if I ONLY use acceptable_target_blocks, it should work?
Also, good to know about the metadata. Thanks for the pointers; they will come in handy.
There is no parameter unique. The once-per-biome feature you describe does not currently exist in Ruins.
Really? I could have sworn I saw one.
But, I could just set uniqueMinDistance to really high, and it would basically get the same result, right (making it spawn just once)?
What's the highest number I can put in? Or, is there no limit?
I'm not sure what "spawning animals" refers to. Ruins (currently) only places blocks, not entities. It can, however, place command blocks that spawn entities...is that what you mean?
Yes, it is done via commandblocks, specifically for CustomNPC Mod NPCs, since that particular mod doesn't have natural spawning.
Leveling is a whole other can of worms. If you don't want leveling--and most templates don't--set leveling_buffer=-1. Without leveling, the best way to think of max_leveling is as specifying how flat the terrain surface must be to spawn this template. If max_leveling=0, it must be perfectly flat over the entire footprint of the structure to be spawned; if max_leveling=1, it can deviate up and/or down by at most one block; and so on. The max_leveling parameter has nothing to do with blocks being removed if leveling is disabled.
So basically, if I set the number higher, it would have a higher chance to spawn, because it doesn't need to be flat, yes?
Then I should do that for NPC spawns since they're just commandblocks.
There is a special "pseudo-block" you can use in template rules: preserveBlock. This is a directive telling Ruins not to replace the block in that position.
Since you mention base blocks, I suspect you're creating templates via the /parseruin command. If so, your template uses an implicit rule0 to represent air (sort of...this post is long enough without going into a full explanation). If you want your template embedded in a medium like dirt or stone without unsightly air pockets, you can manually edit the parseruin-generated template file to add a new preserveBlock rule onto the end of the rule list, and replace some or all of the 0's in the layers with this new rule. So, instead of...
Or I could maybe use a block (say lapis) when I build and then replace that block with preserveBlock in the template?
Yeah, I mainly use /parseruin, then edit the ruin template.
This isn't currently supported in Ruins, at least not directly. As a workaround, though, you could perhaps create a third template C which simply consists of a single command block that spawns either an A or a B in its place. Move templates A and B to a non-biome folder so they aren't naturally generated on their own. Set C's uniqueMinDistance to some big number, like 4096, and voilà! Your A's and B's are widely separated.
I see. Thanks for the workaround! It will be very handy.
And thank you soo much for answering my questions; it helps a lot!
Ruins are weighed versus each other right?
If I want some ruins to be much rarer, should I UP the normal ruins weight higher?
Say, for an extreme example, I set ALL normal house ruins to 31, and one special castle as 1:
it would significantly lower the chance of the 1 castle ruin, but still allow it to spawn, just at a very very low chance?
That's exactly right. A biome-specific template's weight is relative to that of all other biome-specific templates eligible to spawn in a particular biome; a generic template's is relative to all other generic templates. Unfortunately, the value of weight must be an integer, and the default is 1, so yes--you'd have to ratchet up everybody else's weight in order to make low-probability spawns, just as you described.
Or...it just so happens the very latest version of Ruins for Minecraft 1.12.2 adds support for non-integer weight values, so you could simply give your castle template a weight=0.03 and not have to futz with all the rest. However, that change went in after the most recent official release, so to get it you'd have to either pull the code down from GitHub and build it yourself, or cajole AtomicStryker (the owner of Ruins) into releasing an updated 1.12.2 version.
Incidentally, the latest version also includes two other things that might be of interest to you--a new dimensionsToSpawnIn template parameter and improved Galacticraft compatibility. Just sayin'.
So if I ONLY use acceptable_target_blocks, it should work?
Yes. In fact, I'd say that's ideal for most templates.
I could just set uniqueMinDistance to really high, and it would basically get the same result, right (making it spawn just once)?
What's the highest number I can put in? Or, is there no limit?
A ridiculously high uniqueMinDistance will effectively give you one spawn per dimension. The highest allowed value is Java's maximum signed int: 2,147,483,647. The highest meaningful value is twice Minecraft's maximum world size: 59,999,968. I'd just use a cool 60 mill, myself.
So basically, if I set [max_leveling] higher, it would have a higher chance to spawn, because it doesn't need to be flat, yes?
That's the right idea, though it's moot if your template is just a single command block--by definition, there's no height variation over a 1x1 area.
Or I could maybe use a block (say lapis) when I build and then replace that block with preserveBlock in the template?
Yeah, I mainly use /parseruin, then edit the ruin template.
I think that's the method most template authors here use if there needs to be a distinction between air and preserveBlock. Maybe they'll chime in with some other tips as well.
If your structure doesn't need air pockets, however, it might be easiest just to replace rule0. By default, rule0 is implicitly defined as background air (i.e., air that doesn't replace most plants and respects preserve_water and preserve_lava settings). You can define your own replacement rule0; it's easy, but a bit funky. Put the following line before the first rule:
=0,100,preserveBlock
The rule name is intentionally missing, and this must precede all other rules. With this in place, your rule0 is now 100% preserveBlock.
Incidentally, the latest version also includes two other things that might be of interest to you--a new dimensionsToSpawnIn[/b] template parameter and improved Galacticraft compatibility. Just sayin'.
Now that could be VERY useful since i use Galacticraft in my pack.
Sadly, I can't really putt together a build myself, so It would be nice if AtomicStryker released it.
Here is my process I'm going through (slowly, alas) to get my templates up to 1.13.2:
PART A:
1) Make copies of my 1.12 templates in a new folder tree.
2) Leave out all templates that rely upon Command Blocks using RUINSTRIGGER. (This eliminates most of my big "dungeon" projects, and anything spawning custom villages and mobs, sadly. It also leaves out my more recent experiments with spawning paintings on the walls.)
3) Edit each template to set embed_into_distance and max_leveling to 0.
4) Replace all instances of "preserveBlock" with a placeholder block not used elsewhere in the template. For most of my templates, this is glass; for others (i.e., where I actually AM using glass blocks), I replace it with some shade of stained_glass.
5) For any rules where I employed randomization (e.g., "rule6=1,100,minecraft:stonebrick-0,minecraft:stonebrick-1,minecraft:stonebrick-2" for grey stone brick walls with randomized cracks and moss), strip out the randomization so it's just ONE block. I can reintroduce the randomization later. If I have multiple rules that use different types of randomization, I need to make sure I use a different block type, so that when I re-parse things, there will be a different rule generated for each.
6) Replace anything that might be "unstable" (TNT blocks, lava traps, etc.) with a placeholder.
7) Replace random loot table treasure chests with "minecraft:chest" as a placeholder. Leave any containers with pre-specified contents as-is.
8) Rinse, repeat, until ALL the templates I want to bring over to 1.13 have been "converted in this way."
PART B:
1) Generate a 1.12 superflat world topped with a one-block-thick layer of some sort of solid, durable block that I never use in my structures. (E.g., diamond_block.) For pure minimalism, I could just have one block thick of bedrock and one block thick of diamond_block, and that's it, but the exact elevation doesn't really matter. Make sure the biome is a temperate one (not a cold one), so none of my water blocks end up freezing. (Of course, I could just replace them all with placeholder blocks, too.)
2) Open in Creative.
3) /gamerule doDaylightCycle false (to stop the day-night cycle while I'm working)
4) Use /testruin to spawn each and every template I hope to convert over to 1.13, with some amount of space between each of them.
5) Exit. Save a backup of my world. Move all the templates from the 1.12 template folder into a different folder for backup purposes.
6) Upgrade my world to 1.13.
7) Re-enter. Visit each structure, check to make sure it survived the transition, then dig a "moat" around the base into the layer of diamond_block so that there is now a diamond_block "baseplate" underneath the structure, not connected to any of the other diamond_block comprising the rest of the layer.
8) Use /parseruin to capture the new template for each structure. I don't *necessarily* have to do this all at once, but I might as well.
9) For those particular "unstable" blocks that I have been diligently replacing with "placeholder" blocks, go ahead and create some sort of "dummy" structure that incorporates them all -- TNT, lava (but not NEXT to the TNT!), different types of stone brick, whatever -- then use /parseruin to capture it, so I can reference the generated Rules for a clue as to what the new syntax will be for those blocks.
10) Edit the newly-created 1.13 templates to replace placeholders with the appropriate materials.
11) Reference the old 1.12 versions of the same templates to copy over "biomesToSpawnIn" and other such settings.
12) I'm sure there's some other stuff I'll have to tweak. Allowed and prohibited blocks for spawning will have different syntax, so the corresponding lines can't just be copied-and-pasted over, I assume.
...
And I'm still working my way through "Part A" of this grand plan. That's what I get for making so many templates. I'm going to miss all those mega-dungeons and stuff, but maybe there are other ways I can get the Command Blocks to fire off on their own, what with the later changes. I just have to learn more about the new types of Command Block and their various states.
Also, I'm wondering if some of my custom mob-spawners might actually work if I spawn them into the 1.12 world, and then capture them via /parseruin. Only experimentation will tell, I suppose.
I think before I try to convert all my 1.12 structures en masse, I'm going to try converting over the "vanilla generic" Ruins templates included with the ZIP binders, unless someone beats me to it. They don't have a lot of the stumbling points I'm concerned about, so I suppose they should be much easier to convert (or, if absolutely necessary, rebuild).
--- 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)
One might even want to keep such a prepared "template world" in case MC or Forge decide to change everything again.
Eek! Scary thought, but a very good idea. I'll do just that.
--- 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)
Yep, I actually am in the process of creating that template world and have most of my ruins on it. The only thing I had to change was the Embed Into Distance, otherwise the ruins were like five blocks above me head.
It's good to build a new one from scratch, as long-standing development worlds will be littered with versions of builds in various states of evolution.
Gillymoth Structures for Ruins <<< Folder containing my Structure-sets for Ruins mod.
well I have all of my files saved into a template world. Did my first parse, then tried to test it and no matter what I set Embed command to the ruin always spawns four blocks above the surface on a flat world. anyone have a suggestion?
For some reason in flat maps they don't spawn under y=10. If you want them to reach the ground then raise the ground to them by adding blocks to the flat world (in the starting code) such that the lowest point they spawn fits with their intended placement.. In regular worlds structures can be spawned all the way down to bedrock if needed.
Gillymoth Structures for Ruins <<< Folder containing my Structure-sets for Ruins mod.
how do you modify the starting code? they took out the ability to customize flat worlds
When starting a new world, under superflat there is a customize button.
The next screen shows the layers in the world in blocks. At the lower right is a button called "Presets", press it to go to the next screen.
At the top of that screen it has a box with text in it. That is the world code, and there are videos explaining it in detail. To add more dirt layers change the corresponding number.
The text in the box is a very long line., press ALT and A at the same time to select the entire line, then ALT-C and ALT-V to bring it into a text file so you can see the entire line at once while editing it.
I just now checked all this in 1.13.2, the text box for the world code is just in a slightly different place from where it was in previous versions.
Gillymoth Structures for Ruins <<< Folder containing my Structure-sets for Ruins mod.
This is the stuff that should actually be listed in a wiki of some sort...maybe a guide?
The big issue then is that you can't use ruins for mod packs, as the player would name the save game anything they want, meaning I'd never be able to guess what they would call it.
Thanks for the help, but it looks like this mod won't work. IMO this is a truly stupid design.
There's no guessing. Recall I said you won't have a "world" folder configuration if you're starting a brand new world, and presumably anyone installing a modpack is likely starting a brand new world (or joining a server on which a world was already created, in which case it doesn't matter--Ruins currently has no client-side functionality). You only need to include the one edited configuration file config/ruins.txt in your modpack, just as you would for virtually any other mod. It doesn't matter what the world is eventually called; Ruins automatically installs that included configuration into appropriate folders.
The tricky bit about hunting down the world folder only applies if you're adding Ruins to an already existing world. If you're using a new modpack to play in a world created without it, Ruins is probably going to be the least of your problems.
That makes way more sense. In your explanation, it sounded like you had to do a savegame config as well for it to work at all, which really would be dumb. I'm working in a dev environment so I can remake files, savegames, etc. None of this is tricky, I just need to know why it isn't working, since the instructions are pretty lacking for what I'm trying to do.
Okay, I've watched the videos hyping all the new changes to MC 1.14 - "Village and Pillage" - and I've hardly made much progress on redoing my Ruins templates for 1.13. (I've been traveling for work a lot.) My big question is ... does anyone happen to know whether the 1.14 update represents any major structural updates that will upend Ruins templates made for 1.13 that I need to look forward to? (I might therefore be a bit mindful of certain things I might do in structures that are going to be immediately "undone" in the next version of Ruins, and not spend so much effort in that direction.)
I'm fascinated by the thought of lots of new building blocks (stairs, slabs, walls, new crafting workstations), fun things to do with scaffolding and bamboo, new mobs, etc., and curious to see what new sorts of structures may spawn in the world (and therefore what changes I'll have to make to ensure that the right structures spawn in the new biomes, and what sorts of blocks I need to exclude from viable building points, so as to not have my structures pop up on top of whatever new buildings are added in 1.14).
I'm particularly curious about the implications of the new interface for making maps, and then to "freeze" the information on it by putting a glass pane on it. The implication would seem to be that the data is stored in the map object, and that theoretically if I were to spawn items into existence with custom tags, I could make that "map" look like all sorts of things: in other words, a "frozen" map object could essentially be a way to have a custom painting! Or, that's what I'm supposing. I have no idea if it can actually be exploited in that way.
I'm also wondering about the new "Puzzle" block. From how I heard it described, it sounds as if its purpose involves spawning a cluster of structures in the world, in a manner that sounded similar to the "adjacent templates" feature in Ruins. I wonder if that might open up any new possibilities?
--- 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)
Hi, I'm currently trying to use this mod for my mod pack, and I have to adjust things so they work just right.
Problem is, I am rather new to using the mod, and I keep running into issues where I don't know what to do;
some of it due to a lack of information and having to second guess some functions. It's not a good way to work.
I am using version 1.12.2
I'm using this mod to not only spawn ruins, but also spawn animals and CustomNPC Mod npcs into the world
(this mod, surprisingly, is a lot better at it than some of the official spawn control mods out there.)
So, I have quite a few questions about some confusing things. Let's follow the Templates_rules and go over each one:
weight:
I have some issue with this one; it's acting strange.
When I tested it, I set uniqueMinDistance to 1, which causes ruins to spawn way more and closer together.
Then, for testing purposes, I made 2 ruins, one at weight=1 one at weight=2.
Now, you would think it would spawn mostly #2 and sometimes #1, but that isn't the case;
it spawned Ruin #2 100% of the time. I tested it for a while and covered a lot of distance, and not one #1 ruin ever showed up
(keep in mind the ruins show up closely packed together, so it's easy to tell.)
embed_into_distance:
I understand how this works, but it can be a little hard to pinpoint how deep to put it sometimes. For example, what happens if you put it too deep, like beyond bedrock? The surface isn't always smooth, after all.
Does it stop at bedrock, or will it CUT the ruin in half?
acceptable_target_blocks & unacceptable_target_blocks:
Another one I have some issues with, but first some basic questions.
If I want to add blocks to the list, is this correct?:
acceptable_target_blocks=minecraft:stone,galacticraftplanets:mars-1,biomesoplenty:dried_sand
By that I mean having the Mod name before the block?
Also, if I don't specify metadata, will it go for EVERY block of that type, or just the first (AKA minecraft:stone 0) only?
(Also, was that the correct metadata? If not, what's the right way?)
What happens if a blockname is misspelled? Does it ignore all blocks, or just that one?
As for the issue I had:
I set acceptable_target_blocks to only stone from a mod, but the ruin still spawned on other blocks (this was in another dimension BTW).
So, I set all the other blocks in unacceptable_target_blocks, and then it did work.
So how do these two functions actualy work? Do I need to specify every block I DON'T want it to spawn on for every ruin?
I thought if you put a block in acceptable_target_blocks, it would only use those, but that doesn't seem to be the case.
Or, was my result just due to a fluke, or some other error on my part?
Since some dimensions share biomes, I rely heavily on block control to make sure ruins don't spawn in the wrong world (the top block is changed per dimension).
unique:
If I understand this correctly, setting it to 1 it will ONLY make it spawn once per biome, right?
If it is in Generic, it should only spawn once in total, right? Not "once per biome".
uniqueMinDistance:
What would be a good Distance, if I used this for spawning animals?
Default is 1500.
If I set it lower, they will spawn closer, but does anyone have any recomendations?
max_leveling:
If I don't want it to remove any blocks, what do I set it to? 0?
preserving air:
I can't seem to find the info for this.
How do I make it so the ruin keeps air or not?
Say I wanted to burry a skeleton dragon and needed the rock to surround the bones, not clear out the blocks when it's created. How do I do that? Does it have to do with the Base block I use?
Ruin distances to OTHER ruins:
I got some special ruins that I don't want showing up too close to each other; they are different types of ruins.
How do I make it so Ruin A wont spawn anywhere near Ruin B?
Any help would really be appreciated, and it would speed up the process.
Sorry if some seem a bit noobish; although I've read the Templates carefully, I'm still unsure of these things I listed.
If anyhting is confusing, just ask and I'll try to clarify it.
The "problem" you're seeing has nothing to do with weight; it's a consequence of setting uniqueMinDistance=1. I presume you didn't change the value of anyRuinsMinDistance in the Ruins.txt config file, so it's got its default value of 64. That means a #2 can be just 1 block away from another #2, but a #1 has to be at least 64 blocks away from a #2. Once a #2 is spawned, therefore, Ruins is going to keep picking #2 over and over until there's a gap of 64 blocks with no structures (e.g., a wide ocean, if the structures don't spawn on water) and #1 once again becomes an eligible selection, at which point a new random draw is made (33% chance of #1 or 67% of #2, according to the weight values) and the repetition begins anew.
If you want high-density Ruins, a better way to do it is leave uniqueMinDistance=0 in the template files (which is the default; 0 being a special value indicating the global value of templateInstancesMinDistance should be used), and instead set anyRuinsMinDistance=1 and templateInstancesMinDistance=1 in Ruins.txt. You should then get the result you expect.
In general, the value of uniqueMinDistance (and templateInstancesMinDistance) should be equal to or greater than that of anyRuinsMinDistance. Otherwise, you'll tend to get the homogeneity bias you observed, which is almost certainly undesirable. There may be some esoteric situations warranting violation of this guideline, but I can't think of any.
Ruins enforces a floor at Y=8. If you attempt to spawn a structure lower than that (due to, say, embed_into_distance=99999), it will simply spawn at Y=8.
Yes; that's standard Minecraft syntax. Note you may optionally omit the minecraft: part for vanilla blocks--just specifying stone, for instance, instead of minecraft:stone. Also note the "domain" (i.e., the identifier on the left side of the colon) isn't necessarily the name of the mod introducing that block; it usually is, but there are exceptions. Something to watch out for.
Ruins doesn't support metadata values in this context, so it always matches every block with the specified name. If you attempt to apply a metadata value here, it'll be misinterpreted as part of the name.
If a block name is unrecognized, that name is merely skipped. All valid names on the list will still apply. This allows you to specify blocks from mods which may or may not be installed...kind of. The catch is: if all names are invalid, it counts as an empty list, and an empty acceptable_target_blocks list is interpreted as "all blocks," possibly leading to undesirable behavior. Avoid this by including at least one vanilla block on the list. (The same concern does not apply to unacceptable_target_blocks, however, since an empty list there is interpreted as "no blocks.")
A template should specify either acceptable_target_blocks (i.e., spawn only on these) or unacceptable_target_blocks (spawn on anything but these), or neither (spawn on anything). It should never specify both.
I can't say for sure without seeing your template file, but I'd guess in your first attempt, acceptable_target_blocks listed either a misspelled block name or a block name from a mod that wasn't loaded. See the tip above on why this can cause trouble and how to avoid it by including some unlikely vanilla block name on the list (e.g., structure_void).
There is no parameter unique. The once-per-biome feature you describe does not currently exist in Ruins.
I'm not sure what "spawning animals" refers to. Ruins (currently) only places blocks, not entities. It can, however, place command blocks that spawn entities...is that what you mean?
Leveling is a whole other can of worms. If you don't want leveling--and most templates don't--set leveling_buffer=-1. Without leveling, the best way to think of max_leveling is as specifying how flat the terrain surface must be to spawn this template. If max_leveling=0, it must be perfectly flat over the entire footprint of the structure to be spawned; if max_leveling=1, it can deviate up and/or down by at most one block; and so on. The max_leveling parameter has nothing to do with blocks being removed if leveling is disabled.
There is a special "pseudo-block" you can use in template rules: preserveBlock. This is a directive telling Ruins not to replace the block in that position.
Since you mention base blocks, I suspect you're creating templates via the /parseruin command. If so, your template uses an implicit rule0 to represent air (sort of...this post is long enough without going into a full explanation). If you want your template embedded in a medium like dirt or stone without unsightly air pockets, you can manually edit the parseruin-generated template file to add a new preserveBlock rule onto the end of the rule list, and replace some or all of the 0's in the layers with this new rule. So, instead of...
...you would have...
This isn't currently supported in Ruins, at least not directly. As a workaround, though, you could perhaps create a third template C which simply consists of a single command block that spawns either an A or a B in its place. Move templates A and B to a non-biome folder so they aren't naturally generated on their own. Set C's uniqueMinDistance to some big number, like 4096, and voilà! Your A's and B's are widely separated.
That sound like what I tried doing with some of my "inferno dungeon spawners" and such: have a single template that plants a Command_Block that uses RUINTRIGGER to spawn one of several different dungeons, and then the idea is that if I try to reduce the density of "inferno dungeons" by setting a high "uniqueMinDistance," then collectively those dungeons will be rare. I think Gillymoth's templates utilize this sort of approach as well to modulate the spawning frequency of various types of structures.
However, as of Ruins for 1.13, I thought RUINSTRIGGER no longer works? I seem to recall that there was some new type of command block that had a setting to auto-execute, but I'm not sure how to implement that using the Ruins Command_Block functionality. (I guess maybe it would be possible via teBlock?)
--- 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 see, that certainly explains it.
One last question regarding Weight:
Ruins are weighed versus each other right?
If I want some ruins to be much rarer, should I UP the normal ruins weight higher?
Say, for an extreme example, I set ALL normal house ruins to 31, and one special castle as 1:
it would significantly lower the chance of the 1 castle ruin, but still allow it to spawn, just at a very very low chance?
Sweet, no worries then.
So if I ONLY use acceptable_target_blocks, it should work?
Also, good to know about the metadata. Thanks for the pointers; they will come in handy.
Really? I could have sworn I saw one.
But, I could just set uniqueMinDistance to really high, and it would basically get the same result, right (making it spawn just once)?
What's the highest number I can put in? Or, is there no limit?
Yes, it is done via commandblocks, specifically for CustomNPC Mod NPCs, since that particular mod doesn't have natural spawning.
So basically, if I set the number higher, it would have a higher chance to spawn, because it doesn't need to be flat, yes?
Then I should do that for NPC spawns since they're just commandblocks.
Or I could maybe use a block (say lapis) when I build and then replace that block with preserveBlock in the template?
Yeah, I mainly use /parseruin, then edit the ruin template.
I see. Thanks for the workaround! It will be very handy.
And thank you soo much for answering my questions; it helps a lot!
That's exactly right. A biome-specific template's weight is relative to that of all other biome-specific templates eligible to spawn in a particular biome; a generic template's is relative to all other generic templates. Unfortunately, the value of weight must be an integer, and the default is 1, so yes--you'd have to ratchet up everybody else's weight in order to make low-probability spawns, just as you described.
Or...it just so happens the very latest version of Ruins for Minecraft 1.12.2 adds support for non-integer weight values, so you could simply give your castle template a weight=0.03 and not have to futz with all the rest. However, that change went in after the most recent official release, so to get it you'd have to either pull the code down from GitHub and build it yourself, or cajole AtomicStryker (the owner of Ruins) into releasing an updated 1.12.2 version.
Incidentally, the latest version also includes two other things that might be of interest to you--a new dimensionsToSpawnIn template parameter and improved Galacticraft compatibility. Just sayin'.
Yes. In fact, I'd say that's ideal for most templates.
A ridiculously high uniqueMinDistance will effectively give you one spawn per dimension. The highest allowed value is Java's maximum signed int: 2,147,483,647. The highest meaningful value is twice Minecraft's maximum world size: 59,999,968. I'd just use a cool 60 mill, myself.
That's the right idea, though it's moot if your template is just a single command block--by definition, there's no height variation over a 1x1 area.
I think that's the method most template authors here use if there needs to be a distinction between air and preserveBlock. Maybe they'll chime in with some other tips as well.
If your structure doesn't need air pockets, however, it might be easiest just to replace rule0. By default, rule0 is implicitly defined as background air (i.e., air that doesn't replace most plants and respects preserve_water and preserve_lava settings). You can define your own replacement rule0; it's easy, but a bit funky. Put the following line before the first rule:
The rule name is intentionally missing, and this must precede all other rules. With this in place, your rule0 is now 100% preserveBlock.
Now that could be VERY useful since i use Galacticraft in my pack.
Sadly, I can't really putt together a build myself, so It would be nice if AtomicStryker released it.
Re: Minecraft Forum being Archived: Once that happens, will there be a preferred alternative channel for keeping up on news for Ruins?
--- 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)