By "a surface block" i do in fact mean EVERY surface block of the template sized spawning area. And obsolete? Why? There are lava lakes in snow biomes. What would your approach do if a template was to spawn both on snow (allowed) and lava (disallowed)?
Been trying to see if it's mentioned anywhere but searches give a million results and not the info I'm after. Might be easier to just ask you.
Ruins obviously has some sort of randomiser built into it, is there any way to call on that from a spawning ruin ?
Basically want to (ab)use the 'adjoining_template' command to call on a directory rather than a specific template. Throw all the 'house' templates in one directory except one I put in generic. The y test alone should stop it going infinite unless I do it on a flat world and even then with each template only spawning in two directions eventually random numbers are going to mean overlap makes spawn mechanics abort.
Rollback Post to RevisionRollBack
___/\___. Death-9 . . . . Old enough to remember when
. 0 0 . . umop ap!sdn . . the Blue Wave could add
. .(. . . Genghis Cohen . random tag-lines to your
.\____/ . Agnostos Theos. posts.
Where did you get that idea? That is simply untrue. Both these lines are optional and can coexist. A surface block is first checked against the unacceptable list, and then against the acceptable list, but against BOTH in the success case.
Where? Experimentation and WILD GUESSES, because the documentation doesn't exactly tell me these things. But as often happens, the best way for me to learn the particulars is to make broad, sweeping declarations in a public forum that are most probably in error, because it's an effective method so far to prompt someone who knows better to come along and correct me.
EDIT: Also, I have to agree with Agnostos_Theos on ... "Why?" If we first check against the unacceptable list (make there's no lava!) and THEN check against the acceptable list (it can only be stone, grass, dirt, gravel, sand, or clay), then why do we even bother with the first step? Doesn't the first step become redundant, in that unless I put lava (etc.) in BOTH those lists (for who-knows-why reason), the very nature of the exclusive "acceptable_target_block" list will rule out anything in the "unacceptable" list?
From the context of the later example ("spawn both on snow (allowed) and lava (disallowed)") I am having difficulty understanding the process. Does the building routine somehow "forgive" a certain amount of blocks not being of the correct type, if it's checking the entire footprint area? I would have thought that if lava is in the unacceptable_target_blocks list, then if it is checking ALL the surface-level blocks of the footprint, then ANY block being lava would result in a fail, and it would not build there. By the same token, if ALL surface-level blocks are tested against "acceptable_target_blocks" I would expect that ANY block that is not in that list (lava certainly not being the same as snow) would be by definition UNacceptable, and would result in a failure to build.
By implication from your example, I must be incorrect (again), but I am still not certain what IS correct.
I guess I need to figure out where the source is, track down the relevant routine, and see if I can follow the logic well enough to figure out what it's doing and how it's prioritizing things.
Ruins obviously has some sort of randomiser built into it, is there any way to call on that from a spawning ruin ?
Basically want to (ab)use the 'adjoining_template' command to call on a directory rather than a specific template. Throw all the 'house' templates in one directory except one I put in generic.
That is how my cities have random houses in them, and it is good practice to name a new folder for everything that your templates are likely to call, as it keeps the templateparser folder clear and separate from any experimental templates, also choose a folder name that is unlikely to sound like it could be a biome. I chose Gilly to honor our family cat, although it could potentially become a biome name as well.
This is the key line of code from one of my templates that calls random structures:
Every part of it was carefully considered, including the offsets of zero, as this is for my Adobe City, and the top view of this city looks completely random because of the carefully designed random shapes of the sets of buildings themselves. On the other hand, the towers represent a distinctive feature in the cityscape, and have random offsets to scatter them more evenly (using the mathematical scaling of Fibonacci spirals to be precise) Showing example generation of my Adobe City below.
The below example is a render with my MCedit filter designed to make spawn domes instantly, it's set to one thick to show the calibration of my Fibonacci-sunflower spacing of glowstone lighting on the surface of the dome.
I'm trying to do something very similar to what you have for your city there (which looks great by the way!). Could you explain what your code is doing with these commands or point me to documentation that explains how to make something like this?
I've been trying to figure out how to do some random generation to build neat dungeons, but what I've found isn't so much helpful as it is lines of code with little or no explanation.
Rollback Post to RevisionRollBack
Remember: You are unique... Just like everyone else
A wise man once told me, "Coding is 1% writing code and 99% figuring out why it didn't work."
Basically it's a rule in the template that has extra arguments that Ruins will choose from randomly, each entry is weighted evenly, but you can repeat entries that you want weighted more. It's just that simple.
Here is the one line formatted for clarity, notice the repeated sections.
Each part calls a different template in a custom folder called Gilly, and the files are called GillyA1-8 ("A" representing Adobe, short filenames are for clarity and making it easy to debug) It's exactly the same as when the rule specifies "dirt,dirt,dirt,stone_bricks,air", but instead of blocks it references files. Also, there are minor differences between RuinsTrigger and AdjoiningTemplate, and either may be preferred over the other, depending on exactly what is being done.
Was hoping there was a way to call the directory and using what ever randomiser RUINS uses to chose a template from generic when it's just running normaly (mostly because I'm lazy and want to be able to just drag templates into the 'megacity' directory with-out having to then go add another option to the spawner commandblock).
Was thinking I could have a block of air that spawned on dirt (or grass) in generic folder that ran adjoining template to call up that command block NSE&W. testruin doesn't test the surface it's spawning on it just spawns what-ever at location so in each on the actual building templates I use adjoining template again to call up my 'air block' with a y variation of 1 or 2.... my city should spread over small changes in altitude but stop when it hits huge changes or hits a surface that the air block isn't allowed to spawn on. Might have to fiddle with spacing but 'think' it will work for what I want.
Now if I can just find a way to automate notepad++ to make the commandblock rule for me :-)
Rollback Post to RevisionRollBack
___/\___. Death-9 . . . . Old enough to remember when
. 0 0 . . umop ap!sdn . . the Blue Wave could add
. .(. . . Genghis Cohen . random tag-lines to your
.\____/ . Agnostos Theos. posts.
The documentation says both are optional (i checked) and nothing else. Unless i specifically say two settings/entries are exclusive, aka don't work together, they do. In the snow/lava case it would NOT spawn because of the lava collision. There is no forgiveness.
The documentation says both are optional (i checked) and nothing else. Unless i specifically say two settings/entries are exclusive, aka don't work together, they do. In the snow/lava case it would NOT spawn because of the lava collision. There is no forgiveness.
Okay. Approaching this from another direction:
Let us say that acceptable_target_blocks=snow and unacceptable_target_blocks=lava,flowing_lava,water,flowing_lava in a theoretical example for a template that has dimensions of 7,5,5 (so a "footprint" of 5x5 blocks) and embed_into_distance=3.
Ruins randomly picks a spot in an ice plains biome, but there is a slight incline. For simplicity, let's say that dead center of the target area is at elevation 64, whereas the two rightmost columns are at levels 65 and 66, and the two leftmost columns are at levels 62 and 63, and that whatever I set for max_leveling happens to allow for this small variance. I'm assuming that "snow_layer", which would probably be at the topmost level in any snowy region, is ignored. (If I am incorrect, then my example needs adjustment.) And while I don't recall how deep it usually is, let's pretend the snow layer is only two blocks deep.
1: Do the "target blocks" include everything at the same level as where we start building? In my example, would that mean that they're all at level 64? OR, is the elevation for every target block within the "footprint" area calculated separately? Would I get "snow" for all my targets here, or would I run the risk that the rightmost column (level 66 at the surface, and the snow is only two blocks deep -- i.e., levels 65 and 66) will have DIRT as a target block, because what's at level 64 at that point is dirt?
2: Regardless of how the above works, let's pretend that in my example, for some reason, there is a block of STONE at the surface level, within the area of the footprint, and it doesn't have any snow on top of it. (I don't know how this would happen in normal terrain generation in a snowy zone. This is purely hypothetical.) "Stone" is not in the acceptable_target_blocks list, but it's also NOT in the unacceptable_target_blocks list.
In that case, does the structure build or not build, based on the material in the target blocks? If it DOES build, then that would make me wonder what the point was of specifying "acceptable_target_blocks," since all that really mattered was that it was not lava. If it DOES NOT build, then that would make me wonder what the point was of specifying "unacceptable_target_blocks," since all that really mattered was that it was not snow.
I apologize if my example is too convoluted to follow, but I hope this might help to illustrate my point of confusion. Maybe I should make some diagrams. Either that, or I just need to read the source and sort it out for myself.
The Meaning of Life, the Universe, and Everything.
Join Date:
4/27/2014
Posts:
53
Member Details
I would like to have ruins generate in the Abyssalcraft Omothol dimension. Omothol is dimension 52 and I whitelisted that dimension in the ruins.txt file:
# dimension IDs whitelisted for ruins spawning, add custom dimensions IDs here as needed allowedDimensions=0,-1,52
But Abyssalcraft actually saves that dimension in a folder called 'Omothol' rather than 'DIM52' as most dimensions would typically be saved. Does the whitelisted dimension in ruins.txt have to be a number? Or is there a blacklist option instead of whitelist so Omothol will be allowed unless specifically excluded?
anyone willing to put up a jar file of ruins that has all the other structures active and spawnable? Because i really want those. Like desperatly. They are really ineresting (they are in all the other mod packs i have. i have no way to actually do it myself as one, i am kinda stupid, and two, i use a Mac, not PC, which makes it extra difficult.
Ruins gets it's structures from txt files in your mods folder. mods/resources/ruins has folders for every biome, plus one for "generic" and one for "optional". You just need to move the txt files from optional to generic.
Just downloaded the latest Forge 1.9 (1865) and the latest ruins for 1.9 and it's crashing. It's the only mod I have installed so I know it's not a conflict between 2 mods. Do I need to use an earlier version of Forge?
Just downloaded the latest Forge 1.9 (1865) and the latest ruins for 1.9 and it's crashing. It's the only mod I have installed so I know it's not a conflict between 2 mods. Do I need to use an earlier version of Forge?
It works perfectly for me with 1863. Did you extract all the files properly??
Just downloaded the latest Forge 1.9 (1865) and the latest ruins for 1.9 and it's crashing. It's the only mod I have installed so I know it's not a conflict between 2 mods. Do I need to use an earlier version of Forge?
The last relevant post I saw from AtomicStryker on the topic said that the Ruins for MC 1.9 was built against Forge 1846, so that's the build I'm using, and it works fine for me.
I did have some trouble launching MC 1.9 IN GENERAL on one of the computers I work with, but that was with or without Ruins. I ended up having to use the video settings option for "Use VBOs" or else the game (Vanilla or otherwise) could crash immediately upon loading a world (new or otherwise). (The other computer didn't have this problem at all, and they're both running the same operating system and have the same memory capacity, but it worked just fine on the slightly newer computer, and crashed on the slightly older one -- until I made that change. I'm not really sure what the critical difference was.)
I've recently set this up in a personal little mod loadout and am really enjoying it. Finding all these little derelict buildings scattered around that I can break down or fortify for a night is great, plus the little micro-dungeons it adds. Really breathes some life into a largely vanilla overworld.
But I've been noticing a strange happening as I explore more. Sometimes there are blank plots with the ruin footprints. Sometimes even pits like this one.
I'm sure this is entirely my fault. I added a bunch of the obsolete/optional ruins back into the game, though I tested all of them in a superflat (64 deep) world first to make sure they were working. Found a few that refused to spawn in, and removed them from the active folders. But otherwise they were all coming in. In the process of adding these back in, clearly I FUBAR'd something.
What I'm wondering is, is there a way to tell which ruin attempted to spawn at a given spot, so I can track down the template for it?
I'm using 1.7.10 with the appropriate version of RuinsMod, and Forge 1614. I'll be happy to post any other logs or information to help narrow this down.
Otherwise, it's not too big a problem. It's usually pretty small plots of land that get flattened.
EDIT: It occurs to me that I added CoFH Core, Nether Ores, Project Red Core, and Project Red World (I wanted copper + nether ores!) afterward. Perhaps the way they're hooking into world gen is causing problems...
So I have just figured out how to tell my dungeon whether or not to generate a door to more rooms using the new chain command blocks from 1.9. After parsing and testing, only the default (impulse) command blocks have retained their commands.
Lo and behold, the text file for the ruin has saved the blocks and the metadata that corresponds to all of the new options (needs redstone/always active and conditional/unconditional), but has no place to save the commands.
AtomicStryker, this functionality should probably be fixed to work like the normal command blocks.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumBy "a surface block" i do in fact mean EVERY surface block of the template sized spawning area. And obsolete? Why? There are lava lakes in snow biomes. What would your approach do if a template was to spawn both on snow (allowed) and lava (disallowed)?
Yeah, makes sense put like that.
Been trying to see if it's mentioned anywhere but searches give a million results and not the info I'm after. Might be easier to just ask you.
Ruins obviously has some sort of randomiser built into it, is there any way to call on that from a spawning ruin ?
Basically want to (ab)use the 'adjoining_template' command to call on a directory rather than a specific template. Throw all the 'house' templates in one directory except one I put in generic. The y test alone should stop it going infinite unless I do it on a flat world and even then with each template only spawning in two directions eventually random numbers are going to mean overlap makes spawn mechanics abort.
___/\___. Death-9 . . . . Old enough to remember when
. 0 0 . . umop ap!sdn . . the Blue Wave could add
. .(. . . Genghis Cohen . random tag-lines to your
.\____/ . Agnostos Theos. posts.
Where? Experimentation and WILD GUESSES, because the documentation doesn't exactly tell me these things. But as often happens, the best way for me to learn the particulars is to make broad, sweeping declarations in a public forum that are most probably in error, because it's an effective method so far to prompt someone who knows better to come along and correct me.
EDIT: Also, I have to agree with Agnostos_Theos on ... "Why?" If we first check against the unacceptable list (make there's no lava!) and THEN check against the acceptable list (it can only be stone, grass, dirt, gravel, sand, or clay), then why do we even bother with the first step? Doesn't the first step become redundant, in that unless I put lava (etc.) in BOTH those lists (for who-knows-why reason), the very nature of the exclusive "acceptable_target_block" list will rule out anything in the "unacceptable" list?
From the context of the later example ("spawn both on snow (allowed) and lava (disallowed)") I am having difficulty understanding the process. Does the building routine somehow "forgive" a certain amount of blocks not being of the correct type, if it's checking the entire footprint area? I would have thought that if lava is in the unacceptable_target_blocks list, then if it is checking ALL the surface-level blocks of the footprint, then ANY block being lava would result in a fail, and it would not build there. By the same token, if ALL surface-level blocks are tested against "acceptable_target_blocks" I would expect that ANY block that is not in that list (lava certainly not being the same as snow) would be by definition UNacceptable, and would result in a failure to build.
By implication from your example, I must be incorrect (again), but I am still not certain what IS correct.
I guess I need to figure out where the source is, track down the relevant routine, and see if I can follow the logic well enough to figure out what it's doing and how it's prioritizing things.
--- 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)
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumAtomicStryker, Your mod - "Ruins" inspired me to create placemod, thank you very much, mate.
Good job.
(¯`·.¸¸.·´¯`·.¸¸.->
<-.¸¸.·´¯`·.¸¸.·´¯)
That is how my cities have random houses in them, and it is good practice to name a new folder for everything that your templates are likely to call, as it keeps the templateparser folder clear and separate from any experimental templates, also choose a folder name that is unlikely to sound like it could be a biome. I chose Gilly to honor our family cat, although it could potentially become a biome name as well.
This is the key line of code from one of my templates that calls random structures:
rule1=0,100,CommandBlock:RUINSTRIGGER /testruin Gilly/GillyA1 ~0 ~4 ~0:@,CommandBlock:RUINSTRIGGER /testruin Gilly/GillyA2 ~0 ~4 ~0:@,CommandBlock:RUINSTRIGGER /testruin Gilly/GillyA3 ~0 ~4 ~0:@,CommandBlock:RUINSTRIGGER /testruin Gilly/GillyA4 ~0 ~4 ~0:@,CommandBlock:RUINSTRIGGER /testruin Gilly/GillyA5 ~0 ~4 ~0:@,CommandBlock:RUINSTRIGGER /testruin Gilly/GillyA6 ~0 ~4 ~0:@,CommandBlock:RUINSTRIGGER /testruin Gilly/GillyA7 ~0 ~4 ~0:@,CommandBlock:RUINSTRIGGER /testruin Gilly/GillyA8 ~0 ~4 ~0:@
layer
1
endlayer
Every part of it was carefully considered, including the offsets of zero, as this is for my Adobe City, and the top view of this city looks completely random because of the carefully designed random shapes of the sets of buildings themselves. On the other hand, the towers represent a distinctive feature in the cityscape, and have random offsets to scatter them more evenly (using the mathematical scaling of Fibonacci spirals to be precise) Showing example generation of my Adobe City below.
The below example is a render with my MCedit filter designed to make spawn domes instantly, it's set to one thick to show the calibration of my Fibonacci-sunflower spacing of glowstone lighting on the surface of the dome.
Gillymoth Structures for Ruins <<< Folder containing my Structure-sets for Ruins mod.
I'm trying to do something very similar to what you have for your city there (which looks great by the way!). Could you explain what your code is doing with these commands or point me to documentation that explains how to make something like this?
I've been trying to figure out how to do some random generation to build neat dungeons, but what I've found isn't so much helpful as it is lines of code with little or no explanation.
Remember: You are unique... Just like everyone else
A wise man once told me, "Coding is 1% writing code and 99% figuring out why it didn't work."
Basically it's a rule in the template that has extra arguments that Ruins will choose from randomly, each entry is weighted evenly, but you can repeat entries that you want weighted more. It's just that simple.
Here is the one line formatted for clarity, notice the repeated sections.
rule1=0,100,CommandBlock:RUINSTRIGGER /testruin Gilly/GillyA1 ~0 ~4 ~0:@
,CommandBlock:RUINSTRIGGER /testruin Gilly/GillyA2 ~0 ~4 ~0:@
,CommandBlock:RUINSTRIGGER /testruin Gilly/GillyA3 ~0 ~4 ~0:@
,CommandBlock:RUINSTRIGGER /testruin Gilly/GillyA4 ~0 ~4 ~0:@
,CommandBlock:RUINSTRIGGER /testruin Gilly/GillyA5 ~0 ~4 ~0:@
,CommandBlock:RUINSTRIGGER /testruin Gilly/GillyA6 ~0 ~4 ~0:@
,CommandBlock:RUINSTRIGGER /testruin Gilly/GillyA7 ~0 ~4 ~0:@
,CommandBlock:RUINSTRIGGER /testruin Gilly/GillyA8 ~0 ~4 ~0:@
Each part calls a different template in a custom folder called Gilly, and the files are called GillyA1-8 ("A" representing Adobe, short filenames are for clarity and making it easy to debug) It's exactly the same as when the rule specifies "dirt,dirt,dirt,stone_bricks,air", but instead of blocks it references files. Also, there are minor differences between RuinsTrigger and AdjoiningTemplate, and either may be preferred over the other, depending on exactly what is being done.
Gillymoth Structures for Ruins <<< Folder containing my Structure-sets for Ruins mod.
Thank you very much. That makes that a lot clearer.
Remember: You are unique... Just like everyone else
A wise man once told me, "Coding is 1% writing code and 99% figuring out why it didn't work."
Thanks Gilly.
Exactly what I was trying to achieve.
Was hoping there was a way to call the directory and using what ever randomiser RUINS uses to chose a template from generic when it's just running normaly (mostly because I'm lazy and want to be able to just drag templates into the 'megacity' directory with-out having to then go add another option to the spawner commandblock).
Was thinking I could have a block of air that spawned on dirt (or grass) in generic folder that ran adjoining template to call up that command block NSE&W. testruin doesn't test the surface it's spawning on it just spawns what-ever at location so in each on the actual building templates I use adjoining template again to call up my 'air block' with a y variation of 1 or 2.... my city should spread over small changes in altitude but stop when it hits huge changes or hits a surface that the air block isn't allowed to spawn on. Might have to fiddle with spacing but 'think' it will work for what I want.
Now if I can just find a way to automate notepad++ to make the commandblock rule for me :-)
___/\___. Death-9 . . . . Old enough to remember when
. 0 0 . . umop ap!sdn . . the Blue Wave could add
. .(. . . Genghis Cohen . random tag-lines to your
.\____/ . Agnostos Theos. posts.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThe documentation says both are optional (i checked) and nothing else. Unless i specifically say two settings/entries are exclusive, aka don't work together, they do. In the snow/lava case it would NOT spawn because of the lava collision. There is no forgiveness.
Okay. Approaching this from another direction:
Let us say that acceptable_target_blocks=snow and unacceptable_target_blocks=lava,flowing_lava,water,flowing_lava in a theoretical example for a template that has dimensions of 7,5,5 (so a "footprint" of 5x5 blocks) and embed_into_distance=3.
Ruins randomly picks a spot in an ice plains biome, but there is a slight incline. For simplicity, let's say that dead center of the target area is at elevation 64, whereas the two rightmost columns are at levels 65 and 66, and the two leftmost columns are at levels 62 and 63, and that whatever I set for max_leveling happens to allow for this small variance. I'm assuming that "snow_layer", which would probably be at the topmost level in any snowy region, is ignored. (If I am incorrect, then my example needs adjustment.) And while I don't recall how deep it usually is, let's pretend the snow layer is only two blocks deep.
1: Do the "target blocks" include everything at the same level as where we start building? In my example, would that mean that they're all at level 64? OR, is the elevation for every target block within the "footprint" area calculated separately? Would I get "snow" for all my targets here, or would I run the risk that the rightmost column (level 66 at the surface, and the snow is only two blocks deep -- i.e., levels 65 and 66) will have DIRT as a target block, because what's at level 64 at that point is dirt?
2: Regardless of how the above works, let's pretend that in my example, for some reason, there is a block of STONE at the surface level, within the area of the footprint, and it doesn't have any snow on top of it. (I don't know how this would happen in normal terrain generation in a snowy zone. This is purely hypothetical.) "Stone" is not in the acceptable_target_blocks list, but it's also NOT in the unacceptable_target_blocks list.
In that case, does the structure build or not build, based on the material in the target blocks? If it DOES build, then that would make me wonder what the point was of specifying "acceptable_target_blocks," since all that really mattered was that it was not lava. If it DOES NOT build, then that would make me wonder what the point was of specifying "unacceptable_target_blocks," since all that really mattered was that it was not snow.
I apologize if my example is too convoluted to follow, but I hope this might help to illustrate my point of confusion. Maybe I should make some diagrams. Either that, or I just need to read the source and sort it out for myself.
--- 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)
-
View User Profile
-
View Posts
-
Send Message
Curse Premium1. Surface blocks. Each blocks elevation is "found".
2. Would not spawn as stone is not allowed
I would like to have ruins generate in the Abyssalcraft Omothol dimension. Omothol is dimension 52 and I whitelisted that dimension in the ruins.txt file:
# dimension IDs whitelisted for ruins spawning, add custom dimensions IDs here as needed
allowedDimensions=0,-1,52
But Abyssalcraft actually saves that dimension in a folder called 'Omothol' rather than 'DIM52' as most dimensions would typically be saved. Does the whitelisted dimension in ruins.txt have to be a number? Or is there a blacklist option instead of whitelist so Omothol will be allowed unless specifically excluded?
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumDimension ID means the number which is displayed in the F3 stat overlay, and which each and every dimension has
Ruins gets it's structures from txt files in your mods folder. mods/resources/ruins has folders for every biome, plus one for "generic" and one for "optional". You just need to move the txt files from optional to generic.
Just downloaded the latest Forge 1.9 (1865) and the latest ruins for 1.9 and it's crashing. It's the only mod I have installed so I know it's not a conflict between 2 mods. Do I need to use an earlier version of Forge?
It works perfectly for me with 1863. Did you extract all the files properly??
The last relevant post I saw from AtomicStryker on the topic said that the Ruins for MC 1.9 was built against Forge 1846, so that's the build I'm using, and it works fine for me.
I did have some trouble launching MC 1.9 IN GENERAL on one of the computers I work with, but that was with or without Ruins. I ended up having to use the video settings option for "Use VBOs" or else the game (Vanilla or otherwise) could crash immediately upon loading a world (new or otherwise). (The other computer didn't have this problem at all, and they're both running the same operating system and have the same memory capacity, but it worked just fine on the slightly newer computer, and crashed on the slightly older one -- until I made that change. I'm not really sure what the critical difference was.)
--- 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 recently set this up in a personal little mod loadout and am really enjoying it. Finding all these little derelict buildings scattered around that I can break down or fortify for a night is great, plus the little micro-dungeons it adds. Really breathes some life into a largely vanilla overworld.
But I've been noticing a strange happening as I explore more. Sometimes there are blank plots with the ruin footprints. Sometimes even pits like this one.
I'm sure this is entirely my fault. I added a bunch of the obsolete/optional ruins back into the game, though I tested all of them in a superflat (64 deep) world first to make sure they were working. Found a few that refused to spawn in, and removed them from the active folders. But otherwise they were all coming in. In the process of adding these back in, clearly I FUBAR'd something.
What I'm wondering is, is there a way to tell which ruin attempted to spawn at a given spot, so I can track down the template for it?
I'm using 1.7.10 with the appropriate version of RuinsMod, and Forge 1614. I'll be happy to post any other logs or information to help narrow this down.
Otherwise, it's not too big a problem. It's usually pretty small plots of land that get flattened.
EDIT: It occurs to me that I added CoFH Core, Nether Ores, Project Red Core, and Project Red World (I wanted copper + nether ores!) afterward. Perhaps the way they're hooking into world gen is causing problems...
So I have just figured out how to tell my dungeon whether or not to generate a door to more rooms using the new chain command blocks from 1.9. After parsing and testing, only the default (impulse) command blocks have retained their commands.
Lo and behold, the text file for the ruin has saved the blocks and the metadata that corresponds to all of the new options (needs redstone/always active and conditional/unconditional), but has no place to save the commands.
AtomicStryker, this functionality should probably be fixed to work like the normal command blocks.
In the mean time, anyone have an idea for a fix?
Remember: You are unique... Just like everyone else
A wise man once told me, "Coding is 1% writing code and 99% figuring out why it didn't work."