Modifications to the Minecraft base files to assist in compatibility between mods.

Related tags

java minecraft forge mod
Overview

Forge Logo

MinecraftForge

Stable Release Latest Release Discord Support

Forge is a free, open-source modding API all of your favourite mods use!

Version Support
1.16.x Active
1.15.x LTS

Notes:

  • Introduced in 1.13 was a new FML, information found here.

Installing Forge

Go to the Forge website and select the Minecraft version you wish to get Forge for from the list.

You can download the installer for the Recommended Build or the Latest build there. Latest builds may have newer features but may be more unstable as a result. The installer will attempt to install Forge into your vanilla launcher environment, where you can then create a new profile using that version and play the game!

For support and questions, visit the Support Forum.

Here is a short video from Rorax showing how to install and setup Forge.

Creating Mods

See the "Getting Started" section in the Forge Documentation.

Contribute to Forge

If you wish to actually inspect Forge, submit PRs or otherwise work with Forge itself, you're in the right place!

See the guide to setting up a Forge workspace.

Pull requests

See the "Making Changes and Pull Requests" section in the Forge documentation.

Please read the contributing guidelines found here before making a pull request.

Contributor License Agreement

We require all contributors to acknowledge the Forge Contributor License Agreement. Please ensure you have a valid email address associated with your GitHub account to do this. If you have previously signed it, you should be OK.

Donate

Forge is a large project with many collaborators working on it around the clock. Forge is and will always remain free to use and modify. However, it costs money to run such a large project as this, so please consider becoming a patron.

