• 0

    posted a message on [1.14.3] Ruins (Structure Spawning System)

    Can anyone help me with a crash problem?


    Looks like you've got a runaway worldgen cascade, where creating one new chunk forces another to be created, which in turn forces another, and so on until you run out of memory. A lot of pre-1.13 structure-adding mods (including Ruins) cause a bit of worldgen cascade. A little isn't so bad...but if there's a whole pile of it, you get lag spikes and even crashes. That's where you are,


    Your log shows evidence of a classic worldgen cascade: a long chain of new chunk generation. While it is possible for Ruins to trigger a runaway situation, you almost need to maliciously configure it to do so. I'm pretty sure Ruins isn't the culprit here: of the 39 links in your cascade, only 4 of them are from Ruins. As for the others, 5 are from Gany's Nether and a whopping 30 are from Arcana RPG. I'm not familiar enough with those mods to say exactly what's going on, but I suspect your problem really lies with Arcana RPG, or at least how it interacts with one or both of the other two.

    Posted in: Minecraft Mods
  • 0

    posted a message on [1.14.3] Ruins (Structure Spawning System)

    One way could also be to use some other "air block"...


    You're on the right track, but you already have everything you need. My guess is you're using rule0 for both exterior and interior space. Contrary to what you may think, the default rule0 is not air, but rather a special "background" air (namely, ?air) that respects preservation of plants and snow and stuff, as you noted. That's fine for outside space, where you don't want to disrupt the surroundings, but probably not appropriate for inside space, where you do. All you need is a separate interior air rule in addition to rule0, something along the lines of...


    rule19=0,100,air


    ...and use that inside your building. If you use /parseruin to generate Ruins templates, Gillymoth's suggestion above is to fill the interior with something silly, like lime wool, then edit the resultant template file to replace wool-5 with air to easily implement this. Regular, non-background blocks, even air, never care about preservation, happily stomping on whatever gets in their way.


    Incidentally, you can use the question mark prefix to include preservation-honoring background blocks in other rules--not just rule0, and not just air--to achieve certain special effects. There's also an exclamation mark prefix for "foreground" blocks that only clobber stuff that's otherwise preserved (perfect for, say, that house on stilts you always wanted to build). But that's more than you wanted to know.

    Posted in: Minecraft Mods
  • 1

    posted a message on [1.14.3] Ruins (Structure Spawning System)
    Quote from xorange»

    I'm running Ruins on my 1.7.10 server, and every now and then I see something like this:

    [03:32:26] [Server thread/INFO] [STDERR]: [atomicstryker.ruins.common.RuinTemplateRule:doSpecialBlock:677]: Ruins Mod could not determine what to spawn for [minecraft:air] in Ruin template: JG_Sphere_Cave_31_1v7v10.tml


    It tends to spam the console until the server crashes.

    My searches are not yielding any results.

    Anybody have any idea what's going on there and/or how I can prevent it?


    There was a bug, fixed in 1.12.2, preventing Ruins from recognizing minecraft:air as a legitimate block ID. Since you're running a version without that fix, you'll need to replace all occurrences of minecraft:air in your templates with simply air. That should eliminate the errors.


    Note for all other blocks, the minecraft: domain works fine, so you only need to remove it from air blocks. For example, stone and minecraft:stone are both valid and interchangeable. Just not air.

    Posted in: Minecraft Mods
  • 0

    posted a message on [1.14.3] Ruins (Structure Spawning System)
    Quote from Mensrea»

    Would it be possible to have a per-ruin setting that overrides the "anyRuinsMinDistance=" in the global settings? Sort of like the "templateInstancesMinDistance=" override "uniqueMinDistance" but for everything.


    It would be possible, but its effect would almost certainly be undesirable.


    If there were such a template parameter, the question of how its settings for different templates interact with one another arises. If Huggy.tml has it set to 4 and Loner.tml has it set to 4096, what's the minimum distance you'd expect between a Huggy structure and a Loner structure? Some people might think the larger of the two should prevail, some might think the smaller...but either way, the design intention of one of the templates is violated. Or maybe you think only the value for the one that's being considered for placement should be used. In other words, if Ruins is looking to place a structure at a new location 4 blocks away from some other structure, Huggy is a candidate and Loner is not. Effectively, that's kind of the same as giving the smaller value priority; to continue the example, Loner's high value doesn't stop a Huggy from being placed right next to it.


    What's even worse, though, is how the parameter would amplify issues with ad hoc worldgen. There would be a strong bias toward selecting templates with low values over those with high values, leading to giant Huggy forests in which the same template (or a tiny subset of templates) is just selected over and over again. Nobody wants a Huggy forest. Granted, there are ways to compensate somewhat--for example, if Huggy has very restrictive biomesToSpawnIn or acceptable_target_blocks, a forest can only get so big. It'd make balancing things awfully delicate, however, especially if you've got a collection of templates from different authors.


    Finally, if Ruins ever does switch to procedural generation, the parameter would have to be abandoned. Procedural generation relies on fixed mean and minimum distances across the board...or, alternatively, instantiating templates independently of one another with no way to control how far apart their structures appear. That's not a big problem, though, since a bunch of other current parameters would also fall by the wayside, but I'm noting it for completeness.

    Posted in: Minecraft Mods
  • 0

    posted a message on [1.14.3] Ruins (Structure Spawning System)

    Hmm, So it seams Rivers and water holes are generated after the Ruins?
    I can't seam to spawn things in water puddles or rivers* (on water), And sometimes my command block gets cut off near waterholes, rare but happens once in a blue moon.


    This is another unfortunate side effect of Ruins' non-procedural worldgen. What's happening is new chunks are being populated in two separate threads, and the result is indeterminate. In my testing, I notice Ruins structures are usually entirely overwritten by vanilla lakes, but not always--I do see rare instances of partial or even complete structures sitting in water as expected.


    There's no easy solution to this issue. Either Ruins' ad hoc worldgen would need to be significantly bolstered to address some of its current shortcomings, or vanilla Minecraft's procedural scheme would need to be adopted. Both have advantages and disadvantages, as does just keeping things as they are, warts and all...and no, it wouldn't be practical to implement everything and allow one or the other to be chosen via a configuration option. I can't recommend which is "best," since deep design decisions like that are the prerogative of the mod author, but I can say hooking into Minecraft's canonical structure system seems to be strongly favored going forward (i.e., in 1.13 and beyond). Alas, doing so would also entail drastic changes to the Ruins' functionality, almost to the point of making it an entirely different mod. Like I said, no easy solution.


    I did some testing trying to find a work around to an issue i had, And it turns out the latest version doesn't work at all with AdvancedRocketry Dimensions.

    I'm curious as to what "doesn't work at all" means, since I can get the latest versions of the two mods to play together just fine. What exactly isn't working for you?

    Posted in: Minecraft Mods
  • 1

    posted a message on [1.14.3] Ruins (Structure Spawning System)

    Ruins are weighed versus each other right?
    If I want some ruins to be much rarer, should I UP the normal ruins weight higher?

    Say, for an extreme example, I set ALL normal house ruins to 31, and one special castle as 1:
    it would significantly lower the chance of the 1 castle ruin, but still allow it to spawn, just at a very very low chance?



    That's exactly right. A biome-specific template's weight is relative to that of all other biome-specific templates eligible to spawn in a particular biome; a generic template's is relative to all other generic templates. Unfortunately, the value of weight must be an integer, and the default is 1, so yes--you'd have to ratchet up everybody else's weight in order to make low-probability spawns, just as you described.

    Or...it just so happens the very latest version of Ruins for Minecraft 1.12.2 adds support for non-integer weight values, so you could simply give your castle template a weight=0.03 and not have to futz with all the rest. However, that change went in after the most recent official release, so to get it you'd have to either pull the code down from GitHub and build it yourself, or cajole AtomicStryker (the owner of Ruins) into releasing an updated 1.12.2 version.

    Incidentally, the latest version also includes two other things that might be of interest to you--a new dimensionsToSpawnIn template parameter and improved Galacticraft compatibility. Just sayin'.

    So if I ONLY use acceptable_target_blocks, it should work?


    Yes. In fact, I'd say that's ideal for most templates.

    I could just set uniqueMinDistance to really high, and it would basically get the same result, right (making it spawn just once)?
    What's the highest number I can put in? Or, is there no limit?


    A ridiculously high uniqueMinDistance will effectively give you one spawn per dimension. The highest allowed value is Java's maximum signed int: 2,147,483,647. The highest meaningful value is twice Minecraft's maximum world size: 59,999,968. I'd just use a cool 60 mill, myself.

    So basically, if I set [max_leveling] higher, it would have a higher chance to spawn, because it doesn't need to be flat, yes?


    That's the right idea, though it's moot if your template is just a single command block--by definition, there's no height variation over a 1x1 area.

    Or I could maybe use a block (say lapis) when I build and then replace that block with preserveBlock in the template?
    Yeah, I mainly use /parseruin, then edit the ruin template.


    I think that's the method most template authors here use if there needs to be a distinction between air and preserveBlock. Maybe they'll chime in with some other tips as well.

    If your structure doesn't need air pockets, however, it might be easiest just to replace rule0. By default, rule0 is implicitly defined as background air (i.e., air that doesn't replace most plants and respects preserve_water and preserve_lava settings). You can define your own replacement rule0; it's easy, but a bit funky. Put the following line before the first rule:

    =0,100,preserveBlock


    The rule name is intentionally missing, and this must precede all other rules. With this in place, your rule0 is now 100% preserveBlock.

    Posted in: Minecraft Mods
  • 1

    posted a message on [1.14.3] Ruins (Structure Spawning System)

    weight:
    I have some issue with this one; it's acting strange.
    When I tested it, I set uniqueMinDistance to 1, which causes ruins to spawn way more and closer together.
    Then, for testing purposes, I made 2 ruins, one at weight=1 one at weight=2.
    Now, you would think it would spawn mostly #2 and sometimes #1, but that isn't the case;
    it spawned Ruin #2 100% of the time. I tested it for a while and covered a lot of distance, and not one #1 ruin ever showed up
    (keep in mind the ruins show up closely packed together, so it's easy to tell.)


    The "problem" you're seeing has nothing to do with weight; it's a consequence of setting uniqueMinDistance=1. I presume you didn't change the value of anyRuinsMinDistance in the Ruins.txt config file, so it's got its default value of 64. That means a #2 can be just 1 block away from another #2, but a #1 has to be at least 64 blocks away from a #2. Once a #2 is spawned, therefore, Ruins is going to keep picking #2 over and over until there's a gap of 64 blocks with no structures (e.g., a wide ocean, if the structures don't spawn on water) and #1 once again becomes an eligible selection, at which point a new random draw is made (33% chance of #1 or 67% of #2, according to the weight values) and the repetition begins anew.


    If you want high-density Ruins, a better way to do it is leave uniqueMinDistance=0 in the template files (which is the default; 0 being a special value indicating the global value of templateInstancesMinDistance should be used), and instead set anyRuinsMinDistance=1 and templateInstancesMinDistance=1 in Ruins.txt. You should then get the result you expect.


    In general, the value of uniqueMinDistance (and templateInstancesMinDistance) should be equal to or greater than that of anyRuinsMinDistance. Otherwise, you'll tend to get the homogeneity bias you observed, which is almost certainly undesirable. There may be some esoteric situations warranting violation of this guideline, but I can't think of any.

    embed_into_distance:
    I understand how this works, but it can be a little hard to pinpoint how deep to put it sometimes. For example, what happens if you put it too deep, like beyond bedrock? The surface isn't always smooth, after all.
    Does it stop at bedrock, or will it CUT the ruin in half?


    Ruins enforces a floor at Y=8. If you attempt to spawn a structure lower than that (due to, say, embed_into_distance=99999), it will simply spawn at Y=8.

    acceptable_target_blocks & unacceptable_target_blocks:
    If I want to add blocks to the list, is this correct?:
    acceptable_target_blocks=minecraft:stone,galacticraftplanets:mars-1,biomesoplenty:dried_sand
    By that I mean having the Mod name before the block?


    Yes; that's standard Minecraft syntax. Note you may optionally omit the minecraft: part for vanilla blocks--just specifying stone, for instance, instead of minecraft:stone. Also note the "domain" (i.e., the identifier on the left side of the colon) isn't necessarily the name of the mod introducing that block; it usually is, but there are exceptions. Something to watch out for.

    Also, if I don't specify metadata, will it go for EVERY block of that type, or just the first (AKA minecraft:stone 0) only?
    (Also, was that the correct metadata? If not, what's the right way?)
    What happens if a blockname is misspelled? Does it ignore all blocks, or just that one?


    Ruins doesn't support metadata values in this context, so it always matches every block with the specified name. If you attempt to apply a metadata value here, it'll be misinterpreted as part of the name.


    If a block name is unrecognized, that name is merely skipped. All valid names on the list will still apply. This allows you to specify blocks from mods which may or may not be installed...kind of. The catch is: if all names are invalid, it counts as an empty list, and an empty acceptable_target_blocks list is interpreted as "all blocks," possibly leading to undesirable behavior. Avoid this by including at least one vanilla block on the list. (The same concern does not apply to unacceptable_target_blocks, however, since an empty list there is interpreted as "no blocks.")


    A template should specify either acceptable_target_blocks (i.e., spawn only on these) or unacceptable_target_blocks (spawn on anything but these), or neither (spawn on anything). It should never specify both.

    I set acceptable_target_blocks to only stone from a mod, but the ruin still spawned on other blocks (this was in another dimension BTW).
    So, I set all the other blocks in unacceptable_target_blocks, and then it did work.
    So how do these two functions actualy work? Do I need to specify every block I DON'T want it to spawn on for every ruin?
    I thought if you put a block in acceptable_target_blocks, it would only use those, but that doesn't seem to be the case.
    Or, was my result just due to a fluke, or some other error on my part?
    Since some dimensions share biomes, I rely heavily on block control to make sure ruins don't spawn in the wrong world (the top block is changed per dimension).


    I can't say for sure without seeing your template file, but I'd guess in your first attempt, acceptable_target_blocks listed either a misspelled block name or a block name from a mod that wasn't loaded. See the tip above on why this can cause trouble and how to avoid it by including some unlikely vanilla block name on the list (e.g., structure_void).

    unique:
    If I understand this correctly, setting it to 1 it will ONLY make it spawn once per biome, right?
    If it is in Generic, it should only spawn once in total, right? Not "once per biome".


    There is no parameter unique. The once-per-biome feature you describe does not currently exist in Ruins.

    uniqueMinDistance:
    What would be a good Distance, if I used this for spawning animals?
    Default is 1500.
    If I set it lower, they will spawn closer, but does anyone have any recomendations?


    I'm not sure what "spawning animals" refers to. Ruins (currently) only places blocks, not entities. It can, however, place command blocks that spawn entities...is that what you mean?

    max_leveling:
    If I don't want it to remove any blocks, what do I set it to? 0?


    Leveling is a whole other can of worms. If you don't want leveling--and most templates don't--set leveling_buffer=-1. Without leveling, the best way to think of max_leveling is as specifying how flat the terrain surface must be to spawn this template. If max_leveling=0, it must be perfectly flat over the entire footprint of the structure to be spawned; if max_leveling=1, it can deviate up and/or down by at most one block; and so on. The max_leveling parameter has nothing to do with blocks being removed if leveling is disabled.

    preserving air:
    How do I make it so the ruin keeps air or not?
    Say I wanted to burry a skeleton dragon and needed the rock to surround the bones, not clear out the blocks when it's created. How do I do that? Does it have to do with the Base block I use?


    There is a special "pseudo-block" you can use in template rules: preserveBlock. This is a directive telling Ruins not to replace the block in that position.


    Since you mention base blocks, I suspect you're creating templates via the /parseruin command. If so, your template uses an implicit rule0 to represent air (sort of...this post is long enough without going into a full explanation). If you want your template embedded in a medium like dirt or stone without unsightly air pockets, you can manually edit the parseruin-generated template file to add a new preserveBlock rule onto the end of the rule list, and replace some or all of the 0's in the layers with this new rule. So, instead of...

    rule1=0,100,bone_block-4
    rule2=0,100,bone_block-8
    rule3=0,100,bone_block-0
    
    layer
    0,1,0
    2,3,2
    0,1,0
    endlayer
    
    layer
    0,0,0
    0,3,0
    0,0,0
    endlayer


    ...you would have...

    rule1=0,100,bone_block-4
    rule2=0,100,bone_block-8
    rule3=0,100,bone_block-0
    rule4=0,100,preserveBlock
    
    layer
    4,1,4
    2,3,2
    4,1,4
    endlayer
    
    layer
    4,4,4
    4,3,4
    4,4,4
    endlayer

    Ruin distances to OTHER ruins:
    I got some special ruins that I don't want showing up too close to each other; they are different types of ruins.
    How do I make it so Ruin A wont spawn anywhere near Ruin B?


    This isn't currently supported in Ruins, at least not directly. As a workaround, though, you could perhaps create a third template C which simply consists of a single command block that spawns either an A or a B in its place. Move templates A and B to a non-biome folder so they aren't naturally generated on their own. Set C's uniqueMinDistance to some big number, like 4096, and voilà! Your A's and B's are widely separated.

    Posted in: Minecraft Mods
  • 2

    posted a message on [1.14.3] Ruins (Structure Spawning System)
    Quote from MokahTGS»

    ...you can't use ruins for mod packs, as the player would name the save game anything they want, meaning I'd never be able to guess what they would call it.


    There's no guessing. Recall I said you won't have a "world" folder configuration if you're starting a brand new world, and presumably anyone installing a modpack is likely starting a brand new world (or joining a server on which a world was already created, in which case it doesn't matter--Ruins currently has no client-side functionality). You only need to include the one edited configuration file config/ruins.txt in your modpack, just as you would for virtually any other mod. It doesn't matter what the world is eventually called; Ruins automatically installs that included configuration into appropriate folders.


    The tricky bit about hunting down the world folder only applies if you're adding Ruins to an already existing world. If you're using a new modpack to play in a world created without it, Ruins is probably going to be the least of your problems.

    Posted in: Minecraft Mods
  • 0

    posted a message on [1.14.3] Ruins (Structure Spawning System)
    Quote from MokahTGS»

    I need help.



    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.

    Posted in: Minecraft Mods
  • 1

    posted a message on [1.14.3] Ruins (Structure Spawning System)
    Quote from MentalMouse42»

    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.

    Posted in: Minecraft Mods
  • 2

    posted a message on [1.14.3] Ruins (Structure Spawning System)

    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, 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).

    Posted in: Minecraft Mods
  • 0

    posted a message on [1.14.3] Ruins (Structure Spawning System)

    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.

    Posted in: Minecraft Mods
  • 2

    posted a message on [1.14.3] Ruins (Structure Spawning System)
    Quote from Gillymoth»

    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.

    Posted in: Minecraft Mods
  • 1

    posted a message on [1.14.3] Ruins (Structure Spawning System)
    Quote from insell8»

    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).

    Posted in: Minecraft Mods
  • 0

    posted a message on [1.14.3] Ruins (Structure Spawning System)
    Quote from boyslittle»

    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.

    Posted in: Minecraft Mods
  • To post a comment, please or register a new account.