EDIT: To clarify...by "unnamed" I mean there's nothing (like "rule0" or "rule") to the left of the equals sign. I should probably come up with a better term, considering the only tag in my so-called unnamed rule is Name. Oh, well.
Huh. That's ... an odd sort of syntax, but, hey, I'll roll with it. Thanks for the clarification! (And the coding, of course.)
Added ruins:null pseudoblock for use in rules. When "placed," it does not affect the existing block in that position. Same as preserveBlock in previous versions. Example: rule5={Name:"ruins:null"}
Default rule0 is now ruins:null instead of minecraft:air
Is it possible to override the default "rule0"? For instance, if I had a template that was working with the default of 0 as "minecraft:air," could I set up an explicit definition of rule0 to define it that way for that particular template?
I'm at a total loss here SOMETHING is preventing this mod from writing to the BattletowerPositionsFile.txt but I cannot for the life of me figure it out. its not my antivirus as far as i can figure, and the minecraft.exe has access through it anyway. This persists across multiple saves.
I wasn't aware that Ruins would write anything to any files related to Battletowers.
Thanks a lot guys, this sure will make things easier.
Also i find myself using command blocks way more to spawn Ruins, it's been way more effective so far.
In other news, How would you guys recommend spawning in really LARGE ruins?
Would Using the adjoining_template Setting in small chunks be better than one large one?
If you can accomplish it with adjoining_template, I'd say go for it. There are some definite pros-and-cons.
Most of my early "mega-dungeon" structures make extensive use of Command Blocks firing off the "/testruin" command.
PRO: This still works fairly well for underground dungeons, as it allows me to make sure the dungeon modules line up properly with each other (rather than meandering up or down according to the level of the ground above it), AND it allows me to introduce some degree of randomization. (That is, I could have a rule that will randomly choose between "dungeon corridor A," "dungeon corridor B," or "spider-filled treasure room" in this location, for a little bit of variety, so not all my mega-dungeons are *exactly* alike.) Also -- I don't know if this is TRUE -- but my rationale was that by breaking the structure up into smaller bits that wouldn't all necessarily fire off *right as soon as the chunk was generated*, that I might break up server load. (That's been a big concern for multiplayer servers, as my friends tend to want to get modpacks that allow FLIGHT, and then someone starts shooting off in a random direction, exploring vast swathes of territory in search of some *particular* biome, or some "rare" spawning feature, and the resulting lag goes crazy.)
CON: First off, dungeons using this won't work on multiplayer servers that disable Command Blocks. (Sometimes, specific mods don't play well with them, so there's a reason for me to have "no-Command-Block" versions of my packs.) Secondly, it's just a bit weird to have a bunch of "template bombs" waiting to go off until someone gets close enough and moves across a chunk border for the thing to finally fire off. One moment, you see open ground and a tower of Command Blocks, and then -- BOOM! An evil castle and several outbuildings pop into existence. Also, I'm still in the process of trying to port my 1.12 templates over to 1.13, and last I heard, "RUINSTRIGGER" no longer functions in 1.13 onward, so that does away with all of my complex structures that relied on that. (I mean, maybe there's some clever way I can make "self-firing" Command Block chains, but that's something I'll have to experiment with, all over again, and at that point I probably won't be "converting" my old dungeons so much as completely replacing them with something optimized for the new method.)
Later on, I finally got around to using the adjoining_template system.
PRO: This is nice and straightforward for doing things on the surface, and works even if Command Blocks aren't enabled (or RUINSTRIGGER doesn't work for some reason as intended -- I've heard of certain mods interfering with *that*, too). You could, for example, have a custom village put together this way. You could even make a *walled* village, by making lots of wall segments spawning at different points around the village (just keeping in mind that elevation will change for each one, so some care has to be taken in how they line up next to each other).
CON: No randomization of content. The village is going to be just as you specify, and you can't have, say, a choice between Building A, B, or C for each "lot" of the village. The only "randomization" will be through the variance of the terrain upon which it spawns (i.e., a building or wall segment might be missing because there wasn't a valid target block at that location, or maybe there was a ravine at that point or a sky island over head, so that one piece is FAR apart from the others), or randomization within the structure itself.
Also, it doesn't work quite as well for underground structures unless you're in a superflat world, or unless you do some really clever work on making modules that will line up even with some elevation changes. (Gillymoth has done some *brilliant* work on this.)
...
EXCEPTION: A couple of ways to make underground dungeons in multiple segments that line up with each other, spawned by Adjoining_Template:
a) "Bedrock Dungeon." A Ruin won't spawn UNDERNEATH the minimum valid elevation. So, if you make a bunch of dungeon segments that use "embed_into_distance=128" or some other ridiculously high number, odds are high that it's going to go all the way down to bedrock, bump up a minimum predetermined distance (I forget how many layers are minimum) and then start building there. That's how I made my "Bedrock Rail" project, which is basically a hidden railway that runs some distance underground down near the bedrock: The only hope you have of FINDING it is if you happen to be mining very far down and blunder into it, or if you explore a cave system or abandoned mine that happens to intersect with it.
(Or, as in one of my disastrous failed experiments that Gillymoth can attest to, when I tried stretching the boundaries of just HOW FAR OUT Adjoining_Template could go, and ended up spawning a Bedrock Rail so far out from the spawn point that when it triggered, it spawned far, far into already-explored territory, and bulldozed its way right through Gillymoth's basement. Oops.)
You could theoretically provide a chance at "surface access" by having a really tall access tower link up with it, but there's no telling what the elevation of ground level will be above it, so you'd probably want a "tower" with open sides, and thus a chance of entry at multiple points (but of course, that point of entry could end up chopping off a lava lake or a water source, for added weirdness).
"Underwater Dungeon." One nice thing about the ocean is that (barring the occasional island), it's FLAT. Have your "dungeon" spawn in Ocean or Deep_Ocean only, require "water" as a valid target block, and have a hefty "embed_into_distance" (something less than 64) and you could have a dungeon complex underwater. (Just be sure all interior spaces are filled with "air" rather than defaulting to predefined rule0, or else the underwater dungeon just might be *flooded*.) One advantage of this over the Bedrock Dungeon is that you could have a central structure (say, a "Lighthouse" with spiral stairs or a ladder or two "teleport" Command Block mechanisms) that provides access to the dungeon complex up at water level.
There are certain steps that are commonly handled by editing the TML files in a text editor, this is one of them.
After the air (that needs to spawn in as air) is filled in with an otherwise unused block, the structure is saved as a template, and the entry in the file is changed to "air" instead of whatever block was used to represent it for the save.
This is usually one of the very last steps of structure development, as saving it again after spawning will undo the step.
Yeah, what I will often do for my structures is to fill the space with some sort of placeholder block -- either GLASS, or some color of STAINED_GLASS that I'm not using elsewhere in the structure. As of 1.12, it's a lot easier to do this with the /fill command.
(I typically choose GLASS or STAINED_GLASS as my filler block, because: a) I can still see through it, so my creation is still recognizable in my "workspace world" for identification purposes; It doesn't kill any grass blocks that might be buried underneath.)
Then, I can edit the corresponding rule in the .tml file to replace "minecraft:glass" or "minecraft:stained_glass-11" or whatever with "minecraft:air" -- originally done so I could make "air pockets" in underwater structures, but I've also found it useful if I want to keep trees and shrubbery out of a structure. (I just haven't done that consistently, since some of my structures were "ported" up to 1.12 from earlier versions where this didn't seem to be as much of a concern.)
I would guess that you are in a superflat world, since Ruins tries to keep from breaking the bottom of the world, as bedrock is meant to be permanent in general.
Oops. I didn't even think of that angle. I forgot that when I spawn a superflat world for Ruins construction, I have to customize it to give me a thicker dirt layer if I want to be able to test-spawn anything with a "basement" there. (I typically go with 1 layer bedrock, 62 layers dirt, 1 layer grass. However, when manually test-spawning complex "dungeons," I've also found it useful to just spawn an alternate superflat world with 64 layers of GLASS, so I can clearly see what's spawning underground.)
All I did was make a baseplate of stone, 5x5x1, and put a chest on top in the middle. When I spawn my "structure", it's floating about 5 blocks up. Why? D:
I can't see the area where you built, so there could be a number of factors. Lacking omniscience, I'll put forth a couple of suggestions regarding baseplate-building:
1) Stone is a lousy material for a baseplate. I'd recommend, in Creative Mode, using something far less common and unlikely to already be part of your environment, such as bedrock or blocks of diamond.
2) At the very least, if you're going to use something like stone for a baseplate, make sure that the baseplate isn't connected to the ground. Especially make sure it's not adjacent to MORE STONE in the environment. (I'm not sure whether Ruins distinguishes between sub-types of a block when determining the dimensions of a baseplate.)
I don't know that this would be relevant to your particular situation, but it could be worth a shot.
@phuongtbt6813566: It looks like an impressive project! So you converted it into a Ruins template? Does it actually function if it spawns as a Ruins structure during terrain generation? Also, are those yellow "caution stripe" blocks also part of NuclearCraft?
I'm using the 1.12.2 version of ruins mod, the sources where i get custom head code is from this website: https://minecraft-heads.com/ , i used the heads from custom heads category, not player head category, i will give you the template of my head test, i hope you will the answer for my problem.
In my "adventure" template pack for 1.12, in the "plains" biome folder, I have a template called "JG_TravelersInn_CB_1v12.tml" that serves as a testbed for using "custom heads" as table decorations. Due to the nature of using "player heads" as decoration, this only works if you're playing Minecraft with an internet connection; if playing Minecraft with Ruins on a computer that's offline, the resulting inn will just have a macabre display of disembodied heads or skulls on the tables instead.
Here's the "rule" used for the decorative head/blocks randomly placed on each table, as quoted from the template:
It's rather longer than it strictly needs to be, because I wanted an element of randomization, so there are four items that the Ruins builder picks from when placing an item on the table -- either "Beer," "Teacup," "Sandwich," or "Salad."
I didn't use "teBlock" for this one, contrary to my earlier post. (I remembered incorrectly. It's been a while since I ran this "experiment.") The idea is that a Command Block will be spawned in position one block above where I intend for the decorative "head" to appear. Thanks to the "RUINSTRIGGER" key at the start of the Command line, a script in the "Ruins" mod will trigger the Command Block automatically when the chunk containing the Command Block is active AND a player crosses a chunk border, and then the Command Block "self-destructs."
Otherwise, the command (minus the RUINSTRIGGER key) *should* be capable of summoning a customized "player head" with the information given. /setblock is used to place the block. The item is "skull" (head), but "SkullType" is set to 3 (player head), followed by an Owner key that requires both a unique "Id" tag, AND the texture "Value" tag. I copied and pasted the code from a web site very much like the "Minecraft Heads" site you referenced.
However, paging through the Minecraft Heads site, it looks as if the syntax has changed considerably, and it might be possible to accomplish the same thing with a much shorter player-reference ID. I'll have to do some experimentation and get back to this. (I notice that there is a section with code for Minecraft version "1.13+" -- so I hope that means it will be possible to do the same thing in 1.13 and 1.14, if I can tweak things a bit in my templates.)
Hello, could someone teach me how to place a custom head in ruins templates?
I try to make some decoration with those custom head but they all become normal head when i test them. :(((
Which version of Minecraft/Ruins are you using? One of my "Adventurers' Inn" templates specifically uses custom heads in order to make "mugs" and "food bowl" items on top of the tables, as a bit of an experiment, in version 1.12, but I haven't managed to translate the same effect into 1.13 or 1.14 yet (and I'm not sure if it's even possible anymore, since I'm not sure how the equivalent of "TEBLOCK" logic is handled now).
A build for 1.14.3 exists and can be found on curse. Templates from 1.13.2 should be compatible. No, there is still no templates included.
Huzzah! (Re: 1.14.3 build existing.) And, yeah, I'm still behind on getting my templates converted over to 1.13. Are there any major functional changes I should be mindful of between 1.13 and 1.14? (I.e., if I make a template that will work for 1.13, are there any known changes I'll have to make to it in order for it to work for 1.14 as well?)
Thanks for keeping this thing going! I really appreciate it!
Thanks for the heads-up! I was a bit confused when I saw there was a new-post activity notice. I'm glad to see this will be sticking around. I've been busy lately (with my "day job") so I haven't accomplished much Minecraft-wise lately, but I'm definitely looking forward to getting back to tinkering around with the latest version of Ruins as soon as things calm down a bit -- and actually having the forum around for fielding questions and such (and seeing what everyone else is up to) is an *awfully* nice extra.
Gillymoth and Jordan_Peacock: I'm making a modpack (working title is ParasCube, might change later) where I'd like to use your structures. From your readmes, this seems fine? Also, Gillymoth, do you mind if I make minor alterations to the structures for my pack? The change I want to make is to make custom chest loot for some of the houses.
That's fine with me. I'd love to see the finished pack, whenever it's done. (I'm not sure how I'll *find out* about it at this point, though, once this forum locks up. :/ )
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?)
0
Huh. That's ... an odd sort of syntax, but, hey, I'll roll with it. Thanks for the clarification!
(And the coding, of course.)
0
Is it possible to override the default "rule0"? For instance, if I had a template that was working with the default of 0 as "minecraft:air," could I set up an explicit definition of rule0 to define it that way for that particular template?
0
I wasn't aware that Ruins would write anything to any files related to Battletowers.
0
If you can accomplish it with adjoining_template, I'd say go for it. There are some definite pros-and-cons.
Most of my early "mega-dungeon" structures make extensive use of Command Blocks firing off the "/testruin" command.
PRO: This still works fairly well for underground dungeons, as it allows me to make sure the dungeon modules line up properly with each other (rather than meandering up or down according to the level of the ground above it), AND it allows me to introduce some degree of randomization. (That is, I could have a rule that will randomly choose between "dungeon corridor A," "dungeon corridor B," or "spider-filled treasure room" in this location, for a little bit of variety, so not all my mega-dungeons are *exactly* alike.) Also -- I don't know if this is TRUE -- but my rationale was that by breaking the structure up into smaller bits that wouldn't all necessarily fire off *right as soon as the chunk was generated*, that I might break up server load. (That's been a big concern for multiplayer servers, as my friends tend to want to get modpacks that allow FLIGHT, and then someone starts shooting off in a random direction, exploring vast swathes of territory in search of some *particular* biome, or some "rare" spawning feature, and the resulting lag goes crazy.)
CON: First off, dungeons using this won't work on multiplayer servers that disable Command Blocks. (Sometimes, specific mods don't play well with them, so there's a reason for me to have "no-Command-Block" versions of my packs.) Secondly, it's just a bit weird to have a bunch of "template bombs" waiting to go off until someone gets close enough and moves across a chunk border for the thing to finally fire off. One moment, you see open ground and a tower of Command Blocks, and then -- BOOM! An evil castle and several outbuildings pop into existence. Also, I'm still in the process of trying to port my 1.12 templates over to 1.13, and last I heard, "RUINSTRIGGER" no longer functions in 1.13 onward, so that does away with all of my complex structures that relied on that. (I mean, maybe there's some clever way I can make "self-firing" Command Block chains, but that's something I'll have to experiment with, all over again, and at that point I probably won't be "converting" my old dungeons so much as completely replacing them with something optimized for the new method.)
Later on, I finally got around to using the adjoining_template system.
PRO: This is nice and straightforward for doing things on the surface, and works even if Command Blocks aren't enabled (or RUINSTRIGGER doesn't work for some reason as intended -- I've heard of certain mods interfering with *that*, too). You could, for example, have a custom village put together this way. You could even make a *walled* village, by making lots of wall segments spawning at different points around the village (just keeping in mind that elevation will change for each one, so some care has to be taken in how they line up next to each other).
CON: No randomization of content. The village is going to be just as you specify, and you can't have, say, a choice between Building A, B, or C for each "lot" of the village. The only "randomization" will be through the variance of the terrain upon which it spawns (i.e., a building or wall segment might be missing because there wasn't a valid target block at that location, or maybe there was a ravine at that point or a sky island over head, so that one piece is FAR apart from the others), or randomization within the structure itself.
Also, it doesn't work quite as well for underground structures unless you're in a superflat world, or unless you do some really clever work on making modules that will line up even with some elevation changes. (Gillymoth has done some *brilliant* work on this.)
...
EXCEPTION: A couple of ways to make underground dungeons in multiple segments that line up with each other, spawned by Adjoining_Template:
a) "Bedrock Dungeon." A Ruin won't spawn UNDERNEATH the minimum valid elevation. So, if you make a bunch of dungeon segments that use "embed_into_distance=128" or some other ridiculously high number, odds are high that it's going to go all the way down to bedrock, bump up a minimum predetermined distance (I forget how many layers are minimum) and then start building there. That's how I made my "Bedrock Rail" project, which is basically a hidden railway that runs some distance underground down near the bedrock: The only hope you have of FINDING it is if you happen to be mining very far down and blunder into it, or if you explore a cave system or abandoned mine that happens to intersect with it.
(Or, as in one of my disastrous failed experiments that Gillymoth can attest to, when I tried stretching the boundaries of just HOW FAR OUT Adjoining_Template could go, and ended up spawning a Bedrock Rail so far out from the spawn point that when it triggered, it spawned far, far into already-explored territory, and bulldozed its way right through Gillymoth's basement. Oops.)
You could theoretically provide a chance at "surface access" by having a really tall access tower link up with it, but there's no telling what the elevation of ground level will be above it, so you'd probably want a "tower" with open sides, and thus a chance of entry at multiple points (but of course, that point of entry could end up chopping off a lava lake or a water source, for added weirdness).
0
Yeah, what I will often do for my structures is to fill the space with some sort of placeholder block -- either GLASS, or some color of STAINED_GLASS that I'm not using elsewhere in the structure. As of 1.12, it's a lot easier to do this with the /fill command.
It doesn't kill any grass blocks that might be buried underneath.)
(I typically choose GLASS or STAINED_GLASS as my filler block, because: a) I can still see through it, so my creation is still recognizable in my "workspace world" for identification purposes;
Then, I can edit the corresponding rule in the .tml file to replace "minecraft:glass" or "minecraft:stained_glass-11" or whatever with "minecraft:air" -- originally done so I could make "air pockets" in underwater structures, but I've also found it useful if I want to keep trees and shrubbery out of a structure. (I just haven't done that consistently, since some of my structures were "ported" up to 1.12 from earlier versions where this didn't seem to be as much of a concern.)
0
Oops. I didn't even think of that angle. I forgot that when I spawn a superflat world for Ruins construction, I have to customize it to give me a thicker dirt layer if I want to be able to test-spawn anything with a "basement" there. (I typically go with 1 layer bedrock, 62 layers dirt, 1 layer grass. However, when manually test-spawning complex "dungeons," I've also found it useful to just spawn an alternate superflat world with 64 layers of GLASS, so I can clearly see what's spawning underground.)
0
I can't see the area where you built, so there could be a number of factors. Lacking omniscience, I'll put forth a couple of suggestions regarding baseplate-building:
1) Stone is a lousy material for a baseplate. I'd recommend, in Creative Mode, using something far less common and unlikely to already be part of your environment, such as bedrock or blocks of diamond.
2) At the very least, if you're going to use something like stone for a baseplate, make sure that the baseplate isn't connected to the ground. Especially make sure it's not adjacent to MORE STONE in the environment. (I'm not sure whether Ruins distinguishes between sub-types of a block when determining the dimensions of a baseplate.)
I don't know that this would be relevant to your particular situation, but it could be worth a shot.
0
@phuongtbt6813566: It looks like an impressive project! So you converted it into a Ruins template? Does it actually function if it spawns as a Ruins structure during terrain generation? Also, are those yellow "caution stripe" blocks also part of NuclearCraft?
0
In my "adventure" template pack for 1.12, in the "plains" biome folder, I have a template called "JG_TravelersInn_CB_1v12.tml" that serves as a testbed for using "custom heads" as table decorations. Due to the nature of using "player heads" as decoration, this only works if you're playing Minecraft with an internet connection; if playing Minecraft with Ruins on a computer that's offline, the resulting inn will just have a macabre display of disembodied heads or skulls on the tables instead.
Here's the "rule" used for the decorative head/blocks randomly placed on each table, as quoted from the template:
It's rather longer than it strictly needs to be, because I wanted an element of randomization, so there are four items that the Ruins builder picks from when placing an item on the table -- either "Beer," "Teacup," "Sandwich," or "Salad."
I didn't use "teBlock" for this one, contrary to my earlier post. (I remembered incorrectly. It's been a while since I ran this "experiment.") The idea is that a Command Block will be spawned in position one block above where I intend for the decorative "head" to appear. Thanks to the "RUINSTRIGGER" key at the start of the Command line, a script in the "Ruins" mod will trigger the Command Block automatically when the chunk containing the Command Block is active AND a player crosses a chunk border, and then the Command Block "self-destructs."
Otherwise, the command (minus the RUINSTRIGGER key) *should* be capable of summoning a customized "player head" with the information given. /setblock is used to place the block. The item is "skull" (head), but "SkullType" is set to 3 (player head), followed by an Owner key that requires both a unique "Id" tag, AND the texture "Value" tag. I copied and pasted the code from a web site very much like the "Minecraft Heads" site you referenced.
However, paging through the Minecraft Heads site, it looks as if the syntax has changed considerably, and it might be possible to accomplish the same thing with a much shorter player-reference ID. I'll have to do some experimentation and get back to this. (I notice that there is a section with code for Minecraft version "1.13+" -- so I hope that means it will be possible to do the same thing in 1.13 and 1.14, if I can tweak things a bit in my templates.)
0
Which version of Minecraft/Ruins are you using? One of my "Adventurers' Inn" templates specifically uses custom heads in order to make "mugs" and "food bowl" items on top of the tables, as a bit of an experiment, in version 1.12, but I haven't managed to translate the same effect into 1.13 or 1.14 yet (and I'm not sure if it's even possible anymore, since I'm not sure how the equivalent of "TEBLOCK" logic is handled now).
0
Huzzah! (Re: 1.14.3 build existing.) And, yeah, I'm still behind on getting my templates converted over to 1.13. Are there any major functional changes I should be mindful of between 1.13 and 1.14? (I.e., if I make a template that will work for 1.13, are there any known changes I'll have to make to it in order for it to work for 1.14 as well?)
Thanks for keeping this thing going!
I really appreciate it!
0
Thanks for the heads-up! I was a bit confused when I saw there was a new-post activity notice. I'm glad to see this will be sticking around.
I've been busy lately (with my "day job") so I haven't accomplished much Minecraft-wise lately, but I'm definitely looking forward to getting back to tinkering around with the latest version of Ruins as soon as things calm down a bit -- and actually having the forum around for fielding questions and such (and seeing what everyone else is up to) is an *awfully* nice extra. 
0
That's fine with me.
I'd love to see the finished pack, whenever it's done. (I'm not sure how I'll *find out* about it at this point, though, once this forum locks up. :/ )
0
Re: Minecraft Forum being Archived: Once that happens, will there be a preferred alternative channel for keeping up on news for Ruins?
0
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?)