MFMods

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.