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

Allowing multiple tags to be unified together #42

Open
unix-supremacist opened this issue Apr 28, 2023 · 6 comments
Open

Allowing multiple tags to be unified together #42

unix-supremacist opened this issue Apr 28, 2023 · 6 comments

Comments

@unix-supremacist
Copy link

Describe the feature/addition!

i would like for it to be possible to unify 2 separate tags together say c:{material}_ingots and c:ingots/{material}, and it would unify them as if they were the same tag.

Why would like to see this feature/addition?

on fabric we've had 2 tag standards for materials for awhile, one that the fabric port of create introduced which a lot of newer fabric mods use, (gtce unofficial, gregtech intergalactical, etc), and then the cotton standard which older mods use (modern industrialization, tech reborn, etc), and it would be nice to unify them without having to use scripts to convert tags, or to manually tag items, this could also be used in cases where mods ignore tag conventions, like unfinished ports.

@Kanzaji
Copy link

Kanzaji commented Apr 28, 2023

This feature already exists as Tag Ownerships, that was recently released :D
https://github.com/AlmostReliable/almostunified/wiki/Unification-Config#tag-ownerships

GitHub
A Minecraft mod to unify resources. Contribute to AlmostReliable/almostunified development by creating an account on GitHub.

@unix-supremacist
Copy link
Author

does this work with the {material} key? to work with all materials? if not one can manually do it, but you'd have to go through nearly every tag manually, which in modern industrialization and tech reborn alone for that use case, there would be hundreds

@rlnt
Copy link
Member

rlnt commented Apr 28, 2023

It does not. And supporting the material parameter in that feature will be incredibly painful to implement. Will take a look at this next week when I find the time whether this is doable in a reasonable way.

How would you imagine setting up something like this? Maybe this:

"tagOwnerships": {
  "c:{material}_ingots": ["c:ingots/{material}"]
}

However, that may introduce edge cases since it will create that combination for each material. The tag ownership system checks if those tags actually exist. If they don't you'll get a lot of warnings. Not sure if this is a good addition since it could result in more issues than it solves.

@unix-supremacist
Copy link
Author

i see, and yeah thats basically how i would imagine it, but if the tag ownership system checks if those tags exist, would it be possible to instead create another system like "material ownerships" that would be more in line with what this feature would need to do

otherwise ill just write a small kubejs script to generate the tag ownerships config automatically, though id rather do that as a last resort as that would create an extremely bloated config file

@rlnt
Copy link
Member

rlnt commented Apr 28, 2023

We may introduce a custom placeholder system where you can define your own material-like lists.
Something like

"placeholders": {
  "materials": [
    "iron",
    "gold",
    "copper",
    "tin",
    //...
  ],
  "ownershipMaterials": [
    "foo",
    "bar"
  ]
}

You could then access them dynamically in specific areas where placeholders are allowed with the usual {materials} and {ownershipMaterials} syntax.

I might need a little time to work on that though.

@unix-supremacist
Copy link
Author

yeah this makes the most since to me, would lead to the simplest config implementation no matter which standards i the dominate one, also no rush, considering both mods that this feature would majorly benefit unifying with aren't out of alpha

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

No branches or pull requests

3 participants