Testing showed that having things stored in a alchemical bag when you reload means no more items in bag.
No idea WHY this happens, but a bug is still a bug.
I don't know that mod, and i think that i will solve compatibility issues in a radical way - create my own modloader, more powerful than current one.
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.
I've been working on something like it lately - with a varying success thought. If I can help this project - I'll be glad to.
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, but at least it's not crashes.
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?
Guys, Upside Down is a part of Mine Up project, it will be compatible with 1.0.0 in next month.
Current version is for 1.8.1 and it contains OTHER SIDE OF THE WORLD!
I think it would be awesome to have a non-invasive mod adder to the game. By invasive, I mean something the mod maker doesn't need installed in order to make the mod. I think adding layers of wait time on top of what we already have (MC, then MCP), just adds soo many places for bugs and delays that shouldn't be there.
Yes, it will be sufficient API as a bukkit, modder don't have to decompile jars to start the work.
Quote from Pjstaab »
I think it's a great idea. Like modloader did it's job until more needed to be done, and then forge, etc, etc. Obviously newer systems will be able to learn from past ones and build on top of them to make them even better. The idea you currently have seems quite expandable and keeping everything modular to be able to add on new stuff easily. Now get working
I like the concept; I don't think the approach is quite right though.
The best solution I can think of (there are likely better ones out there, but still) would be to move all of the pre-game stuff into the launcher, and include a patcher in the launcher that automatically patches the jar with the mod files for a particular world when selected; then the jar is loaded and goes straight to world generation. This would have the added benefits of making all mods installation-friendly (ala 'put zip in mods folder'), and possibly allowing for the sharing of 'modpacks' through single text files containing the installation order and ID configs.
Lets do it with convention-over-configuration principle.
1) i want to make ID configs part of the world, generated automagically.
2) installation order doesn't matter, or if it matters, it can be specified in that txt file
3) api client include automatic update.
4) some mods will be stored in repository (for ex. apache ivy), client download them on demand
We want include some major changes under that API: multiple worlds in one dimension, gravity changing, dynamic block ids and other things. That changes can't be done on top of any API.
0
-never mind-
0
-never mind-.
0
T_34_85
0
0
I think not less than a week.
3
I am very glad that you completed our mod.
2
0
I don't know that mod, and i think that i will solve compatibility issues in a radical way - create my own modloader, more powerful than current one.
Bugreport from rus forum:
"Bug with torches (pig just flew past)"
0
Yes.
My method broke only one nether feature - fasttravel 1:8. But it works if nether is in separated dimension.
0
agreed.
1
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?
0
Current version is for 1.8.1 and it contains OTHER SIDE OF THE WORLD!
0
Yes, it will be sufficient API as a bukkit, modder don't have to decompile jars to start the work.
"Learn from past ones" is one part of success.
1
Lets do it with convention-over-configuration principle.
1) i want to make ID configs part of the world, generated automagically.
2) installation order doesn't matter, or if it matters, it can be specified in that txt file
3) api client include automatic update.
4) some mods will be stored in repository (for ex. apache ivy), client download them on demand
1
We want include some major changes under that API: multiple worlds in one dimension, gravity changing, dynamic block ids and other things. That changes can't be done on top of any API.