I would guess that you are in a superflat world, since Ruins tries to keep from breaking the bottom of the world, as bedrock is meant to be permanent in general.
Oops. I didn't even think of that angle. I forgot that when I spawn a superflat world for Ruins construction, I have to customize it to give me a thicker dirt layer if I want to be able to test-spawn anything with a "basement" there. (I typically go with 1 layer bedrock, 62 layers dirt, 1 layer grass. However, when manually test-spawning complex "dungeons," I've also found it useful to just spawn an alternate superflat world with 64 layers of GLASS, so I can clearly see what's spawning underground.)
I was just about to ask this question and then I continued to read. Thank you both for your help!
I'm running Ruins on my 1.7.10 server, and every now and then I see something like this:
[03:32:26] [Server thread/INFO] [STDERR]: [atomicstryker.ruins.common.RuinTemplateRule:doSpecialBlock:677]: Ruins Mod could not determine what to spawn for [minecraft:air] in Ruin template: JG_Sphere_Cave_31_1v7v10.tml
It tends to spam the console until the server crashes.
My searches are not yielding any results.
Anybody have any idea what's going on there and/or how I can prevent it?
I'm running Ruins on my 1.7.10 server, and every now and then I see something like this:
[03:32:26] [Server thread/INFO] [STDERR]: [atomicstryker.ruins.common.RuinTemplateRule:doSpecialBlock:677]: Ruins Mod could not determine what to spawn for [minecraft:air] in Ruin template: JG_Sphere_Cave_31_1v7v10.tml
It tends to spam the console until the server crashes.
My searches are not yielding any results.
Anybody have any idea what's going on there and/or how I can prevent it?
There was a bug, fixed in 1.12.2, preventing Ruins from recognizing minecraft:air as a legitimate block ID. Since you're running a version without that fix, you'll need to replace all occurrences of minecraft:air in your templates with simply air. That should eliminate the errors.
Note for all other blocks, the minecraft: domain works fine, so you only need to remove it from air blocks. For example, stone and minecraft:stone are both valid and interchangeable. Just not air.
There was a bug, fixed in 1.12.2, preventing Ruins from recognizing minecraft:air as a legitimate block ID. Since you're running a version without that fix, you'll need to replace all occurrences of minecraft:air in your templates with simply air. That should eliminate the errors.
Note for all other blocks, the minecraft: domain works fine, so you only need to remove it from air blocks. For example, stone and minecraft:stone are both valid and interchangeable. Just not air.
So trees Spawn inside houses, as im sure you are aware since the Mod preserves Leafs/logs/snow by default.
I'm mostly looking for ideas to work around this issue.
One idea would be filling the inside with another block type, (like the barrier block) then, via commandblocks, replace those with air after the structure has spawned. But that's a bit of a hazzle.
I would like to ask if anyone has any better suggestions?
One way could also be to use some other "air block", but i don't really have any mod that has anything like that, Nor the skills to make one.
There are certain steps that are commonly handled by editing the TML files in a text editor, this is one of them.
After the air (that needs to spawn in as air) is filled in with an otherwise unused block, the structure is saved as a template, and the entry in the file is changed to "air" instead of whatever block was used to represent it for the save.
This is usually one of the very last steps of structure development, as saving it again after spawning will undo the step.
One way could also be to use some other "air block"...
You're on the right track, but you already have everything you need. My guess is you're using rule0 for both exterior and interior space. Contrary to what you may think, the default rule0 is notair, but rather a special "background" air (namely, ?air) that respects preservation of plants and snow and stuff, as you noted. That's fine for outside space, where you don't want to disrupt the surroundings, but probably not appropriate for inside space, where you do. All you need is a separate interior air rule in addition to rule0, something along the lines of...
rule19=0,100,air
...and use that inside your building. If you use /parseruin to generate Ruins templates, Gillymoth's suggestion above is to fill the interior with something silly, like lime wool, then edit the resultant template file to replace wool-5 with air to easily implement this. Regular, non-background blocks, even air, never care about preservation, happily stomping on whatever gets in their way.
Incidentally, you can use the question mark prefix to include preservation-honoring background blocks in other rules--not just rule0, and not just air--to achieve certain special effects. There's also an exclamation mark prefix for "foreground" blocks that only clobber stuff that's otherwise preserved (perfect for, say, that house on stilts you always wanted to build). But that's more than you wanted to know.
There are certain steps that are commonly handled by editing the TML files in a text editor, this is one of them.
After the air (that needs to spawn in as air) is filled in with an otherwise unused block, the structure is saved as a template, and the entry in the file is changed to "air" instead of whatever block was used to represent it for the save.
This is usually one of the very last steps of structure development, as saving it again after spawning will undo the step.
Yeah, what I will often do for my structures is to fill the space with some sort of placeholder block -- either GLASS, or some color of STAINED_GLASS that I'm not using elsewhere in the structure. As of 1.12, it's a lot easier to do this with the /fill command.
(I typically choose GLASS or STAINED_GLASS as my filler block, because: a) I can still see through it, so my creation is still recognizable in my "workspace world" for identification purposes; It doesn't kill any grass blocks that might be buried underneath.)
Then, I can edit the corresponding rule in the .tml file to replace "minecraft:glass" or "minecraft:stained_glass-11" or whatever with "minecraft:air" -- originally done so I could make "air pockets" in underwater structures, but I've also found it useful if I want to keep trees and shrubbery out of a structure. (I just haven't done that consistently, since some of my structures were "ported" up to 1.12 from earlier versions where this didn't seem to be as much of a concern.)
Thanks a lot guys, this sure will make things easier.
Also i find myself using command blocks way more to spawn Ruins, it's been way more effective so far.
In other news, How would you guys recommend spawning in really LARGE ruins?
Would Using the adjoining_template Setting in small chunks be better than one large one?
Thanks a lot guys, this sure will make things easier.
Also i find myself using command blocks way more to spawn Ruins, it's been way more effective so far.
In other news, How would you guys recommend spawning in really LARGE ruins?
Would Using the adjoining_template Setting in small chunks be better than one large one?
If you can accomplish it with adjoining_template, I'd say go for it. There are some definite pros-and-cons.
Most of my early "mega-dungeon" structures make extensive use of Command Blocks firing off the "/testruin" command.
PRO: This still works fairly well for underground dungeons, as it allows me to make sure the dungeon modules line up properly with each other (rather than meandering up or down according to the level of the ground above it), AND it allows me to introduce some degree of randomization. (That is, I could have a rule that will randomly choose between "dungeon corridor A," "dungeon corridor B," or "spider-filled treasure room" in this location, for a little bit of variety, so not all my mega-dungeons are *exactly* alike.) Also -- I don't know if this is TRUE -- but my rationale was that by breaking the structure up into smaller bits that wouldn't all necessarily fire off *right as soon as the chunk was generated*, that I might break up server load. (That's been a big concern for multiplayer servers, as my friends tend to want to get modpacks that allow FLIGHT, and then someone starts shooting off in a random direction, exploring vast swathes of territory in search of some *particular* biome, or some "rare" spawning feature, and the resulting lag goes crazy.)
CON: First off, dungeons using this won't work on multiplayer servers that disable Command Blocks. (Sometimes, specific mods don't play well with them, so there's a reason for me to have "no-Command-Block" versions of my packs.) Secondly, it's just a bit weird to have a bunch of "template bombs" waiting to go off until someone gets close enough and moves across a chunk border for the thing to finally fire off. One moment, you see open ground and a tower of Command Blocks, and then -- BOOM! An evil castle and several outbuildings pop into existence. Also, I'm still in the process of trying to port my 1.12 templates over to 1.13, and last I heard, "RUINSTRIGGER" no longer functions in 1.13 onward, so that does away with all of my complex structures that relied on that. (I mean, maybe there's some clever way I can make "self-firing" Command Block chains, but that's something I'll have to experiment with, all over again, and at that point I probably won't be "converting" my old dungeons so much as completely replacing them with something optimized for the new method.)
Later on, I finally got around to using the adjoining_template system.
PRO: This is nice and straightforward for doing things on the surface, and works even if Command Blocks aren't enabled (or RUINSTRIGGER doesn't work for some reason as intended -- I've heard of certain mods interfering with *that*, too). You could, for example, have a custom village put together this way. You could even make a *walled* village, by making lots of wall segments spawning at different points around the village (just keeping in mind that elevation will change for each one, so some care has to be taken in how they line up next to each other).
CON: No randomization of content. The village is going to be just as you specify, and you can't have, say, a choice between Building A, B, or C for each "lot" of the village. The only "randomization" will be through the variance of the terrain upon which it spawns (i.e., a building or wall segment might be missing because there wasn't a valid target block at that location, or maybe there was a ravine at that point or a sky island over head, so that one piece is FAR apart from the others), or randomization within the structure itself.
Also, it doesn't work quite as well for underground structures unless you're in a superflat world, or unless you do some really clever work on making modules that will line up even with some elevation changes. (Gillymoth has done some *brilliant* work on this.)
...
EXCEPTION: A couple of ways to make underground dungeons in multiple segments that line up with each other, spawned by Adjoining_Template:
a) "Bedrock Dungeon." A Ruin won't spawn UNDERNEATH the minimum valid elevation. So, if you make a bunch of dungeon segments that use "embed_into_distance=128" or some other ridiculously high number, odds are high that it's going to go all the way down to bedrock, bump up a minimum predetermined distance (I forget how many layers are minimum) and then start building there. That's how I made my "Bedrock Rail" project, which is basically a hidden railway that runs some distance underground down near the bedrock: The only hope you have of FINDING it is if you happen to be mining very far down and blunder into it, or if you explore a cave system or abandoned mine that happens to intersect with it.
(Or, as in one of my disastrous failed experiments that Gillymoth can attest to, when I tried stretching the boundaries of just HOW FAR OUT Adjoining_Template could go, and ended up spawning a Bedrock Rail so far out from the spawn point that when it triggered, it spawned far, far into already-explored territory, and bulldozed its way right through Gillymoth's basement. Oops.)
You could theoretically provide a chance at "surface access" by having a really tall access tower link up with it, but there's no telling what the elevation of ground level will be above it, so you'd probably want a "tower" with open sides, and thus a chance of entry at multiple points (but of course, that point of entry could end up chopping off a lava lake or a water source, for added weirdness).
"Underwater Dungeon." One nice thing about the ocean is that (barring the occasional island), it's FLAT. Have your "dungeon" spawn in Ocean or Deep_Ocean only, require "water" as a valid target block, and have a hefty "embed_into_distance" (something less than 64) and you could have a dungeon complex underwater. (Just be sure all interior spaces are filled with "air" rather than defaulting to predefined rule0, or else the underwater dungeon just might be *flooded*.) One advantage of this over the Bedrock Dungeon is that you could have a central structure (say, a "Lighthouse" with spiral stairs or a ladder or two "teleport" Command Block mechanisms) that provides access to the dungeon complex up at water level.
I'm at a total loss here SOMETHING is preventing this mod from writing to the BattletowerPositionsFile.txt but I cannot for the life of me figure it out. its not my antivirus as far as i can figure, and the minecraft.exe has access through it anyway. This persists across multiple saves.
I'm at a total loss here SOMETHING is preventing this mod from writing to the BattletowerPositionsFile.txt but I cannot for the life of me figure it out. its not my antivirus as far as i can figure, and the minecraft.exe has access through it anyway. This persists across multiple saves.
I wasn't aware that Ruins would write anything to any files related to Battletowers.
Question, Is there any issue with having to many Ruin files? Or to BIG ruin files?
Lately i have run into a strange lag issue with my Minecraft, but the only thing i've done between then and now is add a bunch a ruins to my pack.
Though i would Doubt this is the case since i added like 1000+ Car ruins to spawn on my (lost cities) Roads. and there was no real slowdown.
Then i added some Craters to my other planets, and now my minecraft runs like a potato.
I'm only asking to make sure, but i don't see why it would be an issue?
(i should note, the lag happens even on my test flat world witch doesn't have any ruins spawning at all, So i wouldn't say its cause they spawn alot.)
The /testruin command loads a template called with it from disk every time it is executed, as it was designed for testing so it needs to get the new files. Anything that spawns in with /testruin should be checked to make sure it can place the file into the world instantly.
Other than that, minecraft itself is designed to operate in vertical sections of the world, from 0 to 255, and is set up better for vertical spawning than for flat spawns with an extremely wide footprint.
I Don't know it just says "The game crashed whilst exception in server tick loop
Error: java.lang.RuntimeException: Ruins mod crashed because it was denied file write access to C:\Users\*****\Twitch\Minecraft\Instances\RLCraft\saves\New World\BattletowerPositionsFile.txt" as far as i can tell permissions are fine, nor would I know how to find and give permission to the mod engine directly. It's for a fairly new modpack and basic searches are netting no results. I just figured id post about it here as "ruins mod" is mentioned.
The Structures in Ruins are designed optimally to use features only present in Ruins Mod, and cannot simply be uprooted from the system they were designed to fit. Features dealing with blending the structure into the landscape and fine-tuned block selection are vitally important to how the structures show up in the world.
So I was directed to ask here for help with an issue I'm having with a bunch of my structures.
A lot of these I got from the old template folders and "optional" folder back in like, 1.10 or so, before Stryker practically wiped all the structures and templates in later builds for some reason.
I'm guessing something changed somewhere down the line as, a lot of the structures now spawn with these weird trenches or "grooves" around them, and I can't for the life of my figure out why. Setting max-leveling to 0 works when spawning the ruin manually but, then the structure never spawns naturally, so leveling is certainly needed. The dimensions are defined correctly, preserved blocks are in place, doesn't make sense.
This is what I'm talking about:
Here is one of the templates in question, the same one as the picture above, that i've been trying to modify to fix this: https://pastebin.com/P9Ug6b6B
any help would be greatly appreciated. oh and if it matters i am on 1.12.2 Ruins.
EDIT: alright big dumb, guess it was leveling-buffer. I set that to 0 and now the groove vanishes, as leveling buffer is set to define the area around the build that also gets leveled, and since it is 1 block deep into the ground, that first layer levels a ring around it. It's strange though that these same builds didn't do this back in 1.10 though, did leveling-buffer do something different back then?
Set leveling_buffer to -1, to completely turn it off, as 0 only limits leveling to inside the template borders. This is useful when the building's footprint doesn't fill the area.
I usually have a few foundation levels below the surface so the building can be firmly anchored to the ground, so I set embed_into_distance and max_leveling to the same number (4-ish), so a few things fall nicely into place. A much larger footprint needs larger numbers in these two to ensure the structure spawns on rough terrain. For me max_leveling is determined by the footprint, and can diverge from the number of basement levels if one has a deep basement on a narrow building. One gets the feel for it after a while.
Of course, with embed_into_distance set, one would also need to put the corresponding number of foundation levels in the structure's design.
You are correct.
I was just about to ask this question and then I continued to read. Thank you both for your help!
I'm running Ruins on my 1.7.10 server, and every now and then I see something like this:
It tends to spam the console until the server crashes.
My searches are not yielding any results.
Anybody have any idea what's going on there and/or how I can prevent it?
There was a bug, fixed in 1.12.2, preventing Ruins from recognizing minecraft:air as a legitimate block ID. Since you're running a version without that fix, you'll need to replace all occurrences of minecraft:air in your templates with simply air. That should eliminate the errors.
Note for all other blocks, the minecraft: domain works fine, so you only need to remove it from air blocks. For example, stone and minecraft:stone are both valid and interchangeable. Just not air.
Ah, gotcha. Can do!
Thank you very much!
So trees Spawn inside houses, as im sure you are aware since the Mod preserves Leafs/logs/snow by default.
I'm mostly looking for ideas to work around this issue.
One idea would be filling the inside with another block type, (like the barrier block) then, via commandblocks, replace those with air after the structure has spawned. But that's a bit of a hazzle.
I would like to ask if anyone has any better suggestions?
One way could also be to use some other "air block", but i don't really have any mod that has anything like that, Nor the skills to make one.
i'm on 1.12.2 version.
There are certain steps that are commonly handled by editing the TML files in a text editor, this is one of them.
After the air (that needs to spawn in as air) is filled in with an otherwise unused block, the structure is saved as a template, and the entry in the file is changed to "air" instead of whatever block was used to represent it for the save.
This is usually one of the very last steps of structure development, as saving it again after spawning will undo the step.
Gillymoth Structures for Ruins <<< Folder containing my Structure-sets for Ruins mod.
You're on the right track, but you already have everything you need. My guess is you're using rule0 for both exterior and interior space. Contrary to what you may think, the default rule0 is not air, but rather a special "background" air (namely, ?air) that respects preservation of plants and snow and stuff, as you noted. That's fine for outside space, where you don't want to disrupt the surroundings, but probably not appropriate for inside space, where you do. All you need is a separate interior air rule in addition to rule0, something along the lines of...
rule19=0,100,air
...and use that inside your building. If you use /parseruin to generate Ruins templates, Gillymoth's suggestion above is to fill the interior with something silly, like lime wool, then edit the resultant template file to replace wool-5 with air to easily implement this. Regular, non-background blocks, even air, never care about preservation, happily stomping on whatever gets in their way.
Incidentally, you can use the question mark prefix to include preservation-honoring background blocks in other rules--not just rule0, and not just air--to achieve certain special effects. There's also an exclamation mark prefix for "foreground" blocks that only clobber stuff that's otherwise preserved (perfect for, say, that house on stilts you always wanted to build). But that's more than you wanted to know.
Yeah, what I will often do for my structures is to fill the space with some sort of placeholder block -- either GLASS, or some color of STAINED_GLASS that I'm not using elsewhere in the structure. As of 1.12, it's a lot easier to do this with the /fill command.
It doesn't kill any grass blocks that might be buried underneath.)
(I typically choose GLASS or STAINED_GLASS as my filler block, because: a) I can still see through it, so my creation is still recognizable in my "workspace world" for identification purposes;
Then, I can edit the corresponding rule in the .tml file to replace "minecraft:glass" or "minecraft:stained_glass-11" or whatever with "minecraft:air" -- originally done so I could make "air pockets" in underwater structures, but I've also found it useful if I want to keep trees and shrubbery out of a structure. (I just haven't done that consistently, since some of my structures were "ported" up to 1.12 from earlier versions where this didn't seem to be as much of a concern.)
--- 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)
Thanks a lot guys, this sure will make things easier.
Also i find myself using command blocks way more to spawn Ruins, it's been way more effective so far.
In other news, How would you guys recommend spawning in really LARGE ruins?
Would Using the adjoining_template Setting in small chunks be better than one large one?
If you can accomplish it with adjoining_template, I'd say go for it. There are some definite pros-and-cons.
Most of my early "mega-dungeon" structures make extensive use of Command Blocks firing off the "/testruin" command.
PRO: This still works fairly well for underground dungeons, as it allows me to make sure the dungeon modules line up properly with each other (rather than meandering up or down according to the level of the ground above it), AND it allows me to introduce some degree of randomization. (That is, I could have a rule that will randomly choose between "dungeon corridor A," "dungeon corridor B," or "spider-filled treasure room" in this location, for a little bit of variety, so not all my mega-dungeons are *exactly* alike.) Also -- I don't know if this is TRUE -- but my rationale was that by breaking the structure up into smaller bits that wouldn't all necessarily fire off *right as soon as the chunk was generated*, that I might break up server load. (That's been a big concern for multiplayer servers, as my friends tend to want to get modpacks that allow FLIGHT, and then someone starts shooting off in a random direction, exploring vast swathes of territory in search of some *particular* biome, or some "rare" spawning feature, and the resulting lag goes crazy.)
CON: First off, dungeons using this won't work on multiplayer servers that disable Command Blocks. (Sometimes, specific mods don't play well with them, so there's a reason for me to have "no-Command-Block" versions of my packs.) Secondly, it's just a bit weird to have a bunch of "template bombs" waiting to go off until someone gets close enough and moves across a chunk border for the thing to finally fire off. One moment, you see open ground and a tower of Command Blocks, and then -- BOOM! An evil castle and several outbuildings pop into existence. Also, I'm still in the process of trying to port my 1.12 templates over to 1.13, and last I heard, "RUINSTRIGGER" no longer functions in 1.13 onward, so that does away with all of my complex structures that relied on that. (I mean, maybe there's some clever way I can make "self-firing" Command Block chains, but that's something I'll have to experiment with, all over again, and at that point I probably won't be "converting" my old dungeons so much as completely replacing them with something optimized for the new method.)
Later on, I finally got around to using the adjoining_template system.
PRO: This is nice and straightforward for doing things on the surface, and works even if Command Blocks aren't enabled (or RUINSTRIGGER doesn't work for some reason as intended -- I've heard of certain mods interfering with *that*, too). You could, for example, have a custom village put together this way. You could even make a *walled* village, by making lots of wall segments spawning at different points around the village (just keeping in mind that elevation will change for each one, so some care has to be taken in how they line up next to each other).
CON: No randomization of content. The village is going to be just as you specify, and you can't have, say, a choice between Building A, B, or C for each "lot" of the village. The only "randomization" will be through the variance of the terrain upon which it spawns (i.e., a building or wall segment might be missing because there wasn't a valid target block at that location, or maybe there was a ravine at that point or a sky island over head, so that one piece is FAR apart from the others), or randomization within the structure itself.
Also, it doesn't work quite as well for underground structures unless you're in a superflat world, or unless you do some really clever work on making modules that will line up even with some elevation changes. (Gillymoth has done some *brilliant* work on this.)
...
EXCEPTION: A couple of ways to make underground dungeons in multiple segments that line up with each other, spawned by Adjoining_Template:
a) "Bedrock Dungeon." A Ruin won't spawn UNDERNEATH the minimum valid elevation. So, if you make a bunch of dungeon segments that use "embed_into_distance=128" or some other ridiculously high number, odds are high that it's going to go all the way down to bedrock, bump up a minimum predetermined distance (I forget how many layers are minimum) and then start building there. That's how I made my "Bedrock Rail" project, which is basically a hidden railway that runs some distance underground down near the bedrock: The only hope you have of FINDING it is if you happen to be mining very far down and blunder into it, or if you explore a cave system or abandoned mine that happens to intersect with it.
(Or, as in one of my disastrous failed experiments that Gillymoth can attest to, when I tried stretching the boundaries of just HOW FAR OUT Adjoining_Template could go, and ended up spawning a Bedrock Rail so far out from the spawn point that when it triggered, it spawned far, far into already-explored territory, and bulldozed its way right through Gillymoth's basement. Oops.)
You could theoretically provide a chance at "surface access" by having a really tall access tower link up with it, but there's no telling what the elevation of ground level will be above it, so you'd probably want a "tower" with open sides, and thus a chance of entry at multiple points (but of course, that point of entry could end up chopping off a lava lake or a water source, for added weirdness).
--- 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 noticed the template format for 1.14.4 () has changed:
old:
new:
Has anyone written a converter, or has anyone already fixed the old templates? I can only find the default ones for the old format.
I'm at a total loss here SOMETHING is preventing this mod from writing to the BattletowerPositionsFile.txt but I cannot for the life of me figure it out. its not my antivirus as far as i can figure, and the minecraft.exe has access through it anyway. This persists across multiple saves.
I wasn't aware that Ruins would write anything to any files related to Battletowers.
--- 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)
Question, Is there any issue with having to many Ruin files? Or to BIG ruin files?
Lately i have run into a strange lag issue with my Minecraft, but the only thing i've done between then and now is add a bunch a ruins to my pack.
Though i would Doubt this is the case since i added like 1000+ Car ruins to spawn on my (lost cities) Roads. and there was no real slowdown.
Then i added some Craters to my other planets, and now my minecraft runs like a potato.
I'm only asking to make sure, but i don't see why it would be an issue?
(i should note, the lag happens even on my test flat world witch doesn't have any ruins spawning at all, So i wouldn't say its cause they spawn alot.)
The /testruin command loads a template called with it from disk every time it is executed, as it was designed for testing so it needs to get the new files. Anything that spawns in with /testruin should be checked to make sure it can place the file into the world instantly.
Other than that, minecraft itself is designed to operate in vertical sections of the world, from 0 to 255, and is set up better for vertical spawning than for flat spawns with an extremely wide footprint.
Gillymoth Structures for Ruins <<< Folder containing my Structure-sets for Ruins mod.
I Don't know it just says "The game crashed whilst exception in server tick loop
Error: java.lang.RuntimeException: Ruins mod crashed because it was denied file write access to C:\Users\*****\Twitch\Minecraft\Instances\RLCraft\saves\New World\BattletowerPositionsFile.txt" as far as i can tell permissions are fine, nor would I know how to find and give permission to the mod engine directly. It's for a fairly new modpack and basic searches are netting no results. I just figured id post about it here as "ruins mod" is mentioned.
Anyone converted the ruins to datapacks yet?
The Structures in Ruins are designed optimally to use features only present in Ruins Mod, and cannot simply be uprooted from the system they were designed to fit. Features dealing with blending the structure into the landscape and fine-tuned block selection are vitally important to how the structures show up in the world.
Gillymoth Structures for Ruins <<< Folder containing my Structure-sets for Ruins mod.
So I was directed to ask here for help with an issue I'm having with a bunch of my structures.
A lot of these I got from the old template folders and "optional" folder back in like, 1.10 or so, before Stryker practically wiped all the structures and templates in later builds for some reason.
I'm guessing something changed somewhere down the line as, a lot of the structures now spawn with these weird trenches or "grooves" around them, and I can't for the life of my figure out why. Setting max-leveling to 0 works when spawning the ruin manually but, then the structure never spawns naturally, so leveling is certainly needed. The dimensions are defined correctly, preserved blocks are in place, doesn't make sense.
This is what I'm talking about:
Here is one of the templates in question, the same one as the picture above, that i've been trying to modify to fix this: https://pastebin.com/P9Ug6b6B
any help would be greatly appreciated. oh and if it matters i am on 1.12.2 Ruins.
EDIT: alright big dumb, guess it was leveling-buffer. I set that to 0 and now the groove vanishes, as leveling buffer is set to define the area around the build that also gets leveled, and since it is 1 block deep into the ground, that first layer levels a ring around it. It's strange though that these same builds didn't do this back in 1.10 though, did leveling-buffer do something different back then?
Set leveling_buffer to -1, to completely turn it off, as 0 only limits leveling to inside the template borders. This is useful when the building's footprint doesn't fill the area.
I usually have a few foundation levels below the surface so the building can be firmly anchored to the ground, so I set embed_into_distance and max_leveling to the same number (4-ish), so a few things fall nicely into place. A much larger footprint needs larger numbers in these two to ensure the structure spawns on rough terrain. For me max_leveling is determined by the footprint, and can diverge from the number of basement levels if one has a deep basement on a narrow building. One gets the feel for it after a while.
Of course, with embed_into_distance set, one would also need to put the corresponding number of foundation levels in the structure's design.
Gillymoth Structures for Ruins <<< Folder containing my Structure-sets for Ruins mod.