Issues
  • Relicensing Forge to LGPL 2.1

    Relicensing Forge to LGPL 2.1

    Forge is currently a mishmash of several different licenses. They are probably all FOSS, however, the primary initial license was not clearly FOSS and had several probable loopholes.

    Additionally, the patches directory needs to be licensed separately, as that is mostly generated code, and it's impossible to properly attribute any form of ownership beyond the project.

    The new license text is found at "LICENSE-new.txt" in the root of the project (1.9 branch) here: https://github.com/MinecraftForge/MinecraftForge/blob/1.9/LICENSE-new.txt

    This issue is to track the consent of all contributors to the Forge project who have code active at this time.

    The below authors list was generated from the 1.9 branch on the 28th April 2016 and represents every line of java code present in Forge today, and it's attribution. Note that many are trivial attributions (changing whitespace or comment boilerplate) and as such we will mark them as accepted since they are non-functional.

    However, others are more substantial and we would like a reply to this issue from each author below consenting to the relicensing of your contribution to the LGPL as detailed above.

    Sample consent message:

    I github user listed above as email address consent to the relicensing of my contributions to the Forge project under the license as stated in LICENSE-new.txt

    The relicense should happen between 1.9.3 and the next release of Minecraft. It has no impact on any mods and their licensing.

    Trivial Contributions

    Some members of this list are authors of what is considered Trivial Contributions. This is a contribution that is to trivial to be copyrightable. Mostly this includes <5 line bug fix, or whitespace changes. Any person listed here as a Trivial Contribution should respond by June 28th 2016 if they have any objections and their contributions can be removed.

    Contributors

    | Accepted | Lines of code | Email address | Comment | | --- | --- | --- | --- | |

    • [x]
    | 27697 | [email protected] | Consent | |
    • [x]
    | 20505 | [email protected] | Consent | |
    • [x]
    | 16723 | [email protected] | Consent | |
    • [x]
    | 7512 | [email protected] | Consent | |
    • [x]
    | 2367 | [email protected] | Consent | |
    • [x]
    | 2148 | [email protected] | Consent | |
    • [x]
    | 1494 | [email protected] | Consent | |
    • [x]
    | 1095 | [email protected] | Consent | |
    • [x]
    | 944 | [email protected] | Consent | |
    • [x]
    | 835 | [email protected] | Consent | |
    • [x]
    | 688 | [email protected] | Consent | |
    • [x]
    | 651 | [email protected] | Consent | |
    • [x]
    | 524 | [email protected] | Consent | |
    • [x]
    | 397 | [email protected] | Consent | |
    • [x]
    | 373 | [email protected] | Consent | |
    • [x]
    | 365 | [email protected] | Consent | |
    • [x]
    | 348 | [email protected] | Consent | |
    • [x]
    | 323 | [email protected] | Consent | |
    • [x]
    | 263 | [email protected] | Consent | |
    • [x]
    | 207 | [email protected] | Consent | |
    • [x]
    | 172 | [email protected] | Consent | |
    • [x]
    | 158 | [email protected] | Consent | |
    • [x]
    | 153 | [email protected] | Consent | |
    • [x]
    | 135 | [email protected] | Consent | |
    • [x]
    | 117 | [email protected] | Consent | |
    • [x]
    | 112 | [email protected] | Consent | |
    • [x]
    | 106 | [email protected] | Consent | |
    • [x]
    | 98 | [email protected] | Consent | |
    • [x]
    | 86 | [email protected] | Consent | |
    • [x]
    | 76 | [email protected] | Consent | |
    • [x]
    | 75 | [email protected] | Consent | |
    • [x]
    | 75 | [email protected] | Consent | |
    • [x]
    | 75 | [email protected] | Consent | |
    • [x]
    | 75 | [email protected] | Consent | |
    • [x]
    | 73 | [email protected] | Consent | |
    • [x]
    | 69 | [email protected] | Consent | |
    • [x]
    | 66 | [email protected] | Consent | |
    • [x]
    | 62 | [email protected] | Consent | |
    • [x]
    | 60 | [email protected] | Consent | |
    • [x]
    | 58 | [email protected] | Consent | |
    • [x]
    | 51 | [email protected] | Consent | |
    • [x]
    | 50 | [email protected] | Consent | |
    • [x]
    | 50 | [email protected] | Consent | |
    • [x]
    | 45 | [email protected] | Consent | |
    • [x]
    | 39 | [email protected] | Consent | |
    • [x]
    | 39 | [email protected] | Consent | |
    • [x]
    | 37 | [email protected] | Consent | |
    • [x]
    | 37 | [email protected] | Consent | |
    • [x]
    | 37 | [email protected] | Consent | |
    • [x]
    | 35 | [email protected] | Consent | |
    • [x]
    | 35 | [email protected] | Consent | |
    • [x]
    | 32 | [email protected] | Consent | |
    • [x]
    | 28 | [email protected] | Consent | |
    • [x]
    | 28 | [email protected] | Consent | |
    • [x]
    | 27 | [email protected] | Consent | |
    • [ ]
    | 26 | [email protected] | | |
    • [x]
    | 26 | [email protected] | Consent | |
    • [x]
    | 25 | [email protected] | Consent | |
    • [x]
    | 22 | [email protected] | Consent | |
    • [x]
    | 21 | [email protected] | Contribution was to FML, not MinecraftForge. Already LGPLv2.1 | |
    • [ ]
    | 19 | [email protected] | | |
    • [x]
    | 19 | [email protected] | Consent | |
    • [x]
    | 18 | [email protected] | Consent | |
    • [x]
    | 15 | [email protected] | Consent | |
    • [x]
    | 14 | [email protected] | Trivial Contribution | |
    • [x]
    | 12 | [email protected] | Consent | |
    • [x]
    | 12 | [email protected] | Consent | |
    • [x]
    | 12 | [email protected] | Consent | |
    • [x]
    | 11 | [email protected] | Consent | |
    • [x]
    | 11 | [email protected] | Consent | |
    • [x]
    | 10 | [email protected] | Consent | |
    • [x]
    | 10 | [email protected] | Consent | |
    • [x]
    | 10 | [email protected] | Consent | |
    • [x]
    | 9 | [email protected] | Consent | |
    • [x]
    | 8 | [email protected] | Consent | |
    • [x]
    | 8 | [email protected] | Consent | |
    • [x]
    | 8 | [email protected] | Consent | |
    • [x]
    | 6 | [email protected] | Consent | |
    • [x]
    | 6 | [email protected] | Trivial Contribution | |
    • [x]
    | 6 | d[email protected] | Trivial Contribution | |
    • [x]
    | 6 | [email protected] | Consent | |
    • [x]
    | 5 | [email protected] | Trivial Contribution | |
    • [x]
    | 5 | [email protected] | Trivial Contribution | |
    • [x]
    | 4 | [email protected] | Trivial Contribution | |
    • [x]
    | 4 | [email protected] | Trivial Contribution | |
    • [x]
    | 4 | [email protected] | Trivial Contribution | |
    • [x]
    | 4 | [email protected] | Trivial Contribution | |
    • [x]
    | 4 | [email protected] | Trivial Contribution | |
    • [x]
    | 3 | [email protected] | Trivial Contribution | |
    • [x]
    | 3 | [email protected] | Trivial Contribution | |
    • [x]
    | 3 | [email protected] | Trivial Contribution | |
    • [x]
    | 2 | [email protected] | Trivial Contribution | |
    • [x]
    | 2 | [email protected] | Consent | |
    • [x]
    | 2 | [email protected] | Trivial Contribution | |
    • [x]
    | 2 | [email protected] | Consent | |
    • [x]
    | 2 | [email protected] | Consent | |
    • [x]
    | 2 | [email protected] | Trivial Contribution | |
    • [x]
    | 2 | [email protected] | Trivial Contribution | |
    • [x]
    | 2 | [email protected] | Trivial Contribution | |
    • [x]
    | 1 | [email protected] | Trivial Contribution | |
    • [x]
    | 1 | [email protected] | Trivial Contribution | |
    • [x]
    | 1 | [email protected] | Trivial Contribution | |
    • [x]
    | 1 | [email protected] | Trivial Contribution | |
    • [x]
    | 1 | [email protected] | Trivial Contribution | |
    • [x]
    | 1 | [email protected] | Consent | |
    • [x]
    | 1 | [email protected] | Consent | |
    • [x]
    | 1 | [email protected] | Consent | |
    • [x]
    | 1 | [email protected] | Consent | |
    • [x]
    | 1 | [email protected] | Trivial Contribution | |
    • [x]
    | 1 | [email protected] | Trivial Contribution | |
    • [x]
    | 1 | [email protected] | Trivial Contribution | |
    • [x]
    | 1 | [email protected] | Trivial Contribution | |
    • [x]
    | 1 | [email protected] | Trivial Contribution | |
    • [x]
    | 1 | [email protected] | Trivial Contribution |

    RFC 
    opened by cpw 97
  • [1.11.x] added CriticalHitEvent, closes #2871

    [1.11.x] added CriticalHitEvent, closes #2871

    Adds an Event to control the behauvior if an Player does an critical hit.

    This is a retargeting of #3004 and solves #2871 .

    Also an example:https://gist.github.com/mcenderdragon/b2e11c054dca08c566934a860087d881

    1.11 Feature New Event 
    opened by mcenderdragon 93
  • IItemHandler missing functionality to determine if a slot accepts an item

    IItemHandler missing functionality to determine if a slot accepts an item

    IItemHandler currently only has functionality to determine if a slot will accept an item. There is no function to determine if it can accept an item. The difference is subtle but important.

    My particular use case involved minecarts. A Chest Cart arrives at an Unloader, next to the Unloader is an inventory that supports IItemHandler, but it is full. The cart is supposed to stay at the Unloader until it is empty or has unloaded all the items the target inventory accepts. The first case is fine and dandy... but the second case fails hard. I have no way to tell which items the IItemHandler accepts, only which items it has room for. As soon as the IItemHandler fills up, I can longer test acceptance, only room.

    opened by CovertJaguar 88
  • Add Unification system for unifying basic materials between mods

    Add Unification system for unifying basic materials between mods

    Supersedes https://github.com/MinecraftForge/MinecraftForge/pull/4139

    This aims to slice off a piece of functionality from OreDictionary and make it something better. Currently the OreDictionary seems to do a few different things all together, and needs replacement. This is one step towards that.

    @Nedelosk and I have worked on a mod to brainstorm how to do this already (it was called OreRegistry), but really this system needs to be in Forge to be effective at all. I used that mod as a starting point for https://github.com/MinecraftForge/MinecraftForge/pull/4139 and improve it further in this PR, based on feedback from the last one.

    Since this is a relatively big feature, it needs community feedback. Below I'll describe the system, taken from the javadoc on UnificationRegistry.java. Before giving feedback please see the code as well.

    Description:

    The UnificationRegistry allows mods to register basic materials so they can be unified. Using the UnificationRegistry, everything can return a single unified type, so for example players will only ever get one kind of Copper Ingot or Tin Ore. Basic materials follow vanilla conventions, like iron ore being smeltable into iron ingots. If other mods cannot make basic assumptions about your materials, do not register them for unification.

    Usage:

    First, create your UnificationMaterials and UnificationForms or use the ones listed in UnificationConstants. Then, add your mod's variant with #add(UnificationMaterial, UnificationForm, T). You will get back instances of Unified, which is used to unify all things with those properties.

    Recipes:

    Recipes created with Unified for an ingredient will accept any item registered for a type, and return just the one unified type. Unifiedcan be used in recipes like ShapedOreRecipe and ShapelessOreRecipe, or you can implement your own recipes. You can also create JSON recipes that use Unified as an ingredient or result, by using the recipe type "forge:ore_shaped" or "forge:ore_shapeless", and using the ingredient format

    {
     "type": "forge:unified", 
     "material": "materialUid", 
     "form":  "formUid"
    }
    

    For examples see the json recipes in the forge test directory src\test\resources\assets\item_unification_test\recipes

    1.12 Feature Stale 
    opened by mezz 82
  • Forge energy interface

    Forge energy interface

    There are quite a few mods that include blocks which consume energy, but "don't really care" about the different energy systems. These mods tend to use Redstone Flux API, designed by the CoFH team. Like any other non-Forge API, this sometimes leads to incompatibilities - particularly when the API changes, or when mods are updated to new Minecraft versions before Redstone Flux is. These mods also tend to have an internal buffer of energy, which they draw from directly, and which is replenished from outside sources.

    Given the variety of energy systems, would it be a good idea for Forge to have an API only for the purpose of energy-system-implementors interfacing with energy-system-agnostic blocks? The API would consist of only one interface, to be implemented by tile entities which can accept energy, with two methods, similar to double getNominalPowerDraw(); and double offerEnergy(double amount, ForgeDirection side); (with the latter returning the amount of energy actually consumed).

    This issue is for discussion; I have not written any code yet, as this API would be more complex politically than technically (all that is required is one interface). If there is a consensus that it this proposed API is desirable, I will submit a pull request.

    Feature 
    opened by immibis 80
  • Fixed lag spike caused by unloading tileentities

    Fixed lag spike caused by unloading tileentities

    Hey there,

    I'm the author of LittleTiles/CreativeCore and recently I found out that Minecraft has a huge lag spike during unloading chunks if the world contains a lot of tileentities.

    How did I find it? Although the performance of LittleTiles was not bad there used to be quite horrible lag spikes, which occurred rather frequently while the player was moving. It became more and more unbearable. So I made several attempts to fix it, but unfortunately without any success. I couldn't find anything in my code. A few months later I tried it again, but this time I was ignoring my code, since I suspected it to be an issue caused by Minecraft itself.

    The issue itself Eventually I found that the lag spike was not caused by loading new chunks, but instead while unloading the old ones. After some further investigations I saw those two suspicious looking lines in World.updateEntities():

    this.tickableTileEntities.removeAll(this.tileEntitiesToBeRemoved);
    this.loadedTileEntityList.removeAll(this.tileEntitiesToBeRemoved);
    

    So I debugged it and ... yes ... wow. There were 20,000 tileentities in tickableTileEntities and loadedTileEntityList while tileEntitiesToBeRemoved had a size of 3,000. Stepping over it using the debugger took quite a long time.

    I finally had found the issue. It's not caused by the amount of traffic or the complexity of tileentities, but caused by the amount of tileentities no matter if there are furnaces or more complicated ones.

    This video demonstrates this issue: https://www.youtube.com/watch?v=vTCJbp45pWM

    I also reported this issue to Mojang: https://bugs.mojang.com/browse/MC-119686

    How did i fix it? I replaced those two lists with HashMap<ChunkPos, List<TileEntity>>. So once a chunk will unload one key will be removed instead of iterating through the whole list several times. This completely solved the lag spikes (as shown in the video).

    I implemented it in CreativeCore v1.8 and eventually decided to create this pr.

    About this PR I changed tickableTileEntities and loadedTileEntityList from an ArrayList to a ChunkedTileEntityList, which basically saves all tileentities in a HashMap<ChunkPos, List<TileEntity>>. Furthermore I added another list to the world (tileEntitiesChunkToBeRemoved), which contains all chunk positions of unloaded chunks. During each tick those will be removed from tickableTileEntities and loadedTileEntityList. It's still possible unloading a tileentity using the old way, but I changed it for the chunk. A chunk will now call markChunkForRemoval instead of calling markTileEntityForRemoval (func_147457_a) for each tileentity.

    If there is anything to complain about my naming or the formatting style, just let me know.

    Possible mod conflicts Since CreativeCore changed it already I can ensure that there is currently only one mod it is conflicting with https://github.com/RootsTeam/Embers/issues/237. As long the iterator is used there are no changes required.

    Last words This issue must have existed for several years now. It probably caused a lot of headaches and definitely ruined the experience for many players, especially if you have build a lot of machines or other stuff close together. So I really hope this improves our modding situation. It affects the server in the same way as the client, only that it might be worse for the server (more loaded tileentities).

    I'm looking forward to smoother gameplay and hope this PR will be merged soon. Once that is done I will create another one for 1.11.2.

    UPDATE All the indexed methods have been implemented. There are bad at performance, but the game will no longer crash of a mod is using them (like Embers).

    In Regards CreativeMD

    1.12 Superseded Vanilla Bug 
    opened by CreativeMD 79
  • [1.13 suggestion] Tag system for Oredict

    [1.13 suggestion] Tag system for Oredict

    Minecraft Snapshot 12w49a adds a new system called Tags. In the update log's own words: This seems really similar to the ore dictionary, and it seems like it'd be pretty easy to use for JSON recipes, along with making checking for ore dictionary matches a lot easier. For example, one of my mods has to have a whole function to check if a slot can accept a certain oredict entry, but that could be shortened to oredict:<entry> or Tag.oredict.<entry>. The main issue is that it might cause a good amount of refactoring needed to add oredict entries to the tag system, and it might not be as easy to access from the code side. I want to try to work on a PR for this, but I'd like some feedback on if people think it's a remotely good idea in the first place.

    opened by Boundarybreaker 71
  • [1.13] Extend the Tag system to cover Forge Registries

    [1.13] Extend the Tag system to cover Forge Registries

    Supersedes #5020. There have been several changes to the proposal but because the originial issue-creator doesn't seem to want to PR his proposal (though It might take a bit til I'm ready to PR this), I'm creating this Issue here.

    In 1.13 the Tag System allows blocks, items and functions to be tagged, this however does not extend to Entities.

    As discussed in #5020 it seems like a good idea to have a system which allows Modders to categorize Enitities like f.e. fire, water, air, flying, etc. Extending the exisiting Tag system has these benifits as far as I can see:

    • Modders will be able to categorize Entities properly allowing them to adapt their behaviour accordingly (like f.e. increase damage of a fireball, when hitting a water entity)
    • Users will be able to reference Entity-Tags in functions and commands, which might make others lives easier
    • Server owners (and maybe Modpack authors) will be able to configure behaviour changes in their games (like declaring certain entities with additional tags, or adding mod-compatibilty tags (depending on how far the PR goes, one could even change things like suddenly make an entity able to breathe underwater))

    This would not be able to prevent people from adding logically each other exculding tags (like f.e. attack/melee and attack/none), but I don't think that anyone who doesn't deliberatly want to destroy the game would add such contrasts...

    So what do you guys think? Should this be made a PR when 1.13 forge code rolls out?

    Edit: After some Feedback I came to the conclusion, that it might be a good idea to not only extend this to Entities (or EntityEntry's to be accurate) but to ForgeRegistries as a whole (though it would be disabled by default).

    The corresponding PR would then add an enableTagging() to the RegistryBuilder. This would also then result in tags being loaded for all ForgeRegistry's (Let's discuss below which should be excluded (SoundEvent and VillagerProfession? Though we could simply add no tags and let modders decide, whether they need it)), redirecting vanilla tagloading and tagsyncing to these (Items, Blocks and Functions will be loaded and synced the vanilla way, but the data will then be redirected to ForgeRegistry's instead of whatever Vanilla uses to store it...). This should ensure that Vanilla-Client-Forge-Server and the other way around will keep working correctly (as far as I know, Forge already has a mechanism, which sync's it's registries only with Forge-Forge connections, right?).

    Benefit: Not only could people do things as descirbed above and below with Entities, but things like f.e.:

    • wands working better in Biomes tagged with magic
    • only allowing enchantment of Items if the Enchantment has certain tags
    • manipulating effects of potions with certain tags
    • etc. ... (I think cross-Mod compatibilty in general will benefit of this)

    I'm sure you guys have more ideas than I have, what can be done with that...

    To be clear my PR will only address adding it to ForgeRegistries and doing some Entity compatibility within Vanilla code - for more I'd ask other people to find the places to add these to and submit PR's of their own (or tell me whilst I'm working on my PR, I can add it then), because I don't have the time to find every possible place for compatibilty with tags (I'm not even sure, whether I'll manage that with Entities, but I'll try)...

    1.13 Feature 
    opened by MajorTuvok 64
  • MAKE MAKING X-RAY MODS BASE CLEAN EASIER

    MAKE MAKING X-RAY MODS BASE CLEAN EASIER

    I made some mestakes in this commit, fix them... I rarely see x-ray mods for Forge so that's why I did this.

    opened by uyjulian 64
  • use json system for machine recipes

    use json system for machine recipes

    The json recipes system is extremely powerfull already. Modders can use custom factories, constants, conditions and custom ingredients to make very powerfull recipe input definitions.

    It would be great to leverage this system for machine crafting as well, i have started expermenting with this but found one major issue with this: everything loaded from JSON is mixed together in 1 general recipe registry.

    This means it could all work currently but it means that your IRecipe would need to always return false in the matches function to prevent recipes from being crafted in a regular crafting table and use a custom function (or instanceof check on the inventory)

    If we where to use it for machine recipes as well like it is right now it would also mean that they would all be in one giant list and slow down finding a maching crafting recipe significatly as next to all the vanilla recipes there would a a huge list of machine recipes to iterate through as well

    The sugestion: allow the factory to handle registring the recipe or configuring where/how to register in the registration of the factory. That way mods can leverage the power of this json system and its ingredient parsing easier and expose machine recipes for pack makers in the way other tweak mods did in the past natively

    Is this something the forge team is already considering/working on or would a PR be prefered?

    Stale 
    opened by AEnterprise 63
  • Inconsistent Attribute Modifier Order

    Inconsistent Attribute Modifier Order

    Currently, attribute modifiers added through the ItemAttributeModifierEvent are unreadable in the item tooltips because the order of the attribute modifiers is inconsistent in a HashMultimap and the attribute modifiers just keep on changing position on the tooltip. However, changing the attribute modifier HashMultimap to a LinkedHashMultimap causes the order of the attribute modifiers to be consistent and readable.

    opened by DavidQF555 1
  • Add methods to handle new lines and components in ForgeI18n

    Add methods to handle new lines and components in ForgeI18n

    Would like some feedback since i'm not sure if this is the right way forward for this

    opened by DarkEyeDragon 1
  • Fix the multilayer model using the missing model when a layer isn't defined.

    Fix the multilayer model using the missing model when a layer isn't defined.

    When a multilayer model is rendered in multiple layers, any layer that doesn't have an entry in the layer -> model map uses the 'missing model' model. This isn't usually an issue, as usually all layers are defined when using a multilayer model. However, when using multilayer models in conjunction with the multipart model, sometimes there are parts of the model that don't have every layer defined. This is when using the 'missing model' model causes problems. A workaround is to define a blank model whenever you don't want to draw a part of a model on a render layer. This PR fixes the problem by using an empty list of quads instead of the 'missing model' model.

    Short discord conversation with @gigaherz for reference: https://discord.com/channels/313125603924639766/725850371834118214/838041528605605899

    1.16 Bug Rendering 
    opened by mrp-v2 0
  • Make ForgeI18n#parseMessage return ITextComponents instead of Strings

    Make ForgeI18n#parseMessage return ITextComponents instead of Strings

    Currently they are parsed and returned as Strings. The big issue here is that they include the new line character which components don't support so converting them into components after parsing is a bit of a pain.

    A better solution would be to return a collection of text components if there should be new lines. (Or a single Textcomponent if just one line.)

    Feature 
    opened by DarkEyeDragon 2
  • Reinstate the MinecartCollisionHandler field to AbstractMinecartEntity

    Reinstate the MinecartCollisionHandler field to AbstractMinecartEntity

    Some time during the 1.12 update cycle, the IMinecartCollisionHandler functionality was moved out of EntityMinecart and into a new interface IForgeEntityMinecart. Unfortunately the static field containing the current handler was moved with it, and due to interface fields being implicitly public static final, and initialized to null, it (and the getter) became totally unusable.

    This PR moves the field and getter (plus the registerCollisionHandler function that was dropped in the move to the interface) back to AbstractMinecartEntity, making this field usable for vanilla minecarts again.

    Since AbstractMinecartEntity is such a usable and prominent template used in almost every mod that uses Minecarts nowadays, I also added comments calling for the removal of the IForgeEntityMinecart field and getter, since it's (normally) impossible for them to return anything except null.

    1.16 Assigned Bug 
    opened by TheCurle 6
  • Comply with PlayerEvent.BreakSpeed's pos being nullable.

    Comply with PlayerEvent.BreakSpeed's pos being nullable.

    As @malte0811 noted in #7615, the BreakSpeed event is fired with Nullable position: https://github.com/MinecraftForge/MinecraftForge/blob/19f8d2a7937dc7968ecbef2f9785687193fcd210/patches/minecraft/net/minecraft/entity/player/PlayerEntity.java.patch#L100-L108

    but the event itself just passes it through with no double checking. The javadoc mentions that a y position of -1 indicates unknown position, so I added a null check:

    this.pos = pos != null ? pos : new BlockPos(0, -1, 0);
    

    This retains compatibility with mods that were written according to the javadoc, and avoids an accidental breaking change.

    Closes #7615.

    1.16 Assigned Bug 
    opened by TheCurle 0
  • Fix OBJ Loader Generator's

    Fix OBJ Loader Generator's "materialLibraryOverride" string

    The OBJ Loader datagen provider previously added a key called materialLibraryOverrideLocation, but the OBJ Loader itself is looking for materialLibraryOverride: https://github.com/MinecraftForge/MinecraftForge/blob/19f8d2a7937dc7968ecbef2f9785687193fcd210/src/main/java/net/minecraftforge/client/model/obj/OBJLoader.java#L67

    Closes #7616

    1.16 Assigned Bug 
    opened by TheCurle 0
  • Fix old assumption that ItemStacks may be null in FluidBucketWrapper

    Fix old assumption that ItemStacks may be null in FluidBucketWrapper

    Previously, FluidBucketWrapper#canFillFluidType checked for getBucket(...) returning null. ItemStacks now use ItemStack.EMPTY rather than null. Closes #7670.

    1.16 Assigned Bug 
    opened by TheCurle 0
  • Replace hardcoded check for dirt in AnimalEntity#checkAnimalSpawnRules.

    Replace hardcoded check for dirt in AnimalEntity#checkAnimalSpawnRules.

    Changes the check for Blocks.GRASS_BLOCK to a new Forge tag, creatures_can_spawn, which contains grass block by default. Mods can add to this tag to make creatures spawnable on their custom blocks.

    Closes #7685

    opened by TheCurle 1
  • Add a small event to retrieve the dynamic registries as soon as they're ready.

    Add a small event to retrieve the dynamic registries as soon as they're ready.

    Full credit to Commoble for locating the proper place to inject this, and for providing the base of the test mod.

    The new DynamicRegistriesLoadedEvent (name pending rethink) serves a similar purpose to the BiomeLoadingEvent.
    The main difference is that it allows direct access to the baked representation of JSON datapack objects.
    It provides the DynamicRegistries.Impl object that contains all seeded objects from the Forge registries, and all JSON objects from datapacks, rather than just the Builder for a specific biome with no other objects available.

    DynamicRegistries contains baked objects, which means that directly editing any object involved requires some reflection or AT, but having one centralized place to acquire the full list of these objects is more conducive to having these improvements in future..

    Ideally, we would pass the Dynamic Registries impl to the BiomeLoadingEvent to get the best of both worlds, but the timings of both events would have to be drastically altered in order to achieve that.

    Whereas before, in order to add a ConfiguredFeature to a vanilla biome, you had to either:
    a) create and register the feature in code, add it to a biome via the BiomeLoadingEvent, or b) create the feature in JSON, add it to a biome by overwriting the biome with json,
    this PR allows mods to create the feature in JSON and add it to a biome's world generation settings directly, which makes customization and compatibility automatic due to the DynReg containing only the ultimate object.
    (pending another PR to make that easier)

    To reiterate, this PR allows mods to both a) use JSON worldgen customization, and b) allow other mods (or just ordinary user datapacks) to change those JSON worldgen customizations. Both A and B are not possible with BiomeLoadingEvent, because it fires after the DynReg is discarded.

    A small test mod is included that covers vanilla deserts in gold blocks using this feature: image

    As compatibility between worldgen mods is currently shaky, I plan to test this in various places before opening this PR for full scrutiny.

    Tests to run: ☑Datapack feature added to code biome
    ☑Datapack feature overwriting BiomeLoadingEvent feature
    ☐ Datapack feature overwriting other datapack feature between mods

    opened by TheCurle 7
