Is there a reason that giant mushrooms and end chorus plants aren't counted among the ignorable plant blocks?
It'd be nice if Minecraft put all plant blocks in one neat, identifiable bundle...but no. Unfortunately, there are about a dozen or so such plant-ish bundles, and blocks are lumped together in unpredictable, seemingly random subsets of these and left out of others. For example, there is literally a PLANTS material a block can be tested for...but cactus, leaves, pumpkin, vine, and the huge mushroom blocks, among others, aren't made of the PLANTS material. Some plants are IGrowable, or IPlantable, or IShearable, and some aren't. When new blocks are added, especially by other mods, who knows how they're going to be implemented and what combination of these properties--if any--they're going to have?
Most of the omitted vanilla blocks are newer ones, and I'm guessing it's just a matter of the code not having been updated to include them, probably based on the assumption new canon blocks would always exhibit established plant properties that are already accounted for. They don't. I could make a pull request to add these blocks to the ignore list, but this is going to be an ongoing issue as vanilla blocks are added or modified. I could rejigger the properties being checked, but that might change the behavior with regard to modded blocks.
I think a better solution would be to let a template explicitly list the blocks it wants to ignore, as it does for unacceptable and acceptable ones. You could use that to do fun things you can't reliably do today, like ignore dirt and grass blocks to make partially buried structures, or don't ignore leaves and make them acceptable instead for tree-top structures. It would break all existing templates, but that's about to happen anyway, so...
I was testing it in rules containing lists of blocks, and/or with or without metadata, which works perfectly in 17.1 in all cases, but most of these permutations in 16.7 caused various anomalies.
Considering the feature wasn't added until Ruins 16.9, it doesn't surprise me it behaves pretty crappily in 16.7...
I'd guess you either get template-breaking "can absolutely not be mapped to anything known" errors in the dimension Ruins log files, or less catastrophic "could not determine what to spawn" warnings in the main Minecraft log file (which effectively replaces the block you wanted with a preserveBlock).
Thanks for giving the feature a thorough tire-kicking, though. Hopefully you folks can make good use of it.
Oh, I suppose it's good that we haven't been forgetting to use the feature since 1.7, I feel slightly less silly now, at least the warnings to make sure the feature are in working order for specific versions are kind of still valid, and good to know that we shouldn't try to back-port the feature too far into earlier versions.
Back to the upcoming 1.13 Great Block Renaming that's going to break all existing templates: I've got two questions.
1) Is it time to switch to the standard Forge CFG (for configuration of the overall mod) and JSON (for dimension overrides and templates) formats? I can see pros and cons either way. Switching to standards would simplify the code by stripping out all the nitty-gritty text parsing stuff and presumably be easier to use for folks new to Ruins but familiar with modding in general. Keeping a custom format would allow the syntax to be tailored specifically to Ruins, eliminating all the "{[{\"verbosity\"}]}" of a generalized grammar, and presumably be easier to use for folks already familiar with Ruins.
2) How married are people to the current names of parameters and special blocks? Since blocks are being renamed, it'd be nice to address some of the inconsistencies of other names at the same time. At the very least, I'd like to wrangle the various lowerCamelCase (e.g., allowedDimensions), UpperCamelCase (e.g., MediumMobSpawn), and lowercase_with_underscores (e.g., embed_into_distance) into a a single convention--probably lowercase_with_underscores (allowed_dimensions, medium_mob_spawn), since that's the convention on which Minecraft itself is converging. I think many of these things could use better names altogether--not just to gratuitously rename stuff, but to make their functions clearer. We can discuss the particulars, but I want to get a general feeling for whether the template creator community is dead set against such changes.
Hopefully AtomicStryker--the mod's author and the one who has ultimate say--will chime in at some point. I understand the desire to keep things as close as possible to how they are now, but I also see how that hinders feature development and confounds new users. I'm not sure what the desired balance should be.
Having labels_with_consistent_naming_conventions would definitely be less confusing for new players, and I sometimes even now look up how things are formatted in templates while writing about the features in the forum.
We could practice typing templates in the forum to see if we like anything specific:
More recently, programming languages have seen a trend towards Enforcement of tiny details like spaces/tabs, and one of the things that breaks code more than anything is mismatching brackets. Of course if Ruins were to go with a compressed format, all the under-the-hood stuff would need in-game hoods to open.
1) I just opened up a few of the json files in my config folder to see what I thought of them, and they're completely awful. No line breaks, no tabs, just random bunches of multiple spaces that don't line up properly no matter how I resize the window. Also, full of those squiggly parenthesis. I remember having to do a lot of work in one of those recently to get harvestcraft drinks to work with Tough as Nails, and I never want to deal with them again. Especially no if it means minecraft has to crash every time I misspell something, the way TaN's config did, instead of just writing an error to the log like it does now.
2) This would be useful to change. I've accidentally put in prevent_rotation and randomHeightOffset quite a few times. Renaming things to be clearer would be good, since so much is changing anyway.
---
I really like being able to change things in text instead of dealing with anything in-game. Not being able to manipulate things via files is the main reason I never got into Recurrent Complex.
If there is any paradigm to my coding at all (heh), it's "change as little as needed". While Ruins has had major refactoring over the years to keep compatible with minecraft, there's still code remnants of ... 6 years? Wow so long ... ago.
I'd hesitate to do any major changes to the template structure, given that as it is right now it *should* be fairly simple to update to any block description format.
The description format of choice would probably be the exact format used for command blocks, as the minecraft (de)serializer guarantees we stay compatible with minecraft and its arbitrary mod blocks. The rotation system will probably have to go? Or templates made unrotating by default, i don't know.
This will make writing templates by hand very difficult, but the idea is that you only edit templates which Ruins parsed for you from ingame blocks. Spelling issues and the like can be avoided if the Ruins template already contains all offered variables set to defaults, and maybe even documentation.
2) How married are people to the current names of parameters and special blocks? Since blocks are being renamed, it'd be nice to address some of the inconsistencies of other names at the same time. At the very least, I'd like to wrangle the various lowerCamelCase (e.g., allowedDimensions), UpperCamelCase (e.g., MediumMobSpawn), and lowercase_with_underscores (e.g., embed_into_distance) into a a single convention--probably lowercase_with_underscores (allowed_dimensions, medium_mob_spawn), since that's the convention on which Minecraft itself is converging. I think many of these things could use better names altogether--not just to gratuitously rename stuff, but to make their functions clearer. We can discuss the particulars, but I want to get a general feeling for whether the template creator community is dead set against such changes.
Would it be possible to write up some sort of conversion script? E.g., put this batch file (or whatever) in a folder full of templates, fire it off, and it'll go through a list of conversions from (old parameter name) to (new parameter name). If something like that were available, I'd be far more accepting of any sweeping changes.
Another helpful thing would be for the /parseruin default template to include ALL the parameters (biomesToSpawnIn, uniqueMinDistance, spawnMinDistance, preventRotation, etc.) even if it's to set them to a null state. If the end user is worried about bulking out the template size needlessly, those default lines can be deleted ... but at least they're present so the spelling is immediately evident while doing the inevitable cleaning-up that's necessary for making a /parsed Ruin ready for showtime.
Being reminded of just how convoluted each single block could potentially get, then quarteranimal's outline of rule names fits in perfectly and facilitates the directive for minimal template disruption.
If each and every block is going to have a ton of qualifiers added to it, then rules could reach to the far side of the editor window fairly quickly.
rulecobble=really long list of blocks and blockstates goes here
However, with all these aspects at our disposal, doors should be easier to wrangle exactly into position, without defaulting to an incomplete subset of the available configurations:
if we are extremely lucky, we will be able to manually set things like the in_wall setting on fence-gates without it resetting, for control of the height difference designed for when it's connected to wall sections, or we could have finer details on glass panes:
You can see where I'm going with this, if we want an awning made of fire or vines in mid-air and perfectly flat, then we may be able do that as well, and depending on if they render their top surfaces, we can make really interesting trap floors.
I guess I will begin by asking how do I change the loot tables? All I want is to have mega loot items spawn in the structures. But I cannot find answers. Could someone help me?
In particular, scroll down to the header near the bottom (right before "History") that says "Custom Maps." This shows where to find the .json files used for loot tables -- and therefore where you can institute customized changes for your game world.
I've developed a smooth-rotation algorithm that both scales correctly and fills in completely.
In order to fill in the "potholes" or rotational artifacts, each block in the template has to be run no more than twice. The efficiency could be cut down to a maximum of 1.42 x, by marking the first block in a vertical column with a data tag "[ruinsRendered=1]" at the end of the generation of a vertical column, and detecting this tag when rendering a column. Of course the block tags would need to be cleaned up in case of overlapping templates.
Of course, changing how the generation is handled would break a lot of things, and could be toggled if a specific structure shouldn't be rotated freely, but the option would be there. What do you think?
Of course, changing how the generation is handled would break a lot of things, and could be toggled if a specific structure shouldn't be rotated freely, but the option would be there. What do you think?
Given that this and other transformations discussed earlier in the thread have limited and very particular application, I think what you're really doing is making the case for is a beefed-up API so addon mods can manipulate ruins arbitrarily before they're made manifest in the world. Don't get me wrong--I love the idea of transformations like this. I'm just not sure they're within the scope of the Ruins mod itself.
I feel a template would pretty much have to be designed from the ground up (no pun intended) with specific transformations in mind. There's a whole host of issues that'd prevent general-use templates from employing them. In the case of non-cardinal rotation, for instance, a template author would need to take into account connected blocks (e.g., glass panes, fences, redstone, rails, beds) not lining up as expected, corner blocks meant to be accessible possibly being hidden behind walls, and--arguably most important--unintended block duplication. That treasure chest with a super duper magic sword buried at the bottom of your dungeon might just be super duplicated.
Still, none of that's not a deal breaker. One could design templates specifically with all that in mind--templates not relying on connectivity, without critical corner blocks, and devoid of especially valuable contents. Landscaping elements, maybe. Because transformations require so many special considerations, though, and therefore shouldn't typically be applied to templates in general, I don't know they belong in the Ruins mod proper. Again, AtomicStryker's call.
On a technical note, you probably wouldn't ever use in-world block data tags for persistent storage of state information. First of all because you likely can't; data tags only apply to blocks with associated tile entities, so unless a building consists entirely of, say, furnaces and chests, you're out of luck. Secondly, it'd be wildly inefficient even if you did make a such a template. If your goal is to avoid repeated recalculation, create a temporary lookup table upon spawning a template that maps every [X,Z] point in the footprint to its one or two transformed destination(s) and reuse that table for each layer.
Specific details like free-rotation are just things that come up while creating standalone worldgen algorithms that could potentially be implemented in minecraft, as the connectedness of points is inherent in the algorithm itself, instead of applied to the map afterwards.
Anyway, the suggestion is mostly because it comes up, and is doable, and it fits my experiments far less than in this context, and of course such Pandora's Boxes would be important to consider all ramifications of before throwing into the code. Lets just say that such things that are very far beyond the scope of Ruins have a considerable interest to me at the moment, and the experiments I'm conducting are non-quantum in nature, if one were to define a structure in Ruins as a quantum unit.
Of course the difference of if it can be done or should actually be done here is very important. As for the potential for duping, there would be a maximum chance per block of +-1.42 blocks at a 45 degree angle, but an average net gain/loss of zero, as the total area would be roughly equal, but the overwrite of a single important block that contains a dungeon key needed to advance would be unrecoverable in such a case, and with a maximum of 2 blocks created instead of one for any given column of blocks.
Of course, necessitating a change to column-first generation in order to make it more efficient for only a new feature would likely make it impractical all by itself. However, not mentioning it as a possible route would have closed off the potential for going in that direction if it were indeed practical to do so, which it may not actually be, but mad science it certainly is!
Of course the difference of if it can be done or should actually be done here is very important. As for the potential for duping, there would be a maximum chance per block of +-1.42 blocks at a 45 degree angle, but an average net gain/loss of zero, as the total area would be roughly equal, but the overwrite of a single important block that contains a dungeon key needed to advance would be unrecoverable in such a case, and with a maximum of 2 blocks created instead of one for any given column of blocks.
Would it be possible to rig such an algorithm so that the center-most column (would require the X/Z dimensions be ODD) would always be preserved, and never duplicated? Facing would vary, of course (N/S/E/W), but it would be the one true constant in the center of the structure, however the whole thing rotates. That way, if you want to design something to have a critical point (a valuable treasure, a CB that spawns the "boss monster," etc.) you could still do so, but you'd just need to make sure it goes in that middle column. Redstone circuits and the like would still be doomed, but obviously this sort of rotation isn't for anything so sophisticated as that.
In my experiments the rotation does indeed pivot on the center of the area, and the second check on the middle block would likely always land within that block as well, since the rotation stays in the range of +-45 degrees, so rotation as it stands now would still be a step in the process. It would still need to be checked to see if other blocks would overwrite that spot, but omitting any block in the template is potentially just as damaging, and we certainly wouldn't want to limit designs to symmetrical/centered layouts.
Mathematically one only ever needs to check two specific points within each block to ensure total coverage, even for a completely diagonal realignment. That is a very strong mathematical assertion to make, but my experiments suggest this is the case. Even so, doubling the operations for placing a template is kind of expensive
Of course it is merely conjecture, especially since some concessions to accommodate it would absolutely break existing implementations. It was no more than a courtesy extended after implementing an algorithm that has just enough fine-tuning to generate an effect on a visual level, and was a side-experiment that involved separating out a single inherent part of something unrelated that I'm designing/exploring.
If I put the contents of the optional folder provided by various ruins lists to generic, what should I expect to happen, generation-wise? As this is what I have been doing.
If I put the contents of the optional folder provided by various ruins lists to generic, what should I expect to happen, generation-wise? As this is what I have been doing.
It means those templates may be chosen as "generic" (typically low probability) candidates to spawn structures in ANY biome. Now, whether they actually DO spawn in a particular biome depends on the ability to find a suitable build site (according to parameters such as acceptable_target_blocks, allowable_overhang, max_leveling, etc.)...but even if they don't, they reduce--albeit slightly--the likelihood other generic structures will spawn. If such a template has a biomesToSpawnIn list, it'll also be added as a "specific" (high probability) candidate in those biomes.
As a general rule of thumb, templates in the generic folder shouldn't have a biomesToSpawnIn list. If an optional template does have one, put it in one of the folders on that list. It doesn't matter which. If it doesn't have one but is obviously associated with a particular biome, put it in the folder for that biome. If it doesn't have one and seems to be the sort of thing that should appear anywhere, put it in the generic folder.
Hi Sunconure, the latest version of Ruins, build 17.1 for mc 1.12.2 has several key fixes that make it optimal to use specific biome folders and retire the generic folder completely. Of course the generic folder is still viable in the case where there are a lot of biomes for which there are no specific structures.
My focus in the past year or so has been to establish civilizations for each of the basic types of terrain, and in tht case for those builds, the specific folders are perfect for them. There are a lot of legacy versions of Ruins for which there are patches in place to make sure everything generates in its place, some of which create inefficiencies that, now that we are aware of them, need to be cleaned up to optimize it for the newest version. Specifically the biome proxy templates, as the biome-list functionality is connected again.
Are the contents of all the biome folders being dumped into generic, or something else, or both? There would definitely be an overall different feel to the world by doing that, especially if the raw contents of the Gilly folder were dumped into Generic, as there are many parts of builds that would end up on the surface, or mostly or entirely buried, without access points. However as a legacy for that eventuality I kept the generic references in my unacceptable_target_blocks lists mostly intact.
It'd be nice if Minecraft put all plant blocks in one neat, identifiable bundle...but no. Unfortunately, there are about a dozen or so such plant-ish bundles, and blocks are lumped together in unpredictable, seemingly random subsets of these and left out of others. For example, there is literally a PLANTS material a block can be tested for...but cactus, leaves, pumpkin, vine, and the huge mushroom blocks, among others, aren't made of the PLANTS material. Some plants are IGrowable, or IPlantable, or IShearable, and some aren't. When new blocks are added, especially by other mods, who knows how they're going to be implemented and what combination of these properties--if any--they're going to have?
Most of the omitted vanilla blocks are newer ones, and I'm guessing it's just a matter of the code not having been updated to include them, probably based on the assumption new canon blocks would always exhibit established plant properties that are already accounted for. They don't. I could make a pull request to add these blocks to the ignore list, but this is going to be an ongoing issue as vanilla blocks are added or modified. I could rejigger the properties being checked, but that might change the behavior with regard to modded blocks.
I think a better solution would be to let a template explicitly list the blocks it wants to ignore, as it does for unacceptable and acceptable ones. You could use that to do fun things you can't reliably do today, like ignore dirt and grass blocks to make partially buried structures, or don't ignore leaves and make them acceptable instead for tree-top structures. It would break all existing templates, but that's about to happen anyway, so...
Considering the feature wasn't added until Ruins 16.9, it doesn't surprise me it behaves pretty crappily in 16.7...
I'd guess you either get template-breaking "can absolutely not be mapped to anything known" errors in the dimension Ruins log files, or less catastrophic "could not determine what to spawn" warnings in the main Minecraft log file (which effectively replaces the block you wanted with a preserveBlock).
Thanks for giving the feature a thorough tire-kicking, though. Hopefully you folks can make good use of it.
Oh, I suppose it's good that we haven't been forgetting to use the feature since 1.7, I feel slightly less silly now, at least the warnings to make sure the feature are in working order for specific versions are kind of still valid, and good to know that we shouldn't try to back-port the feature too far into earlier versions.
Gillymoth Structures for Ruins <<< Folder containing my Structure-sets for Ruins mod.
Back to the upcoming 1.13 Great Block Renaming that's going to break all existing templates: I've got two questions.
1) Is it time to switch to the standard Forge CFG (for configuration of the overall mod) and JSON (for dimension overrides and templates) formats? I can see pros and cons either way. Switching to standards would simplify the code by stripping out all the nitty-gritty text parsing stuff and presumably be easier to use for folks new to Ruins but familiar with modding in general. Keeping a custom format would allow the syntax to be tailored specifically to Ruins, eliminating all the "{[{\"verbosity\"}]}" of a generalized grammar, and presumably be easier to use for folks already familiar with Ruins.
2) How married are people to the current names of parameters and special blocks? Since blocks are being renamed, it'd be nice to address some of the inconsistencies of other names at the same time. At the very least, I'd like to wrangle the various lowerCamelCase (e.g., allowedDimensions), UpperCamelCase (e.g., MediumMobSpawn), and lowercase_with_underscores (e.g., embed_into_distance) into a a single convention--probably lowercase_with_underscores (allowed_dimensions, medium_mob_spawn), since that's the convention on which Minecraft itself is converging. I think many of these things could use better names altogether--not just to gratuitously rename stuff, but to make their functions clearer. We can discuss the particulars, but I want to get a general feeling for whether the template creator community is dead set against such changes.
Hopefully AtomicStryker--the mod's author and the one who has ultimate say--will chime in at some point. I understand the desire to keep things as close as possible to how they are now, but I also see how that hinders feature development and confounds new users. I'm not sure what the desired balance should be.
Having labels_with_consistent_naming_conventions would definitely be less confusing for new players, and I sometimes even now look up how things are formatted in templates while writing about the features in the forum.
We could practice typing templates in the forum to see if we like anything specific:
frequency=1
deepness=5
danger_level=11
places_to_place_this=where_it_fits
places_this_looks_bad=tips_of_mountains,floating_in_space
width=12 (+-4)
depth=12 (+-4)
height=improvise
was_never_part_of_the_code_but_added_in_as_a_prank=30
The_first_time_you_see_this_add_one_to_this_number=7
fuzziness=0
steepness=5
cuddliness=-1
place_under_this=0
place_under_that=0
redacted_in_1.6=0
random_number_that_does_nothing=73,841
optional_variable_that_shows_math_knowledge=1.6182818285
recognized_as_planets=Pluto,Ceres,P3X-852
spawning_worlds_whitelist=twilight_forest,erebus,deep_dark,backyard
More recently, programming languages have seen a trend towards Enforcement of tiny details like spaces/tabs, and one of the things that breaks code more than anything is mismatching brackets. Of course if Ruins were to go with a compressed format, all the under-the-hood stuff would need in-game hoods to open.
Gillymoth Structures for Ruins <<< Folder containing my Structure-sets for Ruins mod.
1) I just opened up a few of the json files in my config folder to see what I thought of them, and they're completely awful. No line breaks, no tabs, just random bunches of multiple spaces that don't line up properly no matter how I resize the window. Also, full of those squiggly parenthesis. I remember having to do a lot of work in one of those recently to get harvestcraft drinks to work with Tough as Nails, and I never want to deal with them again. Especially no if it means minecraft has to crash every time I misspell something, the way TaN's config did, instead of just writing an error to the log like it does now.
2) This would be useful to change. I've accidentally put in prevent_rotation and randomHeightOffset quite a few times. Renaming things to be clearer would be good, since so much is changing anyway.
---
I really like being able to change things in text instead of dealing with anything in-game. Not being able to manipulate things via files is the main reason I never got into Recurrent Complex.
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
If there is any paradigm to my coding at all (heh), it's "change as little as needed". While Ruins has had major refactoring over the years to keep compatible with minecraft, there's still code remnants of ... 6 years? Wow so long ... ago.
I'd hesitate to do any major changes to the template structure, given that as it is right now it *should* be fairly simple to update to any block description format.
The description format of choice would probably be the exact format used for command blocks, as the minecraft (de)serializer guarantees we stay compatible with minecraft and its arbitrary mod blocks. The rotation system will probably have to go? Or templates made unrotating by default, i don't know.
This will make writing templates by hand very difficult, but the idea is that you only edit templates which Ruins parsed for you from ingame blocks. Spelling issues and the like can be avoided if the Ruins template already contains all offered variables set to defaults, and maybe even documentation.
Would it be possible to write up some sort of conversion script? E.g., put this batch file (or whatever) in a folder full of templates, fire it off, and it'll go through a list of conversions from (old parameter name) to (new parameter name). If something like that were available, I'd be far more accepting of any sweeping changes.
Another helpful thing would be for the /parseruin default template to include ALL the parameters (biomesToSpawnIn, uniqueMinDistance, spawnMinDistance, preventRotation, etc.) even if it's to set them to a null state. If the end user is worried about bulking out the template size needlessly, those default lines can be deleted ... but at least they're present so the spelling is immediately evident while doing the inevitable cleaning-up that's necessary for making a /parsed Ruin ready for showtime.
--- 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)
Being reminded of just how convoluted each single block could potentially get, then quarteranimal's outline of rule names fits in perfectly and facilitates the directive for minimal template disruption.
If each and every block is going to have a ton of qualifiers added to it, then rules could reach to the far side of the editor window fairly quickly.
rulecobble=really long list of blocks and blockstates goes here
rule1=0,100,cobble,cobble,down,dooby_do,down,down,cobble,cobble
However, with all these aspects at our disposal, doors should be easier to wrangle exactly into position, without defaulting to an incomplete subset of the available configurations:
acacia_door{facing:north,half:upper,hinge:left,open:true,powered:true}
if we are extremely lucky, we will be able to manually set things like the in_wall setting on fence-gates without it resetting, for control of the height difference designed for when it's connected to wall sections, or we could have finer details on glass panes:
spruce_fence_gate{facing:west,in_wall:true,open:true,powered:true}
glass_pane{west:true,north:false,south:false,east:false}
Or with stairs:
spruce_stairs{facing:west,half:bottom,shape:inner_left}
You can see where I'm going with this, if we want an awning made of fire or vines in mid-air and perfectly flat, then we may be able do that as well, and depending on if they render their top surfaces, we can make really interesting trap floors.
vines{up:true}
Fire{age:0,up:true,west:false,north:false,south:false,east:false}
or this:
iron_trapdoor{facing:north,half:bottom,open:true,powered:false,waterlogged:true}
There are a lot of interesting things we can do with free reign in setting the blockstates, which will come up in the next version of MC.
Gillymoth Structures for Ruins <<< Folder containing my Structure-sets for Ruins mod.
I guess I will begin by asking how do I change the loot tables? All I want is to have mega loot items spawn in the structures. But I cannot find answers. Could someone help me?
The loot tables can be modified by making JSON files for them, alternatively, one can combine loot tables for various chests in the template:
,bookshelf,hay_block,ChestGenHook:chests/spawn_bonus_chest:5-2,ChestGenHook:chests/village_blacksmith:4-2,ChestGenHook:chests/simple_dungeon:5-2,ChestGenHook:chests/abandoned_mineshaft:4-2,ChestGenHook:chests/stronghold_library:3-2,ChestGenHook:chests/stronghold_corridor:2-2,ChestGenHook:chests/stronghold_crossing:2-2,ChestGenHook:chests/igloo_chest:4-2
I store lines like this in a master template file on my desktop, with one line for each rotation: 2,3,4,5
Gillymoth Structures for Ruins <<< Folder containing my Structure-sets for Ruins mod.
@ButcheredSoul:
Here is a very useful article from the Minecraft wiki on Loot Tables: https://minecraft.gamepedia.com/Loot_table
In particular, scroll down to the header near the bottom (right before "History") that says "Custom Maps." This shows where to find the .json files used for loot tables -- and therefore where you can institute customized changes for your game world.
--- 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 developed a smooth-rotation algorithm that both scales correctly and fills in completely.
In order to fill in the "potholes" or rotational artifacts, each block in the template has to be run no more than twice. The efficiency could be cut down to a maximum of 1.42 x, by marking the first block in a vertical column with a data tag "[ruinsRendered=1]" at the end of the generation of a vertical column, and detecting this tag when rendering a column. Of course the block tags would need to be cleaned up in case of overlapping templates.
Of course, changing how the generation is handled would break a lot of things, and could be toggled if a specific structure shouldn't be rotated freely, but the option would be there. What do you think?
Gillymoth Structures for Ruins <<< Folder containing my Structure-sets for Ruins mod.
Given that this and other transformations discussed earlier in the thread have limited and very particular application, I think what you're really doing is making the case for is a beefed-up API so addon mods can manipulate ruins arbitrarily before they're made manifest in the world. Don't get me wrong--I love the idea of transformations like this. I'm just not sure they're within the scope of the Ruins mod itself.
I feel a template would pretty much have to be designed from the ground up (no pun intended) with specific transformations in mind. There's a whole host of issues that'd prevent general-use templates from employing them. In the case of non-cardinal rotation, for instance, a template author would need to take into account connected blocks (e.g., glass panes, fences, redstone, rails, beds) not lining up as expected, corner blocks meant to be accessible possibly being hidden behind walls, and--arguably most important--unintended block duplication. That treasure chest with a super duper magic sword buried at the bottom of your dungeon might just be super duplicated.
Still, none of that's not a deal breaker. One could design templates specifically with all that in mind--templates not relying on connectivity, without critical corner blocks, and devoid of especially valuable contents. Landscaping elements, maybe. Because transformations require so many special considerations, though, and therefore shouldn't typically be applied to templates in general, I don't know they belong in the Ruins mod proper. Again, AtomicStryker's call.
On a technical note, you probably wouldn't ever use in-world block data tags for persistent storage of state information. First of all because you likely can't; data tags only apply to blocks with associated tile entities, so unless a building consists entirely of, say, furnaces and chests, you're out of luck. Secondly, it'd be wildly inefficient even if you did make a such a template. If your goal is to avoid repeated recalculation, create a temporary lookup table upon spawning a template that maps every [X,Z] point in the footprint to its one or two transformed destination(s) and reuse that table for each layer.
Specific details like free-rotation are just things that come up while creating standalone worldgen algorithms that could potentially be implemented in minecraft, as the connectedness of points is inherent in the algorithm itself, instead of applied to the map afterwards.
Anyway, the suggestion is mostly because it comes up, and is doable, and it fits my experiments far less than in this context, and of course such Pandora's Boxes would be important to consider all ramifications of before throwing into the code. Lets just say that such things that are very far beyond the scope of Ruins have a considerable interest to me at the moment, and the experiments I'm conducting are non-quantum in nature, if one were to define a structure in Ruins as a quantum unit.
Of course the difference of if it can be done or should actually be done here is very important. As for the potential for duping, there would be a maximum chance per block of +-1.42 blocks at a 45 degree angle, but an average net gain/loss of zero, as the total area would be roughly equal, but the overwrite of a single important block that contains a dungeon key needed to advance would be unrecoverable in such a case, and with a maximum of 2 blocks created instead of one for any given column of blocks.
Of course, necessitating a change to column-first generation in order to make it more efficient for only a new feature would likely make it impractical all by itself. However, not mentioning it as a possible route would have closed off the potential for going in that direction if it were indeed practical to do so, which it may not actually be, but mad science it certainly is!
Gillymoth Structures for Ruins <<< Folder containing my Structure-sets for Ruins mod.
Would it be possible to rig such an algorithm so that the center-most column (would require the X/Z dimensions be ODD) would always be preserved, and never duplicated? Facing would vary, of course (N/S/E/W), but it would be the one true constant in the center of the structure, however the whole thing rotates. That way, if you want to design something to have a critical point (a valuable treasure, a CB that spawns the "boss monster," etc.) you could still do so, but you'd just need to make sure it goes in that middle column. Redstone circuits and the like would still be doomed, but obviously this sort of rotation isn't for anything so sophisticated as that.
--- Jordan's & Kujaku10's UNOFFICIAL Custom Templates:
Greywolf's Minecraft Ruins (MC versions 1.7.10-1.12.2; requires AtomicStryker's "Ruins" mod)
Latest Updates: v1.7 (May 2018) * v1.8 (Jun 2016) * v1.9 (Sep 2016) * v1.10 (Jan 2017) * v1.11 (Apr 2018) * v1.12.* (Dec 2018)
In my experiments the rotation does indeed pivot on the center of the area, and the second check on the middle block would likely always land within that block as well, since the rotation stays in the range of +-45 degrees, so rotation as it stands now would still be a step in the process. It would still need to be checked to see if other blocks would overwrite that spot, but omitting any block in the template is potentially just as damaging, and we certainly wouldn't want to limit designs to symmetrical/centered layouts.
Mathematically one only ever needs to check two specific points within each block to ensure total coverage, even for a completely diagonal realignment. That is a very strong mathematical assertion to make, but my experiments suggest this is the case. Even so, doubling the operations for placing a template is kind of expensive
Of course it is merely conjecture, especially since some concessions to accommodate it would absolutely break existing implementations. It was no more than a courtesy extended after implementing an algorithm that has just enough fine-tuning to generate an effect on a visual level, and was a side-experiment that involved separating out a single inherent part of something unrelated that I'm designing/exploring.
Gillymoth Structures for Ruins <<< Folder containing my Structure-sets for Ruins mod.
If I put the contents of the optional folder provided by various ruins lists to generic, what should I expect to happen, generation-wise? As this is what I have been doing.
It means those templates may be chosen as "generic" (typically low probability) candidates to spawn structures in ANY biome. Now, whether they actually DO spawn in a particular biome depends on the ability to find a suitable build site (according to parameters such as acceptable_target_blocks, allowable_overhang, max_leveling, etc.)...but even if they don't, they reduce--albeit slightly--the likelihood other generic structures will spawn. If such a template has a biomesToSpawnIn list, it'll also be added as a "specific" (high probability) candidate in those biomes.
As a general rule of thumb, templates in the generic folder shouldn't have a biomesToSpawnIn list. If an optional template does have one, put it in one of the folders on that list. It doesn't matter which. If it doesn't have one but is obviously associated with a particular biome, put it in the folder for that biome. If it doesn't have one and seems to be the sort of thing that should appear anywhere, put it in the generic folder.
Hi Sunconure, the latest version of Ruins, build 17.1 for mc 1.12.2 has several key fixes that make it optimal to use specific biome folders and retire the generic folder completely. Of course the generic folder is still viable in the case where there are a lot of biomes for which there are no specific structures.
My focus in the past year or so has been to establish civilizations for each of the basic types of terrain, and in tht case for those builds, the specific folders are perfect for them. There are a lot of legacy versions of Ruins for which there are patches in place to make sure everything generates in its place, some of which create inefficiencies that, now that we are aware of them, need to be cleaned up to optimize it for the newest version. Specifically the biome proxy templates, as the biome-list functionality is connected again.
Are the contents of all the biome folders being dumped into generic, or something else, or both? There would definitely be an overall different feel to the world by doing that, especially if the raw contents of the Gilly folder were dumped into Generic, as there are many parts of builds that would end up on the surface, or mostly or entirely buried, without access points. However as a legacy for that eventuality I kept the generic references in my unacceptable_target_blocks lists mostly intact.
Gillymoth Structures for Ruins <<< Folder containing my Structure-sets for Ruins mod.