I'm also pretty sure that the "~60 _ ~" part goes after the name of the template, but it's been a while since I completed my template collection, and a few things have changed since then. Try reordering it to rule4=0,100,CommandBlock:RUINSTRIGGER /testruin InvadeUndeadLegion ~60 _ ~:@ if that still doesn't work.
Is the structure generation based on seed? I seem to have the exact same structures spawning on a world I recreated using a seed. I deleted everything in the profile folder, except the configs directory.
Is the structure generation based on seed? I seem to have the exact same structures spawning on a world I recreated using a seed.
Yes, but...
Unlike Minecraft worldgen structures, like villages and mineshafts, Ruins aren't generated procedurally. Ruins does use the world's random number stream, which in turn uses the seed you provided, so the starting area immediately around world spawn will be identical if you use the same seed for two different worlds. However, the distribution of ruins also depends on the order in which chunks are populated, so as you venture away from world spawn, you'll begin to see differences (unless you happen to follow precisely the same path).
Therefore, while the worlds might look the same initially, you'll find they really aren't as you explore further.
Quick Question: Is a weight lower than 1 accaptable? (Like 0.5 or 0.25.)
In the current version of Ruins, all weights are (non-negative) whole numbers, so the only weight lower than 1 is 0. Probably not what you want.
Support for fractional weights has already been added to the next version, though. You'll be able to use values like 0.5 or 0.25 for both block weights and template weights, as well as rule chances and biome-specific spawn chances. (Variant weights, however, remain integers...for now).
This is great! I think I'm going to go through and tweak down the weights of some of the templates intended to be rarer (possibly in exchange for reducing the minimum spawn distance or unique minimum distance a little), since this would now give me that opportunity. Otherwise, even with the "min spawn distance," there's still the chance that unless I really stagger those values, as soon as an adventurer reaches that point, a bunch of the so-called "rare" structures might spawn awfully close to another. Thanks for the help!
Considering the sheer number of templates in any given biome (or in any given spawning list), I'm wondering what the maximum total value is for the spawn-weighting system. If there were 400 templates in a spawn-list, each weighted at 100, the integer value of the total would be 40k. I'm pretty sure that would fall within whatever location the number was stored as, but it's good to bring it up, in case of an overflow, where in some cases the total returned can overflow into a negative number. Again I don't think that would come up, but just in case.
Much more importantly, multiplying the average by 100 or so means that everyone absolutely must follow suit, if sets are combined by players, s one would completely overwrite all the rest. And that is exactly why we have avoided doing so in the past, to avoid flooding over others' generation.
There are a couple dozen completed buildings that I forgot to release late last spring, so this would be a good time to do so.
Considering the sheer number of templates in any given biome (or in any given spawning list), I'm wondering what the maximum total value is for the spawn-weighting system.
Currently, a little over two billion--2,147,483,647. In the next version of Ruins, which allows fractional weights, it'll be on the order of a hundred thousand centillion. As you said, though, the danger of overflow (going over the maximum value) now or underflow (going under the finest precision) later is negligible, unless you're actively trying to break things with pathological weight values.
A word of caution when using weight to control "rarity," however; while it's one of the factors in determining how frequently a particular template spawns, it's not the only--or even necessarily the most important--one. A template's weight only specifies how likely it is to be selected, relative to other templates eligible to spawn in the same biome, for consideration. Once selected, the template's chances of actually spawning a structure depends entirely on the stringency of its surface criteria (acceptable_target_blocks, allowable_overhang, max_leveling, the area of its footprint) and proximity limits (uniqueMinDistance, leveling_buffer). It's also worth noting the higher the value of configuration parameter tries_per_chunk_normal, the more significant these other factors can become.
Bottom line: it's not true to say that, if template A has weight=2 and template B has weight=1, there will be (statistically) twice as many A structures as B (unless A and B are identical in every other relevant way). If A has a bigger footprint, for example, you may very well see more instances of B than A, despite their weights. The best you can reliably say is increasing/decreasing a template's weight makes it more common/rare than it was before the change; it doesn't specify how rarely it actually spawns structures in absolute terms. The only practical way to gauge rarity is by experimenting.
That is a very good point, and also why we've stayed at weight:1 and balanced everything against everything else by building several instances of each type of structure, and it's also why our individual sets play well with one another, as they fit into the same system. If one player increases their weights orders of magnitude over the others, then it has the potential to become an arms race, which itself could break things.
If one were to increase the weight of a broken template to a very large number, then it would merely break generation for its biome, and not actually fix the underlying cause of the break.
It also means that every new template generated would need to have their weight modified (at time of creation) before being tested, as the lists would be a hundred times more saturated than before. This would make it a primary cause of breaks in early testing phases where it wasn't before. Although each of us has a large enough base of structures that existing templates are far more likely to spawn than the ones being tested.
I think the best way to view weight is primarily as a way to offset a template's lower probability to spawn structures due to other characteristics. For example, suppose you have two templates--A and B--with the same acceptable_target_blocks, allowable_overhang, max_leveling, and uniqueMinDistance values, and leveling_buffer=-1. However, A has dimensions=8,32,32 and B has dimensions=8,16,16.
Let's say A and B spawn only in the plains biome, which is relatively level, and the allowable surface parameters give template B a 95% chance of successful instantiation. Assuming the terrain is uniform, template A--with 4 times the footprint area--has a 95%^4, or ~81%, chance of success. If weight=1 for both templates, you're going to see slightly more B structures than A; A has an effective weight of (0.95^4/0.95 =) about 0.86. To make A and B structures equally common, you'd give A a slightly higher weight value than B: (0.95/0.95^4 =) about 1.17. Of course, the current version of Ruins only allows integer values, so you'd give them both weight=1 and live with the slight difference.
Now consider the case where they're spawning in a somewhat rougher terrain, like a forest biome. Maybe B has a 75% chance of success here, so A needs a weight of (0.75/0.75^4 =) 2.37 to compensate. In an even rougher biome, such as taiga, where B might have only a 50% chance, A needs weight=8 just to stay even with B at weight=1.
Alas, real life isn't as clean and simple as that. For one thing, the uniform terrain premise isn't always valid, nor is the probability of success easy to ascertain. Plus the example just considers footprint area, not other pertinent parameters. Also, if a template spawns structures across various biomes--which most do--there's the prospect of different distributions in different terrains. Balancing weights is more of an art than a science, but in general, maybe boost a template's weight value if it has a larger footprint, a more restrictive list of acceptable target blocks, a smaller allowable overhang, or a lower surface bumpiness tolerance (max_leveling). If you care about balancing, that is; there's no reason you necessarily should. For the purpose of controlling rarity, though, it takes a combination of both uniqueMinDistance and weight juggling to get just right, rather than relying on either mechanism by itself.
i would really like to use this mod to have custom structures generate at random in galacticrafts space dimensions. is this possible? is there a way to choose what dims the structures gen in not just the biome? if not can you ad a way to do this? recurrent complex...is just to complex...
i would really like to use this mod to have custom structures generate at random in galacticrafts space dimensions. is this possible? is there a way to choose what dims the structures gen in not just the biome? if not can you ad a way to do this? recurrent complex...is just to complex...
I know that you CAN whitelist the Galacticraft dimensions, so that Ruins *can* spawn there. You'll need to actually create a Galacticraft world to force Ruins to create the "ruins.txt" config file, and then edit the dimensions list to make sure the dimension numbers assigned to the Galacticraft dimensions are included.
It's been a long time since I've played with Galacticraft, so I can't remember whether it has its own unique biomes. *IF SO*, under the way Ruins is currently structured, you could control what Ruins spawn in the Galacticraft dimensions:
1) Remove all templates from the "generic" folder.
2) Put ruins you want to spawn in Galacticraft biomes into the appropriate biome folders.
3) Make sure you don't have any Ruins templates in non-Galacticraft biome folders that would still spawn in those biomes.
Unfortunately, some new features of Ruins would make that harder. The old "BiomesToSpawnIn" field would specify a list of biomes the template CAN spawn in, and if you add some new mod that creates new biomes NOT on that last, then the template just won't spawn there (unless you copy the template and drop it SPECIFICALLY into that new biome folder). HOWEVER, the new version of Ruins allows for "types" of biomes, and so far as I know, the types associated with Galacticraft biomes will still overlap with "normal" Minecraft biomes (e.g., dry, cold, dead, mountain, rare). So you'd need to police for any such settings in templates that might result in a Chalet that was intended for "Extreme Hills" that suddenly ends up on your lunar mountain moonscape because (I'm just making stuff up here) the local biome happened to be "Mountain" and that type was specified in the template.
(Too bad there isn't, say, a standard "OuterSpace" or "Futuristic" biome type. I could just make a point of being sure that all Kujaku's and my cottages, chalets, castles, etc., specifically EXCLUDE spawning in such biome-types. No Kujaku-cottages in space!)
A dimension-lock feature for templates would be *nice*, and it's actually something I've wished for, but I have trouble envisioning the best format for it. A field that might list dimensions in the template ("SpawnDimensions=-1,0,1,7,111") would only have utility if those numbers had universal meaning across all mods (but they don't, necessarily). Maybe if there were a dimension-name-assignment in a separate editable config file? (E.g., Overworld = 0, Nether = -1, End = 1, Twilight_Forest = 7, Lost_City = 9...)
Alas, it'd be another real challenge to account for "open-ended" dimension-generating mods such as Mystcraft. (But then ... I don't know that Mystcraft has been updated for several versions of Minecraft, so that might be a moot point.)
i would really like to use this mod to have custom structures generate at random in galacticrafts space dimensions. is this possible? is there a way to choose what dims the structures gen in not just the biome? if not can you ad a way to do this?
I submitted a pull to add this feature and it's already been accepted, so it'll be available in the next release of Ruins.
Two things prevent the current version of Ruins from working correctly with Galacticraft. First, Galacticraft adds biomes with spaces in their names--namely, outer space, outer space 1, and outer space 2. The next version will handle spacey biome names properly. Second, Galacticraft appears to use those same biomes to mean different things in different dimensions, so you really do need something like a dimensionsToSpawnIn template parameter. Which is exactly what I added, however...
Jordan_Peacock neatly pointed out some of the issues involved in the previous post. I can't rely on dimension ID numbers; there's no way a template author could know for certain which numbers are associated with which dimensions. Instead, I use the lesser-known dimension type names. So, for example, to restrict your template to only spawn in the overworld (dimension 0) and The Twilight Forest (typically--but not necessarily--dimension 7), you'd include the following line:
dimensionsToSpawnIn=overworld,twilight_forest
The default is an empty list, which has the special meaning of allowing spawns in all dimensions. In other words, you don't have to change your existing templates if you're not especially concerned with dimension restrictions; they'll work fine, just as before.
An interesting note is, unlike biomesToSpawnIn, dimensionsToSpawnIndoes also apply to generic spawning. If a template specifies dimensions, it only appears in those dimensions, regardless of which folder it's in. Also, the seemingly (but not actually) related configuration parameter allowedDimensions still uses numeric dimension IDs, as always. That's intentional--mucking around with ID assignment is more a server management task than a template designing one.
The next logical question is...where the heck do I find out what type names I should use? Good question. They're not generally well-documented, and there aren't consistent rules regarding how (or even if) they're constructed by mod authors. Unfortunately, they are case sensitive, they may contain spaces and other special characters, and they're not even necessarily unique. *sigh* Still, they're better than ID numbers, since they don't depend on server configuration. Three you can almost definitely count on are the vanilla dimensions: overworld (ID 0), the_nether (-1), and the_end (1). You also get twilight_forest (default ID 7) for free, since I used that during testing and in the example above. Even if The Twilight Forest dimension is configured to use a different ID, twilight_forest still refers to the correct dimension. Blackendsuns96571's original feature request was with regard to Galacticraft, so I'll throw in moon.moon (-28), planet.mars (-29), planet.asteroids (-30), and planet.venus (-31), too. Unfortunately, Galacticraft applies exactly the same name to its other two dimensions: Space Station (-26 and -27), which is kind of problematic if you're looking to distinguish between the two. If you need a hand finding other modded dimension names, drop me a PM.
Incidentally, note Galacticraft "hides" its worldgen from other mods by default, so Ruins can't build structures in its dimensions unless you configure Galacticraft to not do that. In config/Galacticraft/core.conf, set
B:"Generate all other mods features on planets"=true
to allow Ruins (and everything else) access it its worldgen. You'll see a warning preceding that line in the file, though, advising you to keep it set to false. If you run with a lot of mods, it may indeed introduce troublesome consequences, but there's no real alternative short of either Galacticraft or Ruins adding special built-in compatibility features for the other (Galacticraft apparently already does that for ThaumCraft and the CoFH Thermal mods).
Jordan: AIUI Mystcraft is again in development for 1.12.2. but not really ready for prime time. (At least it crashed on me...) Adding an "outer-space" biome type would be a reasonable request to Forge, it might be that Galacticraft could help lead the charge. Ditto a dimension type, per QuarterAnimal.
Rollback Post to RevisionRollBack
I did some CraftTweaker scripts for Mystical Agriculture. They fill in a couple of small gaps in MA, and also let you make or duplicate not only vanilla plants, but the blocks, plants and wood from Quark and Biomes O'Plenty. Also spawn eggs for most vanilla mobs! The scripts are here on Github.
Adding an "outer-space" biome type would be a reasonable request to Forge, it might be that Galacticraft could help lead the charge. Ditto a dimension type, per QuarterAnimal.
It's a bit confusing, but despite their similar names, biome type (technically, BiomeDictionary.Type) and dimension type (DimensionType) are very different beasts.
Biome types are defined and managed by Forge, and represent descriptive categories into which particular biomes may fit, like DRY, or COLD, or SPOOKY. Mod authors can't create new biome types, but they may specify which types--if any--apply to new biomes they create (or allow Forge to make its own best guess). There's a many-to-many relationship between biomes and biome types.
Dimension types, in contrast, are managed by Minecraft, and each represents a specific dimension. Three are initially defined by Minecraft--overworld, the_end, and the_nether--and others are created by mod authors implementing new dimensions. There's a one-to-one relationship between dimensions and dimension types (though, unfortunately, type names aren't required to be unique...as in Galacticraft's use of the name Space Station for two of its dimension types).
Nothing currently in existence categorizes dimensions (DimensionTypeType?) the same way biome types do for biomes, so I don't think the Forge team can do anything in that regard, aside from creating a whole new dimension dictionary, analogous to the biome dictionary...seems unlikely. Petitioning them for new biome types, though, might be useful.
I haven't tested in game, but looking at the templates, the testruin commands in InvadeUndeadStarter need / in front of them. For example:
rule4=0,100,CommandBlock:RUINSTRIGGER testruin ~60 _ ~ InvadeUndeadLegion:@
should be
rule4=0,100,CommandBlock:RUINSTRIGGER /testruin ~60 _ ~ InvadeUndeadLegion:@
I'm also pretty sure that the "~60 _ ~" part goes after the name of the template, but it's been a while since I completed my template collection, and a few things have changed since then. Try reordering it to rule4=0,100,CommandBlock:RUINSTRIGGER /testruin InvadeUndeadLegion ~60 _ ~:@ if that still doesn't work.
More Ruins Templates: https://www.dropbox.com/sh/e8gwe4638lqbakd/AAD2nsMtDSBvezUADCYmo2s-a?dl=0 Templates for 1.10.2, 1.11.2, 1.12.2. Updated Dec 7, 2018.
My modpack, ParasCraft: An Exploration-based Pokecube Modpack https://minecraft.curseforge.com/projects/parascube
That's the key--name first, coordinates after. The slash is optional.
Is the structure generation based on seed? I seem to have the exact same structures spawning on a world I recreated using a seed. I deleted everything in the profile folder, except the configs directory.
Cool!
Yes, but...
Unlike Minecraft worldgen structures, like villages and mineshafts, Ruins aren't generated procedurally. Ruins does use the world's random number stream, which in turn uses the seed you provided, so the starting area immediately around world spawn will be identical if you use the same seed for two different worlds. However, the distribution of ruins also depends on the order in which chunks are populated, so as you venture away from world spawn, you'll begin to see differences (unless you happen to follow precisely the same path).
Therefore, while the worlds might look the same initially, you'll find they really aren't as you explore further.
Quick Question: Is a weight lower than 1 accaptable? (Like 0.5 or 0.25.)
In the current version of Ruins, all weights are (non-negative) whole numbers, so the only weight lower than 1 is 0. Probably not what you want.
Support for fractional weights has already been added to the next version, though. You'll be able to use values like 0.5 or 0.25 for both block weights and template weights, as well as rule chances and biome-specific spawn chances. (Variant weights, however, remain integers...for now).
Thanks
"unless I go through EVERY SINGLE TEMPLATE I have already, and inflate the values by a factor of 10 or 100 or whatever."
I can do that for you, it's a simple batch script. What value do you want them set to?
Actually, never mind. I went ahead and did it with a base weight=100
https://www.dropbox.com/s/auacztwkoi7xr3d/ruins_weight100.zip?dl=0
This is all of your 1.12 packs
This is great! I think I'm going to go through and tweak down the weights of some of the templates intended to be rarer (possibly in exchange for reducing the minimum spawn distance or unique minimum distance a little), since this would now give me that opportunity. Otherwise, even with the "min spawn distance," there's still the chance that unless I really stagger those values, as soon as an adventurer reaches that point, a bunch of the so-called "rare" structures might spawn awfully close to another. Thanks for the help!
--- 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)
Considering the sheer number of templates in any given biome (or in any given spawning list), I'm wondering what the maximum total value is for the spawn-weighting system. If there were 400 templates in a spawn-list, each weighted at 100, the integer value of the total would be 40k. I'm pretty sure that would fall within whatever location the number was stored as, but it's good to bring it up, in case of an overflow, where in some cases the total returned can overflow into a negative number. Again I don't think that would come up, but just in case.
Much more importantly, multiplying the average by 100 or so means that everyone absolutely must follow suit, if sets are combined by players, s one would completely overwrite all the rest. And that is exactly why we have avoided doing so in the past, to avoid flooding over others' generation.
There are a couple dozen completed buildings that I forgot to release late last spring, so this would be a good time to do so.
Gillymoth Structures for Ruins <<< Folder containing my Structure-sets for Ruins mod.
Currently, a little over two billion--2,147,483,647. In the next version of Ruins, which allows fractional weights, it'll be on the order of a hundred thousand centillion. As you said, though, the danger of overflow (going over the maximum value) now or underflow (going under the finest precision) later is negligible, unless you're actively trying to break things with pathological weight values.
A word of caution when using weight to control "rarity," however; while it's one of the factors in determining how frequently a particular template spawns, it's not the only--or even necessarily the most important--one. A template's weight only specifies how likely it is to be selected, relative to other templates eligible to spawn in the same biome, for consideration. Once selected, the template's chances of actually spawning a structure depends entirely on the stringency of its surface criteria (acceptable_target_blocks, allowable_overhang, max_leveling, the area of its footprint) and proximity limits (uniqueMinDistance, leveling_buffer). It's also worth noting the higher the value of configuration parameter tries_per_chunk_normal, the more significant these other factors can become.
Bottom line: it's not true to say that, if template A has weight=2 and template B has weight=1, there will be (statistically) twice as many A structures as B (unless A and B are identical in every other relevant way). If A has a bigger footprint, for example, you may very well see more instances of B than A, despite their weights. The best you can reliably say is increasing/decreasing a template's weight makes it more common/rare than it was before the change; it doesn't specify how rarely it actually spawns structures in absolute terms. The only practical way to gauge rarity is by experimenting.
That is a very good point, and also why we've stayed at weight:1 and balanced everything against everything else by building several instances of each type of structure, and it's also why our individual sets play well with one another, as they fit into the same system. If one player increases their weights orders of magnitude over the others, then it has the potential to become an arms race, which itself could break things.
If one were to increase the weight of a broken template to a very large number, then it would merely break generation for its biome, and not actually fix the underlying cause of the break.
It also means that every new template generated would need to have their weight modified (at time of creation) before being tested, as the lists would be a hundred times more saturated than before. This would make it a primary cause of breaks in early testing phases where it wasn't before. Although each of us has a large enough base of structures that existing templates are far more likely to spawn than the ones being tested.
Gillymoth Structures for Ruins <<< Folder containing my Structure-sets for Ruins mod.
I think the best way to view weight is primarily as a way to offset a template's lower probability to spawn structures due to other characteristics. For example, suppose you have two templates--A and B--with the same acceptable_target_blocks, allowable_overhang, max_leveling, and uniqueMinDistance values, and leveling_buffer=-1. However, A has dimensions=8,32,32 and B has dimensions=8,16,16.
Let's say A and B spawn only in the plains biome, which is relatively level, and the allowable surface parameters give template B a 95% chance of successful instantiation. Assuming the terrain is uniform, template A--with 4 times the footprint area--has a 95%^4, or ~81%, chance of success. If weight=1 for both templates, you're going to see slightly more B structures than A; A has an effective weight of (0.95^4/0.95 =) about 0.86. To make A and B structures equally common, you'd give A a slightly higher weight value than B: (0.95/0.95^4 =) about 1.17. Of course, the current version of Ruins only allows integer values, so you'd give them both weight=1 and live with the slight difference.
Now consider the case where they're spawning in a somewhat rougher terrain, like a forest biome. Maybe B has a 75% chance of success here, so A needs a weight of (0.75/0.75^4 =) 2.37 to compensate. In an even rougher biome, such as taiga, where B might have only a 50% chance, A needs weight=8 just to stay even with B at weight=1.
Alas, real life isn't as clean and simple as that. For one thing, the uniform terrain premise isn't always valid, nor is the probability of success easy to ascertain. Plus the example just considers footprint area, not other pertinent parameters. Also, if a template spawns structures across various biomes--which most do--there's the prospect of different distributions in different terrains. Balancing weights is more of an art than a science, but in general, maybe boost a template's weight value if it has a larger footprint, a more restrictive list of acceptable target blocks, a smaller allowable overhang, or a lower surface bumpiness tolerance (max_leveling). If you care about balancing, that is; there's no reason you necessarily should. For the purpose of controlling rarity, though, it takes a combination of both uniqueMinDistance and weight juggling to get just right, rather than relying on either mechanism by itself.
i would really like to use this mod to have custom structures generate at random in galacticrafts space dimensions. is this possible? is there a way to choose what dims the structures gen in not just the biome? if not can you ad a way to do this? recurrent complex...is just to complex...
I know that you CAN whitelist the Galacticraft dimensions, so that Ruins *can* spawn there. You'll need to actually create a Galacticraft world to force Ruins to create the "ruins.txt" config file, and then edit the dimensions list to make sure the dimension numbers assigned to the Galacticraft dimensions are included.
It's been a long time since I've played with Galacticraft, so I can't remember whether it has its own unique biomes. *IF SO*, under the way Ruins is currently structured, you could control what Ruins spawn in the Galacticraft dimensions:
1) Remove all templates from the "generic" folder.
2) Put ruins you want to spawn in Galacticraft biomes into the appropriate biome folders.
3) Make sure you don't have any Ruins templates in non-Galacticraft biome folders that would still spawn in those biomes.
Unfortunately, some new features of Ruins would make that harder. The old "BiomesToSpawnIn" field would specify a list of biomes the template CAN spawn in, and if you add some new mod that creates new biomes NOT on that last, then the template just won't spawn there (unless you copy the template and drop it SPECIFICALLY into that new biome folder). HOWEVER, the new version of Ruins allows for "types" of biomes, and so far as I know, the types associated with Galacticraft biomes will still overlap with "normal" Minecraft biomes (e.g., dry, cold, dead, mountain, rare). So you'd need to police for any such settings in templates that might result in a Chalet that was intended for "Extreme Hills" that suddenly ends up on your lunar mountain moonscape because (I'm just making stuff up here) the local biome happened to be "Mountain" and that type was specified in the template.
(Too bad there isn't, say, a standard "OuterSpace" or "Futuristic" biome type. I could just make a point of being sure that all Kujaku's and my cottages, chalets, castles, etc., specifically EXCLUDE spawning in such biome-types. No Kujaku-cottages in space!)
A dimension-lock feature for templates would be *nice*, and it's actually something I've wished for, but I have trouble envisioning the best format for it. A field that might list dimensions in the template ("SpawnDimensions=-1,0,1,7,111") would only have utility if those numbers had universal meaning across all mods (but they don't, necessarily). Maybe if there were a dimension-name-assignment in a separate editable config file? (E.g., Overworld = 0, Nether = -1, End = 1, Twilight_Forest = 7, Lost_City = 9...)
Alas, it'd be another real challenge to account for "open-ended" dimension-generating mods such as Mystcraft. (But then ... I don't know that Mystcraft has been updated for several versions of Minecraft, so that might be a moot point.)
--- 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 submitted a pull to add this feature and it's already been accepted, so it'll be available in the next release of Ruins.
Two things prevent the current version of Ruins from working correctly with Galacticraft. First, Galacticraft adds biomes with spaces in their names--namely, outer space, outer space 1, and outer space 2. The next version will handle spacey biome names properly. Second, Galacticraft appears to use those same biomes to mean different things in different dimensions, so you really do need something like a dimensionsToSpawnIn template parameter. Which is exactly what I added, however...
Jordan_Peacock neatly pointed out some of the issues involved in the previous post. I can't rely on dimension ID numbers; there's no way a template author could know for certain which numbers are associated with which dimensions. Instead, I use the lesser-known dimension type names. So, for example, to restrict your template to only spawn in the overworld (dimension 0) and The Twilight Forest (typically--but not necessarily--dimension 7), you'd include the following line:
dimensionsToSpawnIn=overworld,twilight_forest
The default is an empty list, which has the special meaning of allowing spawns in all dimensions. In other words, you don't have to change your existing templates if you're not especially concerned with dimension restrictions; they'll work fine, just as before.
An interesting note is, unlike biomesToSpawnIn, dimensionsToSpawnIn does also apply to generic spawning. If a template specifies dimensions, it only appears in those dimensions, regardless of which folder it's in. Also, the seemingly (but not actually) related configuration parameter allowedDimensions still uses numeric dimension IDs, as always. That's intentional--mucking around with ID assignment is more a server management task than a template designing one.
The next logical question is...where the heck do I find out what type names I should use? Good question. They're not generally well-documented, and there aren't consistent rules regarding how (or even if) they're constructed by mod authors. Unfortunately, they are case sensitive, they may contain spaces and other special characters, and they're not even necessarily unique. *sigh* Still, they're better than ID numbers, since they don't depend on server configuration. Three you can almost definitely count on are the vanilla dimensions: overworld (ID 0), the_nether (-1), and the_end (1). You also get twilight_forest (default ID 7) for free, since I used that during testing and in the example above. Even if The Twilight Forest dimension is configured to use a different ID, twilight_forest still refers to the correct dimension. Blackendsuns96571's original feature request was with regard to Galacticraft, so I'll throw in moon.moon (-28), planet.mars (-29), planet.asteroids (-30), and planet.venus (-31), too. Unfortunately, Galacticraft applies exactly the same name to its other two dimensions: Space Station (-26 and -27), which is kind of problematic if you're looking to distinguish between the two. If you need a hand finding other modded dimension names, drop me a PM.
Incidentally, note Galacticraft "hides" its worldgen from other mods by default, so Ruins can't build structures in its dimensions unless you configure Galacticraft to not do that. In config/Galacticraft/core.conf, set
B:"Generate all other mods features on planets"=true
to allow Ruins (and everything else) access it its worldgen. You'll see a warning preceding that line in the file, though, advising you to keep it set to false. If you run with a lot of mods, it may indeed introduce troublesome consequences, but there's no real alternative short of either Galacticraft or Ruins adding special built-in compatibility features for the other (Galacticraft apparently already does that for ThaumCraft and the CoFH Thermal mods).
Jordan: AIUI Mystcraft is again in development for 1.12.2. but not really ready for prime time. (At least it crashed on me...) Adding an "outer-space" biome type would be a reasonable request to Forge, it might be that Galacticraft could help lead the charge. Ditto a dimension type, per QuarterAnimal.
It's a bit confusing, but despite their similar names, biome type (technically, BiomeDictionary.Type) and dimension type (DimensionType) are very different beasts.
Biome types are defined and managed by Forge, and represent descriptive categories into which particular biomes may fit, like DRY, or COLD, or SPOOKY. Mod authors can't create new biome types, but they may specify which types--if any--apply to new biomes they create (or allow Forge to make its own best guess). There's a many-to-many relationship between biomes and biome types.
Dimension types, in contrast, are managed by Minecraft, and each represents a specific dimension. Three are initially defined by Minecraft--overworld, the_end, and the_nether--and others are created by mod authors implementing new dimensions. There's a one-to-one relationship between dimensions and dimension types (though, unfortunately, type names aren't required to be unique...as in Galacticraft's use of the name Space Station for two of its dimension types).
Nothing currently in existence categorizes dimensions (DimensionTypeType?) the same way biome types do for biomes, so I don't think the Forge team can do anything in that regard, aside from creating a whole new dimension dictionary, analogous to the biome dictionary...seems unlikely. Petitioning them for new biome types, though, might be useful.