... I do hope that JP, Gilly, and other writers (Perhaps even AS? ) will start distributing ... into suitable biome folders...
We've been sorting work among the biome folders for the past 3 years or so (!), even extensively patching for versions where those specific functionalities were broken, and lots of fine-tuned calibrations, and things which may contain chocolate.
As for the newly revealed features that would allow for absolute complete coverage for the first time, regardless of unforeseen biome additions in future mods. We are behind the scenes sifting through and crunching all the delicious mathematical morsels.
Balancing Level of Control vs Coverage, that sounds like the kind of puzzles we like to play with! and having this level of coverage is going to be extremely useful.
@quarteranimal I was hoping for something like that, as perceived compatibility hinges on being able to populate all the areas on a given map, and it should even remove the need to reload Ruins after adding biome mods to an instance.
What you suggest makes it so much easier to get complete coverage in any given world, and has the effect of having several specific generic folders for a more refined layout than what can be obtained with the generic folder. It can be used like the boardgame "guess-who" where you can specify all jungles that are also wet, as some mods add in jungles that are also deserts, which was surprising when pressing F3 to read jungle while standing on a huge stretch of sand.
Oh, I've refined my implementation of the grid free-rotation, and can rotate the entire range of 0 to +-45 degrees at exactly the correct scale with only a single generation attempt per block (or column), which eliminates all potential duped blocks, but there is still some overlapping blocks that make omitted data occur. All with no overhead or any special calculations, just the transformation calculation itself which is exactly as fast as the simple rough calculation.
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.
...(such as looping through all nearby mobs or analyzing terrain for pathfinding), we get linear and even polynomial runtimes that no constant number of constant time optimizations can make room for. These operations are called per-mob, which is how lots of mobs can slow down the game.
Once for a space game I created a fleet for a cloud-civilization that acted as a single flowing entity. There was a central command station that they swarmed around, and they had a special ability where they shared their shield energy between each other indirectly through the central tower, as it's only 2N operations for each one to send a part of it's shield energy corresponding to it's generation, and feed it to the lowest one via the mothership, as opposed to N^2 to have them talk to each other directly.
Even though their individual attacks were very weak, they were able to take down larger battleships, since they could collectively replenish the shields of any one that got attacked.
If this were a minecraft mob, I would make it neutral, and individual mobs temporarily hostile to reciprocate hits, but hostile like pigmen if the mother-creature were attacked. The mother creature could bestow a regen effect on either individual ones or the entire swarm, whichever ends up balancing them more closely. If players could access regen from it, (or waterbreathing) they might be able to swim through them on their way to or from places.
Absorption is sometimes used to simulate shield effects, but it wouldn't replicate the nuances of the above mechanics.
Yeah, my computer is half-decent, but just toasty enough that optimizations make a difference.
In benchmarking tests done on various operations that appear most often, I've found that multiplication in particular can be expensive, so instances of .3 * .5 in the code itself can save an operation if written as .15, and this can show up in a lot of places in a relatively short space, which ends up saving a noticeable amount of time, even just for this example. Maybe enough would be shaved off that an extra entity or two could be added back in and still cost the same overall.
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.
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!
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?
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.
0
@Zaesar, Are any of my ships the ones you were looking for, if not, can you show a pic of the specific one?
0
There are many sets of extra templates for Ruins, Ill dig up some of my ships and reply.
0
Decided to make a new dress-line for my skin.
The houses in the background are my personal style and design, as I make structures for Ruins mod.
0
Many of these kinds of blocks will no longer be tile entities in 1.13, this includes note-blocks, flowerpots, and the default types of mob skulls.
0
We've been sorting work among the biome folders for the past 3 years or so (!), even extensively patching for versions where those specific functionalities were broken, and lots of fine-tuned calibrations, and things which may contain chocolate.
As for the newly revealed features that would allow for absolute complete coverage for the first time, regardless of unforeseen biome additions in future mods. We are behind the scenes sifting through and crunching all the delicious mathematical morsels.
0
Ty so much Quarteranimal~
Balancing Level of Control vs Coverage, that sounds like the kind of puzzles we like to play with! and having this level of coverage is going to be extremely useful.
1
@quarteranimal I was hoping for something like that, as perceived compatibility hinges on being able to populate all the areas on a given map, and it should even remove the need to reload Ruins after adding biome mods to an instance.
What you suggest makes it so much easier to get complete coverage in any given world, and has the effect of having several specific generic folders for a more refined layout than what can be obtained with the generic folder. It can be used like the boardgame "guess-who" where you can specify all jungles that are also wet, as some mods add in jungles that are also deserts, which was surprising when pressing F3 to read jungle while standing on a huge stretch of sand.
Oh, I've refined my implementation of the grid free-rotation, and can rotate the entire range of 0 to +-45 degrees at exactly the correct scale with only a single generation attempt per block (or column), which eliminates all potential duped blocks, but there is still some overlapping blocks that make omitted data occur. All with no overhead or any special calculations, just the transformation calculation itself which is exactly as fast as the simple rough calculation.
0
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.
0
Once for a space game I created a fleet for a cloud-civilization that acted as a single flowing entity. There was a central command station that they swarmed around, and they had a special ability where they shared their shield energy between each other indirectly through the central tower, as it's only 2N operations for each one to send a part of it's shield energy corresponding to it's generation, and feed it to the lowest one via the mothership, as opposed to N^2 to have them talk to each other directly.
Even though their individual attacks were very weak, they were able to take down larger battleships, since they could collectively replenish the shields of any one that got attacked.
If this were a minecraft mob, I would make it neutral, and individual mobs temporarily hostile to reciprocate hits, but hostile like pigmen if the mother-creature were attacked. The mother creature could bestow a regen effect on either individual ones or the entire swarm, whichever ends up balancing them more closely. If players could access regen from it, (or waterbreathing) they might be able to swim through them on their way to or from places.
Absorption is sometimes used to simulate shield effects, but it wouldn't replicate the nuances of the above mechanics.
0
Yeah, my computer is half-decent, but just toasty enough that optimizations make a difference.
In benchmarking tests done on various operations that appear most often, I've found that multiplication in particular can be expensive, so instances of .3 * .5 in the code itself can save an operation if written as .15, and this can show up in a lot of places in a relatively short space, which ends up saving a noticeable amount of time, even just for this example. Maybe enough would be shaved off that an extra entity or two could be added back in and still cost the same overall.
0
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.
0
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!
1
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?
0
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
0
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.