Ultimate integration guide on how to use other mods' resources in workspace (workarounds for libraries/compatibility)

TUTORIAL: Ultimate integration/add-on guide on how to use other mods' resources within your workspace

Hello! 

I've spent my latest half of a year on searching for a ways to use various elements from other mods, and honestly, it wasn't easy to find out. My solutions are kinda cheap workarounds, probably also being too simple for some of you, but I think you can still find it useful, especially if you make library mod or try to find out "how the heck I can do compatibility with mod X without asking that guy to do 90% of work?".
As I mentioned in title, these workarounds are also limited - you won't have possibility to do everything you would want in the world. They give you a lot of possibilities if used creatively though, since you can already use them to make quite advanced addons or integrations.

❁

I want to make this topic a knowledge base for compatibilities, so anyone wanting such don't need to search, which can be tedious. I'd then suggest writing down your own workarounds and solutions - if they are related to topic and works well, I will add them to my post with respective mention of the author. I hope this list become someday sort of "community summary of guides" and will take the topic of compats/addons in complex way.

TABLE OF CONTENTS

1. Using Tags: Expanded
2. Recipes using items/blocks from different mod
3. Custom recipes from other mods
4. Creating crafting GUIs accessible by other mods
5. Placing blocks/structures/entities from other mods
6. Custom biome spawn conditions of mobs
7. Textures dependable on another mod
8. Loot Tables
9. Enchantments using Tags to determine if they can be applied
10. Enchantments ("smite-like", with custom "can be combined with" list) compatibile with modded ones
11. JER (Just Enough Resources) integration
12. Patchouli integration

1. Using Tags: Expanded 
You are probably aware of how to use Tags in general - you can enter any item from vanilla or your mod to respective Tag. But what if you want to add items/blocks/entities from other mods? Tags are made with .json format, which means they are really easy to edit!

So, let's say, you have one Tag and you want to make it use some Biomes You'll Go items? Then just edit the code of this element, and replace items you put there as a placeholder with "mod_id:name_of_item". In case of BYG, mod_id would be "byg". You can expand the elements to infinity, just remember the syntax of jsons: each elements end with comma, except for the last one.
It is really important also that you state correctly namespace (vanilla/forge/mod) before going into code, because these values aren't possible to be changed from .json code.

Important! If you want to include more than one mod in your .json, don't do this. This is unfortunately really bad limitation of .json extension, that if even *ONLY ONE* element isn't found, whole .json breaks.
So, if you want to include several mods for some feature, just make each Tag for each mod. I know it is tedious, but there's not much you can do with this, doing it on your side. Better solution is, of course, to make one Tag and ask people to include it in their mods (so nothing can break, since they provide all elements), but not all people are willing to do this, especially to small modders. My solution is then aimed on people who really wants to make it nevertheless.
___________________________
2. Recipes using items/blocks from different mod
If you want to make recipes using items/blocks from different mod, you can either make it use a Tag, or do it - personally - more comfy way, via editing .json file. For Tag method, I don't need to explain much - it is supported natively by MCreator, you just need to know the Tag. Or make it yourself (look at walkthrough above).

Editing .json is, though, much more useful, because you don't clutter your workspace with Tags for only one item each. It is pretty simple as well.
Firstly, make recipe as you would do normally. The only difference will be - use placeholder items where you imagine custom item/block appear. So for example, if you want to make staff using only specific crystal from someone else's mod, being on top of two sticks, you can make placeholder like that (I placed redstone block as placeholder, where crystal will go):

Then, when you set all elements where you want, save the recipe. Once it appears in workspace, click on "edit code" part. You will see .json file. Now the only thing you need is to replace your placeholder blocks with custom ones!
So, if you have "minecraft:redstone_block" placeholder, as in my example, you will replace it with "id_of_the_mod:name_of_the_item_or_block". For example, with "cobr:blue_crystal", if mod we want to use has "cobr" id, and it has item called "blue_crystal" we wanted to use.

This method will most probably result in log errors if mod is not loaded - don't worry though, this is totally fine and noone except server owners will even notice that.
If you want to use custom recipes from other mods, head to the next part of this tutorial.
___________________________
3. Custom recipes from other mods
Attention: this part will work only with mods using .json-based custom recipes, so MCreator mods using GUI and procedures for custom crafting will not work! 
You can still use Tags to support MCreator GUI/procedure custom crafting, but if someone don't support it, you will not be able to access it, unfortunately.

