Forge tags I made for foods. 1.20.1

[shy mist]

Made for my own personal use. Thought I'd share here.

Forge tags I made for foods. 1.20.1

[indigo vapor]

i dunno if any current today mod using #forge tag. And actually, all other tags that your provided are already in game. So please, share with us, what exact mod you used for this tags? To actually test an add in the future update of course!

Maybe something is not working on forge exactly it supposed to work?

[shy mist]

When I was testing on Neoforge 1.21.1 it correctly used the provided c tags but when I was playing on my world in 1.20.1 it didn’t seem to make use of them. Once I made the correlating forge tags it worked perfectly. For example it didn’t have any compatabilty with Farmer’s Delight except for the cucumber slicing recipe with the cutting board.

Once I added the tags the rest of the recipes I expected started to work. Stuff like using green beans and cucumbers as generic vegetables for recipes that called for them and the automated cutting board recipe from Create: Slice and Dice.

[indigo vapor]

oh, good point, i will check that later. Strange, when i was testing everything was fine...

[tall scaffold]

@indigo vapor @shy mist I thought that you had tested it on 1.20.1 and confirmed that it was working correctly. This is strange!

🤔🧐

[indigo vapor]

so yeah... it was my fault. Forge using it's separate FORGE tag as a conventional tag for all the mods instead of C tag... yeah i just forgor to add it in the release 😅

[tall scaffold]

Ahh ok

Well since you already set everything up, maybe it would be better if you updated the c tags to Forge tags on the 1.20.1 version? That way I don’t mess it up

And don’t forget, my repo is public now!

[indigo vapor]

actually, it's just renaming the C folder in the data, to the forge... nothing else 😅

that's only for forge release

fabric+neo+quilt are using same C tag

[indigo vapor]

okay, i saw the issue. Some mods, do not have consent on what common tag to use for the forge loader. Forge loader always use it's own forge tag, for the common one, so a lot of mods, for the forge version, provided only wiht forge tag BUT in new version, mod loader shifted for using common tag that are use ACROSS ALL MODLOADERS the C tag

so in new versions, i think all mods are already using c tag across all the mod loaders

but in 1.20.1 yes, the farmer's delight using forge tag as common one... BUT in 1.21.1 it shifte to using C tag across all the modloaders...

so basically... for better and easier management you could o 2 things @tall scaffold

1 just copy paste the "C" folder, and just rename it "forge". Keep it across all versions? Maybe... why not? It's easy... Just a random forge folder for integrity

2 copy paste the "C" folder, rename it "forge" AND keep this folder ONLY for forge builds that are lower than 1.21.1! (less size across versions and loaders that are not using the forge tag at all, but hard to miss it, if you will do thi way. You just could forget to do it from time to time)

[tall scaffold]

I’m already using two different sets of tags— c tags on my 1.21.1 branch and forge tags on my 1.20.1 branch

Check this out

https://github.com/DawsonBodenhamer/AdorableHamsterPets-Source/tree/develop/common/src/main/resources/data/adorablehamsterpets/tags/worldgen/biome

That’s how I’m combining them so I can have the same tags on both branches

Works on 1.21.1 and 1.20.1

Gtg I’ll be back later

[indigo vapor]

oh,, you need also to go to the files and change everything from C tag there... okay i will upload the corresponding update to the github than. Including some changes from @shy mist

[indigo vapor]

great! i will make some changes! They will be in C tag also! Thanks for the reminder!

[indigo vapor]

i will also make sure, to make those changes compatible across all the versions and all the modloaders! (no need to change at all! There will be just a slightly more size for all the versions, but basically no headache for you, to change every folder name at that specific version =-=) I will also download all mods for all the modloaders for supported 1.20.1 and 1.21.1 versions to see what tag system they are using right now, and, from that point - just merger them into one super giant compatible folder...

[tall scaffold]

😱😱😱

🎉

