Leaderboard

The correct way is to check if the Block implements IPlantable. If it does, and IPlantable#getPlantType returns CROP then it can be planted on farmland.

"Sometimes solving the issue is more important than what originated it." Jesus Christ! Do you have any basic programming knowledge?

If blender is too hard for you, you may use Blockbench.

If you haven't already I would recommend giving these a read. They're just Forge Docs. but they explain most of it pretty well. Blender Addon: https://github.com/phonon/blender-minecraft-json Docs: https://mcforge.readthedocs.io/en/latest/models/files/#model-files https://mcforge.readthedocs.io/en/latest/animation/intro/

About Suppliers: https://thejavacult.com/supplier-interface-java-util-function/

As I said, this has NOTHING to do with Forge's code or how we build the classpath. We could technically put the jar whever the hell we want. This is wholy issues with SERVER HOSTS and other users. And the drama/bitching that will come from it. This is just a case of... don't be dumb and run the vanilla server... Unfortunately there isn't anything we can do to mark the world as not loadable by the vanilla jar. As it's not code we control so there isn't any way to add protections into it. Many Many external things can corrupt your world.

Here, this may help you if you're familiar with 1.12, as a LOT of stuff has changed since then. https://gist.github.com/williewillus/353c872bcf1a6ace9921189f6100d09a

You put a `@ObjectHolder` annotation on `ItemInit.example_item` without specifying a modid in either the annotation on the field or on the class (through @Mod or @ObjectHolder). See the documentation on @ObjectHolder for its rules and examples. (ignore the 1.14.x version, it is the same up to 1.16.+)

You need to use the share tag (getShareTag, readShareTag).

Seriously, stop pretending to know what the important bits are and post the whole thing. And your code. Preferably as a git repo

Assuming you are using ItemStackHandler (you should, change it if you are not!), override onContentsChanged. It will be called whenever the contents of a slot changes.

writeSpawnData only sometimes writes an int. readSpawnData always reads an int. The methods must be exactly symmetrical.

Then use the IFormattableTextComponent API, namely func_240701_a_ which applies a formatting to it.

Extend `WorldSavedData` and override `read()` and `write()`. You can also create a empty constructor calling the super constructor with the name of your WorldSavedData. If you have a `ServerWorld`, `ServerWorld#getSavedData` returns a `DimensionSavedDataManager`. Call `DimensionSavedDataManager#getOrCreate` (or `#get`), passing in a Supplier that gives new instances of your WorldSavedData, and a string data identifier. I'm not very sure if this is cross-dimensional.

Actually, I have no certain idea how FoV works in Minecraft. But I if we assume, that it works like an optical camera, I may help you. Here you can see how world is projected to the screen (or matrix in camera). So, to negate FoV deformations you should (using spherical trigonometry) calculate angle distance to center of the screen and take a tangent of it - now you have pure coordinate - distance to target in radius of some sphere. To find a pure coordinate of screen border, you may take tan(FoV/2). Then using screen resolution calculate distance in pixels on screen between center and target. Then again using spherical trigonometry calculate angle between Center-Target and, for example, horizon line, understand that it is unchanged after projection, and get your result vector by this angle and that distance. But please, don't do that! I'm sure, more forge-like way exists to do what you want. For example, this: or net.minecraftforge.client.event.RenderWorldLastEvent.

You can check ForgeInGameGui/InGameGui, there are a lot of similar rendering going on there.

Those tutorials are bad then. Unfortunately most modding tutorials are written by amateurs, who don't even come here to ask for feedback before posting it as just "the way to do it" on Youtube, etc. Registration must happen exactly when Forge tells you. Forge does so by firing the registry event. If you use a static initializer you completely bypass this system. This prevents Forge from doing improvements in the future, such as reloading mods at runtime or even disabling/enabling them. Yes, it's fine now. However if you do write a tutorial I would recommend you use DeferredRegister or at least RegistryObject as they are the current recommended approach. "Magic injection into fields" using @ObjectHolder is ugly. Why do you not want to use them?

It's a pretty complicated system to set up a custom village, but definitely do-able. The current Minecraft villages are created using a "Jigsaw" system. In order to do anything with custom villages, you need to understand how these function. This video is a really good explanation of the system, make sure to watch the whole thing. It's from 1.14, but for the most part the Jigsaw system hasn't changed much since then. The 1.15.2 mod "The Farlanders", which creates custom villages, has all of their code available on Github, so if you were to use that code as well as vanilla village files as reference, then you'd be in a pretty good spot. Not much more documentation exists out there regarding doing something like this, so past everything I've given you, there isn't much else available that can guide you in the process.

Because you never know when a static block will execute, and if it executes too early, Forge can't insure that it has full control over the object. (Forge does lots of lots of behind the scenes magic and dangerous sorcery that you, as a modder, don't need to worry about, but that if it isn't done in order, things break)

Positive, any perceived order after Blocks -> Items could change at any time. I've seen people that know what they're talking about (including Lex) say it a million times.

