Feature Request: Per-block Replacement Configuration

import_user_oitsjustjose_95mQ commented

2019-07-11 14:10:52 +00:00

(Migrated from git.oitsjustjose.com)

Versions:

Minecraft Forge: 1.12.2-14.23.5.2838

Backstory

While working on @Rosethorns 's new pack, we originally started using Underground Biomes' ore replacements to handle ore replacement for their stone, however, due to an issue with UB ore not correctly working with Scannable, we've since switched over to using Content Tweaker to produce custom ores (with samples) for each block type we want to replace (including ore variants for some Quark, Earthworks, Chisel, and Rustic worldgen blocks).

Currently, we're handling this using GregTech "Community Edition" to spawn in our ore, which has moderately good support for configuring its oregen except a distinct lack of being able to set the chance per chunk lower than 50% (and its block state match being completely incorrect).

Desired Functionality

If possible, we would like to be able to switch over to Geolosys, however, before that, we would like to ask for the ability to specify blocks both in the current format of:

[
    "geolosys:ore_vanilla:0", 100
]

And a format that allows for per-blockstate matching:

[
    {
        "weight": 100,
        "default": "geolosys_vanilla:0",
        "replacements": [
            {
                "block": "minecraft:diamond_block",
                "predicate": "undergroundbiomes:igneous_stone:1"
            },
            {
                "block": "minecraft:emerald_block",
                "predicate": "undergroundbiomes:metamorphic_stone:1"
            }
        ]
    }
]

Which would replace igneous stone 1 with a diamond block, metamorphic stone 1 with an emerald block, and everything else would fall back to the default case.

Which I realize is probably a huge undertaking, given how you're currently reading in the config, but it's the only thing that's holding us back at this point from having proper oregen.

Thanks.

## Versions: - Minecraft Forge: 1.12.2-14.23.5.2838 ## Backstory While working on `@Rosethorns` 's new pack, we originally started using Underground Biomes' ore replacements to handle ore replacement for their stone, however, due to an issue with UB ore not correctly working with Scannable, we've since switched over to using Content Tweaker to produce custom ores (with samples) for each block type we want to replace (including ore variants for some Quark, Earthworks, Chisel, and Rustic worldgen blocks). Currently, we're handling this using GregTech "Community Edition" to spawn in our ore, which has moderately good support for configuring its oregen except a distinct lack of being able to set the chance per chunk lower than 50% (and its block state match being completely incorrect). ## Desired Functionality If possible, we would like to be able to switch over to Geolosys, however, before that, we would like to ask for the ability to specify blocks both in the current format of: ```JSON [ "geolosys:ore_vanilla:0", 100 ] ``` And a format that allows for per-blockstate matching: ```JSON [ { "weight": 100, "default": "geolosys_vanilla:0", "replacements": [ { "block": "minecraft:diamond_block", "predicate": "undergroundbiomes:igneous_stone:1" }, { "block": "minecraft:emerald_block", "predicate": "undergroundbiomes:metamorphic_stone:1" } ] } ] ``` Which would replace igneous stone 1 with a diamond block, metamorphic stone 1 with an emerald block, and everything else would fall back to the default case. Which I realize is probably a huge undertaking, given how you're currently reading in the config, but it's the only thing that's holding us back at this point from having *proper* oregen. Thanks.

import_user_oitsjustjose_95mQ commented

2019-07-11 14:20:18 +00:00

(Migrated from git.oitsjustjose.com)

Woof, yeah, this is a really big one.

A few things I can do:

Change the format of the JSON for ores as it was poorly designed anyways:

    "ores": [
        {
            "blocks": [
                {
                        "block": "minecraft:diamond_ore",
                        "chance": 10,
                        "predicate": [
                            "minecraft:stone:1",
                            "minecraft:stone:3"
                        ]
                },
                {
                        "block": "minecraft:gold_ore",
                        "chance": 90,
                        // No predicate
                }
            ],
            "samples": [
                {
                    "block": "some:sample_block:0",
                    "chance": 50
                },
                {
                    "block": "some:sample_block:1",
                    "chance": 50
                }
            ]
        },
    .
    .
    .
    ]

Redesign components of Geolosys to allow for a per-block mapping of predicates, rather than the entire deposit having a predicate.

What's the desired deadline on this? I've been working full-time this summer in research under my professor, so I've been relatively busy but have a little time in the evenings, and weekends free. And once I'm not on full-time, it'll be time to start back at college again.

Woof, yeah, this is a ***really*** big one. A few things I can do: 1. Change the format of the JSON for ores as it was poorly designed anyways: ```jsonc "ores": [ { "blocks": [ { "block": "minecraft:diamond_ore", "chance": 10, "predicate": [ "minecraft:stone:1", "minecraft:stone:3" ] }, { "block": "minecraft:gold_ore", "chance": 90, // No predicate } ], "samples": [ { "block": "some:sample_block:0", "chance": 50 }, { "block": "some:sample_block:1", "chance": 50 } ] }, . . . ] ``` 2. Redesign components of Geolosys to allow for a per-block mapping of predicates, rather than the entire deposit having a predicate. What's the desired deadline on this? I've been working full-time this summer in research under my professor, so I've been relatively busy but have a little time in the evenings, and weekends free. And once I'm not on full-time, it'll be time to start back at college again.

import_user_oitsjustjose_95mQ commented

2019-07-11 15:31:20 +00:00

(Migrated from git.oitsjustjose.com)

I'd say ideally whenever it's possible - we were relatively close (a few weeks or so) to getting out a beta version of the pack for testing when we realized the oregen issue.

If you're okay with changing the config format like that, I can take a look and see if it's something that I feel comfortable with submitting a PR for.

I'd say ideally whenever it's possible - we were relatively close (a few weeks or so) to getting out a beta version of the pack for testing when we realized the oregen issue. If you're okay with changing the config format like that, I can take a look and see if it's something that I feel comfortable with submitting a PR for.

import_user_oitsjustjose_95mQ commented

2019-07-13 00:23:00 +00:00

(Migrated from git.oitsjustjose.com)

I have this mostly complete - though I'm adding a bit extra so that it's usable for the purpose mentioned above. In testing, I found Aang23/UndergroundBiomesConstructs#120 so I'm waiting on that to get fixed before submitting the PR.

import_user_oitsjustjose_95mQ commented

2019-07-13 01:48:29 +00:00

(Migrated from git.oitsjustjose.com)

Oh wow, you're working on the code itself? I was expecting (and willing) to do it myself if necessary but of course, I'll be glad to have the help!

import_user_oitsjustjose_95mQ commented

2019-08-21 20:04:48 +00:00

(Migrated from git.oitsjustjose.com)

Rorax caught me up on the situation, so since this is a big overhaul I'm going to close this for now.

import_user_oitsjustjose_95mQ (Migrated from git.oitsjustjose.com) closed this issue

2019-08-21 20:04:48 +00:00

Rows
Columns

Feature Request: Per-block Replacement Configuration #201

Versions:

Backstory

Desired Functionality