Leaderboard

Word of advice, it will take more than a week of modding/learning java to understand most of this stuff. The fluid concept you want to achieve isn't a very simple implementation. The best way to learn is through reading the source code to see how vanilla achieves things. This almost always requires some digging through packages, or reading forums to get led in the right direction. Regarding the packages you have drawn attention to, the vanilla code is made up of many interfaces and parent classes that act as blueprints, while the classes you are most likely interested in reading are WaterFluid and LavaFluid, as these seem to be the most specific. For example, in the WaterFluid class: @OnlyIn(Dist.CLIENT) public void animateTick(World worldIn, BlockPos pos, IFluidState state, Random random) { if (!state.isSource() && !state.get(FALLING)) { if (random.nextInt(64) == 0) { worldIn.playSound((double)pos.getX() + 0.5D, (double)pos.getY() + 0.5D, (double)pos.getZ() + 0.5D, SoundEvents.BLOCK_WATER_AMBIENT, SoundCategory.BLOCKS, random.nextFloat() * 0.25F + 0.75F, random.nextFloat() + 0.5F, false); } } else if (random.nextInt(10) == 0) { worldIn.addParticle(ParticleTypes.UNDERWATER, (double)pos.getX() + (double)random.nextFloat(), (double)pos.getY() + (double)random.nextFloat(), (double)pos.getZ() + (double)random.nextFloat(), 0.0D, 0.0D, 0.0D); } } You already get a sense that there are block states such as FALLING, that describes the movement/behavior of the water. Looking at how the class is set up: public abstract class WaterFluid extends FlowingFluid { public Fluid getFlowingFluid() { return Fluids.FLOWING_WATER; } public Fluid getStillFluid() { return Fluids.WATER; } public Item getFilledBucket() { return Items.WATER_BUCKET; } Any fluid you'd like to make must have these features. So, you notice that there is a class Fluids that seems to store all the types of fluids. Hence, you should look for a Forge registry that allows you register your own fluid to show up in the game. Hopefully this provides some direction, I personally haven't messed with fluids myself, but this is how I've tried to figure things out. Registries and Events I suggest checking out the net.minecraftforge.event package and poke around. An event is exactly what it sounds like. Something happens in the game. When you annotate your method with a @SubscribeEvent annotation, you signal to Forge that your method should run when something in the game happens. Which event depends on the Event parameter you give it. These events can be found in the aforementioned package. The class that contains this method (called an event handler) must be registered to the MinecraftForge.EVENT_BUS.register(...). An example of using under some condition you didn't want zombies to spawn. In otherwords, you wanted to cancel the event of a zombie spawning. You may have something like: @SubscribeEvent public static void onEntityJoinWorld(EntityJoinWorldEvent event){ if(event.getEntity() instanceof ZombieEntity && condition) event.setCanceled(true); } And behold, during the game, given that condition is true, zombie spawns will be canceled faster than Kevin Hart was for his Oscar speech. Registries are Forge's way of "injecting" your content into the game. Think of it like a list of things to be included into the game. The way you add to this list is to register an item. In your console, you may see something of the following: [19:09:01] [Server-Worker-6/DEBUG] [ne.mi.re.ForgeRegistry/REGISTRYDUMP]: Registry Name: minecraft:block Entry: 0, minecraft:air, Block{minecraft:air} Entry: 1, minecraft:stone, Block{minecraft:stone} Entry: 2, minecraft:granite, Block{minecraft:granite} Entry: 3, minecraft:polished_granite, Block{minecraft:polished_granite} Entry: 4, minecraft:diorite, Block{minecraft:diorite} Entry: 5, minecraft:polished_diorite, Block{minecraft:polished_diorite} ... Here, Forge is registering the blocks. If you don't register your items, they won't be in the game. Hope this provides some guidance. I would suggest reading the Forge Documentation EVEN THOUGH MANY OF THE SPECIFICS ARE OUTDATED (keep in mind, the dudes are doing this for free). Many of the concepts are still relevant, like Registries and Events.

https://mcforge.readthedocs.io/en/latest/gettingstarted/structuring/

I would recommend looking at BrewingRecipeRegistry#addRecipe.

Do you not see a search bar? *sigh* it's to the right of "Merch". *heavy sigh*

Reasons Forge isn't coming to Bedrock: Bedrock is written in C++, which is much harder to decompile than Java Bedrock runs on Xbox 1, PS4, and Switch. Inserting Forge's code onto a console is even harder (Console makers hate homebrew) Furthermore, the decompiled code is nearly impossible to make sense of (or deobfuscate) so modders won't know what they're doing Well there you go. Unless Mojang makes Minecraft open-source, Bedrock modding is very, very, very, very hard to do.

I would not use a ! in your file paths. Try changing that, and see if it makes a difference.

MCP conf folder is in you(user)\.gradle\caches\minecraft\net\minecraftforge\forge\1.7.10-10.13.2.1291(your forge version here)\unpacked\conf

Nope, it is all support, if it's before 1.14.4, there is no support here regardless of what it is for. There are just too many versions, and a choice had to be made what to support, and the current and previous versions are what was chosen to be supported. If I'm wrong, then this thread won't get locked by a moderator