As of lately, I have decided to make a coremod for minecraft 1.11. I'm using forge version 13.19.1.2189 with the mcp mappings snapshot from 11.2.2017.

I have I daresay pretty successfully made a coremod, most of the things stayed the same as they were in 1.7.10 and I was already familiar with Java bytecode and ASM.

So I implemented IFMLLoadingPlugin and pointed it to my transformer class. I added the 'FMLCorePlugin' attribute to the jar's manifest in the Gradle script. When I build the final artifact and load it in a normal runtime environment it works as expected. That's because Forge/FML knows where to find my plugin.

Since running a configuration in a dev env (using IntelliJ IDEA, personally) just puts all the files in a big classpath blob, there is no manifest for Forge/FML to read the location of my plugin from.My question is, whether there is some magic command line option for the instance that tells Forge/FML that there is an IFMLLoadingPlugin that needs loading.
In 1.7.10, something along the lines of -Dfml.coremods.load=<class> could be used, but I tried that and Mojang's

Main.java told me it would ignore the argument because it apparently doesn't know what to do with it:
 

[main/INFO]: Running with arguments: [..., --tweakClass, net.minecraftforge.fml.common.launcher.FMLTweaker, -Dfml.coremods.load=<pkg>.<modid>.asm.<ModId>Plugin, --tweakClass, net.minecraftforge.gradle.tweakers.CoremodTweaker]

 

[main/INFO]: [net.minecraft.client.main.Main:main:59]: Completely ignored arguments: [-Dfml.coremods.load, <pkg>.<modid>.asm.<ModId>Plugin]

 

I tried it in a few different variations, like -Dfml.coremod.load= or -Dfml.coreMods.load= etc.

I looked through the source code, and I found that there is a --tweakerClass option, but it expects an ITweaker, and not an IFMLLoadingPlugin, which is what I have (crashes if one uses the wrong type, tested that much).

I can test the mod in a regular instance, but building the archive, copying it over and restarting minecraft is tedious and doesn't easily allow for debugging.

If there are other command line options, I would be delighted to get to know about those as well, or even better where one can find them.

 

Thanks for taking your time reading this.

 

(There are really few resources on coremodding in general)

Don't make a coremod.

Alternative options, to be used in order:

 - Use APIs

 - Use Events

 - Use Reflection

 - Ask on the forums, you probably missed how to do one of the above

 - Make a Forge Pull Request on GitHub

 - Still don't make a coremod

I guess I should have expected such a reply...

I don't need help with the decision of whether or not making a coremod is the right thing. I have already decided on that.

 - There are no APIs for this purpose. This is defined by how Minecraft at the core defines its methods (ie. a method taking ItemStack as a param in Item.java instead of a method in ItemStack.java; this would not really work because making modders extend ItemStack is just plain old stupid, but sometimes you have to change the behaviour of a method defined in Item.java that is ItemStack-sensitive.)

 - Although there is an event that could potentially be used to achieve this, the behaviour would not be fully equivalent to what I had in mind and how it works right now, and it would be unnecessarily inefficient.

 - Reflection cannot modify methods' bytecode, we use ASM or other instrumentation APIs to do that.

 - I shall think not, there is the event thing, also catching all itemstack creation events and replacing with a wrapper itemstack should work, but a coremod is a cleaner solution imho.

 - The hooks I am implementing are far too specific to be included in forge. There is no reason for these hooks to exist, I don't think, so unless the guys at forge want to add a hook to literally every method there is, I don't think this is a viable option.

 - It is very unlikely that any other coremod would instrument on the methods I am modifying, and my change is very unaggressive (scanning for a return statement, only inserting a hook before it to modify the value already on the stack, aborting if the method is drastically changed from what the code expects... There are a lot of good bytecode manipulation techniques and rules of thumb out there). And, if you still don't think that making a coremod is a good idea in my case, let's say it's for educational purposes. You can't deny that making a coremod is a good idea for the sole purpose of learning how coremodding works.

 

I am fully aware though that in most cases making a coremod is not a good idea, and understand why you would want to stop me from doing so. I still want to make a coremod, and I only want to know how to do this one singular thing. Please.

Why would they not be supported by Forge when it is essentially Forge who adds them?

 

Pls understand me I could do the thing without a coremod but I want to make a coremod. The chanches of anyone evr using this in their game is like low to non-existent.

 

I just want to know how to load coremods in a dev-env. I think Forge should be able to do that?

Edited February 13, 20178 yr by HashtagShell

Do not create coremods. There is no reason to. Especially in actively developed versions. And especially if you admit that you can do it without a coremod.