🤌🏼🤌🏼🤌🏼

🙌🏼🙌🏼🙌🏼

Wow that’s going to be awesome!

[indigo vapor]

was busy figuring out, how the heck to install witcher mods. Still dunno, Why every mod page say different things... with it's own folder hierarchy.. but there is only one? gonna do all of the things. When i will have self spare time. That i could spend ONLY to myself

[indigo vapor]

in your public repository, there are no much recipes, only 4 of them?

you just didn't update the repository?

and in your 1.20 branch, only

i will not change any of the mod recipes/anything else then, Just only the mod compats! I were just duplicating folders, like advancement -> advancements for different version, but i will leave it up to you then. Just rename and redact all the mod compatibilities then

[indigo vapor]

i'm uploading changes, tough, i dunno why changed recipes of another mod on forge not working :__

no...

fabric issue too... i dunno what i'm doing wrong 😅

and the fabric too...

😭

[indigo vapor]

i think you need to build it first... so i could check everything else...

[indigo vapor]

yeah,, i think that's the issue... everything added just to the jar into the data folder will now work? unless you build it? But minecraft folders works somehow but not other mods? But changing recipe of your mod and minecraft works perfectly... changing?

i just checked. Recipe changing via data folder structure like this

not working at all

though, changing and checking everything via datapack works correctly

somehow, this method is... not allowed? but minecraft recipes changes perfectly... and other mods too? The issue with croptopia and farmers delight. They somehow blocking this type of changes...

[tall scaffold]

I have not yet added anything that @shy mist made to the repository

[indigo vapor]

i was telling, that in public repository, not all recipe files for your mod are showing

[tall scaffold]

Oh. That’s really weird because I basically just copy and pasted the folders that you originally created

I’m not at my office yet but I can build something for you later when I get there

But you shouldn’t have to build a mod to add data.

[indigo vapor]

yeah.. only my, of course, but there are also lot more, like bedding crafts and beds 😅 they are not in the public

[tall scaffold]

Oohhh. Yes that’s to be expected. The only stuff I’ve added is the ones that you created a while back

I’m having a little trouble with the language barrier. Could you explain exactly what is going wrong currently?

[indigo vapor]

okay, firstly. In your public repo of the mod, those are the only recipes. But they are should be more (here the full list of recipes in the mod)

the list of the recipes in your public repo

[tall scaffold]

OHHHHHHHHHHHH

Data generation

@indigo vapor 👆🏼

[indigo vapor]

OHHHHH

[tall scaffold]

Most of my recipes are created with fabric’s data generation

The public repository does not have them

Data generation is packed into the jar build process

So when I run my GitHub action which publishes the mod, it runs the build process, which depends on the data generation process

[indigo vapor]

