QuarterAnimal did an amazing pull request on github, and i finally got around to merging it. For now 1.12.1 only. Could you test it a little? I do not seem to have the time ... at all.
I shall quote his "proposal" / explanation (which is more of a complete implementation) in entirety here:
# --- begin proposal ---
#
# The rule syntax was modified a bit to add some new features (variants and variant groups, in particular). None of these changes
# should break or alter the behavior of existing template files.
#
# Block Weighting: Instead of repeating block IDs in a rule to manipulate their probabilities of occurrence, weighting factors may
# now be used. This can make rules shorter and, in certain circumstances, more efficient. Apply a weight to an block in a rule by
# preceding it with a prefix of the form "n*"; this is functionally equivalent to repeating the same block n times. Valid values
# for n are integers between 1 and 99999, inclusive. For example, the following rules are essentially identical, each producing
# blocks of cobble, mossy cobble, and gravel with the same likelihood:
# rule1=0,100,cobblestone,cobblestone,mossy_cobblestone,cobblestone,gravel,cobblestone,mossy_cobblestone,mossy_cobblestone,cobblestone
# rule2=0,100,5*cobblestone,gravel,3*mossy_cobblestone
# Weights are optional. If no weight is specified for a block in a rule, a weight of 1 is assumed.
#
# Rule Variants: Consider a platform composed of many instances of the following rule3:
# rule3=0,100,stone,dirt,cobblestone
# Each generated structure will have a different random assortment of stone, dirt, and cobblestone blocks. Suppose, though, what
# you really want is each platform to be a single, randomly chosen material--either all stone, or all dirt, or all cobblestone.
# You can't do that with a regular rule, since a different color choice is made per block. You could do it with three separate
# templates, of course, but now there's another way. For example:
# rule4=0,100,stone
# ^0,100,dirt
# ^0,100,cobblestone
# Note "ruleXXX=" is replaced by "^" to indicate a line is a variant of the preceding rule, not a separate rule itself. Each time
# a structure with such a rule is generated, one of these variants is randomly chosen to apply to that entire structure wherever
# the corresponding number appears in the layer specifications.
#
# Rule Variant Weighting: Weights can be applied to rule variants to adjust the probability with which they are selected. As with
# block weighting, a prefix of the form "n*" is placed at the beginning of the variant (i.e., just after the = or ^) to assign it
# a weight. For example, you can use this rule for the windows in your structure:
# rule6=3*0,100,2*stained_glass-14
# ^0,100,stained_glass-4
# ^5*0,100,stained_glass-11
# Most of your generated structures will have blue windows (stained_glass-11, with a weight of 5), a little more than half as many
# will have red windows (stained_glass-14, with a weight of 3), and only a precious few will have yellow ones (stained_glass-4,
# with a weight of 1, the default when none is specified).
#
# Grouped Rule Variants: With variants, it may be desirable to coordinate several different rules to guarantee selections are
# only made in particular combinations. A named rule specification using ^ instead of = creates a new rule whose variant choice
# depends on that of the preceding rule. For example, make a small pillar with the following rule7 at the base and rule8 stacked
# above it:
# rule7=0,100,redstone_block
# ^0,100,gold_block
# ^0,100,lapis_block
# rule8^0,100,stained_glass-14
# ^0,100,stained_glass-4
# ^0,100,stained_glass-11
# When a structure chooses variant #1 of rule7, it will always choose variant #1 of rule8 as well, so pillars with redstone at the
# base will have red glass (stained_glass-14) on top. Similarly, gold blocks (rule7, variant #2) will be matched with yellow glass
# (rule8, variant #2) and lapis (rule7, variant #3) with blue (rule8, variant #3).
#
# Rule Variant Group Duplication: Suppose you have a structure with three fancy pillars, as described in the previous example.
# You could make four stacks of rules7 and 8. Different structures would have different kinds of pillars, but all three pillars of
# any one structure would be of the same type. To get variation within the same structure, you're going to need a separate group
# of rules for each pillar--one using rule7 and 8, one using 9 and 10, and one using 11 and 12.
# rule9=0,100,redstone_block
# ^0,100,gold_block
# ^0,100,lapis_block
# rule10^0,100,stained_glass-14
# ^0,100,stained_glass-4
# ^0,100,stained_glass-11
# rule11=0,100,redstone_block
# ^0,100,gold_block
# ^0,100,lapis_block
# rule12^0,100,stained_glass-14
# ^0,100,stained_glass-4
# ^0,100,stained_glass-11
# Note these rule groups are identical except for their names, and there's an easier way. By putting a repeat count of the form
# "n*" in front of the first rule name in a variant group (the one with an =), that many identical groups are automatically
# created. This is a bit tricky, because it does create new rules, which affects the way rules are numbered. To continue the
# example, rule7 could be changed slightly to take advantage of this feature:
# 3*rule7=0,100,redstone_block
# ^0,100,gold_block
# ^0,100,lapis_block
# rule8^0,100,stained_glass-14
# ^0,100,stained_glass-4
# ^0,100,stained_glass-11
# This creates rule7 and 8 as before, but also creates rule9, 10, 11, and 12, exactly as though these lines were cut and pasted
# into the template file 3 times. Note the rule names are irrelevant--rules are assigned numbers based on their ordinal position
# in the template (the first rule is 1, the second 2, and so on, regardless of their names).
#
# Alternate Rule 0: By default, rule 0 is an air block. You can now change it to something else by putting an unnamed rule at the
# top of your rule list:
# =0,100,stained_glass-7,stained_glass-8
# It has to appear before any other rule. It cannot be a variant of a preceding rule (since there isn't one--it has to start with
# = instead of ^), but it can be followed by variants and/or grouped variant rules. It cannot have a repeat count.
#
# --- end proposal ---
#
Wowzers. I really, REALLY love the idea of block-weighting. That will be very useful for my "Le Chateau des Pyrenees" structure, wherein I wanted to have the rock interior have a chance for a few ores here and there, but not an especially high frequency of them.
The dependent rules make for some potential fun as well. I COULD simply make another template that builds the structure in Material A, another template in Material B, and another in Material C, but that has the side effect of leaving the possibility that the slightly-different structures might spawn right next to each other (not a big deal for a mere house foundation ruin, but more an issue for some special "dungeon" with uniqueMinDistance set that I don't want to litter the landscape with any great frequency).
For Alternate Rule 0: When a block has a less-than-100% chance of spawning, and it fails to spawn, would that space be occupied by Rule0?
I ask because one of my structures that I've had trouble with was an "underwater ruin" with some pillars of varying and semi-random height, but the end result is that there end up being gaps in the water where there *could* have potentially been pillar blocks, but instead it failed to spawn because of random chance or because there was no supporting block beneath it. (I only have this problem when my structure includes blocks that have a less-than-100% chance of being placed, and have "needs to be supported" dependency rules.) I suppose the problem should right itself if only something could force the water blocks to update and fill the gaps, but until that happens, it's an odd phenomenon and not quite what I'd intended. If this allows me to replace Rule0 with something else -- such as, say, water, or preserveBlock -- that might be a way of addressing the trouble I was running into.
Anyway, thanks for the added functionality! I'll give it a try in my 1.12 structures.
The new architecture for variations adds a good potential for randomness to generating structures. Using the rule variations for several different blocks in a template will an exponential effect on the variance of each build. And I see its potential to knock out entire walls and continuous sections of a build, making damaged buildings more to my personal liking, instead of making a mere random pockmark pattern on walls. I can finally create the general sense of variable material durability in a build, and make things conform to a "build order", where the framework is built before the walls on any specific level. It applies both to the sense of construction and destruction with respect to a build. I'm most excited about having randomly torn out contiguous sections of a build, the kind of aesthetic I've been doing with my designs already in a less random form.
Considering how the new features will hold up to backporting future templates to older versions, It looks like most of the differences in functionality changes are covered, except for the one case where "rule 0" is expected to be another block (most likely changed to "preserveBlock"). In this case, any template that absolutely needs Rule 0 to be something other than air is going to place Air instead of the needed block in older versions, which means that templates that rely on changing Rule 0 to something else will still have air as rule 0 in older versions, and if a future template needs preserveBlock as rule 0, it will completely carve out the area around it with air instead, so fair warning in this particular case.
Included a few examples of Sectional Damage and Build Order. The damage on my bridge uses 5 templates to make the Random Sectional Damage, and the other two illustrate using the new functionality for the same effect with a single template to get an infinite number of independently spawning large damaged sections.
(this next part applies to already existing rules format architecture, in response to Jordan's above text)
Having just yesterday uploaded the update for my ruin-set with shipwrecks on the seafloor, I've seen the opposite effect (these observations are for 1.12 and may vary depending on which previous version you last tested this in). In pre-existing versions, rules that have an overall chance under 100% will default to "preserveBlock" if the block is decided against spawning in that location. The rules I've tested this on have exactly one block. When making the block rule with a list of blocks, one should also be able to add preserveBlock to the end of the list to weight against spawning, as adding air to that list would make underwater bubbles, and adding water to the list will make flying water blocks if the structure doesn't get entirely submerged.
If you are still relying on string to remove water from structures from the time before I showed you the levellingbuffer=-1 setting, combined with my combined settings for Foundations, then that would explain it. Also, I flew around in a world with your ruins and you do still have rooms filled with string in certain underwater templates, and you should be informed that overuse of string is a known source of lag in game (although i'm not sure by how much and if that is any different than for any other partial blocks, or if it's because string has redstone capability and is checked more often by Minecraft's engine) A friend used string once to keep snow off roads in their city, and they found out the extent of this, so it's good to know.
I COULD simply make another template that builds the structure in Material A, another template in Material B, and another in Material C, but that has the side effect of leaving the possibility that the slightly-different structures might spawn right next to each other...
Interesting. I didn't think of that, but you're right--using variants instead of different templates means you get the "benefit" of keeping similar structures separated by templateInstancesMinDistance or uniqueMinDistance. I'd think that would usually be a desirable thing, but there's still the option of making old school individual templates when it's not.
When a block has a less-than-100% chance of spawning, and it fails to spawn, would that space be occupied by Rule0?
No, it would effectively be occupied by preserveBlock (i.e., the existing block in that space remains unaffected). I didn't change that behavior; it worked that way before, and still does.
I ask because one of my structures that I've had trouble with was an "underwater ruin" with some pillars of varying and semi-random height, but the end result is that there end up being gaps in the water...
I know exactly what you're talking about, but a new rule0 isn't going to help you. The problem isn't the less-than-100% block, it's the conditional one. When the structure is being built, conditional block spaces are "temporarily" replaced by air blocks until all the unconditional ones are filled in, then the conditional ones are considered. Unfortunately, where the condition fails, the placeholder air block remains. I didn't change that behavior, either.
You might try using rule variants instead of conditional rules, though. It's a bit more verbose, but I think it gives you what you want. So, rather than, say:
rule1=0,80,log
rule2=2,80,log
layer
1,2,2,2,2
endlayer
you could use something like:
rule1=8*0,100,log
^2*0,100,preserveBlock
rule2^6*0,100,log
^0,100,preserveBlock
rule3^5*0,100,log
^0,100,preserveBlock
rule4^4*0,100,log
^0,100,preserveBlock
rule5^2*0,100,log
^0,100,preserveBlock
layer
1,2,3,4,5
endlayer
No conditionals, so no pesky air blocks left hanging around. How does it work? With its weighted variants, rule1 effectively has 10 possible cases: cases 1 through 8 are log, cases 9 and 10 are preserveBlock. That's the 80% (8 out of 10) you wanted for block 1. rule2 is "linked" to rule1 (because of the ^ instead of = in its specification), so it always chooses the same case as the previous rule. For rule2, cases 1 through 6 are log, while cases 7 through 10 are preserveBlock (rule2 looks like it only has 7 cases, but the last variant is repeated as necessary when there are too few--I could've written the second variant as ^4*0,100,preserveBlock, but I'm too lazy to type all thatI wanted to be clever I wanted to illustrate how variant padding works). Since every case of rule2 as log also has rule1 as log, and so on with the subsequent rules, you get the connectivity you need; there won't be gaps.
Considering how the new features will hold up to backporting future templates to older versions, It looks like most of the differences in functionality changes are covered, except for the one case where "rule 0" is expected to be another block...
I made no attempt to maintain compatibility between new templates and older versions of the mod--rule0 will be the least of your worries if you try to use these new features in previous builds. Nameless rules, and any rules that include variants, weights, or repeat counts will be rejected at best, or hilariously misinterpreted at worst. I did, however, try very hard to make sure any old, existing templates will still work fine with the new version of the mod. If you don't use the new features, they're invisible. If you do use them, you're pinned to Ruins 16.8 (or later).
Incidentally, the default rule0 is (and always has been) kind of funky. It's not a normal air block; it respects the template's preserve_water and preserve_lava settings. Nor is it a preserveBlock, because it does replace all other unprotected blocks with air. The only way to get that special background block, if you need it, is by leaving rule0 alone.
Welcome to the forums QuarterAnimal, and thank you for the dedication to the codebase.
Yeah, I can see how the "hilariously misinterpreted" block list can happen, once I cut and paste the rules from one file into the layers of another, thinking they would use the same list, and the resulting template had all the wrong blocks used everywhere, and it was indeed hilarious. I'm totally fine with having the responsibility of designing templates that work in different cases still work, being with the template designers themselves, and I'll test for places where the new syntax can still be used transparently with previous versions, even if in just a few minor ways, as the new functionality has good potential for efficient implementations.
Wups, this is on the top of the next page, there are important details for Ruins at the bottom of the previous page, especially for anyone who makes custom templates.
And I might as well post the link to the ruinset update I released yesterday at this time (hides)
you could use something like:
rule1=8*0,100,log ^2*0,100,preserveBlock rule2^6*0,100,log ^0,100,preserveBlock rule3^5*0,100,log ^0,100,preserveBlock rule4^4*0,100,log ^0,100,preserveBlock rule5^2*0,100,log ^0,100,preserveBlock
layer 1,2,3,4,5 endlayer
Fascinating! (EDIT: Deleted a lot of supposition about how things work that, now that I reread the post I'm replying to, is COMPLETELY WRONG.)
*
It took me a couple of tries to realize that I simply had the wrong version of Ruins and MC installed. (I.e., changes are for MC 1.12.1.) With the correct versions of Minecraft, Forge, and Ruins installed, it appears to work now. Yay! Thanks for the added functionality!
I'm totally fine with having the responsibility of designing templates that ... can still be used transparently with previous versions...
If that's a thing, I propose adding a few simple special comment directives to assist in your noble task. One set to hide older, legacy sections of a template from new versions of the Ruins mod:
# only versions prior to 16.8 will see these lines
#[[HIDE 16.8
rule1=0,100,stone,cobblestone
rule2=0,100,gravel,sand
#]]HIDE
Another set to hide all the newfangled stuff from older versions:
# only versions 16.8 and later will see these lines
#[[SHOW 16.8
#rule1=0,100,stone
#^0,100,cobblestone
#rule2^0,100,gravel
#^0,100,sand
#]]SHOW
It's a bit weird--especially the uncommenting SHOW directive that strips # from comment lines--but you kind of need to do something like that so it works with versions prior to when this feature was even added (they just see harmless comments). It's either that or a time-traveling DeLorean.
Hi, I'm currently working on a new MC1.12.1 modpack for my friends to play on and have installed the Ruins mod, and it has been working fine until I decided to add some extra structures.
Since I added Gillymoth's, Jordan_Peacock's and ST753M's ruins. I have noticed a few issues.
Gillymoth files seeming to have problems:
GillyProxyPlains.tml - Don't have biomes set for spawning so they give an ArrayIndexOutOfBounds error - I fixed this by adding in the missing biome info to each of the four files from lavender_fields, meadow, prairie, and flower_field.
Gilly\GillyGardenVines.tml - rule1=0,100 duplicated on the same line causing an error where it thinks it is using numeric blockIDs
ST753M files seeming to have problems:
BoP Generic\BoPGeode.tml - rule3^0,100 should be rule3=0,100
Generic\Geode_Large.tml - rule3^0,100 as above
Generic\Geode_Med.tml - rule3^0,100
Generic\Geode_Small.tml - rule3^0,100
River\Raft.tml - rule4^0,100
Mesa\Meteor_Big.tml - rule4^0,100, rule5^0,100 and rule6^0,100
Mesa\Meteor_Small.tml - rule3,0,100
Forest\RoundRuin1.tml - rule3^0,100, rule4^0,100 and rule5^0,100
Forest\RoundRuin2.tml - rule3^0,100, rule4^0,100 and rule5^0,100
ExtremeHills\SkyIsleVillage.tml - rule82^0,100, rule83^0,100 and rule84^0,100
Desert\Pyramid_Fancytiles.tml - rule3^0,100, rule4^0,100 and rule5^0,100
Mutated_Plains\Oval_Fountain.tml - rules5^0,100, rules6^0,100 and rules7^0,100
Pam's Harvescraft Roofed_Forest\Woodland_Kitchen.tml is using blocks from Cooking for Blockheads mod, but there is no mention of it in the readme so that one won't load properly for people without that mod installed.
Pam's Harvescraft Optional\FineRestaurant.tml also has blocks from the mod Cooking for Blockheads.
There is also a copy of the ST753M folder inside the Jungle folder that is not needed there (This was the 1.12.1 zip file)
Another thing with ST753M files, If I keep the ice_flats\IceHuts_1 to 5 files, I get a crash on loading the server with stackOverflowErrors: https://pastebin.com/TPKLtkzz
Jordan Peacock's files seeming to have problems:
HauntedHouse_CB_1v12.tml - rule29 contains rule2=0,100 three times, causing the mod to treat it like it is using numeric blockIDs
The Meaning of Life, the Universe, and Everything.
Location:
Friendship, NY
Join Date:
12/26/2010
Posts:
639
Minecraft:
LunariusH
Member Details
I was wondering if anyone had come up with a method of making load bearing bosses for ruins? I'm wanting to essentially have certain ruins be indestructible without having to use indestructible blocks, and then once some condition is reached, the blocks would cease to be indestructible. Is there a clever command block method to handle it? Something similar I'm not thinking of?
Rollback Post to RevisionRollBack
"Compatability is King, but configuratiblity is Queen" - InfinityRaider
Thanks for the heads up, I'm surprised that my stuff doesn't have a huge amount more errors, considering that some of them are very much thrown together. I should read the console more when flying around in the test worlds, to catch such things.
BoP Generic\BoPGeode.tml - rule3^0,100 should be rule3=0,100
Generic\Geode_Large.tml - rule3^0,100 as above
Generic\Geode_Med.tml - rule3^0,100
Generic\Geode_Small.tml - rule3^0,100
River\Raft.tml - rule4^0,100
Mesa\Meteor_Big.tml - rule4^0,100, rule5^0,100 and rule6^0,100
Mesa\Meteor_Small.tml - rule3,0,100
Forest\RoundRuin1.tml - rule3^0,100, rule4^0,100 and rule5^0,100
Forest\RoundRuin2.tml - rule3^0,100, rule4^0,100 and rule5^0,100
ExtremeHills\SkyIsleVillage.tml - rule82^0,100, rule83^0,100 and rule84^0,100
Desert\Pyramid_Fancytiles.tml - rule3^0,100, rule4^0,100 and rule5^0,100
Mutated_Plains\Oval_Fountain.tml - rules5^0,100, rules6^0,100 and rules7^0,100
Pam's Harvescraft Roofed_Forest\Woodland_Kitchen.tml is using blocks from Cooking for Blockheads mod, but there is no mention of it in the readme so that one won't load properly for people without that mod installed.
Pam's Harvescraft Optional\FineRestaurant.tml also has blocks from the mod Cooking for Blockheads.
There is also a copy of the ST753M folder inside the Jungle folder that is not needed there (This was the 1.12.1 zip file)
Another thing with ST753M files, If I keep the ice_flats\IceHuts_1 to 5 files, I get a crash on loading the server with stackOverflowErrors: https://pastebin.com/TPKLtkzz
The rule#^0,100 rules are intentional, using the Grouped Rule Variance in the new rules listed in post #4122. They seem to be working properly when I /testruin them on all of those, and appearing in the right color combinations out in the wild when I checked that too. What problem are you having, and are you sure you're using the 1.12.1 version of Ruins?
Sorry about the cooking for blockheads thing. Playing with Cooking for Blockheads is so important to keeping Harvestcraft straight when playing I forgot that C4B wasn't a prerequisite for actually loading Harvestcraft. I'll put a little readme in with a list of those (and any future C4B templates).
I could have sworn I fixed that ice huts problem already. Fixing it again now.
Thank you for finding these. I've just updated my 1.12 and 1.12.1 sets. Let me know if anything else breaks.
Lunarius, I played with such mechanics a year and a half ago outside of the context of Ruins. Things like this work well in a controlled setting, and a survival map is less than controlled, considering that players will insist on mis-using the command-affected area as a farm for things other than mob fights. I'll have to look into it.
Since it would only have to work in the context of a certain modpack, then modded features such as the mcjty forcefield could be used to protect an area effectively, and it could be set up to ensure the forcefield generator doesn't fall into the hands of players after the battle.
In response to ST putting templates into circulation using the newest version's syntax, even if the newest version is meant to already be released for general use, it might be good to consider the new features as "Indev" until the new version finds it's way into actual general use, as certain parts of the new syntax break when run in any previous version.
My sets are only meant to be played with the Ruins version they're named after, so there shouldn't be that problem. Even before new rules, there was enough changes between minecraft versions to warrant making different sets per version (CaveSpider changing to Cave_Spider, EntityHorse splitting up, new blocks like concrete, new gamerules, changes in the biome name system, etc.) The "^ Rules" version of Ruins is the only one specifically labeled as 1.12.1, though I admit it could get confusing with nearly all 1.12 mods still working in 1.12.1.
Ah, I didn't think they were deliberate as when I leave them in, the log file fills up with sections like this:
There was a problem loading the file: SkyIsleVillage.tml
java.lang.NumberFormatException: For input string: "rule82^0"
at java.lang.NumberFormatException.forInputString(Unknown Source)
at java.lang.Integer.parseInt(Unknown Source)
at java.lang.Integer.parseInt(Unknown Source)
at atomicstryker.ruins.common.RuinTemplateRule.<init>(RuinTemplateRule.java:81)
at atomicstryker.ruins.common.RuinTemplate.parseFile(RuinTemplate.java:609)
at atomicstryker.ruins.common.RuinTemplate.<init>(RuinTemplate.java:72)
at atomicstryker.ruins.common.RuinTemplate.<init>(RuinTemplate.java:78)
at atomicstryker.ruins.common.FileHandler.addRuins(FileHandler.java:343)
at atomicstryker.ruins.common.FileHandler.loadSpecificTemplates(FileHandler.java:202)
at atomicstryker.ruins.common.FileHandler.access$700(FileHandler.java:21)
at atomicstryker.ruins.common.FileHandler$LoaderThread.run(FileHandler.java:130)
I am having loads of fun finding all the different builds around my world though. Just got murdered by a bunch of cave spiders in a barn I found near a large forest
Just checked, I'm using the 1.12 version. Just gonna try with the 1.12.1 version from the post on the previous page now.
how do I make structures for the end dimension? should the folder be called sky? or end? (1.7.10)
Where? I don't see a batch or jar in the download...may have a link please?
in 1.7 there is a folder called "The End" in the filepath mods/resources/ruins, and that is where templates go to spawn them in the end dimension.
Gillymoth Structures for Ruins <<< Folder containing my Structure-sets for Ruins mod.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumQuarterAnimal did an amazing pull request on github, and i finally got around to merging it. For now 1.12.1 only. Could you test it a little? I do not seem to have the time ... at all.
https://github.com/AtomicStryker/github.io/blob/master/files/1.12.1/Ruins-1.12.1.jar?raw=true
I shall quote his "proposal" / explanation (which is more of a complete implementation) in entirety here:
# --- begin proposal ---
#
# The rule syntax was modified a bit to add some new features (variants and variant groups, in particular). None of these changes
# should break or alter the behavior of existing template files.
#
# Block Weighting: Instead of repeating block IDs in a rule to manipulate their probabilities of occurrence, weighting factors may
# now be used. This can make rules shorter and, in certain circumstances, more efficient. Apply a weight to an block in a rule by
# preceding it with a prefix of the form "n*"; this is functionally equivalent to repeating the same block n times. Valid values
# for n are integers between 1 and 99999, inclusive. For example, the following rules are essentially identical, each producing
# blocks of cobble, mossy cobble, and gravel with the same likelihood:
# rule1=0,100,cobblestone,cobblestone,mossy_cobblestone,cobblestone,gravel,cobblestone,mossy_cobblestone,mossy_cobblestone,cobblestone
# rule2=0,100,5*cobblestone,gravel,3*mossy_cobblestone
# Weights are optional. If no weight is specified for a block in a rule, a weight of 1 is assumed.
#
# Rule Variants: Consider a platform composed of many instances of the following rule3:
# rule3=0,100,stone,dirt,cobblestone
# Each generated structure will have a different random assortment of stone, dirt, and cobblestone blocks. Suppose, though, what
# you really want is each platform to be a single, randomly chosen material--either all stone, or all dirt, or all cobblestone.
# You can't do that with a regular rule, since a different color choice is made per block. You could do it with three separate
# templates, of course, but now there's another way. For example:
# rule4=0,100,stone
# ^0,100,dirt
# ^0,100,cobblestone
# Note "ruleXXX=" is replaced by "^" to indicate a line is a variant of the preceding rule, not a separate rule itself. Each time
# a structure with such a rule is generated, one of these variants is randomly chosen to apply to that entire structure wherever
# the corresponding number appears in the layer specifications.
#
# Rule Variant Weighting: Weights can be applied to rule variants to adjust the probability with which they are selected. As with
# block weighting, a prefix of the form "n*" is placed at the beginning of the variant (i.e., just after the = or ^) to assign it
# a weight. For example, you can use this rule for the windows in your structure:
# rule6=3*0,100,2*stained_glass-14
# ^0,100,stained_glass-4
# ^5*0,100,stained_glass-11
# Most of your generated structures will have blue windows (stained_glass-11, with a weight of 5), a little more than half as many
# will have red windows (stained_glass-14, with a weight of 3), and only a precious few will have yellow ones (stained_glass-4,
# with a weight of 1, the default when none is specified).
#
# Grouped Rule Variants: With variants, it may be desirable to coordinate several different rules to guarantee selections are
# only made in particular combinations. A named rule specification using ^ instead of = creates a new rule whose variant choice
# depends on that of the preceding rule. For example, make a small pillar with the following rule7 at the base and rule8 stacked
# above it:
# rule7=0,100,redstone_block
# ^0,100,gold_block
# ^0,100,lapis_block
# rule8^0,100,stained_glass-14
# ^0,100,stained_glass-4
# ^0,100,stained_glass-11
# When a structure chooses variant #1 of rule7, it will always choose variant #1 of rule8 as well, so pillars with redstone at the
# base will have red glass (stained_glass-14) on top. Similarly, gold blocks (rule7, variant #2) will be matched with yellow glass
# (rule8, variant #2) and lapis (rule7, variant #3) with blue (rule8, variant #3).
#
# Rule Variant Group Duplication: Suppose you have a structure with three fancy pillars, as described in the previous example.
# You could make four stacks of rules7 and 8. Different structures would have different kinds of pillars, but all three pillars of
# any one structure would be of the same type. To get variation within the same structure, you're going to need a separate group
# of rules for each pillar--one using rule7 and 8, one using 9 and 10, and one using 11 and 12.
# rule9=0,100,redstone_block
# ^0,100,gold_block
# ^0,100,lapis_block
# rule10^0,100,stained_glass-14
# ^0,100,stained_glass-4
# ^0,100,stained_glass-11
# rule11=0,100,redstone_block
# ^0,100,gold_block
# ^0,100,lapis_block
# rule12^0,100,stained_glass-14
# ^0,100,stained_glass-4
# ^0,100,stained_glass-11
# Note these rule groups are identical except for their names, and there's an easier way. By putting a repeat count of the form
# "n*" in front of the first rule name in a variant group (the one with an =), that many identical groups are automatically
# created. This is a bit tricky, because it does create new rules, which affects the way rules are numbered. To continue the
# example, rule7 could be changed slightly to take advantage of this feature:
# 3*rule7=0,100,redstone_block
# ^0,100,gold_block
# ^0,100,lapis_block
# rule8^0,100,stained_glass-14
# ^0,100,stained_glass-4
# ^0,100,stained_glass-11
# This creates rule7 and 8 as before, but also creates rule9, 10, 11, and 12, exactly as though these lines were cut and pasted
# into the template file 3 times. Note the rule names are irrelevant--rules are assigned numbers based on their ordinal position
# in the template (the first rule is 1, the second 2, and so on, regardless of their names).
#
# Alternate Rule 0: By default, rule 0 is an air block. You can now change it to something else by putting an unnamed rule at the
# top of your rule list:
# =0,100,stained_glass-7,stained_glass-8
# It has to appear before any other rule. It cannot be a variant of a preceding rule (since there isn't one--it has to start with
# = instead of ^), but it can be followed by variants and/or grouped variant rules. It cannot have a repeat count.
#
# --- end proposal ---
#
Wowzers. I really, REALLY love the idea of block-weighting. That will be very useful for my "Le Chateau des Pyrenees" structure, wherein I wanted to have the rock interior have a chance for a few ores here and there, but not an especially high frequency of them.
The dependent rules make for some potential fun as well. I COULD simply make another template that builds the structure in Material A, another template in Material B, and another in Material C, but that has the side effect of leaving the possibility that the slightly-different structures might spawn right next to each other (not a big deal for a mere house foundation ruin, but more an issue for some special "dungeon" with uniqueMinDistance set that I don't want to litter the landscape with any great frequency).
For Alternate Rule 0: When a block has a less-than-100% chance of spawning, and it fails to spawn, would that space be occupied by Rule0?
I ask because one of my structures that I've had trouble with was an "underwater ruin" with some pillars of varying and semi-random height, but the end result is that there end up being gaps in the water where there *could* have potentially been pillar blocks, but instead it failed to spawn because of random chance or because there was no supporting block beneath it. (I only have this problem when my structure includes blocks that have a less-than-100% chance of being placed, and have "needs to be supported" dependency rules.) I suppose the problem should right itself if only something could force the water blocks to update and fill the gaps, but until that happens, it's an odd phenomenon and not quite what I'd intended. If this allows me to replace Rule0 with something else -- such as, say, water, or preserveBlock -- that might be a way of addressing the trouble I was running into.
Anyway, thanks for the added functionality! I'll give it a try in my 1.12 structures.
--- 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 new architecture for variations adds a good potential for randomness to generating structures. Using the rule variations for several different blocks in a template will an exponential effect on the variance of each build. And I see its potential to knock out entire walls and continuous sections of a build, making damaged buildings more to my personal liking, instead of making a mere random pockmark pattern on walls. I can finally create the general sense of variable material durability in a build, and make things conform to a "build order", where the framework is built before the walls on any specific level. It applies both to the sense of construction and destruction with respect to a build. I'm most excited about having randomly torn out contiguous sections of a build, the kind of aesthetic I've been doing with my designs already in a less random form.
Considering how the new features will hold up to backporting future templates to older versions, It looks like most of the differences in functionality changes are covered, except for the one case where "rule 0" is expected to be another block (most likely changed to "preserveBlock"). In this case, any template that absolutely needs Rule 0 to be something other than air is going to place Air instead of the needed block in older versions, which means that templates that rely on changing Rule 0 to something else will still have air as rule 0 in older versions, and if a future template needs preserveBlock as rule 0, it will completely carve out the area around it with air instead, so fair warning in this particular case.
Included a few examples of Sectional Damage and Build Order. The damage on my bridge uses 5 templates to make the Random Sectional Damage, and the other two illustrate using the new functionality for the same effect with a single template to get an infinite number of independently spawning large damaged sections.
(this next part applies to already existing rules format architecture, in response to Jordan's above text)
Having just yesterday uploaded the update for my ruin-set with shipwrecks on the seafloor, I've seen the opposite effect (these observations are for 1.12 and may vary depending on which previous version you last tested this in). In pre-existing versions, rules that have an overall chance under 100% will default to "preserveBlock" if the block is decided against spawning in that location. The rules I've tested this on have exactly one block. When making the block rule with a list of blocks, one should also be able to add preserveBlock to the end of the list to weight against spawning, as adding air to that list would make underwater bubbles, and adding water to the list will make flying water blocks if the structure doesn't get entirely submerged.
If you are still relying on string to remove water from structures from the time before I showed you the levellingbuffer=-1 setting, combined with my combined settings for Foundations, then that would explain it. Also, I flew around in a world with your ruins and you do still have rooms filled with string in certain underwater templates, and you should be informed that overuse of string is a known source of lag in game (although i'm not sure by how much and if that is any different than for any other partial blocks, or if it's because string has redstone capability and is checked more often by Minecraft's engine) A friend used string once to keep snow off roads in their city, and they found out the extent of this, so it's good to know.
Gillymoth Structures for Ruins <<< Folder containing my Structure-sets for Ruins mod.
Interesting. I didn't think of that, but you're right--using variants instead of different templates means you get the "benefit" of keeping similar structures separated by templateInstancesMinDistance or uniqueMinDistance. I'd think that would usually be a desirable thing, but there's still the option of making old school individual templates when it's not.
No, it would effectively be occupied by preserveBlock (i.e., the existing block in that space remains unaffected). I didn't change that behavior; it worked that way before, and still does.
I know exactly what you're talking about, but a new rule0 isn't going to help you. The problem isn't the less-than-100% block, it's the conditional one. When the structure is being built, conditional block spaces are "temporarily" replaced by air blocks until all the unconditional ones are filled in, then the conditional ones are considered. Unfortunately, where the condition fails, the placeholder air block remains. I didn't change that behavior, either.
You might try using rule variants instead of conditional rules, though. It's a bit more verbose, but I think it gives you what you want. So, rather than, say:
you could use something like:
No conditionals, so no pesky air blocks left hanging around. How does it work? With its weighted variants, rule1 effectively has 10 possible cases: cases 1 through 8 are log, cases 9 and 10 are preserveBlock. That's the 80% (8 out of 10) you wanted for block 1. rule2 is "linked" to rule1 (because of the ^ instead of = in its specification), so it always chooses the same case as the previous rule. For rule2, cases 1 through 6 are log, while cases 7 through 10 are preserveBlock (rule2 looks like it only has 7 cases, but the last variant is repeated as necessary when there are too few--I could've written the second variant as ^4*0,100,preserveBlock, but
I'm too lazy to type all thatI wanted to be cleverI wanted to illustrate how variant padding works). Since every case of rule2 as log also has rule1 as log, and so on with the subsequent rules, you get the connectivity you need; there won't be gaps.I made no attempt to maintain compatibility between new templates and older versions of the mod--rule0 will be the least of your worries if you try to use these new features in previous builds. Nameless rules, and any rules that include variants, weights, or repeat counts will be rejected at best, or hilariously misinterpreted at worst. I did, however, try very hard to make sure any old, existing templates will still work fine with the new version of the mod. If you don't use the new features, they're invisible. If you do use them, you're pinned to Ruins 16.8 (or later).
Incidentally, the default rule0 is (and always has been) kind of funky. It's not a normal air block; it respects the template's preserve_water and preserve_lava settings. Nor is it a preserveBlock, because it does replace all other unprotected blocks with air. The only way to get that special background block, if you need it, is by leaving rule0 alone.
Welcome to the forums QuarterAnimal, and thank you for the dedication to the codebase.
Yeah, I can see how the "hilariously misinterpreted" block list can happen, once I cut and paste the rules from one file into the layers of another, thinking they would use the same list, and the resulting template had all the wrong blocks used everywhere, and it was indeed hilarious. I'm totally fine with having the responsibility of designing templates that work in different cases still work, being with the template designers themselves, and I'll test for places where the new syntax can still be used transparently with previous versions, even if in just a few minor ways, as the new functionality has good potential for efficient implementations.
Wups, this is on the top of the next page, there are important details for Ruins at the bottom of the previous page, especially for anyone who makes custom templates.
And I might as well post the link to the ruinset update I released yesterday at this time (hides)
Ruin-set Gilly, Exploration update Sept 7 2017
Gillymoth Structures for Ruins <<< Folder containing my Structure-sets for Ruins mod.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThere's little need to worry, older Ruins versions will flat out refuse to load variant rules.
Fascinating! (EDIT: Deleted a lot of supposition about how things work that, now that I reread the post I'm replying to, is COMPLETELY WRONG.)
*
It took me a couple of tries to realize that I simply had the wrong version of Ruins and MC installed. (I.e., changes are for MC 1.12.1.) With the correct versions of Minecraft, Forge, and Ruins installed, it appears to work now. Yay!
--- 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 that's a thing, I propose adding a few simple special comment directives to assist in your noble task. One set to hide older, legacy sections of a template from new versions of the Ruins mod:
Another set to hide all the newfangled stuff from older versions:
It's a bit weird--especially the uncommenting SHOW directive that strips # from comment lines--but you kind of need to do something like that so it works with versions prior to when this feature was even added (they just see harmless comments). It's either that or a time-traveling DeLorean.
Hi, I'm currently working on a new MC1.12.1 modpack for my friends to play on and have installed the Ruins mod, and it has been working fine until I decided to add some extra structures.
Since I added Gillymoth's, Jordan_Peacock's and ST753M's ruins. I have noticed a few issues.
Gillymoth files seeming to have problems:
ST753M files seeming to have problems:
Jordan Peacock's files seeming to have problems:
Just a heads-up in case other people mention anything with these.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI was wondering if anyone had come up with a method of making load bearing bosses for ruins? I'm wanting to essentially have certain ruins be indestructible without having to use indestructible blocks, and then once some condition is reached, the blocks would cease to be indestructible. Is there a clever command block method to handle it? Something similar I'm not thinking of?
Thanks for the heads up, I'm surprised that my stuff doesn't have a huge amount more errors, considering that some of them are very much thrown together. I should read the console more when flying around in the test worlds, to catch such things.
Also thanks for having our builds as worldgen.
Gillymoth Structures for Ruins <<< Folder containing my Structure-sets for Ruins mod.
The rule#^0,100 rules are intentional, using the Grouped Rule Variance in the new rules listed in post #4122. They seem to be working properly when I /testruin them on all of those, and appearing in the right color combinations out in the wild when I checked that too. What problem are you having, and are you sure you're using the 1.12.1 version of Ruins?
Sorry about the cooking for blockheads thing. Playing with Cooking for Blockheads is so important to keeping Harvestcraft straight when playing I forgot that C4B wasn't a prerequisite for actually loading Harvestcraft. I'll put a little readme in with a list of those (and any future C4B templates).
I could have sworn I fixed that ice huts problem already. Fixing it again now.
Thank you for finding these. I've just updated my 1.12 and 1.12.1 sets. Let me know if anything else breaks.
More Ruins Templates: https://www.dropbox.com/sh/e8gwe4638lqbakd/AAD2nsMtDSBvezUADCYmo2s-a?dl=0 Templates for 1.10.2, 1.11.2, 1.12.2. Updated Dec 7, 2018.
My modpack, ParasCraft: An Exploration-based Pokecube Modpack https://minecraft.curseforge.com/projects/parascube
Lunarius, I played with such mechanics a year and a half ago outside of the context of Ruins. Things like this work well in a controlled setting, and a survival map is less than controlled, considering that players will insist on mis-using the command-affected area as a farm for things other than mob fights. I'll have to look into it.
Since it would only have to work in the context of a certain modpack, then modded features such as the mcjty forcefield could be used to protect an area effectively, and it could be set up to ensure the forcefield generator doesn't fall into the hands of players after the battle.
In response to ST putting templates into circulation using the newest version's syntax, even if the newest version is meant to already be released for general use, it might be good to consider the new features as "Indev" until the new version finds it's way into actual general use, as certain parts of the new syntax break when run in any previous version.
Gillymoth Structures for Ruins <<< Folder containing my Structure-sets for Ruins mod.
My sets are only meant to be played with the Ruins version they're named after, so there shouldn't be that problem. Even before new rules, there was enough changes between minecraft versions to warrant making different sets per version (CaveSpider changing to Cave_Spider, EntityHorse splitting up, new blocks like concrete, new gamerules, changes in the biome name system, etc.) The "^ Rules" version of Ruins is the only one specifically labeled as 1.12.1, though I admit it could get confusing with nearly all 1.12 mods still working in 1.12.1.
More Ruins Templates: https://www.dropbox.com/sh/e8gwe4638lqbakd/AAD2nsMtDSBvezUADCYmo2s-a?dl=0 Templates for 1.10.2, 1.11.2, 1.12.2. Updated Dec 7, 2018.
My modpack, ParasCraft: An Exploration-based Pokecube Modpack https://minecraft.curseforge.com/projects/parascube
Of course, addressing the release of templates that only work with an Indev version, there will be incompatibilities nonetheless.
Gillymoth Structures for Ruins <<< Folder containing my Structure-sets for Ruins mod.
Ah, I didn't think they were deliberate as when I leave them in, the log file fills up with sections like this:
I am having loads of fun finding all the different builds around my world though. Just got murdered by a bunch of cave spiders in a barn I found near a large forest
Just checked, I'm using the 1.12 version. Just gonna try with the 1.12.1 version from the post on the previous page now.
Upgrading the mod version fixed the issue, thanks