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]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [ ]

• [x]

• [x]

• [x]

• [x]

• [ ]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

• [x]

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

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.

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

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.

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

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.

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

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?

Updated version of #3642

Modified the code to work with 1.12.x changes

Fixed the java classes having 2 license headers Removed an useless condition inside GuiTabsMenu.addButtons And a few minor changes to use += and -= where possible Improved their functionality Removed redundant code Introduced Default Tabs:

• Added Vanilla Default Tabs (Inside DefaultVanillaGuiTabs.class)

A few refactors (name changes):

• GuiTabList.class -> GuiTabsMenu.class
• getLocalizedName -> getUnlocalizedName (thats what it always was getting, users should translate their names)

Location of the GuiTabs has been moved from player.inventory.tabs -> gui.tabs

Any suggestions for improvements are welcome

Known bugs (fixed):

• [X] The y pos of the paginator
• [X] Some tabs overlapsing with already added onces
• [X] wrong number of pages (displays additonal pages with empty/no tabs)
• [X] When clicking the recipe book, while there are additional tabs the paginator is off place
• [X] Double Chests Tab's Functionality
• [X] Player Recipe book support for paginator
• [X] Crafting Table Recipe book support for paginator

Credits to @ArtixAllMighty for making the original PR and @AshIndigo for updating it to 1.11.x

Just testing the waters to see how many modders would be receptive to the idea of a Permissions API in Forge, and how we should get around to doing it. I intend such a Permissions API to be extended by Sponge, ForgeEssentials and other such permissions-providing systems.

I know this isn't the first time I've raised the topic, but I feel it's an important one to discuss, especially with the return of "big" multiplayer servers based on the Sponge platform, which is pretty much feature-complete at this point.

• I have a current draft of the Permissions API available here.
• This API is sufficiently easy to use for modders (just call PermissionManager.checkPermission(player, "mymod.something.breakTheWorld"), you get back a boolean), and should stay that way.
• Currently, the API draft provides additional permission-checking 'contexts' based on location and entity. I'm looking for more feedback on this (should this be expanded? Removed? Converted to a capability?)
• One thing that can be considered is to add a PermissionActor capability, which would contain the entity doing the action (player? fakeplayer? TE?). This could be used to store a player reference to the owner of a machine, for example.

Outstanding issues:

• How should contexts be structured?

I'd like to hear feedback on this, so I would really appreciate it if you could put your thoughts about this in the comments.

Forge adds IForgeBlockgetBlockPathType method to allow mods to have their block change their pathfinding type based on conditions when a mob attempts to pathfind through it. One extremely useful use case is a block that lets certain entities pathfind through but not others.

The issue is in the static WalkNodeEvaluator$getBlockPathTypeRaw method where Forge patched in the Forge method, null is passed in for the mob. Rendering the mob parameter completely useless.

To fix this will require a breaking change that could be potentially affects quite a number of mods calling getBlockPathTypeRaw. It is a tricky spot. But as of right now, there's no way for a mod to be able to block the pathfinding of certain mobs through their block and allow other mobs which seems to be one of the main points of this Forge method and probably should be restored before the Recommended Build is created. Or overload methods could be made instead and deprecate vanilla methods (suggested by someone)

Confirmed to be happing in both 1.19.2 and 1.19.3 Forge in latest versions of Forge.

My use case is I am grabbing all entries of a block tag to randomly pick one block to spawn. Grabbing the tag entries is done with this code: Optional<HolderSet.Named<Block>> optionalBlocks = Registry.BLOCK.getTag(outputBlockTag);

However, what I found is if I had on another mod with blocks in that tag and then later I remove that mod, the HolderSet that the above code gets will now contain BlockDummyAir objects in place of the removed modded blocks. Which then causes my mod to place these dummy air blocks instead of picking from the currently existing blocks.

At first, I figured I could ignore the dummy air blocks by throwing in an isAir() check but that failed. It appears that dummy air blocks do not pass the isAir check which I would assume is a bug because Minecraft uses the isAir check all over to test for air at various parts. There may be other bugs hidden due to this failing air check with dummy air blocks.

Also, side question, what is the best way for me to test for these dummy air blocks besides my attempt with isAir? It seems the old DummyBlockReplacementTest class (which is now gone from Forge codebase) was testing for the dummy block by literally checking the object's class. Is this the proper way to test for dummy air blocks or is there a helper method somewhere that I should use instead?

This PR adds a new event AlterGroundEvent to do as the name of this PR implies.

The AlterGroundDecorator code by default checks for any blocks within the #minecraft:dirt tag for whether it can alter a ground block, which can be an issue for other mods' dirt blocks if they want them to be in the tag for other behavior but not be affected by things like large spruce trees grown from saplings creating podzol blocks. So, this adds an event that should allow for conditionally determining whether a block can be converted or not, or allow for changing what the created block is under certain conditions.

I debated solving this with a tag, but felt that solution would be too limiting.

TL;DR: This implements a workaround for a GitHub limitation.

In order to run PR opened and reviewed actions we need the autoforge App ID and key, which are usually given as secrets.
However, when workflows run on forks (like the pull_request, pull_request_review and pull_request_review_comment events, which run on the top commit of the branch to merge), we do not have access to secrets, as per the documentation:

With the exception of GITHUB_TOKEN, secrets are not passed to the runner when a workflow is triggered from a forked repository.

Bypassing

In order to bypass this, we are going to use workflow_run and action artifacts to "simulate" events, needing 2 workflows:

• a workflow which will run on pull_request_(review/review_comment): this workflow will upload its event payload json as an artifact;
• a workflow which will listen for completion of the above workflow (using workflow_run), and which will fake the event by replacing the payload with the one from the uploaded artifact. Unfortunately, we cannot use workflow_dispatch as the GITHUB_TOKEN from forks is read-only so we cannot dispatch an event using the API.

This fix can be seen in action in https://github.com/MinecraftForge/Actionable/pull/12.

Minecraft Version: 1.19.3

Forge Version: 44.0.48

Steps to Reproduce:

1. Download mdk
2. runclient
3. create new world
4. warning about experimental features

Description of issue: Previous issue for 1.18 having the same problem: https://github.com/MinecraftForge/MinecraftForge/issues/8414