Metadata for blocks in world has been removed in today's snapshot, didn't realize that feature was already implemented for public testing. Storing directional data as "North" and "West" will make the rotational-mappings file obsolete for new versions, and I thought that change was a little further off than being upon us today.
I'm curious to see how AtomicStryker intends to address this. The use of metadata values from 0-15 is already deprecated in Minecraft 1.12 (maybe even earlier) and the API is already in place to use named properties instead. Unfortunately, I don't think the current "blocktype-metadata" syntax Ruins uses in its template files to define rules is extensible enough to handle what's coming. I have my own bleeding-edge experimental version in which I've adopted the upcoming standard Minecraft command syntax of "blocktype[properties]{tags}" (e.g., minecraft:furnace[facing=south,lit=false]{CustomName:"Fornax",Items:[{Slot:2,id:"minecraft:iron_block",Count:16}]} ...but just plain furnace still works, too, if you're happy with the defaults). Note this completely obviates special "teBlock" handling. I'm trying to make it compatible with the original syntax as well before I submit it as a pull request, but that's proving to be difficult. And then there's the matter of "-addbonemeal"...
Incidentally, with regard to the rotation_mappings.txt file--there's a way to eliminate the need for that altogether. I'll be submitting a pull request for that change after the holiday, after I've had time to test some wacky edge cases and interactions with other mods. Looks good so far.
Simply put, Every block in the game will have the same "NSEW" setting, whether the block rotates or not, so by obsolete, I mean that the file itself will no longer be needed in 1.13+, and this Federated data can be mapped to 0123 internally, however one sees fit.
Of course, there are lots of new data sets, like top/botton, etc, and those datasets will have to be reconsiled into the templates.
Simply put, Every block in the game will have the same "NSEW" setting, whether the block rotates or not...
Every block (technically, every block state, but the distinction isn't relevant here) has zero or more named properties, some of which may or may not be related to directional orientation. They're not all the same, though--not by a long shot. Many blocks, like dirt and stone, have no directional properties. The most common directional property is "facing," which often takes one of four possible values--"north," "east," "south," or "west"--as you describe, but for some blocks also includes possible values of "up" and/or "down." Granted, "up" and "down" aren't affected by rotation...but levers, for example, have additional "facing" values, such as "up_x" and "down_z," that are. Some blocks use an "axis" property instead, with values of "x," "y," or "z" (or, in the case of logs, "none"). Quartz pillars use a "variant" property for specifying orientation, rails use "shape," standing signs use "rotation" (which can take on 16 possible values). Some blocks (e.g., mushroom blocks) have "north," "east," "south," and "west" as separate attributes which can each be independently set true or false. A skull attached to a wall specifies its orientation by its "facing" property, but a skull on the floor uses the "Rot" tag in its associated tile entity. And that's just vanilla blocks!
The point is, block rotational orientation is neither simple nor consistent. Depending on its type, a block could have 1, 2, 4, 6, 8, or 16 different orientations, specified by any of a variety of ways. However, what all blocks (at least properly defined ones) DO have in common is they can all be properly rotated--regardless of their assorted funky properties--by the same one or two API calls. That's why the rotation mapping file and all the special case code can be eliminated. And better sooner than later: the API's support for handling 0-15 metadata values is already deprecated, and may be dropped altogether as early as 1.13. Making a named-property-based rotation mapping file would be nightmarish.
All my command blocks are likely to get scrambled by this (of course!) but I hope that at least for the regular block lines, there should be a one-to-one correspondence, so if there's some utility that can do search-replace across several text files at once, it could be possible to set up a type of conversion script. (I.e., what was once log-0 is now oak_log, and so on.)
Hey, at least "petrified wood" makes a comeback, according to the notes I've seen. I was disappointed when that was updated out of existence. It's very handy for making a cozy little cottage with a wooden slab roof and a netherrack fireplace without the roof burning down in short order. That, and a "bark block" appears to be formalized. (I've found all-bark "log" pieces to be handy for constructing gnarled giant trees.) I hope they'll keep the "all cap" or "all stem" mushroom blocks, since I made a few oddball buildings using those pieces.
All the "technical blocks" like smooth one-piece double slabs and petrified slabs have always been in the game (after their initial addition to the game), some of which have only been accessible for a long time using commands to either give to players or replace blocks directly in the world, in the case of the smooth full slab (or of course by changing the meta-data in the TML file).
The Federalized rotation data field means that the meta numbers already in use will not match the consolidated data set (simply because the old vanilla meta dataset had all sorts of numbers for a block facing "north", depending on the block), and we will find out how the new conventions will manifest in the structure files in a future version of Ruins.
At the very least, structures shouldn't need to be re-parsed in the new version after getting examples of the next version's parsing format for the rule numbers.
All the "technical blocks" like smooth one-piece double slabs and petrified slabs have always been in the game (after their initial addition to the game), some of which have only been accessible for a long time using commands to either give to players or replace blocks directly in the world, in the case of the smooth full slab (or of course by changing the meta-data in the TML file).
Well then, my misadventures in converting my templates between structures led me to be mistaken in thinking that wood-textured stone slabs were disabled at a certain point.
I also had trouble with a few other items that at one point I could spawn into existence in a treasure chest (e.g., an animated fire you could place in a picture frame, a "frame" of water that I could use as the surreal head for an invisible skeleton in order to make a "water elemental") but then suddenly a template (or at least a Command Block) would fail to work as advertised until I replaced the "offending" element with something else.
One thing I'm curious about is the hubbub about a new way of handling recipes. It looks like the snapshot 17w48a introduces a change whereby recipe data is stored in some sub-folder in "data packs." It'd be neat if I could come up with a new sort of unique "treasure" for dungeons, wherein, somehow during the installation process for my particular pack of Ruins templates (unloading the ZIP folder in the proper directory), a new recipe could be dropped in the appropriate folder, and then some dungeon has, as a prize, a recipe book that "unlocks" that new oddball recipe.
Not that this would be terribly exciting. I'm just grasping at ways in which I can add "new stuff" through Ruins (a "new" mob in the dungeon, a "magic item" in a treasure chest, etc.) without requiring the intervention of other mods. Maybe it'd be a new recipe that offers an alternative thing to do with "trash" items that accumulate in games, or create some new sort of "storage block" relationship. Say, 8 wheat seeds + 1 dirt block --> 1 grass block.
What I really wish, though, was if there were some JSON code I could use to make a written book "self-destruct" after use, but I suspect that's something that would require its own fancy mod (i.e., well beyond my ability). It's fairly easy to make a "spellbook" that can do something like summon lightning every time you click on a hyperlink, or summon a fireball from the sky targeted on your position, or perhaps it could summon a skeletal horse ... but the book is STILL THERE, so it becomes kind of stupid if you can just do it again and again without any sort of cost attached.
I've been working unofficially on a hack for Ruins that allows template sets that live under a "sets" subfolder of ruins_config. You create a folder with the name of the set - e.g. Gilly, Jordan_Greywolf - and then all the biome folders, templates and whatever go inside their respective set folders.
ruins_config/
generic/
plains/
desert/
...etc...
sets/
Gilly/
... biome and templates
Jordan_Greywolf/
... biome and templates
ST753M/
... biome and templates
This isolates the .tml files from one another but the mod merges them all together automatically when it loads. I've kept compatibility with the normal ruins_config biome folders structure, and also command blocks that use /testruin are relative to their set folder location. It's much easier to quickly add or remove an entire set of templates say based on naming conflict, mod compatibility or style without having to maintain lots of different copies of ruins_config.
EvertVd: One of the TFC modpacks had custom TFC-block structures a couple years ago, I think it was "TechnoFirmaCraft" and not "Tech Node Firmacraft". I'm currently playing a TFC world with a new modpack, and am pondering converting some of my favorite templates to that format.
Svenhjol: my naming convention of starting every filename with "Gilly" is designed to keep my templates from interacting with other player' content, and hoping that all players adopted unique markers for all their files, to prevent unexpected file interactions between each other as well. However I would suggest that keeping the file structure simple would make seeing what spawns in each biome in a single glance, and that files named with markers as a header serves to group files together for more clear presentation.
I've even gone so far as sub-grouping the filename headers a couple layers deep, to further group files into alike-groups, like "GillyFoundation___", "GillyShip___", and "GillySeafloor___". This way similar structures belonging to a series can be cut-pasted into or out of the folders in one go. This is done in the interest of finding things quickly, especially for other players who would not be familiar with the content, so instead of guessing at a hundred or so completely random filenames, they can search through 15 or so groups of alike objects and find things faster.
@Gillymoth: your naming convention is very clear and it's been one of the easier sets to work with. Some incredible builds there too I might add! What I'm proposing doesn't break compatibility with the current method of copy-pasting into biome folders at the ruins_config/ level, and creating a separate folder for custom templates is a sensible idea. Once you merge four or more sets together (with different naming conventions) it becomes a bit of a pain juggling different ruins_config folders for different scenarios. I just needed a way to be able to very quickly add or remove entire sets based on version or modpack without having to specially label each template with those details.
... hoping that all players adopted unique markers for all their files, to prevent unexpected file interactions between each other as well. ...
That sounds like a pretty good idea, actually. I guess I should go through my sets and put "JG" or "K10" (as appropriate) in front of our template names, next time I get around to uploading updates. Kujaku10 has made a few /parseruin templates that I need to get around to cleaning up and adding to the sets, while I'm at it.
Using the 1.7.10 version. I've looked through the text documents and the forum and I'm just not sure how to prevent certain structures from spawning. Or at least make them spawn less. The config file seems to only deal with global values.
Using the 1.7.10 version. I've looked through the text documents and the forum and I'm just not sure how to prevent certain structures from spawning. Or at least make them spawn less. The config file seems to only deal with global values.
Each structure has its own .tml file. If you want to stop a structure from spawning, you need to figure out which structure it is, and then remove the offending .tml file. If you just want to make it spawn less (but not go away entirely), then it gets more complicated.
If the template is in the "generic" folder, you could move it into one of the biome folders instead, and then it should only spawn in that biome UNLESS the "biomesToSpawnIn" field is specified in the template itself. (Templates can be edited with a typical text editor such as Wordpad. The "biomesToSpawnIn" field is usually toward the top of the template, near the header.)
(In theory, for any given template you could reduce the "weight=*" value in the template itself, but that's only going to help you if it has a "weight" value greater than 1 to start with.)
If you don't know which template is the culprit, you'll want to hunt down the "RuinsPositionsFile.txt" file in your world's save folder. It keeps a tally of every Ruins structure that has been spawned in your world, along with its coordinates. So, in game if you want a structure you dislike and want to see no more of, you could use F3 to show your current location as you go to the center of it, then compare those coordinates to the ranges in that document. There should be an entry very close to the coordinates of that structure (if indeed it was spawned by Ruins), and the name should give you a tip. If you have only installed the templates included with the basic Ruins mod, then any templates are likely to be in the generic, jungle, or ocean folders. "Generic" templates can appear (in theory) ANYWHERE in the world, regardless of biome.
Also, in my Dropbox folder I've got a collection of screen shots of example spawns of the various "generic" Ruins templates, to help in identification.
Ah. That is a bit complicated. But doable. Thanks.
Alas, yes. This is a very tinkery mod (but still fun!). Here's another possibility, in case there is a ruin you don't mind popping up once in a very great while:
In the template, there is an optional setting called "uniqueMinDistance." If it is not already specified in the template, you could add the following line somewhere near the header. (I usually put it right next to "biomesToSpawnIn.")
uniqueMinDistance=5000
What this means is that when terrain gen happens and the Ruins program randomly rolls up this particular template again for consideration, it will NOT build this structure if it is within 5000 blocks of the last recorded instance of this template spawning. (Please note: It doesn't matter whether or not that structure is *still there*. You could have demolished the previous instance, but the Ruins program has no way of knowing that. I think it just checks the listing of spawned structures for that world.)
The "5000" can be replaced with whatever other value you prefer. A bigger number means a greater distance between instances of this particular structure.
Please note that this only applies to instances of THIS particular template. You might have several different structures that you don't wish to see very many of, with a very high "uniqueMinDistance" value, but there's technically nothing stopping the Ruins program from spawning them all very close to your world entry point. It'll only be upon *further* exploration that this will come into play to ensure that they're fairly "rare" for the world.
(Alas, I haven't yet figured out any clever way to prevent a template from spawning at all UNTIL you travel some distance from the world entry point. About the only way I can think of to force that would be if, as part of my template installation, I offered a bogus "RuinsPositionsFile.txt" file as a world-starter that has false entries for each of the Ruins I don't want to appear near the game start, and set an appropriately high "uniqueMinDistance" for each one, so Ruins will "think" those buildings have already spawned once each near world-start and therefore not to build another one for quite some distance out.)
The Meaning of Life, the Universe, and Everything.
Join Date:
5/25/2017
Posts:
57
Member Details
I like to make unique dungeons that only spawn once per world and have something game-breaking inside, such as a sword with knockback and sharpness 10.
I'm curious to see how AtomicStryker intends to address this. The use of metadata values from 0-15 is already deprecated in Minecraft 1.12 (maybe even earlier) and the API is already in place to use named properties instead. Unfortunately, I don't think the current "blocktype-metadata" syntax Ruins uses in its template files to define rules is extensible enough to handle what's coming. I have my own bleeding-edge experimental version in which I've adopted the upcoming standard Minecraft command syntax of "blocktype[properties]{tags}" (e.g., minecraft:furnace[facing=south,lit=false]{CustomName:"Fornax",Items:[{Slot:2,id:"minecraft:iron_block",Count:16}]} ...but just plain furnace still works, too, if you're happy with the defaults). Note this completely obviates special "teBlock" handling. I'm trying to make it compatible with the original syntax as well before I submit it as a pull request, but that's proving to be difficult. And then there's the matter of "-addbonemeal"...
Incidentally, with regard to the rotation_mappings.txt file--there's a way to eliminate the need for that altogether. I'll be submitting a pull request for that change after the holiday, after I've had time to test some wacky edge cases and interactions with other mods. Looks good so far.
Internally, they _will_ have to save block rotation by some kind of number, no matter how they obfuscate that fact.
Using a built-in general rotation system would be nice.
Simply put, Every block in the game will have the same "NSEW" setting, whether the block rotates or not, so by obsolete, I mean that the file itself will no longer be needed in 1.13+, and this Federated data can be mapped to 0123 internally, however one sees fit.
Of course, there are lots of new data sets, like top/botton, etc, and those datasets will have to be reconsiled into the templates.
Gillymoth Structures for Ruins <<< Folder containing my Structure-sets for Ruins mod.
Every block (technically, every block state, but the distinction isn't relevant here) has zero or more named properties, some of which may or may not be related to directional orientation. They're not all the same, though--not by a long shot. Many blocks, like dirt and stone, have no directional properties. The most common directional property is "facing," which often takes one of four possible values--"north," "east," "south," or "west"--as you describe, but for some blocks also includes possible values of "up" and/or "down." Granted, "up" and "down" aren't affected by rotation...but levers, for example, have additional "facing" values, such as "up_x" and "down_z," that are. Some blocks use an "axis" property instead, with values of "x," "y," or "z" (or, in the case of logs, "none"). Quartz pillars use a "variant" property for specifying orientation, rails use "shape," standing signs use "rotation" (which can take on 16 possible values). Some blocks (e.g., mushroom blocks) have "north," "east," "south," and "west" as separate attributes which can each be independently set true or false. A skull attached to a wall specifies its orientation by its "facing" property, but a skull on the floor uses the "Rot" tag in its associated tile entity. And that's just vanilla blocks!
The point is, block rotational orientation is neither simple nor consistent. Depending on its type, a block could have 1, 2, 4, 6, 8, or 16 different orientations, specified by any of a variety of ways. However, what all blocks (at least properly defined ones) DO have in common is they can all be properly rotated--regardless of their assorted funky properties--by the same one or two API calls. That's why the rotation mapping file and all the special case code can be eliminated. And better sooner than later: the API's support for handling 0-15 metadata values is already deprecated, and may be dropped altogether as early as 1.13. Making a named-property-based rotation mapping file would be nightmarish.
My point is, THEY will have to implement this mapping. And i will make use of it.
All my command blocks are likely to get scrambled by this (of course!) but I hope that at least for the regular block lines, there should be a one-to-one correspondence, so if there's some utility that can do search-replace across several text files at once, it could be possible to set up a type of conversion script. (I.e., what was once log-0 is now oak_log, and so on.)
Hey, at least "petrified wood" makes a comeback, according to the notes I've seen. I was disappointed when that was updated out of existence. It's very handy for making a cozy little cottage with a wooden slab roof and a netherrack fireplace without the roof burning down in short order. That, and a "bark block" appears to be formalized. (I've found all-bark "log" pieces to be handy for constructing gnarled giant trees.) I hope they'll keep the "all cap" or "all stem" mushroom blocks, since I made a few oddball buildings using those pieces.
--- 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)
All the "technical blocks" like smooth one-piece double slabs and petrified slabs have always been in the game (after their initial addition to the game), some of which have only been accessible for a long time using commands to either give to players or replace blocks directly in the world, in the case of the smooth full slab (or of course by changing the meta-data in the TML file).
The Federalized rotation data field means that the meta numbers already in use will not match the consolidated data set (simply because the old vanilla meta dataset had all sorts of numbers for a block facing "north", depending on the block), and we will find out how the new conventions will manifest in the structure files in a future version of Ruins.
At the very least, structures shouldn't need to be re-parsed in the new version after getting examples of the next version's parsing format for the rule numbers.
Gillymoth Structures for Ruins <<< Folder containing my Structure-sets for Ruins mod.
Well then, my misadventures in converting my templates between structures led me to be mistaken in thinking that wood-textured stone slabs were disabled at a certain point.
I also had trouble with a few other items that at one point I could spawn into existence in a treasure chest (e.g., an animated fire you could place in a picture frame, a "frame" of water that I could use as the surreal head for an invisible skeleton in order to make a "water elemental") but then suddenly a template (or at least a Command Block) would fail to work as advertised until I replaced the "offending" element with something else.
One thing I'm curious about is the hubbub about a new way of handling recipes. It looks like the snapshot 17w48a introduces a change whereby recipe data is stored in some sub-folder in "data packs." It'd be neat if I could come up with a new sort of unique "treasure" for dungeons, wherein, somehow during the installation process for my particular pack of Ruins templates (unloading the ZIP folder in the proper directory), a new recipe could be dropped in the appropriate folder, and then some dungeon has, as a prize, a recipe book that "unlocks" that new oddball recipe.
Not that this would be terribly exciting. I'm just grasping at ways in which I can add "new stuff" through Ruins (a "new" mob in the dungeon, a "magic item" in a treasure chest, etc.) without requiring the intervention of other mods. Maybe it'd be a new recipe that offers an alternative thing to do with "trash" items that accumulate in games, or create some new sort of "storage block" relationship. Say, 8 wheat seeds + 1 dirt block --> 1 grass block.
What I really wish, though, was if there were some JSON code I could use to make a written book "self-destruct" after use, but I suspect that's something that would require its own fancy mod (i.e., well beyond my ability). It's fairly easy to make a "spellbook" that can do something like summon lightning every time you click on a hyperlink, or summon a fireball from the sky targeted on your position, or perhaps it could summon a skeletal horse ... but the book is STILL THERE, so it becomes kind of stupid if you can just do it again and again without any sort of cost attached.
--- Jordan's & Kujaku10's UNOFFICIAL Custom Templates:
Greywolf's Minecraft Ruins (MC versions 1.7.10-1.12.2; requires AtomicStryker's "Ruins" mod)
Latest Updates: v1.7 (May 2018) * v1.8 (Jun 2016) * v1.9 (Sep 2016) * v1.10 (Jan 2017) * v1.11 (Apr 2018) * v1.12.* (Dec 2018)
I've been working unofficially on a hack for Ruins that allows template sets that live under a "sets" subfolder of ruins_config. You create a folder with the name of the set - e.g. Gilly, Jordan_Greywolf - and then all the biome folders, templates and whatever go inside their respective set folders.
This isolates the .tml files from one another but the mod merges them all together automatically when it loads. I've kept compatibility with the normal ruins_config biome folders structure, and also command blocks that use /testruin are relative to their set folder location. It's much easier to quickly add or remove an entire set of templates say based on naming conflict, mod compatibility or style without having to maintain lots of different copies of ruins_config.
I've pushed a commit with this code back to github here: https://github.com/svenhjol/atomicstrykers-minecraft-mods/commit/c2b01217e3e64aefd6b92dee37832fa967a9a6a9 .
Does anyone know of TerraFirmaCraft templates for download anywhere?
EvertVd: One of the TFC modpacks had custom TFC-block structures a couple years ago, I think it was "TechnoFirmaCraft" and not "Tech Node Firmacraft". I'm currently playing a TFC world with a new modpack, and am pondering converting some of my favorite templates to that format.
Svenhjol: my naming convention of starting every filename with "Gilly" is designed to keep my templates from interacting with other player' content, and hoping that all players adopted unique markers for all their files, to prevent unexpected file interactions between each other as well. However I would suggest that keeping the file structure simple would make seeing what spawns in each biome in a single glance, and that files named with markers as a header serves to group files together for more clear presentation.
I've even gone so far as sub-grouping the filename headers a couple layers deep, to further group files into alike-groups, like "GillyFoundation___", "GillyShip___", and "GillySeafloor___". This way similar structures belonging to a series can be cut-pasted into or out of the folders in one go. This is done in the interest of finding things quickly, especially for other players who would not be familiar with the content, so instead of guessing at a hundred or so completely random filenames, they can search through 15 or so groups of alike objects and find things faster.
Gillymoth Structures for Ruins <<< Folder containing my Structure-sets for Ruins mod.
@Gillymoth: thanks, didn't think to look at modpacks. Couldn't find any templates in TechnoFirmaCraft, but I did in TerraFirmaPunk 2.
@Gillymoth: your naming convention is very clear and it's been one of the easier sets to work with. Some incredible builds there too I might add! What I'm proposing doesn't break compatibility with the current method of copy-pasting into biome folders at the ruins_config/ level, and creating a separate folder for custom templates is a sensible idea. Once you merge four or more sets together (with different naming conventions) it becomes a bit of a pain juggling different ruins_config folders for different scenarios. I just needed a way to be able to very quickly add or remove entire sets based on version or modpack without having to specially label each template with those details.
That sounds like a pretty good idea, actually. I guess I should go through my sets and put "JG" or "K10" (as appropriate) in front of our template names, next time I get around to uploading updates. Kujaku10 has made a few /parseruin templates that I need to get around to cleaning up and adding to the sets, while I'm at it.
--- 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)
Using the 1.7.10 version. I've looked through the text documents and the forum and I'm just not sure how to prevent certain structures from spawning. Or at least make them spawn less. The config file seems to only deal with global values.
Each structure has its own .tml file. If you want to stop a structure from spawning, you need to figure out which structure it is, and then remove the offending .tml file. If you just want to make it spawn less (but not go away entirely), then it gets more complicated.
If the template is in the "generic" folder, you could move it into one of the biome folders instead, and then it should only spawn in that biome UNLESS the "biomesToSpawnIn" field is specified in the template itself. (Templates can be edited with a typical text editor such as Wordpad. The "biomesToSpawnIn" field is usually toward the top of the template, near the header.)
(In theory, for any given template you could reduce the "weight=*" value in the template itself, but that's only going to help you if it has a "weight" value greater than 1 to start with.)
If you don't know which template is the culprit, you'll want to hunt down the "RuinsPositionsFile.txt" file in your world's save folder. It keeps a tally of every Ruins structure that has been spawned in your world, along with its coordinates. So, in game if you want a structure you dislike and want to see no more of, you could use F3 to show your current location as you go to the center of it, then compare those coordinates to the ranges in that document. There should be an entry very close to the coordinates of that structure (if indeed it was spawned by Ruins), and the name should give you a tip. If you have only installed the templates included with the basic Ruins mod, then any templates are likely to be in the generic, jungle, or ocean folders. "Generic" templates can appear (in theory) ANYWHERE in the world, regardless of biome.
Also, in my Dropbox folder I've got a collection of screen shots of example spawns of the various "generic" Ruins templates, to help in identification.
--- 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)
Ah. That is a bit complicated. But doable. Thanks.
Alas, yes. This is a very tinkery mod (but still fun!). Here's another possibility, in case there is a ruin you don't mind popping up once in a very great while:
In the template, there is an optional setting called "uniqueMinDistance." If it is not already specified in the template, you could add the following line somewhere near the header. (I usually put it right next to "biomesToSpawnIn.")
uniqueMinDistance=5000
What this means is that when terrain gen happens and the Ruins program randomly rolls up this particular template again for consideration, it will NOT build this structure if it is within 5000 blocks of the last recorded instance of this template spawning. (Please note: It doesn't matter whether or not that structure is *still there*. You could have demolished the previous instance, but the Ruins program has no way of knowing that. I think it just checks the listing of spawned structures for that world.)
The "5000" can be replaced with whatever other value you prefer. A bigger number means a greater distance between instances of this particular structure.
Please note that this only applies to instances of THIS particular template. You might have several different structures that you don't wish to see very many of, with a very high "uniqueMinDistance" value, but there's technically nothing stopping the Ruins program from spawning them all very close to your world entry point. It'll only be upon *further* exploration that this will come into play to ensure that they're fairly "rare" for the world.
(Alas, I haven't yet figured out any clever way to prevent a template from spawning at all UNTIL you travel some distance from the world entry point. About the only way I can think of to force that would be if, as part of my template installation, I offered a bogus "RuinsPositionsFile.txt" file as a world-starter that has false entries for each of the Ruins I don't want to appear near the game start, and set an appropriately high "uniqueMinDistance" for each one, so Ruins will "think" those buildings have already spawned once each near world-start and therefore not to build another one for quite some distance out.)
--- 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)
That's a really nice idea... rare structures that you have to travel out to find. Might be worth a hack...
I like to make unique dungeons that only spawn once per world and have something game-breaking inside, such as a sword with knockback and sharpness 10.