Cross-loader common tags convention

[glossy harness]

many fd food do that. i have 2 that do that

[cobalt moon]

Cake is going under foods/edible_when_placed tag

So it isn’t just cakes and stuff. Any food that is placeable before eating. Farmer delight has many of those that aren’t cakes

(Also pumpkin pie exist and isn’t placeable and is eaten in hand)

[glossy harness]

yeah i guess grouping pies and grouping cakes wont be needed as i dont see a use case even tho many mods add similar items and blocks

[cobalt moon]

If you find more mods trying to make and use a ropes/chain tag, Lmk. I’ll spend time at some point to find who is trying to make the rope and ropes tags that the sheet shows

[steady crown]

Comforts adds the item tag forge:rope to use in one of its recipes.

[edgy folio]

the argument was that item tags are kind of by definition a diversified group. "fishes" is "salmon, cod, tropical fish, pufferfish", "meats" is "pork, beef, mutton, chicken"

[alpine lagoon]

shrug I can see it both ways tbh

[edgy folio]

i don't personally care strongly either way, just pointing that out since that is why some people wanted that

[cobalt moon]

Well it’s fishes now cause minecraft:fishes exist and having fish alongside that is too inconsistent for me

[edgy folio]

we incidentally might benefit from, as part of a food API whenever that happens, a way to identify the associated food properties and how many servings the item/block is [something that tags alone can't do, but i know there's been talk about a food API in the past]

[cobalt moon]

My findings on who are trying to do rope and chain tags on fabric and forge:

[cobalt moon]

@copper aurora is there a reason you don't have a rope item tag usage for your recipes that uses rope? Wondering as you do have block tag for ropes

[copper aurora]

mostly cuz safety sets and ropes can be converted back and forth

and using a tag there would "convert" modded ropes into FD rope

[cobalt moon]

just fyi, you'll want to switch to forge:ropes for now to work with supplementaries

[cobalt moon]

You’ll probably want to add your ropes to forge:ropes too so at the very least, the other mods can use your ropes

Block and item tag

[edgy folio]

are we distinguishing between "place and then collect a portion with a knife or bowl" vs "place and then eat by clicking"?

[cobalt moon]

Place in world and eat in world

Like cake and farmer delight meals stuff

The collect portion is not edible in world. That’s creating new items that you later eat

[hazy wind]

are food tags intended to use the culinary or botanical definition of their name? (e.g. if there was a berry tag would a modded strawberry use the tag)

[cobalt moon]

Culinary. The Javadoc will tell you that

[merry furnace]

telepathicgrunt

