One more question: how invasive will these API be? I mean, will it involve many base class replacements, or it will be mostly scripted on it's own loader and will enable only features requested by specific mods?
The main reason I'm interested in such API is that I'm rather disappointed in Forge's direction to modify base classes without looking at compatibility with non-forge mods.
Of course we have to do a DSL for modders, and DSL is not the part of API, there must be a way to do same thing on pure java.
What about DSL based on groovy?
Making a class loader interface accessible from certain mod's class sholdnt be much of a problem. A groovy-based DSL is as good as any, but it also should accept some sort of "templated java" as in my example - this will potentially increase auditory(since no knowlegde on how class loader works is required to make such file) and easen automatic generation of files, fetched just from sources of modified base classes.
What if modified base classes will be stored as diffs? This way multiple mods that modify same class can work together! (unless they modify same methods)
Meta may be stored as intercept methods(hooks) executed in chain - this would allow mods to modify same methods and work fine in some cases. An example input to MCAssist(working title of that my project, since it uses javassist to compile code):
In net.minecraft.src.BlockDirt:
public int quantityDropped( java.util.Random random ) {
if( ( random.nextInt() & 1 ) == 1 ) return 0;
return $call_next( $$ );
}
Which would make BlockDirt drop it's loot each second time, regardless on how that loot was modified by other mods. Some logic compatibility issues unavoidable of course, bu at least it's not crashes.
What value did you change it to? Block IDs 1-122 I think are used by Minecraft, so you may not use them(zero has reserved meaning). Also, run startclient.bat from your MCP directory to see the error in console window.
//Created by Xmr.winX////Copyright Xmr.winX 2011//
package net.minecraft.src;
public class BlockMoreBlock extends Block <--- not my mod_file to the side dont commet saying that
{
public int secondTex = ModLoader.AddOverride( "\terrain.png", "second texture.png" );
public BlockMoreBlock(int i, int j)
{
super(i, Material.iron);
blockIndexInTexture = j;
}
public int getBlockTextureFromSideAndMetadata( int side, int meta ) {
if( meta == 1 ) return secondTex;
else return blockIndexInTexture;
}
}
If metadata(damage id, as you say) is 1, blocks texture will be "second texture.png", otherwise whichever texture you've passed to constructor.
Well, this time error message is meaningful:
"Slot 120 is already occupied by net.minecraft.src.BlockEndPortalFrame@27982 when adding net.minecraft.src.CobbleLight@778255"
1
Yes, I've mentioned it in this thread. Didn't have much time to work on it sadly.
At load time atcually. This allows to assemble your modded minecraft in ram before running it.
0
The main reason I'm interested in such API is that I'm rather disappointed in Forge's direction to modify base classes without looking at compatibility with non-forge mods.
0
Making a class loader interface accessible from certain mod's class sholdnt be much of a problem. A groovy-based DSL is as good as any, but it also should accept some sort of "templated java" as in my example - this will potentially increase auditory(since no knowlegde on how class loader works is required to make such file) and easen automatic generation of files, fetched just from sources of modified base classes.
1
Meta may be stored as intercept methods(hooks) executed in chain - this would allow mods to modify same methods and work fine in some cases. An example input to MCAssist(working title of that my project, since it uses javassist to compile code):
Which would make BlockDirt drop it's loot each second time, regardless on how that loot was modified by other mods. Some logic compatibility issues unavoidable of course, bu at least it's not crashes.
0
That's why override annotations are useful - they assure that method with such signature exists in one of base classes.
0
0
0
0
If metadata(damage id, as you say) is 1, blocks texture will be "second texture.png", otherwise whichever texture you've passed to constructor.
0
0
0
0
Edis: oh, I see you figured that yourself. Maybe one of your blocks has id 313?
0
"Slot 120 is already occupied by net.minecraft.src.BlockEndPortalFrame@27982 when adding net.minecraft.src.CobbleLight@778255"
0