As we all very well know, upon every game update we lose all mods we have. Any worlds with blocks that were added from a mod are then corrupt. What could possibly be implemented in order to support all mods upon updates, and to make a more universal way of creating mods? What things should be added to the game?
Idea list:
*All 'unknown' blocks are replaced with their ID number as a texture for all sides and are translucent, having the strength of glass. Upon update, all unknown blocks will not corrupt your world but just temporarily not look pretty. Same with all 'unknown' items. This would allow items to not get deleted upon an update... just lose their properties.
*A mod list in game available, in a manner like the texture packs are. Inside each mod zip file is a path that lists what folders need to change what. As in, most will edit Bin -> Minecraft.jar -> class files, or will add a mod_file. Etc. This will allow you to do what needs to be done. All conflicting mods will be lit up, a la Minecrafter.
*Upon update, not all mods are lost. The mods that are incompatible will state that they are incompatible and simply not function. Perhaps mandate a naming sequence where the first thing that needs to be written is "1.3_01 " so that every mod that is not the correct number will not work.
*For more texture pack mod support, the "HD patcher" should be unnecessary. It should automatically do it.
*Add systems to add new buttons to the menu for settings and systems. The control scheme menu could be able to be edited with further choices added from mods. Of course perhaps properties files could be added to each mod's folder so that even if the mod is disabled, the preferences are saved.
*Custom maps could be added in the game and generated with a custom seed, so specific seeds could be temporarily overwritten.
*More Block IDs would help to be added to the base game to allow more mods. It should detect new block creation and its ID so that they can be altered?
no doubt Mod Support will be implemented by dynamic class loading and checking for a certain interface.
At least, that's how I've done it in all my endeavours that required a plugin type architecture.
What this means is that:
new versions of minecraft will probably use the same interface definition for the plugins, so old plugins will continue to work, as long as nothing they do conflicts with things added in the latest version (for example, if it adds blocks that have the same ID as a block added in a new version of the base game there will be problems).
If the interface is updated, then it can be made into a new interface; say, iMinecraftPlugin2, that derives from the original plugin interface and adds the new functionality that way.
No doubt however mod support will include more then a single interface; it may mean that many of the internal classes and data structures of the game are exposed, which means that, for the most part, most mods can be "ported" without too much effort.
Idea list:
*All 'unknown' blocks are replaced with their ID number as a texture for all sides and are translucent, having the strength of glass. Upon update, all unknown blocks will not corrupt your world but just temporarily not look pretty. Same with all 'unknown' items. This would allow items to not get deleted upon an update... just lose their properties.
*A mod list in game available, in a manner like the texture packs are. Inside each mod zip file is a path that lists what folders need to change what. As in, most will edit Bin -> Minecraft.jar -> class files, or will add a mod_file. Etc. This will allow you to do what needs to be done. All conflicting mods will be lit up, a la Minecrafter.
*Upon update, not all mods are lost. The mods that are incompatible will state that they are incompatible and simply not function. Perhaps mandate a naming sequence where the first thing that needs to be written is "1.3_01 " so that every mod that is not the correct number will not work.
*For more texture pack mod support, the "HD patcher" should be unnecessary. It should automatically do it.
*Add systems to add new buttons to the menu for settings and systems. The control scheme menu could be able to be edited with further choices added from mods. Of course perhaps properties files could be added to each mod's folder so that even if the mod is disabled, the preferences are saved.
*Custom maps could be added in the game and generated with a custom seed, so specific seeds could be temporarily overwritten.
*More Block IDs would help to be added to the base game to allow more mods. It should detect new block creation and its ID so that they can be altered?
At least, that's how I've done it in all my endeavours that required a plugin type architecture.
What this means is that:
new versions of minecraft will probably use the same interface definition for the plugins, so old plugins will continue to work, as long as nothing they do conflicts with things added in the latest version (for example, if it adds blocks that have the same ID as a block added in a new version of the base game there will be problems).
If the interface is updated, then it can be made into a new interface; say, iMinecraftPlugin2, that derives from the original plugin interface and adds the new functionality that way.
No doubt however mod support will include more then a single interface; it may mean that many of the internal classes and data structures of the game are exposed, which means that, for the most part, most mods can be "ported" without too much effort.