Owner
Minecraft Forge
Minecraft Forge
A fast, customizable and compatible open source server for Minecraft: Java Edition

Glowstone A fast, customizable and compatible open source server for Minecraft: Java Edition. Introduction Glowstone is a lightweight, from scratch, o

Glowstone Project 1.4k Mar 15, 2021
Equivalent Exchange 3 Apache 2 Equivalent Exchange 3 pahimar Equivalent-Exchange-3. Mods for Minecraft. License: Apache 2 , .

Welcome to Equivalent Exchange 3! All versions are available here Minecraft Forums page Compiling EE3 - For those that want the latest unreleased feat

Rob Davis 725 Apr 14, 2021
Primary repo for the Figura Project

Downloads Modrinth Curseforge Join the Discord! Figura REQUIRES the Fabric API to run. You can find the Fabric API here. Figura The Figura Project is

Zandra 82 Apr 7, 2021
🗺️ Minecraft map editor and mod

A Minecraft Map Editor... that runs in-game! With selections, schematics, copy and paste, brushes, and scripting! Use it in creative, survival in sing

EngineHub 1.9k Mar 14, 2021
A Minecraft DM manager

Livemessage Check out the trailer video here! Livemessage is a client-sided DM manager for Minecraft 1.12.2. It is inspired by older chat applications