Watch this: https://www.youtube.com/watch?v=FyCYva9DhsI

The 1.16 mappings are being made manually, hence the old date. Once MMMS lands, we'll be in a much better position. For the mean time, Kashike is working on updating as many of the common mappings as possible.

Thanks for the amazing work, it was such a fast release!

Forge for 1.16.1 The first Forge build for 1.16.1 is now live thanks to the hard work of: covers, illy, jd, garrett, giga, and the rest of the forge crew. With their help we were also able to release the updates to MCPConfig for 1.16 and 1.16.1 the same day that vanilla did. The Nether Update has brought a lot of changes to many systems, and as with any update there are likely to be bugs. We are still evaluating and working on some of the systems like dimensions and trees to come up with the best system to allow for modders to integrate with vanilla’s new dimension system. We are also expecting Mojang to release a 1.16.2 fairly shortly and are prepared to work on updating to it as soon as they do. As with every update, there are bugs and other minor things to be expected. Please report them responsibly and have fun with the new version! Changes to the LTS There are a couple changes happening to the Long Term Support system originally introduced here. We are moving the LTS from 1.14.4 to 1.15.2 to reflect the community being more active and also changing how we chose what version the LTS will be to be more maintainable. We are now going to be supporting the latest (n) and second latest (n - 1) versions, with the reservation of potentially having the LTS being n - 2 if something is Mojang ends up really making a mess of a particular version. That being said we still will be providing critical fixes for all possible versions. Do not worry about 1.14 being instantly dropped while we are still working on updating 1.16, as we have a customary grace period for while everything is still in flux before we start strictly enforcing the LTS rules. New Team Members We are happy to announce we've added a few new members to the Forge team officially. These people have been a part of the community for a while and have been helping out a lot. The first two are new members of the 'Toolchain' team. Which is responsible for some of the backend tools, like the decompiler, update scripts, gradle and other internals. The others are joining our ever growing list of Triage team members. Who are responsible for managing the issues and pull requests on our github. They are the front line of bug reports and feature requests, treat them with respect and listen to what they tell you! Toolchain covers1624 JDLogic Triage AshersLab Curle OrionOnline pupnewfster

What is this? This is a collection of common issues and recommendations for the Modder Support subforum. Instead of repeating these things over and over again, a link to this thread can be used instead. This post will be updated as needed. Suggestions either via PM to me or in a separate thread to keep this topic clean.

Please provide a screenshot of your launcher

Look at the TickEvent class. Also check the docs on events. Check out the various subclasses of GuiScreenEvent which allow you to modify existing screens. You can also use GuiOpenEvent to completely replace a screen.

No, don't leave dependencies.examplemod, that declares dependencies for a mod that doesn't exist The logo does matter if you plan to open the mod list All values in mods.toml marked #Optional should be set or removed entirely, do not leave them blank

Just adding onto that, if you put your modid into an @ObjectHolder above your class, then any `public static final` fields will be auto-injected with the object according to their fields' name. Again, I refer you to the documentation on this, as it has examples.

setRequiresTool() in AbstractBlock.Properties So canHarvestBlock() will do tool checking when block is harvest. You can also see how blocks in Blocks.java do it.

This cannot return null.

