Im wondering if anyone can help me. Im using ruins mod for minecraft 1.7.10 and have just installed the ruin templates made by Jordan_Greywolf, however it appears that many of the ruins incorporating command blocks are not generating properly... there are just stacks or individual command blocks sitting there where it appears a structure should be. Anyone have any idea why? I'm not familiar with command blocks.
Im wondering if anyone can help me. Im using ruins mod for minecraft 1.7.10 and have just installed the ruin templates made by Jordan_Greywolf, however it appears that many of the ruins incorporating command blocks are not generating properly... there are just stacks or individual command blocks sitting there where it appears a structure should be. Anyone have any idea why? I'm not familiar with command blocks.
I'd recommend using the "NO CB" version of my templates, then, if for some reason Command Blocks aren't working with your particular mod setup.
Im wondering if anyone can help me. Im using ruins mod for minecraft 1.7.10 and have just installed the ruin templates made by Jordan_Greywolf, however it appears that many of the ruins incorporating command blocks are not generating properly... there are just stacks or individual command blocks sitting there where it appears a structure should be. Anyone have any idea why? I'm not familiar with command blocks.
I had this problem once with minecraft 1.7.10 when I updated the fastcraft mod to fastcraft-1.22.jar. The Ruins mod ruinstrigger command stopped working and command blocks would just exist in the world doing nothing. Once I rolled back to fastcraft-1.21.jar, the problem went away.
The Meaning of Life, the Universe, and Everything.
Location:
Somewhere. Not sure. There?
Join Date:
12/10/2012
Posts:
49
Location:
On the side of the planet.
Minecraft:
Mr_Maddox
Xbox:
admjmaddox
PSN:
admjmaddox
Member Details
So, I've been away from the minecraft game for a bit, and have recently resumed playing. Yes, of course I had to get the Ruins Mod. So anyways, I've made a template called MM-Dock.tml that I would like for some to test to provide me with insight / constructive criticism.
It's just a basic build, nothing fancy. As far as I know, the build (which is basic) doesn't contain any required mods.
I have attached some screenshots. If you'd like to test this just shoot me a message. I can be reached on Facebook (admjmaddox / Terry Handel) and Discord (admjmaddox#8311)
ATTACHMENTS
2019-02-16_06.18.43
2019-02-16_06.20.22
2019-02-16_06.21.11
2019-02-16_06.21.56
2019-02-16_06.23.09
Rollback Post to RevisionRollBack
Terry R. Handel
Citizen Minecraftian
"Is it Summer yet?"
Just be aware that areas covered with auto-lamps such as cities can have extreme lag spikes at every sunrise and sunset, on the order of a full second, using just as many lamps as pictured above (70 or so). Of course they would produce the most lag per lamp if each lamp was in it's own chunk.
The Meaning of Life, the Universe, and Everything.
Location:
Somewhere. Not sure. There?
Join Date:
12/10/2012
Posts:
49
Location:
On the side of the planet.
Minecraft:
Mr_Maddox
Xbox:
admjmaddox
PSN:
admjmaddox
Member Details
Okay, so I'll go in and change out the lighting to avoid that. On my P.C. it doesn't lag for me, but it helps remind me others do. I'm wondering if I should use Glowstone or Torches for the lighting.
Rollback Post to RevisionRollBack
Terry R. Handel
Citizen Minecraftian
"Is it Summer yet?"
Is it the lantern that causes the lag, or the method of switching? If you're just going to leave the lighting always-on, I suppose you could just have lanterns but keep them triggered. (Although I guess they might not look as aesthetically pleasing as the lantern-with-panel-on-top build.)
Random ideas:
* Glowstone + trap doors = interesting "lantern" substitute. Place a glowstone block, then put trap doors on each side, and flip them down, so you have a trap door texture on each side.
* You might be able to keep the same basic idea, but reduce the number of lamps you need for the end result, by having more of your area floored with blocks that mobs won't (normally) spawn on. Half-slabs are great for this, but only if the half-slab occupies the lower-half of the block it's in. Same goes for stairs (as long as they're right-side-up, not upside-down). For whatever reason, if it's the very same slab but it occupies the UPPER half, mobs will spawn there normally. Note: This will NOT work for dissuading mobs spawned by mob-spawners. By paving large areas with lower-half slabs (and stairs, for level changes) you would free up large areas where you don't have to push the light level above 7 to dissuade creeper-spawning. And, I'm guessing, a lower density of lamps would mean a lower drag on the system.
(I remember a while back, when my local gang first toyed around with Minecraft on multiplayer servers, we had some players who'd forswear lighting up their areas -- and press others to follow their example -- claiming that every loaded light source dragged down server processing. That made things a bit more *challenging*. I have no idea how much truth was behind such claims. It gave me some incentive to find other ways to keep the monster-count down other than just light sources, since that was before we had any of those oh-so-useful mods that would allow us to advance through the night if a mere majority of players in the Overworld hit the bed -- back then, even ONE person could be still awake, in the Nether, and we'd be stuck watching as creepers kept popping up in our orchards all night. I tended to move out to "floating bases" over water, or up to a sky-island or sky-ship, where I could have a little more insulation against random mob spawns without having to give up my view of the great blocky outdoors.)
I have managed to perform the basic port of Ruins to Forge 1.13.2.
[I will make a public release later, after I've investigated some features removed for now and possibly returning, like rotation...]
On a minor note, no existing template will work with it.
The only realistic avenue of moving configs over is, unfortunately, to place them all in a 1.12 or earlier world, load the save in 1.13, and use the ingame parser to get new format templates.
Yeah, I expect it's going to be a major undertaking, and my "collection" for 1.13 will necessarily be a lot smaller to start off with, but I look forward to getting started on this, and making use of the changes in 1.13. (I'm really hoping that once they've gotten over this hurdle in how they handle objects, MAYYYYBE the inevitable move from 1.13 to 1.14 won't be quite as disruptive? Ah well. I can dream. )
Is there any documentation on the new syntax? For instance, for the example "unacceptable_target_blocks," does the "0" count as some sort of wild card? (As in, I am guessing that the "level" must correspond to partially-filled lava/water block flows or something like that, and that there are several variants, but the "0" in this context makes sure that ALL forms of lava and water are unacceptable?)
But most importantly, again, THANK YOU for tackling this. Despite the obvious challenges, I look forward to getting cracking on this (starting with the fairly "simple" stuff first -- without getting too crazy with the command blocks), and seeing what new things I can do in 1.13.
The new syntax is the vanilla minecraft NBT scheme for 1.13. My only addition is the inclusion of TileEntity data inside the IBlockState nbt (denoted by the tag "ruinsTE") because i have to store both together.
Properties:{level:"0"} is an IFluid state. Level 0 means ... full block of water/lava? Look up your minecraft metadata wiki of choice to figure out how that works. I am using vanilla methods for serializing and deserializing.
@AtomicStryker: Okay, thanks! As for how Ruins handles the new syntax -- if I make an unacceptable_target_blocks line as you've spelled out above, but I leave out the Properties:{level:"0"} part, will it still exclude water/lava (regardless of fill level, perhaps) or would that break the syntax? (I.e., if I DO NOT specify the Properties in that line, will that cause a problem, or is there some sort of default assumption?)
I would assume that any property you leave unspecified remains in the default state, which in case of fluids is indeed 0.
You have pinpointed what i consider the biggest drawback for Ruins of this new system: There is no such thing as wildcards or ranges. Unless i implement that.
Working: Template parsing (for any block and tiles), template spawning by command, (tentatively..) randomly spawning in world, template rotation, chest loot tables (parse empty tables and get them filled with loot automatically).
Not working: Ruins auto triggered command blocks, block spawn chance (always 100% now), block conditionals (no longer needed)
Is it possible to work around the lack of a block spawn chance (in order to make RUINED ruins) by making use of multiple-choice for a given block rule? (E.g., stone, stone, stone, air = 75% chance of stone block, 25% of empty air?)
Also, what is meant by "block conditionals" (that are no longer needed)?
The <condition> part of a rule, in which you could put values like "only spawn if adjoining block exists" or "only spawn if block below exists".
Mostly used in conjunction with wall torches, signs etc which relied on blocks other than themselves - but the new IBlockStates make that irrelevant. AFAIK blocks should no longer calculate their own status using neighbour blocks. (Pistons maybe?!)
The <condition> part of a rule, in which you could put values like "only spawn if adjoining block exists" or "only spawn if block below exists".
Mostly used in conjunction with wall torches, signs etc which relied on blocks other than themselves - but the new IBlockStates make that irrelevant. AFAIK blocks should no longer calculate their own status using neighbour blocks. (Pistons maybe?!)
Okay, but the "ruined" part of Ruins (or the randomization thereof) pretty much depended upon those sorts of relationships. I could have, say, a crumbling wall structure, and randomly take chunks out of it, but in order to make sure that doesn't result in orphaned blocks floating in mid-air, rule #1 was handy for making sure none of those blocks would be placed unless they were supported by something other than air.
I can still make "ruined" buildings, it seems, but I either make it a static structure (it is ruined in EXACTLY this particular way), or else I just have a few select blocks that might or might not be missing here or there, but there will still be an underlying "skeleton" that will still be intact, to minimize the chance of gravity-defying segments floating about. It's doable, I hope -- just different.
Anyway, I'm presently working my way through my library of structures and modifying them: removing all "random" elements, converting dungeon chests back to plain empty minecraft:chest objects, disabling any RUINSTRIGGER Command Blocks, zeroing out "embed_into_distance" settings -- and then to replace all instances of "preserveBlock" with a placeholder block, such as stained glass). For now, anything of mine that used Command Blocks to spawn custom one-time monsters (or structures) isn't worth the trouble, since that part isn't working. I'll try experimenting with the adjoining templates, to see if they work.
I'm curious to see whether any of my customized Mob Spawners might actually work (if they'll be picked up by the parseruin routine); no harm in trying, I suppose.
My plan is to spawn them all in a superflat 1.12 world to serve as a conversion "workshop" -- one layer of bedrock, one layer of diamond block, and I ought to have a good starting point for base plates to chip away at as needed for parsing in 1.13.
I guess I'll try converting over the old Ruins-bundle ruins as well.
I need help. I'm trying to get a structure I made with the parser to spawn in the Beneath dimension and it is not working. Anyone else have any success getting structures to spawn in a particular dimension?
I have the dimension listed in that file and it is in the Beneath folder in the ruins config folder. Not sure what is wrong. Is there a way to get ruins to spawn in specific dimensions, and if so, what is the correct syntax for making it happen?
Couple things right off the bat. Firstly, the unfortunately-named dimensions config parameter refers to the size of the structure, not the dimensions in which it spawns. In your case, you should set it as follows:
dimensions=6,9,9
Secondly, the folders are named after biomes, not dimensions, so unless there's a biome named "Beneath" (unlikely, though I'm not familiar with that mod), you'll have to either rename the folder to a biome name, or move the template to an existing biome folder and add to the biomesToSpawnIn list (or add biome types to the biomeTypesToSpawnIn list) so as to include the desired new biome(s).
Thirdly--and this is the tricky one--you have to enable Ruins to work in the mod dimension. It looks like you already determined the dimension ID number (10); this needs to be added to the allowedDimensions list in both config/ruins.txt and world/DIM10/ruins.txt:
allowedDimensions=0,1,-1,10
The "world" folder might not be called "world" in your case, depending on whether you're running single-player, or if you modified level-name in server.properties, so you might have to poke around for that file. In fact, if you're starting a brand new world, it won't exist at all...but if it does, you'll have to modify it.
Maybe I am missing it somewhere but can someone tell me how to bring my old ruins into 1.13.2? every time I try to load one to save into new format I get errors loading. I hope I don't have to rebuild them!!!
Maybe I am missing it somewhere but can someone tell me how to bring my old ruins into 1.13.2? every time I try to load one to save into new format I get errors loading. I hope I don't have to rebuild them!!!
Unfortunately there is no API for loading the legacy format directly into Ruins version 1.13+, so carrying things over is left to other methods.
Lately I've been hardcoding worldgen in such a way that generates things entirely with mathematics, with quite a lot in place in a standalone programming language, and have developed several completed systems that I'm ready to bring into Java.
Im wondering if anyone can help me. Im using ruins mod for minecraft 1.7.10 and have just installed the ruin templates made by Jordan_Greywolf, however it appears that many of the ruins incorporating command blocks are not generating properly... there are just stacks or individual command blocks sitting there where it appears a structure should be. Anyone have any idea why? I'm not familiar with command blocks.
I'd recommend using the "NO CB" version of my templates, then, if for some reason Command Blocks aren't working with your particular mod setup.
--- 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 had this problem once with minecraft 1.7.10 when I updated the fastcraft mod to fastcraft-1.22.jar. The Ruins mod ruinstrigger command stopped working and command blocks would just exist in the world doing nothing. Once I rolled back to fastcraft-1.21.jar, the problem went away.
So, I've been away from the minecraft game for a bit, and have recently resumed playing. Yes, of course I had to get the Ruins Mod. So anyways, I've made a template called MM-Dock.tml that I would like for some to test to provide me with insight / constructive criticism.
It's just a basic build, nothing fancy. As far as I know, the build (which is basic) doesn't contain any required mods.
I have attached some screenshots. If you'd like to test this just shoot me a message. I can be reached on Facebook (admjmaddox / Terry Handel) and Discord (admjmaddox#8311)
Terry R. Handel
Citizen Minecraftian
"Is it Summer yet?"
Looking good.
Just be aware that areas covered with auto-lamps such as cities can have extreme lag spikes at every sunrise and sunset, on the order of a full second, using just as many lamps as pictured above (70 or so). Of course they would produce the most lag per lamp if each lamp was in it's own chunk.
Gillymoth Structures for Ruins <<< Folder containing my Structure-sets for Ruins mod.
Okay, so I'll go in and change out the lighting to avoid that. On my P.C. it doesn't lag for me, but it helps remind me others do. I'm wondering if I should use Glowstone or Torches for the lighting.
Terry R. Handel
Citizen Minecraftian
"Is it Summer yet?"
@admjmaddox:
Is it the lantern that causes the lag, or the method of switching? If you're just going to leave the lighting always-on, I suppose you could just have lanterns but keep them triggered. (Although I guess they might not look as aesthetically pleasing as the lantern-with-panel-on-top build.)
Random ideas:
* Glowstone + trap doors = interesting "lantern" substitute. Place a glowstone block, then put trap doors on each side, and flip them down, so you have a trap door texture on each side.
* You might be able to keep the same basic idea, but reduce the number of lamps you need for the end result, by having more of your area floored with blocks that mobs won't (normally) spawn on. Half-slabs are great for this, but only if the half-slab occupies the lower-half of the block it's in. Same goes for stairs (as long as they're right-side-up, not upside-down). For whatever reason, if it's the very same slab but it occupies the UPPER half, mobs will spawn there normally. Note: This will NOT work for dissuading mobs spawned by mob-spawners. By paving large areas with lower-half slabs (and stairs, for level changes) you would free up large areas where you don't have to push the light level above 7 to dissuade creeper-spawning. And, I'm guessing, a lower density of lamps would mean a lower drag on the system.
(I remember a while back, when my local gang first toyed around with Minecraft on multiplayer servers, we had some players who'd forswear lighting up their areas -- and press others to follow their example -- claiming that every loaded light source dragged down server processing. That made things a bit more *challenging*. I have no idea how much truth was behind such claims. It gave me some incentive to find other ways to keep the monster-count down other than just light sources, since that was before we had any of those oh-so-useful mods that would allow us to advance through the night if a mere majority of players in the Overworld hit the bed -- back then, even ONE person could be still awake, in the Nether, and we'd be stuck watching as creepers kept popping up in our orchards all night. I tended to move out to "floating bases" over water, or up to a sky-island or sky-ship, where I could have a little more insulation against random mob spawns without having to give up my view of the great blocky outdoors.)
--- 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)
Good news everyone!
I have managed to perform the basic port of Ruins to Forge 1.13.2.
[I will make a public release later, after I've investigated some features removed for now and possibly returning, like rotation...]
On a minor note, no existing template will work with it.
The only realistic avenue of moving configs over is, unfortunately, to place them all in a 1.12 or earlier world, load the save in 1.13, and use the ingame parser to get new format templates.
Some examples of why this is unavoidable:
unacceptable_target_blocks={Properties:{level:"0"},Name:"minecraft:water"},{Properties:{level:"0"},Name:"minecraft:lava"}
THANKYOUTHANKYOUTHANKYOUSOMUCH!
Yeah, I expect it's going to be a major undertaking, and my "collection" for 1.13 will necessarily be a lot smaller to start off with, but I look forward to getting started on this, and making use of the changes in 1.13. (I'm really hoping that once they've gotten over this hurdle in how they handle objects, MAYYYYBE the inevitable move from 1.13 to 1.14 won't be quite as disruptive? Ah well. I can dream. )
Is there any documentation on the new syntax? For instance, for the example "unacceptable_target_blocks," does the "0" count as some sort of wild card? (As in, I am guessing that the "level" must correspond to partially-filled lava/water block flows or something like that, and that there are several variants, but the "0" in this context makes sure that ALL forms of lava and water are unacceptable?)
But most importantly, again, THANK YOU for tackling this. Despite the obvious challenges, I look forward to getting cracking on this (starting with the fairly "simple" stuff first -- without getting too crazy with the command blocks), and seeing what new things I can do in 1.13.
--- 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)
The new syntax is the vanilla minecraft NBT scheme for 1.13. My only addition is the inclusion of TileEntity data inside the IBlockState nbt (denoted by the tag "ruinsTE") because i have to store both together.
Properties:{level:"0"} is an IFluid state. Level 0 means ... full block of water/lava? Look up your minecraft metadata wiki of choice to figure out how that works. I am using vanilla methods for serializing and deserializing.
@AtomicStryker: Okay, thanks! As for how Ruins handles the new syntax -- if I make an unacceptable_target_blocks line as you've spelled out above, but I leave out the Properties:{level:"0"} part, will it still exclude water/lava (regardless of fill level, perhaps) or would that break the syntax? (I.e., if I DO NOT specify the Properties in that line, will that cause a problem, or is there some sort of default assumption?)
--- 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 would assume that any property you leave unspecified remains in the default state, which in case of fluids is indeed 0.
You have pinpointed what i consider the biggest drawback for Ruins of this new system: There is no such thing as wildcards or ranges. Unless i implement that.
Well, have a release for 1.13.2
https://minecraft.curseforge.com/projects/ruins-structure-spawning-system/files/2691187
Working: Template parsing (for any block and tiles), template spawning by command, (tentatively..) randomly spawning in world, template rotation, chest loot tables (parse empty tables and get them filled with loot automatically).
Not working: Ruins auto triggered command blocks, block spawn chance (always 100% now), block conditionals (no longer needed)
Untested: Adjoining templates
DOES NOT CONTAIN ANY TEMPLATES
@AtomicStryker:
Is it possible to work around the lack of a block spawn chance (in order to make RUINED ruins) by making use of multiple-choice for a given block rule? (E.g., stone, stone, stone, air = 75% chance of stone block, 25% of empty air?)
Also, what is meant by "block conditionals" (that are no longer needed)?
--- 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)
Yes
The <condition> part of a rule, in which you could put values like "only spawn if adjoining block exists" or "only spawn if block below exists".
Mostly used in conjunction with wall torches, signs etc which relied on blocks other than themselves - but the new IBlockStates make that irrelevant. AFAIK blocks should no longer calculate their own status using neighbour blocks. (Pistons maybe?!)
Okay, but the "ruined" part of Ruins (or the randomization thereof) pretty much depended upon those sorts of relationships. I could have, say, a crumbling wall structure, and randomly take chunks out of it, but in order to make sure that doesn't result in orphaned blocks floating in mid-air, rule #1 was handy for making sure none of those blocks would be placed unless they were supported by something other than air.
I can still make "ruined" buildings, it seems, but I either make it a static structure (it is ruined in EXACTLY this particular way), or else I just have a few select blocks that might or might not be missing here or there, but there will still be an underlying "skeleton" that will still be intact, to minimize the chance of gravity-defying segments floating about. It's doable, I hope -- just different.
Anyway, I'm presently working my way through my library of structures and modifying them: removing all "random" elements, converting dungeon chests back to plain empty minecraft:chest objects, disabling any RUINSTRIGGER Command Blocks, zeroing out "embed_into_distance" settings -- and then to replace all instances of "preserveBlock" with a placeholder block, such as stained glass). For now, anything of mine that used Command Blocks to spawn custom one-time monsters (or structures) isn't worth the trouble, since that part isn't working. I'll try experimenting with the adjoining templates, to see if they work.
I'm curious to see whether any of my customized Mob Spawners might actually work (if they'll be picked up by the parseruin routine); no harm in trying, I suppose.
My plan is to spawn them all in a superflat 1.12 world to serve as a conversion "workshop" -- one layer of bedrock, one layer of diamond block, and I ought to have a good starting point for base plates to chip away at as needed for parsing in 1.13.
I guess I'll try converting over the old Ruins-bundle ruins as well.
--- 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 need help. I'm trying to get a structure I made with the parser to spawn in the Beneath dimension and it is not working. Anyone else have any success getting structures to spawn in a particular dimension?
This is the file the parser made: https://pastebin.com/Djs0gPkL
I have the dimension listed in that file and it is in the Beneath folder in the ruins config folder. Not sure what is wrong. Is there a way to get ruins to spawn in specific dimensions, and if so, what is the correct syntax for making it happen?
Couple things right off the bat. Firstly, the unfortunately-named dimensions config parameter refers to the size of the structure, not the dimensions in which it spawns. In your case, you should set it as follows:
dimensions=6,9,9
Secondly, the folders are named after biomes, not dimensions, so unless there's a biome named "Beneath" (unlikely, though I'm not familiar with that mod), you'll have to either rename the folder to a biome name, or move the template to an existing biome folder and add to the biomesToSpawnIn list (or add biome types to the biomeTypesToSpawnIn list) so as to include the desired new biome(s).
Thirdly--and this is the tricky one--you have to enable Ruins to work in the mod dimension. It looks like you already determined the dimension ID number (10); this needs to be added to the allowedDimensions list in both config/ruins.txt and world/DIM10/ruins.txt:
allowedDimensions=0,1,-1,10
The "world" folder might not be called "world" in your case, depending on whether you're running single-player, or if you modified level-name in server.properties, so you might have to poke around for that file. In fact, if you're starting a brand new world, it won't exist at all...but if it does, you'll have to modify it.
Maybe I am missing it somewhere but can someone tell me how to bring my old ruins into 1.13.2? every time I try to load one to save into new format I get errors loading. I hope I don't have to rebuild them!!!
Unfortunately there is no API for loading the legacy format directly into Ruins version 1.13+, so carrying things over is left to other methods.
Lately I've been hardcoding worldgen in such a way that generates things entirely with mathematics, with quite a lot in place in a standalone programming language, and have developed several completed systems that I'm ready to bring into Java.
Gillymoth Structures for Ruins <<< Folder containing my Structure-sets for Ruins mod.