From Minecraft Forge
This is a How-To guide or
detailing a practice or process for
or related .
This page was made for Minecraft 1.7.2 using Forge 10.12.0.967. It might not work with other versions.
A Core Mod (coremod or CoreMod) for
is a non- type mod that is loaded before any
classes are loaded. The purpose of a core mod is to patch actual Minecraft code. It grants access to modifying the source files directly via ,
class modification, or any other Java bytecode modification.
This is not advisable for default mods. Core mods inherently part of another mod should be kept as a separate project - do not try to merge the two.
Most programmers believe creating a core mod is necessary when they lack the knowledge of the API or approach the problem incorrectly. The following is a list of reasons to against creating core mods. It is not an exhaustive list.
Code instability
Time consumption
Lack of upward compatibility
Rewrite default functionality pipeline
The following sections introduce common thought processes mod programmers conclude regarding core mods. Each section explains a better solution or approach to the problem. These solutions may prevent the mod from becoming destructive, unstable, or losing Minecraft upwards compatbility.
(see also: ). It is fast and easy for few accesses. For multiple accesses that may slow Minecraft, consider .
If the class is not final, use
and extend the class.
Read about
for a tutorial.
Add a custom block or item, and then remove references (recipes, drops, to name a few) to the original (vanilla) block or item.
Alternatively, and only if need be, overwrite the object in the registries. Simply using ASM to rewrite functionality will destruct compatibility with other mods editing the same object anyway.
There are many
already included in Minecraft Forge. Many are generic enough to used in their own right or extended.
When there is a genuine usefulness, need, documented proposal, and no other event suits the purpose then possible options are:
for another programmer to implement
with your own approach at implementation
The more generic the event, the higher likelihood of its inclusion.
This problem is related to . Instead of adding functionality to a class, consider extending it. This adds power and flexibility to an existing parent without modification.
Also inspect the code closely to see how much you can achieve with static additions and/or reflection.
Though cases are rare, the need to modify the existing code may be the only solution. Some legitimate cases may include:
Intercepting all calls to non-Mojang methods (e.g. OpenGL) to replace default pipeline functionality
Running a -oriented code analyzer constructing functionality, in the form of code blocks or additional methods/fields, from variables, annotations, or similar, in mods
Add highly specific event hooks that are specific and only useful for the mod
A core mod always starts with an IFMLLoadingPlugin. Make a class implementing that interface.
Here are a few useful optional annotations to add:
@IFMLLoadingPlugin.Name(value = &MyCoreMod&) // The readable mod name@IFMLLoadingPlugin.MCVersion(value = &1.7.2&) // The MC version it is designed for (Remember? Upwards/Downwards compatibility lost!)@IFMLLoadingPlugin.TransformerExclusions(value = &mypackage.mycoremod.&) // Your whole core mod package - Whatever you don't want the transformers to run over to prevent circularity Exceptions@IFMLLoadingPlugin.SortingIndex(value = 1001) // How early your core mod is called - Use & 1000 to work with srg names
The class returned by getASMTransformerClass() must implement IClassTransformer
The class returned by getModContainerClass must implement ModContainer (preferably: extends DummyModContainer).
Remember to set the default mod metadata values (from super.getMetadata()) in the constructor of the mod container, and register it in the bus overwriting registerBus().
Now that you have your LoadingPlugin, you need it to be actually loaded.
Add the launch parameter -Dfml.coreMods.load= mypackage.mycoremod.MyCoreModLoadingPlugin
Add the following to your build.gradle file (Creating the manifest):
jar {        manifest {        attributes 'FMLCorePlugin': 'mypackage.mycoremod.MyCoreModLoadingPlugin',                        'FMLCorePluginContainsFMLMod': 'true'    }}
Optionally, setting FMLCorePluginContainsFMLMod: true, distributes both the core mod and FML mod in a single jar.
This is beyond the scope of this article. For further information, see
(Obsolete for Core Mods since 1.7 - UseCodeChickenCore Mod 1.8/1.7.10/1.7.2 | Minecraft Mods
& CodeChickenCore Mod 1.8/1.7.10/1.7.2
CodeChickenCore Mod 1.8/1.7.10/1.7.2
| By: chicken_bones
CodeChickenCore Mod provides you with all classes that all
mods use. It’s compulsory that you install this if you are going to install any of ChickenBones mods.
This goes in the COREMODS folder.
Changelogs:
v1.7.2 ? rc1
Update to Minecraft 1.7.2
Older versions:
For 1.7.10
Credits: chicken_bones
Related Posts
Where you can find out anything for utilities of Minecraft.}