MFMods

how are you launching the game? because it looks like java 1.8 (likely system default)

try deleting mantle config inside your savegame directory. if it doesn't help, revert mantle and tc to versions two or three weeks old and notify the developer.

one class inside another, just like you have fields and methods inside of a class. ok, i admit it's not very intuitive now that type definitions are no longer a thing... it doesn't have to be inner class, it can be a separate class. it's just more maintainable if you don't have two separate non-inner classes whose life cycles are connected. just make both classes. serializer will make condition class instances when the game needs them.

the game comes with their own thing now - called tags, so - obviously - forge dropped oredictionary in favor of tags. if you're for example adding a new zinc ingot, you'll need to make a json file in resources/data/forge/tags/items called ingots.json and add your ingot there. that's for things that need all ingots (and i probably should have skipped that one in order not to confuse people). more importantly, in resources/data/forge/tags/items/ingots make a file called zinc.json - that will register your item tag. in addition to item tags, there are block tags (separate thing), fluid tags... for json content see other mods. then, in recipes, instead of saying "item": "your_mod_id:ingot_zinc" you say "tag": "forge:ingots/zinc" . and then crafting table will accept both your ingot and other mods' ingots. in code, for example, if you have a blockstate that player clicked or stepped on, you can called its is() method to see if this block belongs to a given tag.

scrap all that (factory and _factories.json), it's for an older version. do have a condition in a recipe json file. the one you have up there will do fine. make a class that implements ICondition. getID() should return "uncrafted:spawner_enabled". test() should check options and enable/disable the recipe. inside the condition class make a serializer class (yes inside, inner class, static) that implements IConditionSerializer<YourCondition>. getID should return same as above; read should return an instance of your condition class. use json.getAsJsonPrimitive("value_or_flag_name_or_whatever") to get the setting name (if you use a single condition for several recipes); write should do the opposite of read - json.addProperty. finally, register your condition in FMLCommonSetupEvent. call CraftingHelper.register and pass the serializer instance. enjoy!