[Jump to referenced message](#1134480199937957969 message) in #1134480199937957969

Nov 12, 2023, 1:40 PM

[cobalt moon]

Berries are separate from fruits because there’s a ridiculous ton of berry foods that it is more useful to separate from fruits

https://github.com/TelepathicGrunt/Bumblezone/blob/1.20-Arch/common/src/main/resources/data/the_bumblezone/bz_bee_queen_trades/berries.json

Cherry would be fruit tho. Even culinary says fruit for it due to pit in center. Stone fruit

[edgy folio]

i'd say culinary because the recipe for fruit salad should not accept tomatoes 😛

plus if we go by the scientific definition almost nothing is actually a nut, we need some tag to put peanuts and walnuts and cashews in [none of which are either nuts or the same kind of thing as each other]

[cobalt moon]

maybe a block tag of c:in_world_edible would be good too. Or c:placed_edible to be similar to item tag. thoughts?

Or forgo block tag for this. Not sure if people need something to tell if block in world is edible like cake

[regal bridge]

i know of a few mods that add in-world placeable foods but you have to interact with them using something like a bowl to get the actual food item from them

so it might work but i think it's probably not worth it

[cobalt moon]

Those wouldn’t be in the tag as those blocks are not being eaten. They are giving you items that you later eat. The new items is what would be food tagged and all

The block tag would be for blocks that you directly eat in world like cake.

[hazy wind]

how about a edible/harmful tag for food that's technically edible but harmful/dangerous to eat

[cobalt moon]

does rotten flesh go into there?

what is "harmful"?

[hazy wind]

probably

[cobalt moon]

how about suspicious stew? can have any effect including harmful

[hazy wind]

anything that does harm to you in some way when you eat it, for example uncooked elder berries, pufferfish, a magic plant from another dimension that turns your guts inside out when when you eat it

[hazy wind]

not sure, suspicious stew is strange

[low kraken]

Is chorus fruit harmful

[cobalt moon]

some could argue rotten flesh hunger isn't "harmful" is the problem. harm imply damage imo. like poison or something

[hazy wind]

rotten flesh causes hunger which can cause starvation which causes damage

[cobalt moon]

how about a food that gives levitation? You fly up, lose effect, fall and take damage

is that a harmful food? or a tactical food that you use to get to higher places?

[hazy wind]

i think that depends on the length of the effect, if it gives you a few seconds of levitation its probably tactical, if it gives you a minute of levitation its probably harmful

[cobalt moon]

now we are reaching arbitrary lines

and that can be an issue for this tag

if people cant understand what is harmful or not, the tag will start to get entries that not everyone agrees with from each mod and can cause weird conflicts

[hazy wind]

maybe the tag could be edible/toxic or edible/poisonous, it would be the same in most of the non-edge cases, and it would avoid a lot of the edge cases

[lapis wren]

That's still got a lot of edge cases

It just seems too wishy-washy to me in terms of what goes in it

[craggy bronze]

why not use the mod effect category for that effect? And tag them with all of the applying effects?

Mob Effects are already categorized for beneficial, harmful and neutral

[cobalt moon]

it could also be foods that directly damage you without effects. or a food that deletes your armor

edge case galore

[reef charm]

Every categorization system will end up with edge cases

[cobalt moon]

This one is especially problematic is the issue

There can be a foods/poisonous for spider eye and poisonous potato but that excludes rotten flesh. It is more clear it is for poisonous foods. But I can’t think of any category that includes all three items without also including a ton of questionable items as well

[reef charm]

Isn't hunger supposed to represent food poisoning?

[cobalt moon]

wouldnt that be better represented by poison or nausea?

food that makes you hungerier seems like just zombie magic thingy

making you just as hungry as zombies

[reef charm]

I guess? I always thought poison as actual venom

Hunger as food poisoning

And nausea as what you get when you spin too fast

[cobalt moon]

venum and poison are different. Venomous is toxins that are injected like a snake bite. Poison are toxins you ingest or touch or whatnot. Hence why it is Poisonous Potato and not Venomous Potato. The Spider eye is poisonous and not venomous because you eat it.

[cobalt moon]

pufferfish

[reef charm]

There's pufferfish?

[cobalt moon]

You eat pufferfish in game and you get nausea

[reef charm]

Welcome to English and distinctions in the language I'm not acquainted to lol

[reef charm]

I wasn't even aware that pufferfish existed nor that you could eat them

[cobalt moon]

https://minecraft.wiki/w/Pufferfish_(item)

(Though I do play devils advocate to try and make sure suggestions are strong enough to be added)

I guess rotten flesh hunger feels more of a debuff than harm in a way.

[lapis wren]

The issue is that it really gets iffy fast when stuff like chorus fruit is considered

And in general, "harmful" is an iffy category, and "poisonous" is well defined only so long as you mean specifically the poison effect and nothing else and then it's not a very useful category

[stray ore]

how about instead of having a tag for food with negative effects, we add a tag for "food with mob effect", leaving it up to mods to decipher whether it is harmful or not via the mob effect(assuming that is available from the Item)

[primal quarry]

chorus is not harmful and not beneficial

[lapis wren]

Do you mean mob effect or generic "does something besides filling hunger"? As those are two different things

[stray ore]

good point, hadn't thought that far

[lapis wren]

Chorus fruit once again rears it's ugly head

That said, I think stuff should be based on usage. What's the actual case where folks want a tag for this and what's the expected behavior of a tag in that case, and can we go from there? And if nobody wants to use this tag it shouldn't be included, but if people do want it lets collect the details from the intended use

[cobalt moon]

Exclude poisonous potatoes from vegetable food tag by doing ingredient exclusion of poisonous food tag in a recipe?

Either that or I remove poisonous potato from vegetable tag

[stray ore]

I don't think posionous potatos and spider eyes should go in food tags, even though they are edible

[cobalt moon]

They do restore hunger a bit and were in the c:foods tag that fabric already have now

In code, if you check food property, they have one so by minecraft, it is food

[stray ore]

if all you care about is whether or not an item restores some hunger, you can just check their food value.

[cobalt moon]

Even wiki says it is food

[stray ore]

I don't agree with that, at best they should be considered "edible"

[lapis wren]

I'd say I wouldn't put it in the vegetable category. The javadocs says the vegetable tag is based on culinary category. Poisonous potatoes, culinarily, are inedible

So they can go in the food tag, based on the food attribute, but I wouldn't put them in the vegetable tag as that's meant for recipes

[stray ore]

I think this logic should apply to all "foods" categories, being edible doesn't equal being food IMO

[soft night]

Everything is edible, you might not survive the first time eating it

[cobalt moon]

even minecraft puts spider eyes in the food creative tab

if you don't mark it as food, it confuses people because mc says it is food

[lapis wren]

The food tag is meant to represent the player being able to eat it, from my understanding, in a way that can be used in places where tags are required and you can't check the item food attribute

[soft night]

(To Telepathic)

[lapis wren]

Yeah, I'm with you on it being food, but the poisonous potato shouldn't be a vegetable in my mind

[cobalt moon]

Yeah I can remove it from the vegatable tag and just keep it in c:foods.

[lapis wren]

Because that one is specifically based on culinary category

[cobalt moon]

current setup. (fabric view cause it is cleaner and easier to share than neoforge's datagen code)

[lapis wren]

Dicey on the golden/enchanted stuff in the vegetable/fruit tags, especially if the poisonous stuff isn't, but I don't know if there's a good solution there

[craggy bronze]

can we get a cake tag? there are a lot of mods that add cakes (as a block&item tag)

[cobalt moon]

can add a c:foods/golden and you ingredient exclude if you wont want golden

[cobalt moon]

EDIBLE_WHEN_PLACED_FOODS is for cake and other items that places blocks that you then eat

[cobalt moon]

was asking earlier if a block tag should exist for that

[craggy bronze]

yeah, but cakes are not just in world eadible foods, they are a somewhat special imo, and yeah, placed foods is something I would also want a tag for

[cobalt moon]

you'll have to explain what case is needed for cake tag that c:foods/edible_when_placed doesn't cover for the item tag

[hazy wind]

probably way too complicated, but how about edible/harmful defined as ```[only gives effects, hunger, and, saturation when eaten and, [the total of f(effect) for each negative effect it gives is greater than the total of f(effect) for each positive effect it gives]]
or
[does something that reduces one or more of your resources without giving a equivalent amount of one or more resources* back on average]
when eaten

*resource defined as [anything you can have that you can spend, lose, or gain in some way that does not match the definition of harmful], items.
if something is the direct opposite of a resource and, not a resource it is considered to be a negative amount of that resource

**calculating equivalence between different resources would be difficult in some cases, if no simple way of converting between amounts of two resources exists its assumed that they can never be equal,
when converting between effects and health a potion effect is equal to the health regeneration it would regenerate over its length if it was regeneration,
hunger and saturation are considered equal to the health they would eventually regenerate,
items have greater than infinite value when lost and no value when gained,
death is equal to the loss of a infinite amount of hearts

***f(effect) = effect.level * effect.length```
(negative effect referring to harmful effects, because that's how minecraft.wiki refers to the categories of effects)
there's probably a better word than resource, but i can't think of it

in vanilla resources would be your health, items, armor points, effects, etc

this would hopefully solve a lot of the edge cases, solutions to the previously listed edge cases: food that deletes your armor: infinite loss of resources and thus harmful. chorus fruit: only effects position, position is not a resource, not harmful. food that gives levitation: always gives levitation, which is negative, and nothing else, harmful. rotten flesh: harmful, out of characters

(sorry for the wall of text)

[cobalt moon]

i think you missed the point

a datapacker, modder, and players are going to see c:foods/harmful. Only modders looking at the modloader's class directly will see the javadoc for what goes in the tag.

the issue is everyone else who looks at the tag name will be hevaily confused and start putting items that doesn't belong in it into the tag

that's the issue.

c:foods/harmful is too vague and open-ended when viewed alone compared to all the other tags

[cobalt moon]

also, I aint reading all that and running calculations on my items just to determine if it goes in a tag

and no one else will do so either

it has to quick to understand and quick to decide if my item goes in it or not

c:foods/poisonous works because it is clear it is about foods that are toxic and gives poison. Or could do c:foods/food_poisoning if we want to take the risk of expanding it to include foods that people feel would give food poisoning irl like rotten flesh and nausea foods.

[hazy wind]

i'd say food_poisoning

[lapis wren]

let's leave the math for worldgen. Tags should be intuitive except in very rare cases

[craggy bronze]

probably not enough cases so that a tag is really needed

[timid pumice]

Same, since you get it from raw chicken as well

[cobalt moon]

it what

(adds it to food poisoning tag)

[hazy wind]

would food_poisoning include a bowl of soup containing billions of microscopic needles?

[coral valve]

is a medical waste disposal box a soup

[low kraken]

probably more a stew

[cobalt moon]

bigger question is why you marked your soap with needles as edible

lets focus more on things people are likely to add lol

i misread soup as soap

if your food does something that can be interpeted as food poisoning, put it in there. And be realistic on what you would expect from the tag lol

no a bomb that you eat is not food poisoning

[low kraken]

Is the Forbidden Cheese food poisoning?

[cobalt moon]

That’s food death

Instant death

Anyway, back to topic as we beat this food poisoning to death.

Is a golden tag something needed. Or block tag for placed edibles needed

[glossy harness]

Supplementaries soap is edible and very harmful ☠️

If we are still looking for a name what about has_negative_side_effect

[cobalt moon]

Negative side effect is problematic as it is too vague and we get into issue of is chorus consider negative or levitation foods negative and so forth

What does your soap do when eaten

Oh it gives poison. Put it in food poisoning tag

[glossy harness]

Yeah makes sense.

[edgy folio]

I'm pretty sure the vanilla food API already lets you query if food gives an effect, though idk if it works for suspicious stew

[cobalt moon]

Sure but if you have a recipe for say toxic soup and you want food poisoning items in it, the tag helps here. Or spawn poisonous foods in decaying structures for fun or something idk

But yes in code you should be able to get the exact effects somehow

[hazy wind]

but gunpowder is a toxin, and the metals bombs are made of are usually also toxic, so you would still get poisoned from the bomb fragments in your mouth if you managed to swallow them, so the bomb should have the food poisoning tag.

or if the bomb is made from lead you wouldn't even need to swallow

you could also not ignite the bomb and slowly scrape off bits of the metal using your teeth for food poisoning from the metal

now that i think about it food/poisonous is probably better than food/food_poisoning,
it solves the bombs and magic cheese as google defines poisonous as
"(of a substance or plant) causing or capable of causing death or illness if taken into the bory.", the forbidden cheese kills you when ingested, so its technically poisonous,
the bomb is probably made from multiple poisonous substances, so its technically poisonous

and repeating the word food in food/food_poisoning sounds a bit weird when you read it a lot

[cobalt moon]

Plat was joking about the cheese

[hazy wind]

however the cheese is still a concern, as a mod may add forbidden cheese

[cobalt moon]

if the modder makes it so that eating a bomb grants poison, then it is food poisoning and goes in tag. If the modder makes bomb explode when eaten, that is not food poisoning.

you dont call someone getting blown up by a bomb an illness. You call that an injury or death

food poisoning is illness

[hazy wind]

yes, the explosion ripping your head off isn't a illness, but if you somehow survived you'd eventually end up with heavy metal poisoning(assuming the bomb is made from heavy metals)

[cobalt moon]

ok let me know whan a modder implements that lol

i think we hit fringe edge cases with food poisoning tag so that means it is solid. More solid than foods/harmful. Rather roll with it for now and see how modders handle it.

[edgy folio]

In general the phrase "food poisoning" refers to foodborne illness or bacterial toxins rather than poison in general. And, it may be worth considering, rotten flesh and raw chicken inflict the hunger effect rather than poison

[hazy wind]

i'd say rotten flesh and raw chicken would count as poisonous

[rich torrent]

Since it's half related to tags, any news on the situation of https://github.com/neoforged/NeoForge/pull/59 ? Is it scheduled after this bunch of tag migration or are there problems with it?

[cobalt moon]

Depends on what @uneven nova wants to do with that and depends on if those tags are functionality tied to some code or not

[uneven nova]

hm?

Damage type tags are more code-tied than most tags

I don't think there is anything blocking #59 though, it just needs to be rebased

[cobalt moon]

yeah if functional tied, those tags would exist under neoforge namespace and not the c namespace and so, not related to my unifying tag pr

[rich torrent]

Oh, I understood it as all forge tags becoming c

[lapis wren]

Only convention tags

[spring crane]

is that not all the tags that forge has atm?

[lapis wren]

Not quite

Enchanting fuel I think?

Maybe one or two others

Well, enchanting fuel is deprecated for now until any sort of fallback tags are implemented so maybe?

[cobalt moon]

Functional forge tags

[spring crane]

cool

wanted to make sure they were being renamed too

[west juniper]

functional vs utility

[lapis wren]

Worldgen stones - not sure that's functional, I'd consider it a convention tag. Unless neoforge is patching in behavior based on that in which case I at whatever is going on there

[primal quarry]

I'd consider worldgen tags convention and not functional because the functionality is not patched in via code but it is used in datapacks

[cobalt moon]

It’s patched in

https://github.com/neoforged/NeoForge/blob/1.20.x/patches/net/minecraft/world/level/levelgen/feature/Feature.java.patch

right here

Hence why i moved it from forge:stone to neoforge:worldgen/stones

cc: @primal quarry ^

I'll edit javadoc to mention where it is patched in

[alpine lagoon]

yayyy

[cobalt moon]

not sure if sarcastic yay

[lapis wren]

what's wrong with base_stone_overworld that necessitates that?

[cobalt moon]

No idea

[lapis wren]

I... okay. But weird but alright

[cobalt moon]

But I didn’t want to make the decision to yeet a functional tag

[lapis wren]

Yeah no, that's fair, that's a different issue than what you're doing

[cobalt moon]

If neoforge team yeets the forge:stone tag now, I can remove it from my pr

What I think happened is forge had forge:stone first. Patched it in so features replaced it. Then Mc came with its own stone worldgen tag. But forge decided to replace that tag in the feature instead of removing their own tag

Could’ve been an optional forge:stone tag entry put into vanilla’s worldgen stone tag and then the forge tag removed

[lapis wren]

Yeah seems funky to patch when including the tag in the vanilla one is possible

[cobalt moon]

Or maybe the patch should just be yeeted and the functional tag turned into a normal conventional tag

[lapis wren]

I'd yeet the patch but yeah, it's a whole different issue

[cobalt moon]

you go make issue report to Neo to yeet patch!

(I’m at work procrastinating)

[lapis wren]

(i asked in #neoforge-github for more info already)

[barren sand]

With all the documentation happening via comments I think it would be beneficial for NeoForge & Fabric to consider incorporating a comment field within the JSON of tag files.
This would provide clarity for modpack makers and regular users by allowing them to understand the purpose of datapack tags directly from the comment, eliminating the need to rely on source code comments or some wiki.

[cobalt moon]

Issue is raw json by default doesn’t allow for comments. You can do // comments since Mc is lenient mode parsing (actually not sure if tags are parsed lenient). However in many editors, that // will be marked as an error.

I had to add this entry to make GitHub stop marking my //comments in red for my structure tutorial mod
https://github.com/TelepathicGrunt/StructureTutorialMod/blob/3c143e5a8298c4eebff26efc9c006a2750a58b2c/.gitattributes#L1

Also, datagen doesn’t allow comments either

[barren sand]

Sorry I didn't literally mean code comments but more like a valid json field called comment

[cobalt moon]

So the datagen would have to be created in a different pr for comments first before tag pr can even have them

[cobalt moon]

Ngl, I hate that workaround a ton

It’s very ugly

I used to do that for my structure tutorial mod and was too much
https://github.com/TelepathicGrunt/StructureTutorialMod/blob/54f4f2d4af6aac4b53298ccdda360d522aed7dc7/src/main/resources/data/structure_tutorial/worldgen/template_pool/run_down_house/start_pool.json

Vs https://github.com/TelepathicGrunt/StructureTutorialMod/blob/1.16.3-Forge-jigsaw/src/main/resources/data/structure_tutorial/worldgen/template_pool/run_down_house/start_pool.json

You can make an issue report to Neoforge and fabric repo asking for them to look into comments for json files and to develop the datagen for them. As it cannot be set by hand since the datagen will wipe out any hand-made work on the json files

[barren sand]

Yeah you're right it would need to be part of datagen.

But honestly I don't need it. So I don't think I will open a issue for that any time soon 🙃

I mostly mentioned it for the sake of accessibility for non-mod-dev people.

[barren sand]

ok your right the first example is a nightmare

[cobalt moon]

pluralizing to mean many different types now. I reached fluids and oof

honeys

feels so wrong but do it I must for consistency

but this would be the same as saying minecraft:waters

or maybe fluid is special and is more about saying the type than saying multiple types?

[primal quarry]

the vanilla water tag should not have a pluralised translated name because it is for behaviour and not recipes

[cobalt moon]

not in forge/neo

water/lava tag behavior was removed for FluidTypes to work

So in forge/neo, the fluid tags are turned into normal conventional-ish tags

[primal quarry]

question is does the fabric side patch that out too?

[cobalt moon]

nope

they have their own c:water and c:lava tag for people who want to tag their fluid without side effects

[primal quarry]

well then we can't use the vanilla tag for 2 different things

[lapis wren]

c tag should be for convention, vanilla for behavior, even if in forge that behavior does nothing

[cobalt moon]

So you want this

c:waters

[lapis wren]

I'd say yes

[stray ore]

why do we need such specific stew tags?

[cobalt moon]

was asked for by knightminer saying several mods had stew fluids

[stray ore]

is there one for all stews too?

[soft night]

Soup carts go brrr

[cobalt moon]

https://github.com/neoforged/NeoForge/pull/135#discussion_r1331700422

[lapis wren]

Basically, you need a very specific tag because though it exists in vanilla, the fluid doesn't, and mods want to be able to consume each other's fluids of it

[coral valve]

CONSUME SOUP

[cobalt moon]

Side note,
forge:dusts/prismarine
I don't want to just delete a tag but this is just wildly specific and I can't find any usage of this. Maybe this should just be deleted

or maybe I am looking in wrong places

[lapis wren]

What even goes on that?

[cobalt moon]

dust like redstone dust or glowstone dust like items

crushed and grinded down prismarine shards/crystals I guess

wait, forge adds prismarine shards to it...
https://github.com/MinecraftForge/MinecraftForge/blob/1.19.x/src/generated/resources/data/forge/tags/items/dusts/prismarine.json

what the hip hoppity heck is this

shard != dust

[lapis wren]

Okay so... um... yeah, yeet that

If I were a modder I'd expect that to have, like, actual prismarine dust in it

And it screws over any modder who does happen to add that

Because now they have no tag for stuff

Maybe a dedicated prismarine shard tag or something? I don't know, seems pretty niche

[cobalt moon]

I cant find anyone actually adding to that tag so it's entirely unused anyway for tagging stuff.

[regal bridge]

I'd say keep the tag, but remove the item?

Just in case there is some random person using it

[lapis wren]

People can add to tags neoforge doesn't add

[cobalt moon]

if they make a prismarine dust, they cna make their own c:dusts/primsarine tag

[regal bridge]

oh right, I was just thinking Tags.Items.DUSTS_PRISMARINE 🙃

[fervent brook]

Also https://github.com/MinecraftForge/MinecraftForge/blob/1.19.x/src/generated/resources/data/forge/tags/items/gems/prismarine.json

[cobalt moon]

cause otherwise, this tag doesn't even have any usage right not. If someone was adding an item to the tag I could find,t hen yeah it has use

[lapis wren]

Eh, not really worth it if the convention is established by other stuff

[regal bridge]

Yeah, you're right

[lapis wren]

Erm, okay. That's at least more sensible

[regal bridge]

I've had a long day today, my brain isn't 100% there 🤣

[cobalt moon]

but all the usages I can find reading the tag can just take prismarine shard directly

[lapis wren]

Not sure WTF that dust tag is doing

[regal bridge]

Honestly, I don't think prismarine should be in a tag anyway

[fervent brook]

The gem tag containing effectively a pile of crystals instead of a single gem feels a little bit strange personally, but still better than the dust one

[regal bridge]

Since IIRC you only get prismarine crystals from guardians/elder guardians; as far as I'm aware all of the other gems come from ores

[cobalt moon]

gem tag doesnt define where the gem comes from. Just that it is a gem

same way not every ingot is from smelting

oh im missing red nether bricks. Unless we want to split bricks into their own c:bricks tag

[regal bridge]

True, but ender pearls are not classed as gems despite being basically a gemstone in the same way that real pearls are

[cobalt moon]

any objections to this? If later you complain after PR is merged but never spoke up now to voice opposition, that's on you lol

[regal bridge]

It seems fine to me; I remember a few mods that add different types of water so I can see that being the same for lava and milk

Not 100% sure about the soups and stews (I'm guessing they're stew/suspicious,... and soup/beetroot?) but I suppose they work

[lapis wren]

Those ones are super necessary as since vanilla doesn't have a fluid, different mods can end up adding the same sort of fluid for those

[cobalt moon]

She is asking about foldering them

[lapis wren]

Ah, yeah

[regal bridge]

Yeah, my thought would be to folder them based on how ingots are setup

[lapis wren]

Not sure I'd folder them honestly

[cobalt moon]

bricks/bricks lol

[lapis wren]

Unless there's a root folder tag grouping all the subfolders

And then you'd have to figure out how to handle soup vs stews and we're back to that whole issue

[regal bridge]

I know a bunch of food mods add different type of soups and stews, so fluids for those would make sense too

Hooonestly, I'm fine with just calling a soup a stew

[lapis wren]

that exact discussion came up a while back

[regal bridge]

if it's for the sake of having a single parent folder

[cobalt moon]

bricks/normal bricks/nether bricks:red_nether

[lapis wren]

In this case, I feel like stews/beetroot would be confusing

[regal bridge]

¯_(ツ)_/¯

[lapis wren]

But not that big of a deal either way as long as the tags exist

[fervent brook]

Clay brick perhaps?

[cobalt moon]

inb4 someone makes a brick of just unbaked clay

[regal bridge]

that does exist

IIRC terrafirmacraft has something like that

[fervent brook]

Hmm, fair

[lapis wren]

Honestly bricks/brick seems fine in my mind. It's accurate if nothing else

"Ah yes, this brick is made of brick"

[regal bridge]

this is from the TFC+ wiki but IIRC it's also in "base" TFC itself

[cobalt moon]

stews are soups. So the 4 soup/stews would be under c:soups/ like how the food tags are setup now

[regal bridge]

sounds good to me

i don't mind which one you choose as long as they're consistent 😅

I was just thinking that there were more items named stew in vanilla

[cobalt moon]

oh wait there is no red nether brick. Just the block form.

only difference between Nether Brick and Nether Bricks is an s

not sure if keeping _stews or not is desired

[static scroll]

hot take but I think fluid tags should be singular

I see 3 pots of soup I say that's a lot of soup, I see 14 apples I say that's a lot of apples

[cobalt moon]

that's the argument that we been having with foods.

a noun can be plural without the s if uncountable. But the s is added when talking about many different types of the noun.

in terms of vanilla, they have minecraft:fishes and more uses of s/es for meaning more than oen type instead of the uncountable plural form tags.

but ngl the plural type fluid tags do feel wrong but consistency. Unless fluid tags gets exempted from this types distinction

[static scroll]

we do already diverge from vanilla tangibly so I don't think convention tags need to be completely beholdent, but they do use singular fluids

[static scroll]

I'm truthfully coming at it from the EMI perspective where seeing "fishes" makes me go "sure" and seeing "waters" would make me raise an eyebrow

[edgy folio]

I'd say that an overarching soups/stews tag to contain all of those would be justified, but mushroom stew should just be mushroom stew

since it's only one logical type of fluid, just registered by multiple mods because forge doesn't register it

[cobalt moon]

you talking fluid or item tag

[edgy folio]

fluid tag

as an extension

i'd expect "honeys" to include various special honeys like the starry honey from resourceful bees, "honey" to include only fluids that represent the contents of a vanilla honey bottle item

[cobalt moon]

I'm not sure folderizing the fluid tags makes sense tbh. When a mod checks fluid tags, they are looking for a specific kind of fluid. i can't see what behavior they would need a general soups tag for.

[regal bridge]

a mod making fluid crafting recipes for soups and stews?

[edgy folio]

what fluids are allowed in a 'soup pot' tank? idk, i do think tags representing multiple kinds of fluid are a valid concept in general

'molten metals' would be another obvious example, there's dozens of those in tcon

[cobalt moon]

so 1. soup/mushroom
or 2. soup/mushroom_stew
or just 3. soup alongside mushroom_stew

[edgy folio]

i think alongside is fine, we don't need an elaborate folder structure...

[regal bridge]

shrug, i think consistency is better for tags which describe an "is-a" relationship

[cobalt moon]

you two, fight it out lol. Imma eat lunch

[edgy folio]

except on the other hand, molten_metals/iron could be useful because some mods infer relationships between tags based on sharing the same name [i haven't seen anything that does so for molten metals, but e.g. industrial foregoing has a machine to process ores/X into dusts/X]

[regal bridge]

one thought i had was a mod using something like create mixers to make fluid-based soup crafting, where you put in a bunch of items to craft soups in multiple steps

i can see the folder structure being potentially useful in that case

[lapis wren]

Tags name different kinds of things, not different things - and in English that means always making it plural

I'd argue fluids should be the same

"honeys" or "waters" or "lavas" is correct because it's different kinds of water, not just a bunch of water

If I have, I don't know, salt water and swamp water and sugar water, I have multiple waters

It's the same reason for stones instead of stone

[regal bridge]

yeah and with lavas too you could have silicate lavas, felsic lavas and so on

(they have different flowing characteristics and solidify into different types of rocks, and they're all a little bit intertwined)

[lapis wren]

Exactly. With any of these the whole point of a tag is that it holds multiple types of stuff

[cobalt moon]

I encourage you to go to the fabric discord/fabric unify tag pr and ask for plural fluid tags there. I have a feeling it's not going to go well to ask them to do c:waters/c:lavas. or maybe I'm wrong and they want that.

I'm taking a break for now

[glass hull]

i put this on the gh repo Neoforge#274 but it was suggested on another discord i say it in here. armor and tool convention should match all the other material forms (form/type), armors/slot/material tools/type/material. eg, armors/leggings/leather, tools/pickaxes/iron.

[cobalt moon]

but the armor and tool tags arent material based

they are about the categories. Not materials

if you are asking for materials for these tags, there's multiple problems.

1. nested folders would be an uphill battle. Took a bit to get fabric folks onboard with folder in first place. nest folders would be an uphill battle for both loaders.

2. i don't see the benefit.

like, leggings/iron tag doesn't relaly help as you would just check for iron leggings directly since that would just only hold iron leggings anyway. Chains is different

makes more sense to have tags on the types like leggings type itself.

curious tho, is there a reason you thought these tags were material based?

[glass hull]

i actually was looking at the wrong repo when i thought they were material based. however i think they should be material based

and at least back when we had oredict, plenty of mods added their own variations of leggingsIron, or whatever. one of mine for example adds its own variation of leather armor

er no i was right, i dont think i said they are presently material based? sorry its freezing here having trouble thinking

maybe my memory is wrong but i swear we used to have slotMaterial oredicts in base forge

hrm. looked at old forge src appears we did not have those in base forge. maybe it was in gregtech or something, i played that a lot back then

anyway. the actual use case i have is my mod adds a set of leather-type armor that can be used directly as an alternative for leather armor, including in recipes. without tags, the only way to ensure it works for all recipes is hackily modifying the recipemanager

i would also settle for armors/form/armormaterial as opposed to literal material

which may also be more useful

for ex, a recipe requires an iron-level axe

[brittle spear]

that seems rather oddly specific

how many mods add recipes that would want to use an iron-level axe? is that the harvest level specifically, or how do you chose what level to put a tool in?

[glass hull]

tier

tho i guess that would be a case for a custom recipe type

[cobalt moon]

If armor, you use ArmorMaterial in code to get the material

[glass hull]

that doesn't help me with vanilla or mod-added recipes

and making my item compatible with them

[cobalt moon]

I’m gonna be honest

This doesn’t sound like tag convention

This is going onto functional tags

Because if you mark an tool as iron level by tag, you would expect said tag to make it act iron level

But that’s not what happens

I don’t have the code in front of me but I’m sure you define the tool’s strength in code somewhere

So you would need to unhook that and make it tag based for the tag to make sense. Otherwise you get people putting tools made of iron into the tag but not actually iron level harvest ability

Thus breaking your use case

This is an entirely separate can of worms that unifying tag pr shouldn’t touch

[glass hull]

well hold on. we have storage_blocks/gold

[cobalt moon]

That doesn’t control any behavior

Not same thing

[glass hull]

i'm not talking about controling behavior

[cobalt moon]

Doesn’t matter

[glass hull]

leggings/iron tag doesn't relaly help as you would just check for iron leggings directly since that would just only hold iron leggings anyway

how is storage blocks any different?

[cobalt moon]

pickaxe/iron item tag sounds like pickaxes that would work with minecraft:mineables/pickaxe_iron block tag

[cobalt moon]

Storage blocks is just categorizing blocks made of a specific ingredient and can be reversed back to that ingredient

It has no functionality tied to it.

This pickaxe iron is far too close to the mineable tags and would confused people

And lies to people about the tier level

Because the tags aren’t the tier levels

Ok mineables doesn’t state tier just pickaxe. I know somewhere mentions tier levels but I still prefer no tags for tiers since the tags doesn’t control the tiers. I’ll let other say their thoughts about it but I prefer that be done outside the tag convention pr in its own pr (not made by me)

[glass hull]

tier is defined when creatign the item ie new PickaxeItem(Tiers.IRON...

likewise armor

[cobalt moon]

https://github.com/misode/mcmeta/blob/data-json/data/minecraft/tags/blocks/needs_diamond_tool.json

[glass hull]

tho they use diff enums

i see what ur saying

[barren sand]

I think "elemental" damage type tags could be useful and 1.19.4 already introduced like 3 elemental tags (is_fire, is_freezing, is_lightning).
That way mods could make their mobs weak or immune against specific damage types.

[cobalt moon]

Look at @uneven nova’s damage type pr

There’s tags in there that will have some functionality attached to it so it’s going to be under neoforge namespace

https://github.com/neoforged/NeoForge/pull/59

Unless shadow is fine with some damage type tags being duplicated into c namespace but his pr only reads the neoforge namespaced ones

[cobalt moon]

I asked in fabric discord and no replies about common damage type. Vanilla's seems to be good enough and there's no burning desire for more. Sorry

[hazy wind]

how about a incorporeal or non-material tag for items and blocks that are not made of matter

[cobalt moon]

sounds wildly niche

[olive mango]

like cloud blocks?

[west juniper]

that seems incredibly mod-specific

what vanilla items would even go there?

IMO, it makes no sense to have a standard definition for a tag for which vanilla doesn't have items, unless it's extremely common for mods to add those items

[olive mango]

yeah I don't know

[hazy wind]

experience is likely not made of matter so bottles of enchanting would probably count

[west juniper]

but the bottle is glass

in any case

"probably"

do you have a use case for this?

or are you just thinking possible tags that you don't actually care about?

[hazy wind]

a bottle of tomato sauce is still food, even though the bottle isn't

[west juniper]

irl, I'd argue not -- it contains food but isn't just "food"
but in mc we have cases of things that are in containers and are food (like stew), so I have to accept that the container doesn't matter and the tags are the content

[cobalt moon]

Point is, intangible or non-matter tag has no use or likely too niche

Can’t see mods or pack makers actually using it for anything

[hazy wind]

and for the use case if a mod adds a particle accelerator it problaly shouldn't accept a item that isn't even made from matter as that would break physics

a machine that breaks down items into the quarks making up their atoms shouldn't accept items not made from matter

a machine reacting reacting antimatter with items to produce energy shouldn't accept items not made from matter as they couldn't react with the antimatter

[cobalt moon]

How many of said mods actually exist right now and would like said tag

[lapis wren]

"what's matter" is... just so iffy with vanilla stuff that that's something those mods would have to figure out anyways

Cause, like, I don't think it's the place of neoforge/fabric/whatever to dictate that "experience is not matter" - if some mod decides that it is and that makes sense - given that MC doesn't really have any sort of actual information about what experience is?

[alpine lagoon]

forge has always tried to dictate what should matter for devs/players

neoforge hasn't been much better in my experience

it's hardly a departure

but I do agree this seems insanely niche

to the point where I can't even think of one mod that might use it

which then just raises the question of why it should be neoforge's responsibility

[spring crane]

lol not again

[alpine lagoon]

oh I'm not allowed to give opinions relevant to the topic of conversation now?

well shit

[cobalt moon]

tslat, i don't want shitflinging or hostility here

[alpine lagoon]

it's specifically relevant and in response to luke's statement

it's a direct response to him

[cobalt moon]

this is the tag channel and i want this space to be calm

[alpine lagoon]

It was calm

until someone decided to bring it up as a point of contention

[lapis wren]

Eh, that wasn't really hostile, and it was relevant in terms of trying to avoid a problematic historic precedent

[alpine lagoon]

^

the fact that I can't even talk calmly, in direct response to someone's specific statement without being harassed

maybe some introspection is warranted

[lapis wren]

Though all things considered I think we're all in agreement about this point in regard to the issue at hand

[alpine lagoon]

too niche

way too niche

[brittle spear]

personally a tag for non-material or incorporeal is something I could totally see myself using, and I've definitely seen a handful of mods with ghostly/phantasm items that might fit

[brittle spear]

do you... have a specific use case you need this for? or is it just a what if type thing?

[lapis wren]

The question is really what vanilla stuff would unambigously go into it. If there isn't anything, it's hard to set a convention

[hazy wind]

if phantoms are spirits/ghosts or manifeststions of the players nightmares/insomnia than phantom membranes

bottles o' enchanting as it wouldn't make much sense for XP to be made out of matter

vanilla is a bit difficult as its lore is intentionally ambigous and this tag kind of depends on a item/block's lore

[cobalt moon]

I don’t agree

Phantoms are made of matter

See the problem here

We can’t agree

Taggers wont agree

And more problems will arise from said tag than it would solve

Let the modders talk to each other and they themselves roll out their own tag for things they agree on

[west juniper]

IMO phantoms are made of end-stuff, same as endermen and the end dragon

it doesn't necessarily match up with the ingame mechanics but that's my brain-lore

[floral skiff]

and there's the problem

there is no real game mechanics behind this to begin with

[lapis wren]

No game mechanic and it's impossible to make a crafting convention for it

[alpine lagoon]

I mean even if its possible

If its just gonna be a topic of debate its not common enough to include

[static scroll]

hey I just noticed, forge 1.20.1 is scrombling tag order

is that one of lex's weirdo 0 second review PRs or is neo also doing that

[west juniper]

uhh

that seems completely unrelated to this thread

[static scroll]

tag convention?

it's tag stuff

[west juniper]

that's about trying to get fabric and neo tags to be the same

as in, same filenames

[static scroll]

if neo's not doing it then no concerns, if neo is doing it I think it should stop to be similar to fabric and also better suit the goal

[west juniper]

and same contents

so your concern is that tag order may be different between fabric and neo?

[static scroll]

in vanilla and fabric, tags have meaningful order

oak planks are always first, oak logs are always first, etc

on some 1.20.1 version of forge, they're randomly scrambled inconsistently every launch

neo 47.1.81 vs forge 47.2.0

it seems like latest 1.20.1 neo does not have the scrombling and I'm not sure how to quickly test on 1.20.2 so I'll just assume it's not a problem but uh, don't pull in whatever lexforge did recently

[west juniper]

1.20.2 is fully forked

we are no longer pulling forge changes

[spring crane]

tag order was fixed recently

[west juniper]

and if someone ports something that was done first over there, we would review it with the same scrutiny as something done without prior use there

[spring crane]

in neoforge 20.2, neoforge 20.1, and in lexforge 20.1

[static scroll]

then my worries were for naught

[west juniper]

and yeah, just because something happens in lexforge but not neo, doesn't mean lex did something to cause it

it can also mean a fix was applied on neo but not (yet) forge

[static scroll]

someone had to break it at some point in forge

[west juniper]

probably years ago

before the fork

[static scroll]

nope, worked fine in 1.19.2

I am extremely mindful of tags :p

[west juniper]

then it broke during the 1.19.3/.4/1.20/.1 development cycle

[static scroll]

it was broken in 47.1.36, on 2023-07-19

actually it looks to be caused by a commit authored specifically by lex on that day

https://github.com/MinecraftForge/MinecraftForge/commit/2745531f08bf159e1346f1b69cbe757ed7e8d67b

[west juniper]

looks like it was a simple mistake

ImmutableSet preserves insertion order, but HashSet does not, so when making tags mutable again, they inadvertently lost the order

which doesn't matter to 99% of people

but it's fixed now

so this thread can return to its intended topic :P

[late atlas]

hello, just passing by to ask if there would be utility in providing an item tag which item viewers and the like can use for a "hide this item by default" (for things which are items out of necessity, but shouldn't be viewed through item viewers)

[spring crane]

This already exists

And yeah we can provide it since it's supposed to be standard, IMO

[late atlas]

[spring crane]

I think it's c:hidden_from_recipe_viewers on Fabric

[cobalt moon]

@static scroll does EMI check any tag for hiding items?

@rough edge @flat knoll same for JEI and REI. Do they check any tag for what items to hide? I just want to double check that all recipe viewers are currently checking the same specific tag or not

[flat knoll]

yes that exact tag above

all three viewer mods should be checking that iirc

[remote ledge]

just to confirm, all 3 do use the tag c:hidden_from_recipe_viewers

• JEI (id decl)
• REI
• EMI (id decl)

tbh i didnt even know this tag existed, until just now
thought to hide an ingredient had to go through each mods api and blacklist it
having this be a common convention tag, would be real handy
mods wouldnt need a soft dependency on each recipe viewer mod just to hide an ingredient

[late atlas]

looks at EMI code
consolodateTags

[late atlas]

me too

[remote ledge]

also looks like REI only checks the tag for block/item/fluid ingredients
while the others check against what ever registry type the ingredient is associated with
dont know how useful this information is though

guess common convention can provide keys for those 3 common types
others types you gotta make the TagKey yourself

[late atlas]

common common convention tags

(the first common being the 'type', like 'item', 'block', 'fluid')

[low kraken]

I 99% play forge, so it's not surprising

[static scroll]

EMI does a lot of tag stuff, don't worry about it :)

[low kraken]

shouldn't that be consolidate?

[static scroll]

I dunno, I'm not an english teachur

okay that message was a typo but it's contextually funny

[cobalt moon]

recipe viewer hidden tag added now. PR updated for 1.20.4 now
https://github.com/neoforged/NeoForge/pull/135

[cobalt moon]

c:air tag. Yay or nah? Mods would have to explicitly check for the tag tho.

Currently, if you mark you block as isAir in code, your block gets replaced by Air if the entire chunk section is made of any isAir blocks. Thus isAir is not safe for mods to used for custom air blocks.

The alternative to the tag is to patch Mc to only mark the chunk section as Air only if all blocks are Air instead of checking isAir. Which would make using isAir safe again for modded use

[west juniper]

a better question I think is, does it make sense to have an air block that is expected to be preserved? if you flag it as air, shouldn't it be assumed to be replaceable with a different air?
as opposite to a breathable, replaceable block with no collision but special purpose.
IMO, a tag makes more sense for this, but (and I expect others to disagree with this) I don't think it should be an air tag.
that said, I don't think something like c:gases/breathable or c:airlike is discoverable enough, so if it has to be c:air, while I don't like it, it is still a better option than intentionally breaking the "if all blocks are air, make the chunk section empty and discard the arrays"

[cobalt moon]

Think of modded air like Argon air that is supposed to act like air in all cases except is smothers fire next to it and can't be replaced by fire. Or Windy Air that pushes entities but otherwise, is replaceable by anything else.

The problem with vanilla is, if you set say an entire chunk section with your air and have isAir true, vanilla will assume that all positions in the chunk is vanilla Air and return only that air instead of your block. That's a bug imo as if you set an entire chunk section with Cave Air, you don't get back Cave Air when checking later.

[prime wharf]

Yeah

Which is fine

Practically speaking

None of the examples that you mentioned need support for the "full subchunk" mechanic

So I would argue that this should be considered in two different approaches:

1. What does c:air get us, functionality wise?

[cobalt moon]

mods can replace their isAir checks in code with a tag check. How long it takes for mods to make that switch would have to be seen

[prime wharf]

2. Patch the subchunk logic seperately

But what does this get you?

From a consumer of the isAir check currently()

You could reasonably assume that isAir() == c:air

Could you not?

[cobalt moon]

Like what any other tag do? Lets other mods know they have an actual air-intended block and can do their behaviors for it

[prime wharf]

I would argue the other way around

I would potentially argue the other way around

Instead of introducing c:air

We should add a method isDefault()

Which then is checked in the subchunk

Because that is the only exceptional behaviour

[cobalt moon]

For reference in LevelChunkSection

And in LevelChunk, it then checks the hasOnlyAir method and if true, returns AIR

[prime wharf]

Then you should possibly introduce an "isEmpty" method

And then fix it there

[cobalt moon]

Wouldn't it make more sence to just swap the isAir check with .is(Blocks.AIR) and keep hasOnlyAir which now means vanilla Air like it should be? Adding isEmpty and patching all the hasOnlyAir calls to isEmpty would be a significantly bigger patch

[lapis wren]

Does vanilla have more than one isAir block? Because if so suddenly this change has a change in how vanilla chunk sections behave and quite possibly a (minor) performance impact. Something something cave air in large underground caves?

[fervent brook]

Air, cave air and void air.

Wonder if that may be worth a bug report to vanilla? May be a viable report if e.g. some datapack could use different types of air for some sort of logic but then that doesn't work in The End void or whatever since it's not saved I guess?

[cobalt moon]

Cave air is only in ravines and certain vanilla structures. No area large enough of entirely Cave Air so you would not get any performance impact realistically.

[lapis wren]

Alright, fair enough. Where's void air used?

Ah, stuff that's out of range

Is cave air not used in, well, caves?

[cobalt moon]

for positions outside would build height. Top of nether iirc. Might be replaced by AIR due to vanilla's logic

Noise caves do not place Cave Air

only carvers do. And ravine is the only carver left in overworld

[lapis wren]

Huh, funky

[lapis wren]

Let's check the nether ceiling bit, cause that would be a real issue if you made this change and those chunk sections started taking up more memory, cause there's a lot of them. But otherwise, seems like it would be minor enough that you could go with patching the isAir check to use some new method instead

[cobalt moon]

nether roof is turned into air

it replaced void air. Might as well just patch the void air calls to just be AIR lmao

actually, void air started after 256

so 128 to 256 in nether is already air

[errant quest]

Iirc cave air is also used for cave structures that want to place air

[cobalt moon]

ik. strongholds and mineshafts due to legacy reasons

and dungeons.

[errant quest]

Yeah, mineshafts for sure

I saw it once during a palette corruption

Or well

On a screenshare

[cobalt moon]

https://github.com/neoforged/NeoForge/pull/471

[lapis wren]

To avoid weird edge cases we haven't thought of, can we:

• add a new method for whether or not a block is replaceable by air to compress chunks
• make chunk sections use that
• make the vanilla cave/void air blocks have that property

[cobalt moon]

effort!

[lapis wren]

Yeah but I don't want to discover down the road that someone was filling massive areas with cave air for some weird datapack use or whatever, that they expected to get recompressed later but never did...

[cobalt moon]

why dont they just use regular air then?

[lapis wren]

There's just too many potential edge cases when changing vanilla behavior

[lapis wren]

No clue, it was a made up example. My point is that we shouldn't make assumptions about how people use this vanilla behavior

[cobalt moon]

that's what I dont get. If it always goes from desire block -> Air, then any use case you had for the desired block is lost.

[errant quest]

I don't like the idea of changing Vanilla behavior

For the tag, I think c:gas would be better than c:air

[cobalt moon]

what do i do, IBlockExtension/IBlockStateExtension? Trying to remmeber where stuff is

[lapis wren]

Yes, but they may be placing large amounts of it anyways (why does cave air currently exist?)

Changing vanilla behavior is iffy

[cobalt moon]

cave air used to be a way to know if in caves

then cave overhaul came in and added noise caves with Air

so anyone still looking for cave air is now broken

[lapis wren]

The former i think? Though honestly I'm still in favor of a tag over changing this behavior around, but that requires getting mods to use the tag instead of the check which is iffy so... no clean solutions I guess

[lapis wren]

Those mean different things in terms of what people tend to think of when they think of it

[cobalt moon]

method added now

No idea how I would even PR this to Fabric given they don't do extensions iirc

[errant quest]

They have some

[lapis wren]

Add something to FabricBlockSettings or whatever it's called and store in the the block properties?

Though this whole solution is a more invasive change than they might like, so no clue, you'd have to see

[uneven nova]

Is that tracked on mojira? Seems like something they might care about

[cobalt moon]

https://bugs.mojang.com/browse/MC-232360

best I can find

[low kraken]

looks good enough imo

[errant quest]

Tbh you could just do this solution

[cobalt moon]

Issues/PRs to neo for Vanilla issues generally should have a link to the jira report which is what Shadow was basically asking for

[low kraken]

and a comment on the patch iirc

but the current comment should be enough

[cobalt moon]

in this case, we are not fixing the vanilla blocks so no bug was fixed within vanilla itself. Just making it safe for modded

[low kraken]

yeah, but once the vanilla bug is fixed, the patch might not be needed anymore

[west juniper]

I'm surprised it wasn't just closed as "works as intended" tbh

I get why mods might want to have custom air

but for vanilla purposes there is no reason not to erase the cave/void air, when they serve no purpose and doing so makes saves smaller (sometimes, slightly)

[cobalt moon]

How do you reference jira links in patches. Just #232360 ?

[west juniper]

// Neo: Fix MC-232360 for modded blocks or whatever

[cobalt moon]

check out the parrot spawner issue report

https://bugs.mojang.com/browse/MC-232359

[prime wharf]

Yep

[cobalt moon]

you want to have space turn off parrot spawning by filling with cave air? nope. Too much space and it becomes air and parrots spawn

[west juniper]

ew, now that seems like a bug

[cobalt moon]

wait, uppercase or lowercase neo?

[west juniper]

whatever the convention was

can't remember

[cobalt moon]

NEO, NEo, NeO, nEO, Neo, nEo, neO, neo

[prime wharf]

It really does not matter

Pick one that you like

The only real convention is that if it is something like a TODO

Then the comment needs to start with //TODO

So that the IDEs can detect it

[west juniper]

I'd say there's enough precedent of it being Neo to keep doing that

[prime wharf]

Seems reasonable

[west juniper]

found one that is different case, and it's NEO :P

[low kraken]

just gotta have a random non air block in each chunk section

[edgy folio]

empty wall blocks

of course then people can't build there either

[bold hull]

do light blocks have a 0 light level option?

[floral skiff]

according to the wiki, yes

https://minecraft.wiki/w/Light_Block

[low kraken]

at that point, just use a structure void

[bold hull]

those have hitboxes tho

[cobalt moon]

^

[low kraken]

ah, right

[cobalt moon]

anyway, pr made. Now updoot it

or die a doot death

[late atlas]

and that's the one which I wrote

[cobalt moon]

pr a fix!

Whole ass pr to adjust casing in a comment

Totally will fly

[low kraken]

make two prs, one for the E and one for the O

[stuck loom]

What about a block and item tag for infested blocks (Tele should know why )?

[cobalt moon]

There hasn’t been any other request for the infested blocks so I’m assuming people are doing instanceof checks instead?

[stuck loom]

That's fair, yeah, and should be sufficient for my use case as well. Never mind me then 😄

[cobalt moon]

https://github.com/VazkiiMods/Botania/issues/4502
c:workbenches?
are workbenches only crafting tables? Would stonecutter or loom count?

[bold hull]

I thnk its only crafting tables (source: https://minecraft.wiki/w/Workbench redirects to https://minecraft.wiki/w/Crafting_Table)

based on other google results workbench and crafting table are commonly interchangeable

[cobalt moon]

should it then just be called c:crafting_tables to reduce confusion?

[bold hull]

yeah, being more explicit is good

[cobalt moon]

To recap some discussion from fabric:

there will be a crafting_tables and furnaces and campfires tag as there’s many mods with variations of these. Some want to expand this to include loom, enchanting table, grindstone, smithing table, etc.

Issue is there’s so many of these blocks that we would prefer to stick them under a parent tag or two for organization. No mention of workbench or workstation as those gets confused with villager job sites

some ideas:

c:crafting_based/
c:burning_based/
c:enchanting_based/

Loom would be under crafting. You craft new banners. Grindstone under enchanting maybe as it removes enchantments

Or are we over complicating this

Vanilla tags can be viewed here. They already covered anvil: https://github.com/misode/mcmeta/tree/data-json/data/minecraft/tags

[primal quarry]

I wouldn't do subgroups just one group for all

[spring crane]

if there's doubt I'm also happy to have less tags

[cobalt moon]

Wdym? Just c:crafting_tables c:furnaces and no folder?

[errant quest]

I think c:crafting/crafting_tables, c:crafting/furnaces, etc.

[reef charm]

I wouldn't say crafting

At most tools or machines or something else in English

A furnace arguably doesn't craft

It smelts

[cobalt moon]

If just one folder, what name should it be then? That’s the tricky part lol

[spring crane]

c:crafting_tables etc sounds good to me

[reef charm]

machinery?

[cobalt moon]

Craft tables as machines?

Aren’t you doing the crafting there by hand

[reef charm]

if I don't see the physical animation, it's not by hand /j

[errant quest]

It uses crafting recipes though

Though arguably those can just be called "recipes"

[olive mango]

recipe_machinery maybe?

[cobalt moon]

Wouldn’t cover loom or grindstone or enchanting table. But maybe those are fine to ignore

Just only furnace and crafting table tags as those have the most modded variety

[primal quarry]

if there weren't the possible confusion with villagers I'd say workstation

[reef charm]

workstations_but_not_villagers

[floral skiff]

but some of those are also villager workstations (smokers, blast furnaces, smithing tables)

what about crafting_stations

[cobalt moon]

Furnace?

[floral skiff]

recipe_processors

idfk

[cobalt moon]

c:recipe_based/
And anything not recipe based would have to be handled by mods on a case by case basis as not many people are going to make loom variants or enchanting table variants and stuff

[errant quest]

menus_that_arent_containers /j

[floral skiff]

eh, no

[reef charm]

has_recipes

[floral skiff]

the crafting table isn't a container either

[errant quest]

That's my point

It's not a container

But it has a menu

[olive mango]

recipe_blocks maybe?

[cobalt moon]

has_recipes sounds good to me

Unless someone reads that as if the block itself has a recipe rather than it processes recipes

[reef charm]

Everything has a recipe pretty much

It would be a very useless tag

[primal quarry]

but the furnace is a container but should be in the same grouped tag

[errant quest]

True

[edgy folio]

i think the main use of a crafting table tag is in recipes that craft something using a crafting table, and for things like 'crafting table that's made of an alternate material or specific wood type' and maybe things like the tinker's crafting station.

there's a similar case for mods that add furnaces made of different types of stone... tags that might contain more than one vanilla block seem less useful, though. Even campfires.

[a campfire tag might be useful if some mod wanted to make separate campfire blocks crafted with charcoal vs coal, or with specific log types, though. That would not include the soul campfire.]

[well, the soul campfire is actually something i can see being a contentious issue, considering it executes the same vanilla recipes but at least one prominent mod, create, treats it as being different]

[regal bridge]

I think that crafting tables, furnaces, campfires and so on are different enough that they should have different tags with no common parent. If I want a crafting table, regardless of material, I don't want a furnace, and I imagine most other modders would have the same view.

agh, ping T_T

To clarify, I definitely think we should have something like c:crafting_tables and c:furnaces but we should hold off on something like c:crafting_stations/crafting_table or c:crafting_stations/furnace until somebody gives a compelling use case for multiple mods to have it (rather than just a mymod:crafting_stations containing c:crafting_tables and so on)

[cobalt moon]

was just gonna do c:has_recipes/ and only add furance and crafting table by default

[primal quarry]

you'd need to add smoker, blast furnace, campfire and stonecutter too as they also use the recipe system

[cobalt moon]

i'll leave those out as there's not enough modded variants that i can find of them

mods can add to the folder too if they need to

[edgy folio]

....eh, that doesn't quite feel right either. What people want is usually crafting tables, not 'anything that can execute a crafting recipe' [including, for example, the crafty crate itself]

[cobalt moon]

fight silk over it

the folder is to mainly just group furnace and crafting table together somewhere

[edgy folio]

like the use case here is 'biomes of plenty registers a whateverwood crafting table and crafts it instead of the vanilla one when you use four whateverwood planks'

[static scroll]

recipe_workstations/

[cobalt moon]

any potential confusion with villager workstations/jobsites?

recipe_workstations/ or player_workstations/ works tbh. Nice suggestion. I just need to decide which to go with later

[reef charm]

player_workstations/ if you also have villager_workstations/

[cobalt moon]

the unify pr has c:villager_job_sites tag (not folder)

i guess it comes down to how much room to leave other mods to add on their own to the folder.

If you view that the folder should only hold recipe processing blocks, recipe_workstations/

If you view the folder should allow other mods to add tags for like loom or something, player_workstations/

[reef charm]

#2

[cobalt moon]

done. Now waiting until 1.21...

[errant quest]

Guess there doesn't need to be armor tags anymore

[static scroll]

I imagine the enchantment tags are for enchantment targets

[cobalt moon]

There’s non enchanting item tags

minecraft:head_armors

Or maybe not. The snapshot page only lists enchantable

[errant quest]

There are

They're in the code

E.g.

[edgy folio]

huh is there a tag to include both helmets and pumpkins, mob heads, etc?

actually using tags to define equippability would make sense in the long run given vanilla's general trend to using tags for more stuff, but it also means attribute modifiers would have to be redesigned

[floral skiff]

not really? they'd just need to check that tag instead of the EquipmentSlot checks they currently use

[cobalt moon]

hmm are golems a worthy entity type tag? Are they very common in mods?

[lapis wren]

@ skyjay in MMD

So maybe?

I've seen a few other mods with them too

[alpine lagoon]

you know what I'd like to see is a tag for global base worldgen blocks

I run into this a bunch

for things that I want to only affect "natural" blocks but not at worldgen, and I don't wanna have to like.. try get each 'base_stone_x' tag

basically a global 'base_stone' or something

like I can't check base_stone_x for a dim I don't know exists at compiletime

[cobalt moon]

what specifically is your use case? Most people only add features to specific dimensions they are targeting because doing any can be disastrous as they ahve no idea how the dimension is setup (void terrain, cave dimension, mining dimension, water world, overworld like, floating islands, etc...

Me adds heads

Mojang: nope skulls

[alpine lagoon]

wanting to generate an ore block dynamically in a dim without knowing what the dim is?

Wanting to make a 3x3 pickaxe that only affects natural stone blocks, but make it compatible with other dims

A mob with an ability that impacts the terrain but you only want it to affect the natural terrain, etc

[civic ginkgo]

With all of these you'd probably still want it to be dimension specific. Like, some blocks might be a base_stone in one dimension but not in the other.

Like, just because some mod added a dimension that is mostly made of concrete doesn't mean a mob should suddenly start interacting with concrete in the overworld.

[cobalt moon]

^

You can still add the mod compat tags per dimension and hold it in your mod. Little more work but can be a map of dimension key to a TagKey and use that for getting which tag to check or something.

Combining all the base stone tags into one is going to have cross dimension side effects

Bumblezone is going to make you see honeycombs as terrain blocks in overworld

[civic ginkgo]

I guess having some way to get a base_stone tag for any dimension would make sense. I would have proposed doing that by name (i.e. <dimension_namespace>:base_stone_<dimension_name>), if vanilla wouldn't immediately break that by calling it minecraft:base_stone_nether and not minecraft:base_stone_the_nether.

[olive mango]

why mojang? most of them are called head xD

[coral valve]

any head eventually becomes a skull if you wait long enough

[cobalt moon]

mummies be like:

[stray ore]

every head has a skull, not every skull has a head

[lapis wren]

Cabbage

[stray ore]

[coral valve]

challenge accepted, gonna make a cabbage plant that drops cabbage skulls

[worthy mirage]

Is there like a head (disambiguation) page on Wikipedia we can check

[stray ore]

https://en.wikipedia.org/wiki/Head_(disambiguation)

[worthy mirage]

That caught me off guard lol

[coral valve]

https://people.com/thmb/6RW63s9mIGvWjQN73cpk2XIM9Aw=/1500x0/filters:no_upscale():max_bytes(150000):strip_icc():focal(749x0:751x2):format(webp)/liz-truss-head-lettuce-102022-1-15c504a7a9ed48b4967ddff98b62cdc3.jpg

[spring crane]

I made a proof of concept for what a common tag definition repo might look like

see https://github.com/CommonMC/tags/tree/main/src/main/java/org/commonmc/tags/definitions

@cobalt moon @real ravine FYI

[worn orchid]

hmm, there are 2 backend, does it directly allow generating to .json files, as needed in a datapack?

[errant quest]

That could be a good backend to make

[real ravine]

I still think the backend code should live in the repo of each project.

[errant quest]

Yeah, maybe just have the raw datapack backend built-in or something

[cobalt moon]

modloader specific code makes sense to live in the modloader repo so they can handle it and tweak it more for their stuff/api/helpers etc

[spring crane]

that is fine, the question is then of course how to depend on the common code - JSON isn't the worst option

[dawn nova]

i mean what common code would there be if each loader generates their own classes?

if each loader generates classes in their own mappings, own structure, using their own apis, in their own package, and with different field names there's no common code

[coral valve]

instead of having common code there should really just be a spec paper

[dawn nova]

(that's why i don't see the point in bothering but w/e)

[spring crane]

yes there is no code

however the spec is shared

[errant quest]

I mean, it's Java

So it could just be classpath()ed and called in a task

Could even be made to generate into the generated code directory

[cobalt moon]

Common repo generates the json of all tags and lang. Forge and neoforge has a special task like genData that reaches out and copies in the generated files and sticks it into the modloader's datagen folder?

[errant quest]

Also you were talking about golems? I think that might be a builtin tag now

Ok maybe not

[spring crane]

The reason why I generate code is because we want modders to be able to reference the tags via ConventionalXxxTags on fabric and Tags on neoforge

[cobalt moon]

Could modloaders generate the Tags code files from the tag jsons? as part of a special gradle task

[spring crane]

And because it enforces that all the registry entry references are valid as well

Not from the datapack tag files, no, since you'd lose comments

[errant quest]

Yeah, there'd be no comments

There could be a separate comments file

[worthy mirage]

Parchment???

[civic ginkgo]

Minecraft does allow comments in most json files (including tags).

[worn orchid]

i dont think its possible (or at least easy) to re-parse those into source tho ,for generated code

[civic ginkgo]

If you just put them at the top of the files (which would be the most reasonable place to put them anyways), I don't think it would be too hard?

[worn orchid]

if you use vanilla tag loading? so youd have to re-find the files?

since those comments are a side effect of lenient json parsing, right?

so get discarded as junk?

[cobalt moon]

the idea would be the common repo just sends the tags and comments in whatever format to modloaders and modloaders generate the code from that

binary for all we care

[errant quest]

Yeah, it doesn't have to be in Vanilla's json tag format

[civic ginkgo]

If the format isn't vanilla tag json files, then there should also be a modloader independent way to generate those vanilla tag json files (with comments ideally), for datapack use.

[errant quest]

Yeah, datagen code could be generated from those files (or the data could be generated directly)

[cobalt moon]

Hmmm

https://www.reddit.com/r/feedthebeast/comments/1ank3gp/whats_the_most_useless_modded_recipe_you_know_of/kpt19wc/

If people have been constantly removing shulker boxes from chests, maybe it should be a separate tag not in the c:chests tag?

[late atlas]

are shulker chests themselves crafted with chests based on the tag

[cobalt moon]

the person mispelled. They meant shulker box

[late atlas]

ah.

[west juniper]

shulker boxes really shouldn't be in a chests tag

[cobalt moon]

hmm nvm. they meant ender chest

[west juniper]

chests and shulker boxes could be in an item_containers tag, but shulker boxes shouldn't be in the chests tag because they are intrinsically different things

[cobalt moon]

the recipes are using wrong tag then. Should be using wooden chest tag

[west juniper]

oh ender chests is less clear

I assume there's no way currently to allow iron chests, but not ender chests

[cobalt moon]

c:inorganic_chests

[cobalt moon]

There's mods in 1.12.2 that is adding shulker boxes to chest ore dict wtf

[worn orchid]

This mod created to fix it doesn't know what caused it either lol
https://www.curseforge.com/minecraft/customization/shulker-oredict-removal

[glad socket]

coughs at https://github.com/Darkhax-Minecraft/Bookshelf/blob/1.12.2/src/main/java/net/darkhax/bookshelf/util/OreDictUtils.java#L406

[worn orchid]

Oh no

[glad socket]

It's the major cause of it in 1.12 afaik
People not understanding what that specific config value in Bookshelf does, so don't know to disable it
The comment on it isn't clear

[glad socket]

Likely the packs this where meant for just have Bookshelf installed

[worn orchid]

I wonder if any other mods also add it to oredict

[cobalt moon]

@lunar pond you better not be adding shulker boxes to the chest tags in newer Mc version lol. Otherwise imma make a bug report to you!

[glad socket]

Also just realised the 1.11.2 version of that code doesn't have a config value to disable it.

[cobalt moon]

If a config is made and no one is around to see it, does it exist?

[lunar pond]

Glad to see this is resurfacing again lol

[lunar pond]

It wasn't just Bookshelf doing it back then, I actually added it after seeing several others do the same, but I guess Bookshelf is probably the most widely used of those mods these days lol

[cobalt moon]

Hopefully this doesn’t carry to tags. There’s a shulker box tag that can be used instead of chests

[edgy folio]

we've had the chest discussion before [i didn't know shulker boxes were in it, but ender chests have the same problem, as do certain modded things like the mek personal chest]

people don't want to use the wooden chest tag because of various other edge cases of cheap chests [stone chests from whatever mod stoneblock uses, quark mushroom chests] but they do want something that only encompasses cheap chests that are just a chest and nothing else [iron chest wouldn't fit either]

iirc a similar issue with glass was what led to the awkwardly named 'silica glass' tag

[west juniper]

IMHO

[edgy folio]

[to exclude both tinted glass and various modded stuff like ethereal/glowing/reinforced glass]

[west juniper]

we shouldn't worry about those edge cases

[glad socket]

c:standard_chests_that_people_would_likely_use_in_crafting_recipes

[west juniper]

people can have a "cheap_chests" tag in THEIR mod, that includes wooden by default

and modpack authors can add other tags to it

[edgy folio]

i mean, ultimately the problem is you want basically everything that uses a chest - including the hopper recipe - to use such a tag for crafting

[and, yeah, maybe it's not that big a deal in most modpacks to need to farm some wood to make vanilla chests for crafting, but you could say the same for almost any tag that we change recipes to use]

[cobalt moon]

There’s ingredients where you can exclude enderchests tag from chests tag in recipes

[spring crane]

Yeah but that's really cursed

[cobalt moon]

but that's its entire point. It was added specifically for the case where you have a tag but only want some of its entries

if documentation is an issue, someone should make a neoforge doc page on it that can be given to people that ask how to use it in json/datagen

[dawn nova]

mek personal chests / barrels are especially a problem with using a chest tag in a recipe because they can store items

[olive mango]

what about containers/filled and containers/empty

[spring crane]

Just use chests/wooden for recipes

[olive mango]

that'll work

[swift hamlet]

Nah we removed them from the item tag, they are still in the block tag. Too many people were having issues

[edgy folio]

The problem with that is that there's arguably chests that should be usable in most recipes but shouldn't be 'wooden'.

[west juniper]

as I said.

[10:45]gigaherz: people can have a "cheap_chests" tag in THEIR mod, that includes wooden by default
[10:45]gigaherz: and modpack authors can add other tags to it

we don't have to cover every imaginable corner case

[edgy folio]

"what chests are appropriate for recipes for crafting things such as hoppers" is not exactly a corner case

if we're not going to do it we might as well leave it as vanilla chest only

[west juniper]

add a basic_chests or simple_chests, then

cos "chests_that_you_might_potentially_want_to_use_for_crafting_stuff_like_hoppers" is a bit too specific IMO ;P

[lunar pond]

I think fixing things data side is just kicking the can down the road. If mods moved to a new tag that has both cheap and expensive chests, the moment you try to autocraft a recipe that uses those tags you're in the same situation.

[spring crane]

Maybe chests/cheap tag then?

[coral valve]

that's as bad as glass/silicate

I feel like the solution here is to not have situations where grabby autocrafty things can greedily pull the wrong block, not make weirdly specific tags that every recipe has to use explicitly

[west juniper]

I really don't think using "cheap" is a good qualifier

[lapis wren]

chests/normal

Or even chests/boring

(/hj)

[coral valve]

case in point of something that causes the problem and what can be done to prevent the problem from existing, I have this crafting gui where you select a recipe and then it eats ingredients from your inventory when you pick up the result from the result slot

https://camo.githubusercontent.com/6b87258f39b8a6d7885045a8aeb8eec67e2a92c76475fed1590f4081ce33e282/68747470733a2f2f6375626963696e746572706f6c6174696f6e2e6e65742f696d616765732f6d6f72657265642f676174656372616674696e675f6775692e706e67

now, if one of the recipes used the chest tag for an ingredient, and you have chests and shulker boxes in your inventory, it might eat a shulker box. That's bad!

so what I want to do to improve this is, to put a 3x3 crafting grid where you can drop or shift-click ingredients to, like a regular crafting table or furnace or whatever

maybe as you add ingredients it filters the recipes on the left

and you still have to select a recipe, because clearly some recipes have the same ingredients

but once you've selected your recipe AND the explicit ingredients, then you can craft the result

this wouldn't require explictly using a dumb tag like chests/normal in my recipes, and it prevents shulker boxes from being eaten by accident

for factory automation setups with automatic crafting, you have a similar problem, but generally as a user you just want to make sure you're not dropping shulker boxes in the chest intake or whatever

[spring crane]

That's just not how autocrafting works

It's much easier to make mods use the proper tags 😉

[coral valve]

chests is a proper tag

chests/normal is stupid

if something is asking for a chest tag and eating shulker boxes from the player's backpack, that's the mod's fault. I need to change my mod.

If something is asking for a chest tag and eating shulker boxes from the player's dump stash, that's the user's fault, they shouldn't put shulker boxes in the input chest for their factory

maybe shulker box is a bad example because shulker boxes probably shouldn't be being tagged as chests in the first place

glass vs glass/silicate vs reactor glass is the usual example

[cobalt moon]

Shulker boxes aren’t in chest tag

[lapis wren]

I'd say just don't put the ender chest in the chest tag

If it's meant to be used for crafting

[primal quarry]

well if the snapshot is the first for 1.21 then we should get this ready for neoforge and fabric

[dreamy stirrup]

@cobalt moon (srry if ping bothers) since the 1.20.5-pre1 release, we might have to consider adding a tools tag as well as it is removed and replaced with breaks_decorated_pots

[worn orchid]

im guessing tools was removed because of the component

[dreamy stirrup]

nope, removed because it was only used in decorated pots

so they essentially renamed it

[dreamy stirrup]

i dont see the component at least

[remote ledge]

the tools component was added couple snapshots ago iirc
so might not appear in the 20.5-pre snowblower diffs

DataComponents.TOOL

[dreamy stirrup]

oh shii

ty for letting me know

[cobalt moon]

? There are dedicated c tool tags which means the pr must have a parent c:tools tag that contains all the sub folder entries

But otherwise, check for data component if looking for tools

[dreamy stirrup]

yh i just realised

[cobalt moon]

The c:tools tag in pr already is only for recipes

[dreamy stirrup]

sorry for bothering

[cobalt moon]

It’s alright. Though it is a good idea to check the pr itself for if a tag already exist

I need to go through it later and remove any that vanilla added now

[remote ledge]

i believe recipes can check for existence of a component and maybe also the value but unsure on that last one
so i would still say check for the tool component
at least i know loot tables have a bunch of data component lookups and modifier stuff
feel like the tag is mute now that the component exists tbh

[cobalt moon]

Pack makers

[remote ledge]

ok? pack makers can have their recipes/loot tables check if an item has the tool component, rather than tag
component imo should be preferred over the tag

[cobalt moon]

Easier to add to a tag for a recipe change than to mess with some sort of or condition check between a component and another item. Unless splitting it into multiple recipe files

What if there’s a recipe that takes tools but pack maker want it to match a non-tool? That’s where or condition comes in

[remote ledge]

check if item does not have the component

for non tool

[cobalt moon]

And anyway, the c:tools cannot be removed because it’s the parent tag of all the c:tools/

[cobalt moon]

No that’s not what I said

Tools component OR minecraft:sticks as an example

Whatever. Forget it. Tired rn

[old magnet]

Can't check components in recipe inputs

[remote ledge]

you cant? oh i thought you could, my mistake then if thats the case

[cobalt moon]

Prerelease already sigh. Stuff like meats is going to need to be removed from c in favor of mc’s

[cobalt moon]

feeling better rn. So this shouldnt be too bad since the unify PRs are for 1.21 so there's time for 1.20.5 to settle and see how things goes.

Heads up, 1.20.5 might be seen as a bigger breaking change than 1.21. Fabric might be willing to have unify in 1.20.5

More details to come if this is the path towards the weekend

[errant quest]

Btw what happened to Tech's codegen thing? Will something be done with that? Like publishing some kind of tags file that's used in a Gradle task on both Neo and Fabric to generate code

[cobalt moon]

You would have to ask @spring crane

[spring crane]

feel free to use it

I don't want to spend more time on it 😛

[errant quest]

I think some kind of unified repo that's used to generate stuff could be a good idea

[cobalt moon]

Question to neo maintainers, what branch should I merge to my tag branch to have 1.20.5 codebase?

[errant quest]

Just maybe not that one

[spring crane]

port/24w14a if you're impatient

otherwise wait for the pre branch 😛

shouldn't really matter

[cobalt moon]

Alright. I'll work on fabric side first and then neo after in case branch is ready then. Needed the 1.20.5 codebase for referencing the new vanilla tags in the code

[spring crane]

👍

[cobalt moon]

Fabric PR updated now
https://github.com/FabricMC/fabric/pull/3310

[civic ginkgo]

Why is it c:is_the_end but c:is_nether? That seems inconsistent.

[errant quest]

Aren't the dimension IDs the_end and nether? Or is that just a Bukkit thing?

[civic ginkgo]

in vanilla its minecraft:the_end, minecraft:the_nether, and minecraft:overworld. I think the tags should either have no the at all, or follow the dimension ids.

[cobalt moon]

that was what fabric had originally

i can change it

[civic ginkgo]

Ah, you just changed the in to is and kept the rest? Yeah, since it changes name anyways, I think would make sense to be consistent, since then it also establishes a standard naming scheme for modded dimensions. (or maybe they should be in their own namespace anyways?)

[cobalt moon]

there's no way to dynamically find the modded dimension tags anyway

so modders would just make their own tag under their own namespace. People who want the tag would have to explicitly grab it anyway

[civic ginkgo]

Why? ${dimension_namespace}:is_${dimension_path} would work if documented properly? But that's beside the point, if the tags are renamed anyways, then they might as well be renamed to something consistent, so they are slightly easier to find. 🤷‍♂️

[cobalt moon]

example: bumblezone my mod. The dimension is The Bumblezone. My biome tag is the_bumblezone:the_bumblezone. I really hate the_bumblezone:bumblezone for my dimension as it is not Bumblezone. It's The Bumblezone.

you wont get people to consistently keep or omit the the part

[civic ginkgo]

Well, you certainly won't if the convention tag does it for one vanilla dimension but not the other...

[cobalt moon]

That was corrected. But again, people would be explicitly grabbing the biome tags for the modded dimension. And it would be pointless anyway

since you can just grab the dimension itself in the mod and go to the biome provider and call possibleBiomes to get all the biomes in that dimension

[civic ginkgo]

Well that depends on where you use it, but doesn't really matter, just noticed the inconsistency in regard to the vanilla biomes.

[cobalt moon]

would the parent tag be enchantables or enchantable

nvm

[uneven nova]

those are vanilla tags now aren't they™️

[cobalt moon]

yep

[cobalt moon]

what?

[unkempt furnace]

Make it optional. The mace tag is only present with experiments on

[cobalt moon]

1.20.5 unify PR is ready for review
https://github.com/neoforged/NeoForge/pull/135

@spring crane How should I contact the neoforge maintainers to make sure they are on board with moving up the unify PR to 1.20.5?

[spring crane]

<@&1128776937410670663> are you on board? let's vote

[late atlas]

can't you make a poll

[spring crane]

i don't know and i don't care 😛

[late atlas]

wait, no, if we make it a poll, we can't see who voted and can't restrict it to Maintainers

for the record, what's your vote

[spring crane]

👍 but I doubt it will matter

[late atlas]

(I said it because you also have the thumbs-down -- just for avoidance of doubt)

shall we coordinate with the Fabric folk before/immediately after merging

i see merge conflicts

[cobalt moon]

I spoke to @real ravine and he was on board for 1.20.5 merge due to how giant a breaking change 1.20.5 is and how likely that 1.21 would not be breaking

[cobalt moon]

that's cause 1.20.5 branch is not in 1.20.x yet

[late atlas]

fair enough

[cobalt moon]

Once it is, the conflicts will yeet

[late atlas]

oh wait, we can see who voted in the poll

BRING ON THE POLL

[real ravine]

Yes, totally happy to do it, ideally this weekend if possible. If it becomes a rush then maybe hold off, want to make sure its done right

[cobalt moon]

i think people are just gonna click the reacts on tech's comment than use the poll lol

[errant quest]

You can see who voted on a poll

[dreamy stirrup]

I'm a full supporter of this change.

[spring crane]

why would you use a discord poll

[cobalt moon]

it's fun to click the big buttons!

[dawn nova]

why would you not

[dreamy stirrup]

exactly

[spring crane]

there's 0 benefits over standard votes that's the funniest thing 😛

[dawn nova]

let's all remind ourselves of that mod name vote in #maintenance-talk where people got confused about what emoji to use because of ordering, whereas polls are clear?

also sorry to break it to you, but polls are now standard votes 😛

also polls can either be multi option or single option, you can't vote both yes and no and then ruin it

and the author can cast their vote

so there's your >0 benefits

[west juniper]

having single answer polls that the author can themselves vote properly seems like a clear enough advantage to me

[dawn nova]

it is, tech is just afraid of change