Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Scanning by tags? #13

Open
danaYatsuta opened this issue Jul 15, 2024 · 2 comments
Open

Scanning by tags? #13

danaYatsuta opened this issue Jul 15, 2024 · 2 comments

Comments

@danaYatsuta
Copy link

For vanilla ores, JER shows combined ore distribution for normal ore variant and deepslate variant, which is convenient, since if you are looking for ore you likely don't care what variant it is. Is there a way to generate world-gen.json in such a way that, for example, Create's both zinc ore and deepslate zinc ore have the same distrib values that are actually combined distribution of those two ores?

@RundownRhino
Copy link
Owner

It could be done, but I'm a bit uneasy about it. For one, it's a bit hacky to do it by forging distributions on the RS side, rather than the JER side. For another, it's not actually that trivial to figure out which ores are variants of others. For the vanilla ores it's the deepslate_ prefix, and most mods like Create follow the same pattern, but e.g. DeepResonance instead uses the _deepslate suffix vs the _stone suffix for the deep and normal variants. So it'll be some fairly messy code. As an example, here's how I did it last time I was making some modded ore distribution plots:

def collect_variants(ores) -> dict[str, list[str]]:
    ore_combs = {}
    for el in ores:
        if "xychorium" in el:
            continue # these are many, and uninteresting
        raw = el.replace("deepslate_", "").replace("_deepslate", "").replace(":stone_", ":").replace("_stone", "")
        ore_combs.setdefault(raw, []).append(el)
    return ore_combs

So I'm thinking if I do it at all, it'd be in the form of some python scripts that I publish along with RegionScanner, rather than as part of its own code. That way it'd be easier to modify and play around with the parameters.

@danaYatsuta
Copy link
Author

That makes sense.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants