Multiple versions of Minecraft within Same minecraft.jar
Game Modes using specific ones
[UPDATE x2: Inside spoiler here, Click Below:
[ Mojang hired bukkit team to create Official Server API with Client modding support ]
Some Minecraft Modding-Support News:
Mojang is helping bukkit prepare for MC v1.2
4 main members of bukkit are working with Mojang, hired, to create a completely new Official Server API which will also support Client-side modding and will replace bukkit.
Today we can announce that the four main developers of bukkit ? a community-based Minecraft server implementation ? have joined ranks with Mojang to bring you the same flexibility and versatility to the official Minecraft server. The four, Warren Loo (@evilseph), Erik Broes (@_grum), Nathan Adams (@dinnerbone) and Nathan Gilbert (@tahgtahv), will work on improving both the server and the client to offer better official support for larger servers and server modifications.
The plan is to build a fresh server API, and then extend it to support client-side modding (in one way or another). We will try to make it easy for bukkit users to convert if they wish to do so, but backwards compatibility is not guaranteed. We will, however, help bukkit to be compatible with 1.2, to avoid having a long gap while you wait for the official Minecraft server to catch up.
Many of you may ask why we decided to work with bukkit instead of other Minecraft teams, such as Spout or Forge. The reason is that we want more than just modding, and these guys have always had server admins in mind when developing their additions to the game. We hope that this will help the quality of Minecraft multi-player to improve, both for large and private family servers, while still being able to add fun stuff for the bigger audience.
In addition to the bukkit members, Daniel Kaplan (@kappische) will join to handle the project lead to coordinate Minecraft?s broader goals. I (@jeb_) will remain as lead developer and game designer for Minecraft.
This is a rewording and clarification of a concept that I've been pursuing for a while but perhaps this (below) will make the idea clearer and someone can let me know if it's possible, please:
Do any coders here know if it would be possible to have sub-folders within the minecraft.jar itself with complete but modded or alternate versions of minecraft ( the minecraft classes ) inside of those sub-folders?
And could you then have a world that's been made as a specific [Game Mode], such as with the Game Mode API, always use a specific version/copy of minecraft within a specific sub-folder in the jar?
That way, for instance, a Cubic Chunks or MineUp! modded version of minecraft could reside within a sub-folder and be the version automatically used by a World that was made with a [ Cubic World ] or [ MineUp! World ] Mode. Then any worlds made in the normal Modes would be Vanilla and always play as vanilla and vice-verse. Of course; once the [ Cubic World ] Game Mode were selected the person would then have the normal sub-options of Survival/Creative etc, or those could just be made as Primary options,
Of course; this would require that the Core primary version of minecraft in it's main .jar be specially modded for this, at least the initial menuing system. But this shouldn't affect anything else in the game.
I foresee a central unified modding system growing into this position. Worlds made this way could both use the code in a specific sub-folder as well as shared unified code/API's in this future Unified Modding System. This way, even if two different mods can't be used in the same world, or if you don't want them to be, you can still have them both available in the same minecraft.jar. btw: I realized what the acronym for central unified modding system would be, heh heh, so I shortened it to Unified Modding System. :wink.gif:
* It may work out that instead of necessarily always having entire versions of the minecraft.jar within sub-folders within the main minecraft.jar file that we could primarily have just a copy of the specific minecraft classes in each sub-folder that a specific mod needs to modify while the rest of each mod resides at the main level of the .jar. Then when that mod needs to access that class in-game it could be made to automatically use that sub-folder version of it, and the same with other mods that need to modify the same class. That way two mods that can't otherwise work together because they modify the same class might now be able to work together, though this may not work as desired in every case. Just something to think about.
** The game always works best though when modders are able to work together to combine both of their custom codes into the same class, or better yet when there is a comprehensive enough of a central API with hooks into those classes to enable those mods to do everything they need to do using only the API. :smile.gif:
I could also see something like a special version of MCPatcher being used to patch, manage, and install the alternate versions (or alternately modded copies) of minecraft into the minecraft.jar.
- A standardized means of dealing with mod config files and such that would normally be placed somewhere within the .minecraft folder would need to be devised since you will end up with multiple copies of the same mods in the same .jar.
++ Thanks go to Liquid Metal Slime for helping to distill my ideas on a mod unification system via the internal Folder method. :smile.gif:
Bergensten's next step is to work on the mod API for Minecraft, a feature that players have been yearning for.
"Until January I will be the only developer on Minecraft, so things will have to be slow initially. But my absolute main priority now is to create a mod API, because there is no way in hell I will be able to add as much content as the whole internet can do," he laughed.
"The game needs an API, so end users can obtain the mods without hassle.... I'm not going to do it all by myself though. We have a new programmer beginning in January, and we are talking to existing mod API teams, such as Bukkit, Minecraft Forge, and Minecraft Coder Pack."
As for an estimated release date for the API, the new Minecraft frontman suggested that we will see a release "no sooner than March."
** Ok! So it looks like Mojang will finally be working on their long promised Mod-API. And even better, they will be doing it with deep input from this Modding community!
Hopefully the members of our community which will be in contact with Jeb on a regular basis regarding this will be bringing all of the great ideas as well as concerns that we have to him and in a useful manner. :smile.gif:
+ I would hope that however Jeb implements this that he will at the least build in a good Mod-Manager Interface for the Launcher, and/or in-game, as well as allow deep Mod use of Game Modes etc. If he does that officially then he can keep the mods in a separate Mod folder and not need to have people alter the main minecraft.jar.
This, of course, is what we were all hoping for since long ago. Thankfully now it's actually in motion. :smile.gif: This is great news for all of us! :biggrin.gif:
[EDIT] Hmm, Will he also be working on making the entire game into a Server, even SSP, like they've been saying they would? Part of the idea with that was that you would only need one Mod-API and one set of mods instead of a separate one for Clients & Servers.
Just thought of this: it could use a modified ClassLoader; I believe that ModLoader already does something like this to load mods from the "mods" folder. If this were done, unloading classes would be difficult, but selectively loading classes should work quite well.
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)
Hello. I am glad others are seeing this vision. I have spoken to the author of 'mine up!' to help me develop the architecture of this kind of project. I already have a assorted list of things to do, involving a front-end gui system and containment for server services via mod containment and such. I ask of MineUp! author and Robinton to help me do the bottom work as far as frame work for the loading and access of mods.
In such a short time I have already seen tested and proven Modders offering ideas and methods by which a Unified Modding System could be implemented, as well as Commitments by others who already have code and ability that could make this a reality.
By what I am currently seeing I am hopeful that something can be made, agreed upon, and implemented that can give us all what we really want with this Game.
We all know that the majority of players have no interest in jumping through different hoops every week in order to have some fun, especially when the core of this game resides on people investing their precious time developing their personal Minecraft world, and NOT losing it..
Whatever else happens, we already know at this point that telling people they either HAVE to use one mod or another will no longer fly. These days that just means that they will generally go with the mod that works with more of the other mods that they like or start using a system that allows them to have multiple copies of Minecraft installed.
** I believe that both Modders and Players, often one and the same, want the same thing. I also believe that both can have everything they want, with no compromises.
by the way: Please don't be upset if you don't get a +1 from me right away. I'm already out of them and get so few per day by this forum... Plus, you all know how many different threads I visit and spend my +1's in every day. :wink.gif:
This is quite a good idea! And even one of the developers of MCP has seen this thread!
This means you can install every mod available without worrying that it will crash your game. You just load your game, create a new world, select which game mode you want, and there you go.
Although i'm wondering now, if you do want to use several mods in 1 world, how would you do that?
Can you choose the mods in a list?
And of course this also has to be available in multiplayer.
And the last thing, you want 1 API for everything? So that API handles dimension creation, world generation, new blocks and all other stuff. This would be a very great idea, I get irritated if I like a mod but it needs like 3 API's, and then for a different mod you need to install 2 more API's...
Now hope Notch will see this and implement it in the game, so the modders could work with that.
I think you should also ask Risugami the creator of ModLoader to join the project, since he has experience with working with loading mods and stuff.
Thank you for your questions. I've seen you before and I know that you love mods and want the best for them.
In answer to one of your questions; If an entire copy of minecraft is kept in a subfolder within the minecraft.jar, perhaps several of them, then any mods could be applied to any of those sub-folder copies of the game. Easy. In fact, something like MCPatcher could do it without breaking a sweat. Each sub-folder, with such a tool, could get it's own install of each mod.
A post has, of course, been made to Risugami's thread. How could I not? And also to the Forge thread. Unfortunately; there are so many other modders and threads that I believe should also be included. As such; I have entrusted a copy of the invite to the MCP thread as well. I trust that all Modders check the MCP thread from time to time.
I guess that this issue serves to highlight the scattered nature of the current Modding Community. We all want the same thing, lets find a way to share resources to make it happen!
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.
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.
Thank you for mentioning this type of approach. I, in fact, have a long text file describing something similar to this, a Meta-Launcher design that I was about to release.
But I now think that this type of approach might be best.
One way or another; I would hope that something usefull will come from this thread.
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.
I had very similar idea. But in my solution if you leave the world and then re-enter it immediately minecraft.jar wouldn't be reloaded. It's too late here, so I'll describe it tomorrow.
Of course, the files in the main folder wouldn't necessarily have to be perfectly vanilla. For example, you could have simple mods in there that could be what you prefer to play with all the time, such as apple tree mods.
The "World Type" button could be modded to actually function, being able to be toggled between world generators that are in their own folders. Gamemode files could prevent certain world generators from being used with a particular gamemode, like ones that would cause significant problems or don't gel well together. For example, one of those flat worlds that are popular for building on could be modded as a World Type, but due to the fact that it would be impossible to survive there what with the lack of any trees, it could be modded to work with only Creative. Perhaps some mods that are World Type could even have an alternate terrain generator in the folder that would be used if a certain combination of gamemode/World Type were selected.
A "World Type Options" button would be useful, as they could fulfill the purpose of the config file that is used in alternate generators such as Biospheres, and it could be MineUp's world layer configuration menu. It could have options even in the "Normal" world type such as Flat Bedrock.
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
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 :tongue.gif:
Despite that modloader allows mods to be loaded from the mods folder, that kind of direction doesn't seem aparent by modloader. All the instructions say to add whatever mods zip file into your minecraft jar, yet you should be able to go to the .minecraft/mods folder and drop it there. Modloader should be whatever MC is missing to load mods from the mods folder and give you the GUI to select them in the games UI.
I think a combination of modloader, mcpatcher and gamemodes should be the idea. Something to fix the missing piece in MC, and add a UI layer that allows the user to select mods, configure mods, within the games UI.
TLDR version: Like the comic strip says.
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.
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 think the point (if just for the moment) is to not over-complicate things; create a system that works with exactly what we have in the modding community, which can be adapted once successful.
1) Auto-assigning IDs is an auto-include given the nature of the system, admittedly.
2) The order *should* always be specified, at least in the case of class conflicts and dependencies. Since this method of loading mods will remove the awkwardness of installing base-class mods, it'll be safe to assume that there will be times where mods have to be installed in a specific order for desired functionality.
3) While APIs and most dependencies tend to be backwards-compatible, this isn't always going to be the case. I'd suggest switching this out for a prompt to update should one of the mods that uses the API lists a more recent version as compatible or required. Control over the mods used should be kept as close to the player's hands as possible imo.
Though even that's probably over-complicating things. While I love theorycraft as much as the next guy, a proof-of-concept is what we need for the moment before making the idea too large.
I agree. We need a simple combination of what we have before we go further. I like the ideas of Mod World Creation options, per world auto-patching. It's a fantastic plan. But we need to have ONE API before expanding, otherwise we have a high risk of just creating another update layer or two on top of what we already have.
I can't see what this would have to do with an API; the idea as it stands falls somewhat under the same category as HDpatcher, just done in a far more convenient manner in regards to installing mods. The best way to create a new standard is to create something that doesn't actually replace any current standards, but instead allows people to use them.
We can talk of overthrowing the APIs after this is working.
It's not about overthrowing. I don't want to push those people out. I want them working together on a single mod API that incorporates everything all of them have done up to this point. There's just no reason to have Forge, ModLoader and ModLoaderMp as separate mods anymore. What you're talking about is exactly what I want to avoid. People are already complaining about the lag in update times. I don't want an ADDITIONAL mod on top of all the other API mods to exacerbate that problem. A collaboration on a single, overall API is the ideal for me, and no one better to do it than the original authors of the original API mods.
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.
Multiple versions of Minecraft within Same minecraft.jar
Game Modes using specific ones
[UPDATE x2: Inside spoiler here, Click Below:
[ Mojang hired bukkit team to create Official Server API with Client modding support ]
Some Minecraft Modding-Support News:
Official Mojang Statement (2012-02-28)
Minecraft Team Strengthened!
by Jens Bergensten on February 28, 2012
Today we can announce that the four main developers of bukkit ? a community-based Minecraft server implementation ? have joined ranks with Mojang to bring you the same flexibility and versatility to the official Minecraft server. The four, Warren Loo (@evilseph), Erik Broes (@_grum), Nathan Adams (@dinnerbone) and Nathan Gilbert (@tahgtahv), will work on improving both the server and the client to offer better official support for larger servers and server modifications.
The plan is to build a fresh server API, and then extend it to support client-side modding (in one way or another). We will try to make it easy for bukkit users to convert if they wish to do so, but backwards compatibility is not guaranteed. We will, however, help bukkit to be compatible with 1.2, to avoid having a long gap while you wait for the official Minecraft server to catch up.
Many of you may ask why we decided to work with bukkit instead of other Minecraft teams, such as Spout or Forge. The reason is that we want more than just modding, and these guys have always had server admins in mind when developing their additions to the game. We hope that this will help the quality of Minecraft multi-player to improve, both for large and private family servers, while still being able to add fun stuff for the bigger audience.
In addition to the bukkit members, Daniel Kaplan (@kappische) will join to handle the project lead to coordinate Minecraft?s broader goals. I (@jeb_) will remain as lead developer and game designer for Minecraft.
Rock Paper Shotgun - Article
[ UPDATE at Bottom of this post! ]
This is a rewording and clarification of a concept that I've been pursuing for a while but perhaps this (below) will make the idea clearer and someone can let me know if it's possible, please:
Do any coders here know if it would be possible to have sub-folders within the minecraft.jar itself with complete but modded or alternate versions of minecraft ( the minecraft classes ) inside of those sub-folders?
And could you then have a world that's been made as a specific [ Game Mode ], such as with the Game Mode API, always use a specific version/copy of minecraft within a specific sub-folder in the jar?
That way, for instance, a Cubic Chunks or MineUp! modded version of minecraft could reside within a sub-folder and be the version automatically used by a World that was made with a [ Cubic World ] or [ MineUp! World ] Mode. Then any worlds made in the normal Modes would be Vanilla and always play as vanilla and vice-verse. Of course; once the [ Cubic World ] Game Mode were selected the person would then have the normal sub-options of Survival/Creative etc, or those could just be made as Primary options,
[ Cubic Survival ] [ Cubic Creative ] [ Cubic Zombie Apocalypse ]. :wink.gif:
Of course; this would require that the Core primary version of minecraft in it's main .jar be specially modded for this, at least the initial menuing system. But this shouldn't affect anything else in the game.
I foresee a central unified modding system growing into this position. Worlds made this way could both use the code in a specific sub-folder as well as shared unified code/API's in this future Unified Modding System. This way, even if two different mods can't be used in the same world, or if you don't want them to be, you can still have them both available in the same minecraft.jar. btw: I realized what the acronym for central unified modding system would be, heh heh, so I shortened it to Unified Modding System. :wink.gif:
* It may work out that instead of necessarily always having entire versions of the minecraft.jar within sub-folders within the main minecraft.jar file that we could primarily have just a copy of the specific minecraft classes in each sub-folder that a specific mod needs to modify while the rest of each mod resides at the main level of the .jar. Then when that mod needs to access that class in-game it could be made to automatically use that sub-folder version of it, and the same with other mods that need to modify the same class. That way two mods that can't otherwise work together because they modify the same class might now be able to work together, though this may not work as desired in every case. Just something to think about.
** The game always works best though when modders are able to work together to combine both of their custom codes into the same class, or better yet when there is a comprehensive enough of a central API with hooks into those classes to enable those mods to do everything they need to do using only the API. :smile.gif:
I could also see something like a special version of MCPatcher being used to patch, manage, and install the alternate versions (or alternately modded copies) of minecraft into the minecraft.jar.
- A standardized means of dealing with mod config files and such that would normally be placed somewhere within the .minecraft folder would need to be devised since you will end up with multiple copies of the same mods in the same .jar.
++ Thanks go to Liquid Metal Slime for helping to distill my ideas on a mod unification system via the internal Folder method. :smile.gif:
[UPDATE]
Jeb's Mod API
From new GamaSutra article:
** Ok! So it looks like Mojang will finally be working on their long promised Mod-API. And even better, they will be doing it with deep input from this Modding community!
Hopefully the members of our community which will be in contact with Jeb on a regular basis regarding this will be bringing all of the great ideas as well as concerns that we have to him and in a useful manner. :smile.gif:
+ I would hope that however Jeb implements this that he will at the least build in a good Mod-Manager Interface for the Launcher, and/or in-game, as well as allow deep Mod use of Game Modes etc. If he does that officially then he can keep the mods in a separate Mod folder and not need to have people alter the main minecraft.jar.
This, of course, is what we were all hoping for since long ago. Thankfully now it's actually in motion. :smile.gif: This is great news for all of us! :biggrin.gif:
[EDIT] Hmm, Will he also be working on making the entire game into a Server, even SSP, like they've been saying they would? Part of the idea with that was that you would only need one Mod-API and one set of mods instead of a separate one for Clients & Servers.
- The Cubic Chunks Mod is back! Be a part of it's rebirth and Development.
-- Robinton's Mods: [ Mirror ] for some of his Mods incl Cubic Chunks Mod, due to DropBox broken links.
- Dungeon Generator for the Open Cubic Chunks Mod
- QuickSAVE-QuickLOAD for the Open Cubic Chunks Mod
This is decidedly good!
In such a short time I have already seen tested and proven Modders offering ideas and methods by which a Unified Modding System could be implemented, as well as Commitments by others who already have code and ability that could make this a reality.
By what I am currently seeing I am hopeful that something can be made, agreed upon, and implemented that can give us all what we really want with this Game.
We all know that the majority of players have no interest in jumping through different hoops every week in order to have some fun, especially when the core of this game resides on people investing their precious time developing their personal Minecraft world, and NOT losing it..
Whatever else happens, we already know at this point that telling people they either HAVE to use one mod or another will no longer fly. These days that just means that they will generally go with the mod that works with more of the other mods that they like or start using a system that allows them to have multiple copies of Minecraft installed.
** I believe that both Modders and Players, often one and the same, want the same thing. I also believe that both can have everything they want, with no compromises.
by the way: Please don't be upset if you don't get a +1 from me right away. I'm already out of them and get so few per day by this forum... Plus, you all know how many different threads I visit and spend my +1's in every day. :wink.gif:
Thank you for your questions. I've seen you before and I know that you love mods and want the best for them.
In answer to one of your questions; If an entire copy of minecraft is kept in a subfolder within the minecraft.jar, perhaps several of them, then any mods could be applied to any of those sub-folder copies of the game. Easy. In fact, something like MCPatcher could do it without breaking a sweat. Each sub-folder, with such a tool, could get it's own install of each mod.
A post has, of course, been made to Risugami's thread. How could I not? And also to the Forge thread. Unfortunately; there are so many other modders and threads that I believe should also be included. As such; I have entrusted a copy of the invite to the MCP thread as well. I trust that all Modders check the MCP thread from time to time.
I guess that this issue serves to highlight the scattered nature of the current Modding Community. We all want the same thing, lets find a way to share resources to make it happen!
- The Cubic Chunks Mod is back! Be a part of it's rebirth and Development.
-- Robinton's Mods: [ Mirror ] for some of his Mods incl Cubic Chunks Mod, due to DropBox broken links.
- Dungeon Generator for the Open Cubic Chunks Mod
- QuickSAVE-QuickLOAD for the Open Cubic Chunks Mod
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.
Thank you for mentioning this type of approach. I, in fact, have a long text file describing something similar to this, a Meta-Launcher design that I was about to release.
But I now think that this type of approach might be best.
One way or another; I would hope that something usefull will come from this thread.
- The Cubic Chunks Mod is back! Be a part of it's rebirth and Development.
-- Robinton's Mods: [ Mirror ] for some of his Mods incl Cubic Chunks Mod, due to DropBox broken links.
- Dungeon Generator for the Open Cubic Chunks Mod
- QuickSAVE-QuickLOAD for the Open Cubic Chunks Mod
1) He promised API to be in 1.5... now it's 1.0.0 and still no API.
2) It's a bit different.
I had very similar idea. But in my solution if you leave the world and then re-enter it immediately minecraft.jar wouldn't be reloaded. It's too late here, so I'll describe it tomorrow.
Also, it's possible to make main menu a separate java app that is "between" launcher and minecraft.jar. Similarly to this mod: http://www.minecraftforum.net/topic/819387-mod-manager
The "World Type" button could be modded to actually function, being able to be toggled between world generators that are in their own folders. Gamemode files could prevent certain world generators from being used with a particular gamemode, like ones that would cause significant problems or don't gel well together. For example, one of those flat worlds that are popular for building on could be modded as a World Type, but due to the fact that it would be impossible to survive there what with the lack of any trees, it could be modded to work with only Creative. Perhaps some mods that are World Type could even have an alternate terrain generator in the folder that would be used if a certain combination of gamemode/World Type were selected.
A "World Type Options" button would be useful, as they could fulfill the purpose of the config file that is used in alternate generators such as Biospheres, and it could be MineUp's world layer configuration menu. It could have options even in the "Normal" world type such as Flat Bedrock.
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
I think a combination of modloader, mcpatcher and gamemodes should be the idea. Something to fix the missing piece in MC, and add a UI layer that allows the user to select mods, configure mods, within the games UI.
TLDR version: Like the comic strip says.
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.
"Learn from past ones" is one part of success.
I agree. We need a simple combination of what we have before we go further. I like the ideas of Mod World Creation options, per world auto-patching. It's a fantastic plan. But we need to have ONE API before expanding, otherwise we have a high risk of just creating another update layer or two on top of what we already have.
It's not about overthrowing. I don't want to push those people out. I want them working together on a single mod API that incorporates everything all of them have done up to this point. There's just no reason to have Forge, ModLoader and ModLoaderMp as separate mods anymore. What you're talking about is exactly what I want to avoid. People are already complaining about the lag in update times. I don't want an ADDITIONAL mod on top of all the other API mods to exacerbate that problem. A collaboration on a single, overall API is the ideal for me, and no one better to do it than the original authors of the original API mods.
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.