MFMods

find furnace.json in the treeview on the side of your ide (/assets/minecraft/models/block/furnace.json). start there.

https://github.com/TheGreyGhost/MinecraftByExample and for your sake (and the sake of unsuspecting players), do not watch youtube tutorials (unless the guy is called mcjty, in which case by all means, do watch those). authors of those videos (aside from that one exception) WILL teach you wrong ways to do everything.

sorry, we need way more info than that. how do you launch the game? launcher that came with the game or some external launcher? which version of the game? could you launch a game without mods before preparing a modded instance? can you do that now? after you answer these, we may need logs, but i suspect we won't. please start with answering questions above...

1) run the game in debug mode. 2) make an item on an anvil (in-game, using books) in creative mode. 3) then toss it (Q key, just drop it). 4) then catch that with a break point in an event: @SubscribeEvent public static void OnItemToss(ItemTossEvent event) { sys.out.println("breakpoint here"); } 5) then examine the tag record inside the item object. all of the enchantment data is inside the NBT tag structure. you need to replicate what you see when creating an output itemstack in your recipe.

look, this isn't a new question to be answered. tech mods exist. old, established tech mods. and in them, one ingot is 144mb. so what choice do you have? choice "a": ingot is 144mb, block is 9x that much, somewhat more than fits in a bucket. choice "b": you make it configurable, and then users set it to choice "a" so there wouldn't be a magical fluid creation loop. it doesn't necessarily have to be 144mb. some other value is possible if all overlapping mods (within a pack) make it configurable. but i assure you no one will set the option to 111mb or 111.11mb

well spiders can do it, so apparently yes. look for net.minecraft.entity.monster.SpiderEntity class. ladders code may (or may not be) a wrong place to look because it relies on player being inside the block area.

make a desaturated texture (find vanilla grass (small grass shrub not the grass cube) ). call Minecraft.getInstance().getBlockColors().register(...) in your client proxy. inside make an anonymous IBlockColor that calls BiomeColors.getGrassColor or BiomeColors.getFoliageColor.

several things. there are several tutorials for setting up the environment, start with one... https://cadiboo.github.io/tutorials/1.15.2/forge/ https://www.youtube.com/watch?v=DgY6kKf5rGU&list=PLmaTwVFUUXiBKYYSyrv_uPPoPZtEsCBVJ then try https://github.com/TheGreyGhost/MinecraftByExample

it's hard to answer without knowing what you need, but maybe you are yet to determine what you need... try this: respond to "join world" event; if the entity that fired event is a player, do your stuff and leave a simple signature in player's extra data (nbt). check for that signature at the start of "join world" event handler and don't do anything if it's not the first time for player to join. things to note: 1) the event mentioned above fires for every player on the server instance and on any number of client instances. you may want to check whether world is remote (meaning client). 2) your signature (if it's a nbt string) needs to be below "persisted_nbt_tag" so that you wouldn't need to handle player "clone" event and copy the signature (i haven't checked whether that's still a thing in 1.15, but i'm willing to bet it is). give it a try. if it's too early for you, there are ways of delaying things for a few seconds...

Three events are of interest to you - player death event (LivingDeath), PlayerDrops event and player Clone event. First two trigger when player's avatar dies - player looks at the death message and the respawn button button. Items are scattered all over the death site. Then - maybe 5 seconds later - player clicks the respawn button. Then the Clone event fires - data is transfered from old (dead) player instance to a freshly created one. Be sure to note the (possibly) long delay between items being scattered and the new instance of the player being created (yes, the game will create a new player object. do not fight that). First event - Living death can be used to remember in which slot each item was. Second event - drops - has a "drops" collection - a list of ItemStacks that the dead player is about to drop dropped. You need to put them back into his inventory (the dead player object waits for the clone event; it will be destroyed at some point after the clone event) and delete from drops list. Third event - Clone - is where you go through player inventories of the old/dead player (main inventory (36 slots), armor inventory (4 slots), offhand inventory (1 slot) ), copy each item and add it to the new player's inventory. (when everything works, consider baubles support.) ------------------------- that's at least how i did it a while ago (disclaimer: i may not have remembered everything correctly)... it may not be the best way. Start with printing a line or two into console for every event. Once you get events and conditions to output proper messages, copying item stacks will be a small step.

ok. you found the clone event. inside you write new-player-instance.value1 <- old-player-instance.value1 new-player-instance.value2 <- old-player-instance.value2 now persistence... if you just ask how do i store 1 integer on a player/cow/pickaxe, people here will say "learn capabilities. use capabilities. love capabilities." (https://mcforge.readthedocs.io/en/latest/datastorage/capabilities/) i do not quite agree... yes, the capability system allows you to store several values as a nice structured record. yes the system allows modA to nicely and properly access the data some modB has stored. but sometimes you just need one integer or one string and you can not imagine other mods wanting to interact. so you may elect not to make two interfaces and three more classes to keep that one value. and it's fine. entities and item stacks still have a nbt compound where you can keep your value across game shutdown/load. but in your case you can just read modifiers from the old player instance and apply onto a new player instance. no need to duplicate data.

the game will clone the player. in "player clone" event you are to copy your data from old (dead) player to new instance. before that, you need to solve persistance problem - ie. store the value. you dot that covered already?

in FMLInitializationEvent, you can iterate through ForgeRegistries.RECIPES, check recipe output and remove all recipes that output items you want to remove. or if you want to target specific registries ForgeRegistries.RECIPES has a remove method that takes a ResourceLocation. you need to cast it first. disclaimer: answer may be inaccurate due to forge versions.

i can't confirm on 1.15 but back around 1.11 or so, i had a similar problem - i made the projectile right but it was invisible. solution was to call RegisterModEntity or whatever it was called on entity registry. that made it visible. but given that it was several versions ago, that issue may be entirely obsolete.

what do you mean by "render"? do you want it just to work like a simple projectile or do you want something special? if it's a simple projectile, you don't do any rendering. you just assign a texture to an entity (new one, you will create it) which will be identical to a snowball/egg/enderpearl in every way except this texture and maybe particles. just investigate EntitySnowball class that comes with minecraft. one method for in-flight particles, one method for handling impact and that's all.