when you first unpack the mdk archive (when you're starting a new mod) and you edit the build.gradle file, you'll find the text project.file('run') in there (3 occurrences). change that to project.file('../run') if you do that, all your mods will share the game directory for testing, including worlds. much nicer and cleaner. (this assumes mods for different versions are in different workspaces. if they are clumped together, append game version after "run".)

nice. thank you.

I'm stumped regarding a mod that I want to make so I'll take a break and ask a few questions here. How high is the cost of using access transformers? Is it once-and-done during initialization or is there a cost to each access to each field?

there is no definite answer. for your case - bees - you need to investigate bee entity and bee hive and see what code is where. investigate bee goals (or ai tasks). goals can be replaced with your own. or, maybe instead of removing original goal for finding flowers, you can just add your own and bee will sometimes use original code and sometimes your code for finding flowers. and there are always events - when a bee entity is about to be spawned, you can decide you don't want that. store all the bee's data and cancel it being added to the world. then later (when it gets warmer or whatever), take the bees you stored and add them to the world yourself (when you deserialize their data, they'll know their hive location).... events can do wonders, but onlyu after you looked into the flow of original code.

are you sure you understand the geometry in that code? adding sine to Z and cosine to X gives you a circle. but why are you adding anything to Y? that gives you a spiral (not a vertical one, also, but you didn't want any kind). and are you sure you get the part about incrementing the angle? because that code would be much simpler if you did - you'd make a constant holding the number of particles and just divide 2pi by N.

I don't know if there is any documentation, but at least half the mods you play with are configurable - you find their source code and look at it. there is really no way to explaining this other than dumping a bit of code: public class OptionsHolder { public static class Common { private static final int defaultInt1 = 37; private static final boolean defaultBool1 = true; public final ConfigValue<Integer> Int1; public final ConfigValue<Boolean> Bool1; public Common(ForgeConfigSpec.Builder builder) { builder.push("category1"); this.Int1 = builder.comment("This is a nice description of your option. Make it a lot longer than this. Max is 60, default is 37. Enjoy...") .worldRestart() .defineInRange("Short but readable name", defaultInt1, 1, 60); this.Bool1 = builder.comment("asdasd as asd asd asd asdas aasd as asd asd. asd as asd asd. asdasdad asd.") .define("Short but readable name 2", defaultBool1); builder.pop(); } } public static final Common COMMON; public static final ForgeConfigSpec COMMON_SPEC; static //constructor { Pair<Common, ForgeConfigSpec> commonSpecPair = new ForgeConfigSpec.Builder().configure(Common::new); COMMON = commonSpecPair.getLeft(); COMMON_SPEC = commonSpecPair.getRight(); } } then, in your main class constructor you say: ModLoadingContext.get().registerConfig(ModConfig.Type.COMMON, OptionsHolder.COMMON_SPEC); and that's it. the game will create the config file. players will edit it and you read values by saying OptionsHolder.COMMON.Bool1.get(). this creates a single config file in config folder. you can have separate server config (created in world save folder) and client config (in config folder) by creating two small static classes inside the big one (same file) and duplicating that one line in the main class constructor. or you can have just the server config or just the client config.

is downgrading the server version an option for you? lex mentioned milk fluid in change log for 36.1.0, maybe someone forgot to finish something. i can't look into details now but if you could downgrade, you have a workaround.

that's basically it, though a short instruction would be better that working code. and be careful about sides or your mod will crash multiplayer games.

1) delete everything you have. 2) do not go anywhere other than to curseforge. internet is full of idiots offering fake mods and repacked modpacks with who-knows-what inside. 3) go to curseforge, pick a modpack (or separate mods if you have time and willingness to make the pack just right) 4) load the modpack into multimc launcher. do not use any launcher other than multimc or mojang's vanilla launcher. 5) enjoy!

yesterday i decided to port a small mod of mine from 1.12 to 1.16. all in all it wasn't too difficult and took less than a day. the part that gave me some headache was the GlobalLootModifier system and i want to share the headache with others. i had the HarvestDrops event in the old branch and noticed it was killed off. simple internet search led me to a few pages on github and apparently this was a big problem and a big hole in forge for months. those days, looks like i would not have been able to port at all... and then i found the instructions about this new system.... so, draco made a thing. i expect people aren't united on whether it's an improvement and i won't go there. the important thing is - this new thing came with a documentation, proper documentation in proper place. plus the three quite different examples for the LootModifier class. documentation and examples? who does that? i made json files like draco said, made LootModifier like he said and the thing worked. it didn't feel like making a forge mod on a brand new version (for me) at all. with positive item behind us, it was time for negative moments. in short about the mod: HarvestDrops event is like this (in 1.12 language): loop through drops; for each item stack, if it belongs to the oredictionary group that starts with "gem", there is playersLuckLevel*10% chance to duplicate the item. that's all in there. so first thing i saw was that loot context has a getLuck method. sweet. launch the game to try and - nope - context.getLuck returns 0.0 when i break a block even though i have luck III effect on me. that's a bug right? looks like a bug. ok, there should be a player in this context, right? yep, found it. that worked, in terms of me getting a proper luck level, but revealed a few things. first issue was that LootManager.doApply triggers not just for block drops but also when a bat flies into lava or i kill a zombie. that is a bit of a problem for me - i need to spend the first half of doApply method to actually figure out what happened. only when i determine that a player has just mined a block, i can do my main code (outlined above). can we have some enumeration there as a parameter so we know what happened? it would be nicer and faster than every LootManager having to do type checks and casts to know what happened. what do you guys think? also, turned out that getLuck method returns a correct luck value when i kill a zombie but incorrect one when i mine a block. that is it for this rant/blog about my first day with 1.16. whoever actually read all of this, will get a sweet berry cookie from me.

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...