second changing recipes of other mods (croptopia and farmers delight) not working at all (these two, that are just replacing the #c tag in the og recipe, for just cucumber - cucumber seed form that mod, cause, it's strange, why putting ANY cucumber in the crafting table, will result into acquiring ONLY the croptopia seeds)

and i can't seem to figure out why? Changing recipe of you mod this way - works perfectly. Changing vanilla recipes - works perfectly. Tags? — Seems fine

[tall scaffold]

Hmm that’s odd… I guess you’ve tried doing it via a data pack and also doing it by dropping the recipes directly into the jar file?

I would assume that both methods should work the same… 🤔

[indigo vapor]

i origignally tested this setup with datapack, and, datapacks are working fine. Maybe, something to do with priority when loaded?

[tall scaffold]

Oh I see

[indigo vapor]

yeah, and downloaded build, 3.4.0 those recipes are not working either

[tall scaffold]

I will have to look into that. I’ve never heard of a different priority when the recipes are directly in the jar file versus when they are added with a data pack

[tall scaffold]

If you downloaded something off of GitHub, the data generation process would not have run so you’ll probably run into a lot of issues

[indigo vapor]

no, from the modrinth

the released version

[tall scaffold]

Oh gotcha

[indigo vapor]

so, for now, those recipes are just not working at all. (checked the thermal expnsion, and others working fine)

[tall scaffold]

Exactly which recipes are not working at all right now?

[indigo vapor]

data/croptopia/recipe
data/farmersdelight/recipe (you don't have any recipe in that folder for now, but, i just was checking, and this folder not working too)

If you want to change any recipe from putting any
data/adorablehamsterpets/recipe
into the jar of any other mod folder, it working perfectly

maybe those mods are just hardcoding recipes? 😅

[indigo vapor]

so, changing recipes this way, of your mod, and the vanilla ones working perfectly. Something to do with those mods? I never met this type of issue before

[tall scaffold]

Seems unlikely to me, but maybe we should peek into their jar file files to see if they are?

[tall scaffold]

Yeah that is weird, your testing seems pretty thorough, which makes me think it might be a problem on their end

[indigo vapor]

or maybe... just a loading order? So, seems you mod loads last.... that's should not be an issue in fabric and neoforge... But, maybe somehow? Okay, that's really not necessary to change at all. Just 2 recipes not an issue, but very inconvenient one

[tall scaffold]

Ahhhhhh yes maybe it could be loading order… Although my mod usually comes up first in alphabetical sorting…

But yeah not a big deal if it’s just these two little recipes

[indigo vapor]

i think everything else is done. Now you don't need to change anything about the mod compat, moving different versions and different mod loaders.

[tall scaffold]

@indigo vapor here's what chatgpt says lol

[indigo vapor]

a lot of mods, including double 1.20.1 and 1.21.1 structure as well as forge tags. It's not a big size, why not?

[tall scaffold]

AWESOME

[tall scaffold]

Not sure what this means

[indigo vapor]

data/c/tags/items + data/c/tags/item + data/forge/tags/items + data/forge/tags/item

for 1.20.1 and 1.21.1 all the conventions

included in a release version

[tall scaffold]

AHh yes

I understand now

You were not asking me to do anything, you were just commenting that a lot of other mods are also doing the same thing that you're doing right now?

[indigo vapor]

of course you could manually remove unnecessary one, and decrease mod size by a little, that's up to you

[indigo vapor]

yep

[tall scaffold]

Nah, the size difference is so small, I don't think it matters. The convenience far outweighs it

Just so I understand, moving forward, the compatibility data will now be identical for both of my branches, right?

[indigo vapor]

you could check the commit and what added/fixed. Translation is on the way

[tall scaffold]

referring to this, right?

[indigo vapor]

yes

[tall scaffold]

WOW THIS IS AWESOME

AMAZING JOB

[indigo vapor]

yes, for both 1.20.1 an 1.21.1 and for all the loaders, are correct, you don't need to change anything in the mod compat sections, like changing "item" folder to "items" when moving different versions

[tall scaffold]

HELPFUL

[tall scaffold]

@indigo vapor Let me know if I missed anything!

### Added
- **Mod Compatibility Improvements** (Huge thanks to [@CasualAnimalEnjoyer](https://github.com/CasualAnimalEnjoyer)!)
  - Added conventional `c` tags for Cheese to improve cross-mod compatibility.
  - Added specific data structures and loading conditions to support the legacy Forge loader.

### Fixed
- **Data Structure & Recipes** (Thanks again [@CasualAnimalEnjoyer](https://github.com/CasualAnimalEnjoyer)!)
  - Duplicated tag folders to resolve structural differences between 1.20.1 (plural directories) and 1.21.1 (singular directories).
  - Corrected the Cloche and Insolator compatibility recipe paths for 1.20.1.
  - Fixed load conditions for Thermal Expansion integration to ensure recipes only load when the mod is present.

(no code block; formatting shown) 👇🏼👇🏼👇🏼

Added

• Mod Compatibility Improvements (Huge thanks to @CasualAnimalEnjoyer!)
  • Added conventional c tags for Cheese to improve cross-mod compatibility.
  • Added specific data structures and loading conditions to support the legacy Forge loader.

Fixed

• Data Structure & Recipes (Thanks again @CasualAnimalEnjoyer!)
  • Duplicated tag folders to resolve structural differences between 1.20.1 (plural directories) and 1.21.1 (singular directories).
  • Corrected the Cloche and Insolator compatibility recipe paths for 1.20.1.
  • Fixed load conditions for Thermal Expansion integration to ensure recipes only load when the mod is present.

[frozen coral]

Oooo

[indigo vapor]

don't forget to thank the @shy mist for the issue with forge. You could credit him alone about the forge. Of course i just looked at the config to make sure, but that was his/her idea along!

[frozen coral]

Thank you @shy mist for the Forge fix as my current long term playthrough is on forge! Appreciate you

But thank you as well Animal. Teamwork makes the dream work in these situations!

Mods in general are a community endeavour and it’s lovely to see all helping out on being able to enjoy this adorable lil hamster mod to its fullest

[tall scaffold]

OH YES HOW COULD I FORGET

thank you!

I will def add him to the README

[tall scaffold]

Ok @indigo vapor how's this?

[indigo vapor]

oh, the @shy mist just provied the forge tags. The forge loading conditions i searched because o that issue with not loading recipes, i thought that might help... but yeah.

so, forge loading conditions my idea
forge tags his/her first thought and implementation, i just reworked them a little or cross all the compat

😅

[tall scaffold]

Ok gotcha.

So I'm cherry picking the changes down to 1.20.1 and there are some conflicts

@indigo vapor Do we need alternate version of these for 1.20.1?

Should I just go in and manually tweak them to say "forge:mod_loaded" instead of "neoforge:mod_loaded" and hope they work? lol

[indigo vapor]

i've changed a structure a little, so, the forge loading condition on the top, then neo, than fabric, you put the fabric first, and then the neo, that's why there "conlicts" that re just moving code different places

everything is fine there, i double checked

maybe...

yep, those deleted lines are ok. And also or the cloche part too, where item -> id. Since, cloche is not for that version yet, but i already did the change!

oh, i see now, i firstly didn't recognized what the middle tab is doing... it's just like witcher mod conflict reviser 😅 Yeah, it's ok to leave mine. I you want, you could send files (the og and the changed one, so i could see fully side by side in my side, maybe the og file was something different)

[indigo vapor]

or this question - no. They are already 2 versions for both 1.20.1 and 1.21.1 in my commit

recipe for 1.21.1 and recipes for 1.20.1

[indigo vapor]

checked, again, and my version is fine in my commit, in that folder!

[indigo vapor]

and this one too!

[tall scaffold]

@indigo vapor Sorry, the language barrier is getting in the way here. I just want to make sure I understand you about the 1.20.1 branch specifically.

Referencing this screenshot, in the conflict window for cloche_cucumber.json:

• Left (Current 1.20.1 branch): Uses forge:mod_loaded and "id".
• Right (Your Incoming Commit from my 1.21.1 branch): Uses neoforge:mod_loaded and "item".

If I choose 'Accept Yours', it puts neoforge code into the 1.20.1 branch. Wouldn't that break the legacy Forge loader for 1.20.1?

Shouldn't I manually tweak it to keep using forge:mod_loaded and "item" for 1.20.1?

The reason i'm confused is because I was under the impression that the changes you were making would result in a situation where I could have the same files across both branches, but it seems all the recipes are formatted for 1.21.1.

Similar conflicts in all of these files

[indigo vapor]

To clarify things. I dunno how exactly cherry picking is working at all. All i see, that it tries to somehow manage 2 files into one - that is not good in this case.

If your develop file is on the right it is not correct. Why? The data -> recipes folder is for 1.20.1 and, the file structure "id" is for the 1.21.1. So mine, on the right with "item" is correct way.

Secondly, in your file on the left, first condition "forge" and the second one "forge" again, so it's not correct either. Why putting 2 same conditions in the same file?

i'd rather say "just not cherry pick, and leave my files". I dunno why currently in your "recipes" folder are ile structure with 1.21.1 "id" in the result line and double of "condition"

hope I explained this well this time. And don't forget, it's not a language barrier in my case, it's more of a brain barrier 😅 Even in my native language, people much always are having hard times understanding me. My thoughts are a very big "scene", that i could describe and perfectly portray only trough a BIG chunk of text (literature). Describing that scene in a small chunks — you don't have enough context to understand it

[tall scaffold]

I think I see where the confusion is coming from regarding Git and the versions.

To explain: My develop branch is only for Minecraft 1.21.1. My 1.20.x branch is a completely separate file structure for Minecraft 1.20.1.

When I "cherry-pick" your commit from develop to 1.20.x, it takes the exact text you wrote for 1.21.1 and tries to force it into the 1.20.1 files.

1. The Loader Issue: Your code (shown on the right side) uses neoforge:mod_loaded. If I copy ("cherry-pick") that text into the 1.20.1 branch, it will break, because the legacy Forge loader on 1.20.1 doesn't know what "neoforge" is. It requires forge:mod_loaded. You can see an example of it on the left side.
2. The Syntax Issue: You mentioned id vs item. Syntax changes between Minecraft versions. 1.20.1 requires "id" (which is what I had previously) and 1.21.1 requires "item" (your change), so copying ("cherry-picking") your 1.21.1 file directly to the 1.20.1 branch will cause the recipes to stop working.

My main question:
Did you actually launch a Minecraft 1.20.1 instance and test that these specific files (with "item" and neoforge conditions) work in-game?

I want to keep your folder restructuring (that part is great!), but I suspect I need to manually revert the syntax inside the files to match 1.20.1 standards.

[indigo vapor]

1 - in the file it has conditions for forge and for neo
"conditions": [
{
"type": "forge:mod_loaded", "modid": "thermal_expansion"
}
],
"neoforge:conditions": [
{
"type": "neoforge:mod_loaded", "modid": "thermal_expansion"
}
],
"fabric:load_conditions": [
{
"condition": "fabric:all_mods_loaded", "values": ["thermal_expansion"]
}

so, conditions for forge
neoforge conditions for neo
an fabric load conditions

[indigo vapor]

if, you are saying, that, in 1.20.1 branch, neoforge is using the forge:mod_loaded as i assume, than yes, my structure is not correct. Change for every recipe need to be made to change every
"neoforge:conditions": [ { "type": "neoforge:mod_loaded", "modid": "thermal_expansion" }
to
"neoforge:conditions": [ { "type": "forge:mod_loaded", "modid": "thermal_expansion" }

Or, just better delete the NEO forge condition entirely. I didn't know, that on 1.20.1 branch, neoforge is using legacy forge load conditions? and leaving just
"conditions": [
{
"type": "forge:mod_loaded", "modid": "thermal_expansion"
}
]

I understood you correctly in this case?
than yes, i could delete all the neo, for 1.20.1 conditions, and upload once more the fix.

[indigo vapor]

Though, the file already include
"conditions": [ { "type": "forge:mod_loaded", "modid": "thermal_expansion" } ]

so, it is loading corectly, even if
"neoforge:conditions": [ { "type": "forge:mod_loaded", "modid": "thermal_expansion" }

is not working at all on 1.20.1 branch

How we could solve this issue easily, by not using the cherry pick method. I will just also commit into the 1.20.1 branch so there would be no conflicts for that part

To do this, i need to know for now only one thing, about the loading conditions (you definitely know it's better)

So for 1.21.1 loading conditions are:

FORGE
"conditions": [ { "type": "forge:mod_loaded", "modid": "thermal_expansion" } ],

NEOFORGE
"neoforge:conditions": [ { "type": "neoforge:mod_loaded", "modid": "thermal_expansion" } ],

FABRIC
"fabric:load_conditions": [ { "condition": "fabric:all_mods_loaded", "values": ["thermal_expansion"] }

For 1.20.1 loading conditions are:

FORGE + NEOFORGE (cause, neo on 1.20.1 is using legacy forge conditions)
"conditions": [ { "type": "forge:mod_loaded", "modid": "thermal_expansion" } ],

FABRIC
"fabric:load_conditions": [ { "condition": "fabric:all_mods_loaded", "values": ["thermal_expansion"] }

Why it's showing you (on the left, where the local changes) the same "type": "forge:mod_loaded", "modid": "thermal_expansion" line two times? There is no file that double that line at all :__ i definitely don't know how cherry picking is working in this case...

[indigo vapor]

For the 2 part.
Shouldn't it be the other way around?
1.20.1 - is using item
1.21.1 - is using id

For this part, actually, i checked the folders side by side, what is in the development + 1.20.1 branch

So, in the cloche version, it's using id incorrectly of course! There should be item for 1.20.1 branch!

(double checked by downloading the original immersive engineering and checking recipes structure!)

That's why it was confusing at first. It was incorrectly using id for the 1.20.1 branch! That's why commit description says "+fixed incorrect compat recipe in 1.20.1 for cloche+insolator (id -> item)" (so everything is perfect regarding this part)

and once again, i could easily upload to the 1.20.1 branch, if you tell me more about the loading conditions.

For the id and item part i think we solved this. I initially forgot that there was an issue for 1.20.1, that's why i didn't tell you about that at first

if there were some more cherry picking "conflicts" regarding item / id part, please tell me about them, maybe i missed something!

[tall scaffold]

Thanks for pointing that out. It looks like you've actually discovered a redundant duplicate "conditions" block.

It does not need to look like this:

  "conditions": [
    {
      "type": "forge:mod_loaded", "modid": "immersiveengineering"
    }
  ],
  "conditions": [
    {
      "type": "forge:mod_loaded", "modid": "immersiveengineering"
    }
  ],

Instead, it should look like this on 1.21.1 👇🏼

  "neoforge:conditions": [
    {
      "type": "neoforge:mod_loaded", "modid": "immersiveengineering"
    }
  ],

And it should look like this on 1.20.1 👇🏼

  "conditions": [
    {
      "type": "forge:mod_loaded", "modid": "immersiveengineering"
    }
  ],

(fabric load conditions stay the same on 1.21.1 and 1.20.1, like this 👇🏼)

  "fabric:load_conditions": [
    {
      "condition": "fabric:all_mods_loaded", "values": ["immersiveengineering"]
    }
  ],

[indigo vapor]

about this code block

And it should look like this on 1.20.1 👇🏼

"conditions": [ { "type": "forge:mod_loaded", "modid": "immersiveengineering" } ],

it's true, that on 1.20.1 neoforge is using legacy forge loading conditions?

[tall scaffold]

You're correct, 1.20.1 is supposed to be using item, and 1.12.1 is supposed to be using id.

[tall scaffold]

so you would be correct if you said that "these are backwards"

You're right— let's not cherry pick these changes.

[tall scaffold]

I love your idea of submitting another commit via GitHub for the 1.20.1 branch

I think that would keep things a lot more simple rather than me trying to interpret your work

[indigo vapor]

on the left, should be as on the right

[tall scaffold]

that way, you can test out all the tags/recipes on 1.20.1 to confirm if they work, And all I need to do is accept your pull request via Github and we're done!

I'll abort the cherry pick

[indigo vapor]

i'll make some changes and will commit to main and 1.20.1 branches! the moment till i fix the discord and other sites

[tall scaffold]

Since I aborted the commit, here's what we currently have in the 1.20.1 branch of Adorable Hamster Pets

Where did these files come from? They came from here:

👆🏼 this is what you made

[indigo vapor]

i'll do the 1.20.1 branch commit a litlle later today

[tall scaffold]

Awesome

[indigo vapor]

everything is uploaded!

i checked, and everything should be fine + similiral across those 2 branches but MAYBE it could be some differences here and there (unintentinal)

[tall scaffold]

THANK YOU!

[indigo vapor]

working on translations now.

[tall scaffold]

does this look right?

11 files?

Just double checking

[tall scaffold]

Awesome! I still plan to get to your questions in #🗺️・translations but I am waiting until I actually have time to fix the issues you pointed out

I'm leaving them "unread" until then to remind myself

and I have a seperate note as well

Also, I had to do a force push on the develop branch so keep in mind that your fork is most likely outdated now; you might need to hard reset your fork based on the remote repo

[indigo vapor]

Could you ping me after all the work on the new update? So i will check if the structure for compat stays the same

[tall scaffold]

I did not touch any of your edits that you submitted in your pull request to the develop branch.

So they should all still be exactly the same as when you submitted the pull request

[indigo vapor]

ah, just understood what do yo mean. Ha, i was just very busy it didin't read tht properly. Don't need to be worry! was forking consttly at that day... ha, cause i could not figure out HOW to chang branch with github desktop... yeah... So was eleting and forking gain, so it's a very high chance that i used the correct version at that time. Of cousee i also checked configs again as well!

[indigo vapor]

better was to not writhe that stupid paragraph and just say "okay got you". I like to describe things, that nobody could unserstand :__ my proffesional skill 😅

[tall scaffold]

I’m pretty similar, sometimes I get in a mood where I want to explain everything in great detail 🤣

[tall scaffold]

@indigo vapor have you seen this?

I've been so busy I have not had time to check it out until now, but it's been there ever since I accepted your pull request on Github

I'm seeing this log output on 1.21.1, but I haven't checked 1.20.1 yet

[indigo vapor]

yeah... totally missed that with the last commit. The problem is in the comma in the last line of each of those...

{
"replace": false,
"values": [
"#c:crops/cucumber",
"#c:crops/greenbean", <--- this one, it should not be here 😅
]
}

Do i need to commit again with changed files 1.21.1 and 1.20.1 branch tomorrow?

[tall scaffold]

actually if it's just a single extra comma, I think I can handle that myself lol

thanks for the info!

[indigo vapor]

yeah, just a single comma. But it working even without those files! (cause main files are in the folders. Those jsons' are pointing to the folders. Folder files are fine). Those extra files outside the folders crops/vegetables etc called the same are for some specific mods that didn't thought of using folders at all, something between those lines

[tall scaffold]

Is it just the five files in this screenshot? Or are there extra commas in other files?

[indigo vapor]

crops/vegetables in c/tags/item c/tags/items forge/tags/item forge/tags/items

totally... 8 files

[tall scaffold]

Do you know if these extra commas also exist on the 1.20.1 version, or is that one ok?

[indigo vapor]

both 1.21.1 and 1.20.1 branch 😅

[tall scaffold]

Ok no prob

[indigo vapor]

Oh, i think the commit to the 1.20.1 branch got lost during the changes? Or it was not updated on the github?

[tall scaffold]

I've got it right here

not sure what GitHub looks like because I've done git push --force several times lol

[indigo vapor]

okie, github just don't show that i've commited at all. goood 😅 maybe my vpn or smth

[tall scaffold]

ehhh it's probably me wiping the history

llol

maybe

idk, I don't fully understand Git yet 😂

[indigo vapor]

prob my "vpn" that "unlocks" sites and "locks" others, lol. Still need another one for crowdin, so, opening another browser 😅

[tall scaffold]

ahhh

[indigo vapor]

yeah, internet providers are a mess here

[tall scaffold]

ohhhhhh yeah