Leave it at 1 for normal fall damage. Certain blocks set this value to reduce fall damage. Hay for example sets it to 0.2 (see HayBlock#onFallenUpon), SlimeBlock even sets it to 0 to completely disable fall damage.

If you are checking your own entity: check doBlockCollisions in Entity, if you are checking your own block, override onEntityCollision (its bb cannot be a full cube). Otherwise check it manually as Dzuchun mentioned above using LivingTickEvent (I don't think there's a event for collision) and do checkings like how doBlockCollisions in Entity does.

If you look into vanilla slabs, slab has one property (ignores water logged boolean property), and 3 possible types: top, bottom, and double which represents theirs states, but I think you should be able to use vanilla slab class instead of creating your own one.

FontRenderer has methods that accept ITextProperties (which ITextComponent extends). Look at how IngameGui draws the title, for example.

ClientTickEvent is usually the only place to check for key bindings. Anything else doesn't really make sense. The keyboard input events are for raw keyboard input, not key bindings. isKeyDown will return true if the key is currently down. If you check this every tick, you might miss key presses (the key can be pressed and released during Minecraft's "sleep time" waiting for the next tick, in that case you'd miss it). That is why isPressed exists. isPressed will return true for as many times as the key was pressed. So you usually have a while (isPressed) loop and do your action there. This ensures that if you e.g. click twice during Minecraft's waiting time, it will still swing your sword twice.

Check out net.minecraft.util.math.AxisAlignedBB class. You may take Player AABB and then use AxisAlignedBB#intersect method on blocks positioned at player's coordinates +1(-1). AABB has constructor AxisAlignedBB(BlockPos pos). Don't forget to check if block at selected BlockPos exists and is not air (optional)

Please use the .gitignore file that comes with the MDK. You should not check in the run folder to Git and you are missing essential files (mainly the gradle wrapper). Lets go through your logic step by step. At first the flame timer is 0. The entity collides with your block. This line sets the flame timer to 1. This if statement never runs, because the flame timer is at least 1 here.

https://github.com/Tavi007/ElementalCombat/blob/1390c4b3be278d93c6be25369ac14cb8f7e74b68/1.15.2/src/main/java/Tavi007/ElementalCombat/StartupCommon.java#L26 Your FMLCommonSetupEvent isn't annotated with @SubscribeEvent , it's never called. https://github.com/Tavi007/ElementalCombat/blob/1390c4b3be278d93c6be25369ac14cb8f7e74b68/1.15.2/src/main/java/Tavi007/ElementalCombat/events/AttachCapabilityEvent.java#L14 For events to be called, you have to register them to the event bus by calling IEventBus#register, you never call MinecraftForge.EVENT_BUS.register(new AttachCapabilityEvent), so it doesn't fire. Maybe you can put the ResourceLocation as a parameter in your constructor? I haven't worked with particles myself, just an assumption. I don't think you should, they're all small issues that can be tackled in one post instead of spamming the forums with small 1 reply threads. Edit: Dzuchun is also correct, though you don't have to use @Mod.EventBusSubscriber if you're methods aren't static, but you still have to register an instance of your class. Edit 2: Btw, you can't really have both FMLCommonSetupEvent and ServerAboutToStartEvent in the same @Mod.EventBusSubscriber annotated class as they fire on separate buses, FMLCommonSetupEvent fires on the mod bus, ServerAboutToStartEvent on the Forge bus. Edit 3: This is from the Forge discord,

1.12 is not supported on this forum. Please update to a modern version of Minecraft to receive support.

Looked at the load order, for some reason I thought CommonSetup was called sooner. ERROR(null), VALIDATE(null), CONSTRUCT(null), CREATE_REGISTRIES(null), LOAD_REGISTRIES(null), COMMON_SETUP(()-> FMLCommonSetupEvent::new), SIDED_SETUP(SidedProvider.SIDED_SETUP_EVENT::get), ENQUEUE_IMC(()-> InterModEnqueueEvent::new), PROCESS_IMC(()-> InterModProcessEvent::new), COMPLETE(()-> FMLLoadCompleteEvent::new), DONE(null), GATHERDATA(ModLoader.get()::getDataGeneratorEvent);

The new system is still being developed and tested, it's not ready for use yet, however there are manually-created mapping versions pinned in the modder-support-116 channel of the Forge Discord

It doesn't exist anymore, you have to make the methods manually, it looks a bit like this: public class MyMessage { int value; public MyMessage(int value) { this.value = value; } public static void encode(MyMessage msg, PacketBuffer buffer) { buffer.writeInt(msg.value); } public static MyMessage decode(PacketBuffer buffer) { return new MyMessage(buffer.readInt()); //Remember to read in the same oreder you wrote! } public static void handle(MyMessage msg, Supplier<NetworkEvent.Context> ctx) { if (ctx.get().getDirection() == NetworkDirection.PLAY_TO_SERVER) { //Checks if the packet's direction is to the server ctx.get().enqueueWork(() -> { //Your code goes here }); } ctx.get().setPacketHandled(true); } } I'm 99% sure that's correct, kinda freestyled it though. To send it use SimpleChannel#sendToServer, don't forget to register it with SimpleChannel#registerMessage, and don't worry if you don't understand it right away, it took me a while to fully understand packets in 1.15.

I misunderstood the problem. I am not sure, then.

I think you need a custom Teleporter class. Been a while since I looked into it, but I recall that if you don't have one, vanilla is like "oh you changed dimensions, lemme just build a nether portal for you..."

That is precisely what that event is for. If you set the result the Pre event to DENY, then the plant won't advance to the next growth stage. You can find a (complicated) example here: https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/harderfarming/EventHandlers.java#L103 That takes into account biome temperature, rainfall, and neighboring plants to determine whether or not to grow. The net result is that crops of the same type grow at approximately the same speed, and its influenced by the ambient conditions (and different crops have different ideal conditions).

<image of vanilla code removed - diesieben07>

{ ... "result": { "item": "your_item", "nbt": { //Your nbt tag goes here. } } }

Oh god why? Do not use @OnlyIn. Do not use IInventory (LockableLootTileEntity). Especially because you already have an IItemHandler... You can't do this. There can be multiple people looking at the TE. You have not shown where you open your GUI, I'm guessing that is in your block class.

You could probably just do the render call yourself in one of forges render events. Looking at why the player isn’t rendering (where the code is that disables it) would be a good start to deciding where to do the render call from. Personally I don’t think that Pixelmon is a good source, I would look at the vanilla code to understand what is going on, then at the pixelmon code to see what they do and then I would write my own implementation.