Jasper Rebane 46 May 9, 2021
A Minecraft Mod for Fabric which aims to make Block Entity rendering faster and more customizable with almost no compromises.

Enhanced Block Entities EBE is a 100% client side mod for Minecraft on the Fabric mod loader which aims to increase the performance of block entity re

null 18 Mar 21, 2021
bedroom is a latest version fabric base for minecraft clients.

bedroom is a latest version fabric base for minecraft clients. this was made to serve as the base for beach house, i'm just making it public so others

beach house development 13 Apr 2, 2021
A minecraft mod that allows using minecrafts structure block based test system

MC Tester Mod This mod allows using the automated structure based test system Mojang created for minecraft. The test system is only partially included

2No2Name 11 Mar 23, 2021
please read README to see how to play this. and star me to help me! this is very helpful and thanksful for me.

Sharustry Mod Browser / 모드 브라우저로 다운로드하기 Only possible with 124 or higher, only can download "latest" release 124 버전 이상에서만 가능하고, 오직 가장 최근의 정식 릴리즈만 다운로드

Sharlotte 14 Mar 27, 2021
A minecraft mod that allows additional windows to be opened alongside the game

Breakout API BreakoutAPI is a Minecraft mod which allows developers to create new windows that run alongside Minecraft. All the windows run on the sam

Raph Hennessy 10 Mar 7, 2021
A Hypixel Skyblock Utilities mod

SkytilsMod A Hypixel Skyblock Utilities mod. Features General Client Side Custom Armor Colors Custom Command Aliases Griffin Burrow Locator and Waypoi

null 25 Mar 27, 2021
BuildCraft

Welcome to BuildCraft on GitHub Reporting an issue Please open an issue for a bug report only if: you are sure the bug is caused by BuildCraft and not

BuildCraft Team 1.2k Apr 21, 2021
A Fabric mod designed to improve the chunk performance of Minecraft.

C^2M-Engine A Fabric mod designed to improve the chunk performance of Minecraft. So what is C2ME? C^2M-Engine, or C2ME for short, is a Fabric mod desi

null 66 Apr 1, 2021
Minecraft 1.16.5 Utility Mod for Anarchy and Crystal PvP

Fabric 1.16.5 port for GameSense. A more interesting readme will be coming soon, but check out the main repo at https://github.com/IUDevman/gamesense-

null 14 Apr 18, 2021