There are two ways you can access others' crafting - either by their own tutorial (like Farmer's Delight do, for example: https://github.com/vectorwing/FarmersDelight/wiki/Cooking-Pot-Recipes) or by examining .jar file of the mod (you can simply use 7zip to browse them) and finding recipe .jsons and copying their contents.
Either way, you will obtain some form of template. Now, how to use them?
Create recipe, like you would do normally in MCreator. Now, when you have its contents, do some totally random placeholders, so you can save it. With custom recipes it doesn't matter that much.
Now, when you saved it, click on "edit code" option. And instead of replacing elements, just erase all code from it. Then, paste your template we were talking about. For example, Farmer's Delight cooking pot recipe (linked above):

{
  "type": "farmersdelight:cooking",
  "ingredients": [
    {
      "item": "namespace:your_item"
    },
    {
      "tag": "namespace:your_tag"
    },
    [
      {"item": "namespace:item_variant_1"},
      {"item": "namespace:item_variant_2"}
    ]
  ],
  "result": {
    "item": "namespace:your_result"
  },
  "container": {
    "item": "namespace:your_custom_container"
  },
  "cookingtime": 200
}

The most important thing you need to know about custom recipes is their "type" - it includes their namespace (farmersdelight in this example) and type of recipe (cooking here).
Each custom recipe has different rules on how to use it, but you can look in-game through JEI how these recipes are handled and probably figure out what goes where. Usually though, recipes have quite straight-forward names for elements, so you will know what should replace which part.
Because yeah, similarly to previous compatibility part, we need to only replace elements with our own items or tags.
Remember .json syntax, of course (using "," in respective places).

For more context, this is my Farmer's Delight recipe, using tsua petals to make tasty straw ^^

{
  "type": "farmersdelight:cooking",
  "ingredients": [
    {
      "item": "wobr:tsua_petals"
    },
    [
      {"item": "minecraft:popped_chorus_fruit"},
      {"item": "minecraft:chorus_fruit"}
    ]
  ],
  "result": {
    "item": "wobr:tsua_straw"
  },
  "container": {
    "item": "minecraft:bowl"
  },
  "cookingtime": 300
}

Small hint: these "[]" brackets including popped chorus and chorus fruit mean that you can use either first or second, recipe will use either of those.

___________________________
4. Creating crafting GUIs accessible by other mods
Crafting GUIs in MCreator are working differently than in coded mods due to them not using official ways for that - this means you need to use procedures accessing them, not .jsons recipes. This limitation can be evaded with some trickery. Previously we used Tags, now we will use NBT tags - both being awesome at doing workarounds for integrations.

First, you need to decide on NBT name you will use - make it a bit specific, so it won't be repeated by other mod. It will be used for player, to indicate whether player is using this custom crafting station or not.
Now, you will need to make two procedures - first will change that NBT tag to one value, and second to another (I'd recommend logic NBT tag, so it will be either "true" or "false").
Enter your GUI menu, and set these procedures on triggers "GUI opened" (it should set NBT to true) and "GUI closed" (it should set NBT to false).

Basically, you did everything for integration - but this also can be helpful for you, because this way of making crafting "recipes" needs no buttons to make your GUI. Let me then explain how to use your GUI now (tutorial below can be used both by you and someone else).

Create procedure using global trigger "on player tick" - this way, during crafting, your table/slots will update immediately (this is why no buttons are needed). Next, you will need to specify conditions when this will take place: global triggers, especially such as player tick, can be extremely laggy and buggy without conditions. Use "if entity NBT tag (name of NBT tag I previously asked you to decide) is true". This way, as you can probably assume, you will use this procedure only when accessing your specific GUI.

And that's it! You can now use typical GUI elements, such as "if slot 1 in GUI = potato -> remove slot 1 -> set slot 5 in GUI = baked potato". It will work as you would use it on different triggers from GUI menu, but it will be less buggy due to depending on more general solution. Although...

Important notes to remember:

A. You still need to create procedure to delete input contents when item from output slot is taken.
B. You can skip this note, if you do not understand it, as not all GUIs need to care about it. If you don't want some recipes being broken, check all used GUI slots before creating the output: even if some are not used at the moment. For recipe using only part of the slots, check for unused slots if they contain "air". This way people will not use them if not necessary (and if you made procedure from note A removing all input slots, they won't lose any items).
C. If you find yourself with trouble of output item flickering in output slot, there's because it is put there in every tick.
There's simple fix for that: add another "set NBT tag to true" block after recipe is correctly placed in slots - you can name it whatever you want, I use "recipe_corr" name for it [short for recipe_correct]. Then, make additional procedures/parts of procedures if output slot is taken, or input slots are changed, or GUI is closed - let them all change this NBT tag to false, as well as clear output slots, if needed (closed GUI will not always require output slots being cleared, for example with custom smelter).
Finally, make all recipes from global procedure run only if this "recipe_corr" is false. This way, output slot will change only once, after all input items are correctly set, but global procedure will not be called anymore until you close GUI/remove contents.

^ Example on how I used this in my mod's firearm table. Slot 5 is output slot, but it only change its contents if recipe is not set yet. Then, it disables global trigger (recipe_corr is set to true) until you take any items from slots (when recipe_corr is set back to false).
Third recipe is example on how I used note B. Slot 3 isn't required to be filled, but since I always erase all slots when player takes the gun out, I made requirement that player needs to keep this slot empty (otherwise item placed there by mistake would be erased too).
___________________________
5. Placing blocks/structures/entities from other mods
This one is really simple. What you need is these mods that elements will be used, installed on Minecraft client. Go ahead and build a structure from these blocks, or make "air structure" containing entity (for use of entity). Next, when you save it with your structure block, find your structure on "saves/name_of_your_world/generated" folder. It should be called the same way you named it, just with .nbt extension.
Now! Let's go to your MCreator project. Import this .nbt file to your structures list. You can now use this as a structure which - when called - will spawn either structure, single block, or entity, if the mod you used is loaded.

Important! If you want to make it less buggy, I strongly suggest you use Mod Checker plugin (https://mcreator.net/plugin/76162/mod-checker ; for 2021.3, I included my slight remake version in comments).
Making structures/entities spawn no matter the mod is loaded can result on some unecessary log errors or even more serious issues. If you condition it to be loaded only if specific mod is loaded, it will make your mod much cleaner.
___________________________
6. Custom biome spawn conditions of mobs (by Lyof)
If you want your mod's biome to be open for someone else's addon or compatibility without code, you can set custom temperature on it, being in range between 0.0 and 2.0, using much more numbers after comma than it is shown.
For example, if you set your biome temperature to 1.6004856, there's no chance other mod will have biome with exact temperature number.
This way, other mods can spawn entities or structures conditioning it only by temperature, but since only your biome will have such specific number, these will spawn only there.

Important! MCreator won't show all numbers you write after the comma, but don't worry - they will be there. If you want to assure yourself they exist, you can see them in code (search for "temperature" element in code, it should have your temperature with additional "f" on the end)

Idea by Lyof/efanum (creator of End's Phantasm).
___________________________
7. Textures dependable on another mod
Sometimes, for some reason, you want to access someone else's texture, but the license won't allow you to do so. Good solution for this is making your texture dependent on this mod, so it will show if you have this mod installed - and it will not show, if not.
To do that, you will need to use "edit code" option for blocks. Depending on block type, it will show you different amount of .json files, but generally you can check them one by one and see which one have structure that I will write below - these are the ones we need.
Structure that we need looks like that:

{
  "parent": "block/cube",
  "textures": {
    "down": "cobr:blocks/esrah_log_top",
    "up": "cobr:blocks/esrah_log_top",
    "north": "cobr:blocks/esrah_log",
    "east": "cobr:blocks/esrah_log",
    "south": "cobr:blocks/esrah_log",
    "west": "cobr:blocks/esrah_log",
    "particle": "cobr:blocks/esrah_log_top"
  }
}

or like that:

{
  "parent": "block/outer_stairs",
  "textures": {
    "bottom": "cobr:blocks/esrah_planks",
    "top": "cobr:blocks/esrah_planks",
    "side": "cobr:blocks/esrah_planks"
  }
}

You can probably understand what this means - each "down", "up" and so on means the side of the block texture uses, and "cobr:blocks/esrah_log_top" is texture used by your mod (cobr is my one, so you will have different value, but you should recognise it from your texture files menu).
So, what do you need to do? Basically change these "cobr:blahblah" values to the ones provided by mod you want to use textures from. You need to know their mod ID and block ID to assign that correctly. Also, don't forget that all blocks need to have "blocks/" part included (look at attention part in the end of this tutorial though).
Remember that all .json files having such structure need to be changed! So if you see three .jsons with that structure (it happens with slab/stairs), then all of them have to be changed.

Small additional comment from me: if you, for some reason, want to have exclusive slab textures if they are stacked on top of each other (like smooth stone slabs in vanilla Minecraft), you need json file ending with "_full.json". This one is used for such purpose.

Attention! Sometimes folder names are a bit different, so instead of "blocks/" you will need to write simply "block/" (without s at the end), for example. I would recommend either opening .jar with mod you want have dependency and seeing that by yourself (it should be in "assets/id_of_the_mod/textures" localisation) or checking it by doing one version and playing the game - if you choose wrong path, you will see purple-black textures instead of the ones you want.
___________________________
8. Loot Tables (by The_Librarian)

Forum topic with the tutorial (click for the topic)

___________________________
9. Enchantments using Tags to determine if they can be applied (by Fofogoo & me)

Forum topic with the tutorial (click for the topic)

Code gist (1.14.4 - 1.18.2 support)

___________________________
10. Enchantments ("smite-like", with custom "can be combined with" list) compatibile with modded ones

Most enchantments don't have any restrictions for the combinations, but if they do... you probably go to enchantment element page, search for "can be combined with" element and... select all vanilla enchantments that should be allowed, right?

This - aside from being not really convenient - has also one more, much more important! disadvantage. It creates whitelist. So, the list of enchantments that can combine. Therefore, that list won't allow *any* modded enchantment to be combined with yours, if you use this element!

Fortunately for you, creating blacklist, so exact opposition of default MCreator feature, is very easy. Go to enchantment page and select enchantments in the same field I criticised. But, instead of enchantments you want for it be compatibile with - use the ones you want to be incompatibile. Save the element.

Now, yes, you guessed right, let's edit the code!
Enchantment code can look different, depending on version of Minecraft you work with, but you should see exact same patterns for each one of them. This one is for me (on version 1.15):

You see, I selected the only part of the code we are interested in: the part with name "canApplyTogether" (or something similarly sounding on newer versions, should be named similarly anyway :P)
Things you can probably realise between my code and your code is that - in case of MCreator code, it will return true for all elements starting with "if", and on the end, it will return false. This is exactly how whitelisting works! It checks if item is enchanted with these enchantments, and if it finds additional (non-listed) enchantment, it will not allow for enchantments combining.
So, if you want to reverse this - so it would only check for incompatibile enchantments - simply put false where there's true, and put true on the end (so it will always return possibility of combination, if it doesn't find any enchantments you excluded).

Done! Your enchantment now can be combined with as many modded ones as you want! ^^

___________________________
11. JER (Just Enough Resources) integration

JER recognises loot tables, so if you want your mob drops being integrated with JER, you need to create separate loot table for each mob. If you use default drop element from entity GUI, this will not work (same with procedures controlling mob drops).
___________________________
12. Patchouli integration
This one is really well-written already in Vazkii's documentation (https://vazkiimods.github.io/Patchouli/docs/intro), so I will not repeat their wiki. The only thing that I found important is where to place Patchouli book for it to appear in-game.
So, for this one you need to access your mod's directory.
You can either

• use external program to write .json files (such as Visual Studio Code) and, using 7zip or any other archive manager, open exported .jar file and put files inside, or
• write/copy-paste all .jsons into MCreator using its feature of directory managment (on upper left side of the screen you have extremely small left-right arrows - they are exactly this feature, showing you all files of the mod).

Once you did any of those steps, go specifically into location "data/your_mod_id/". Here you can drag/create your "patchouli_books" folder.

❁

Troubles with getting the book in survival? It may be because the book itself isn't registered, so it shows as regular "patchouli:guide_book" item. If you encounter such issue, don't worry, it's as simple as adding NBT tag"patchouli:book":"id_of_the_book". So, you can do it via event or recipe. Let me show you the ways:

1. If you want to give guide to player with specific action, you simply need to use this command:

/give @s patchouli:guide_book{"patchouli:book":"id_of_the_book"}

2. If you want to make it recipe-based, make recipe you want, with placeholder output (can be vanilla book, for example). Then, press "edit code".
When you enter the .json, you will see standard recipe template. Replace part starting from "result" to the end with this:

  "result": {
    "item": "patchouli:guide_book",
    "count": 1,
    "nbt": {"patchouli:book": "id_of_the_book"}
  }
}

Replace the id_of_the_book value, and voila! Your book will craft with NBT tag added during the process!
___
How to get "id_of_the_book"? Well, if you did everything like I wrote above, your id should be "name_of_the_mod:name_of_the_book_folder". But if you need to check it, just hold correct Patchouli book in your hand (you should be able to find it in creative inventory) and use command:

/data get entity @s SelectedItem

I hope I helped you and your Patchouli book will now work flawlessly with your mod!

I hope this will help you with setting some integrations to your mod(s)! Feel free to ask any questions, as well as your own ideas or links to tutorials which are not yet included here ^^