everyone likes forge because it makes modding easier for modders, and it makes installing them easy, there are also a few more reasons, but i'm too lazy to list them. and modloader is dead now the latest version is for 1.6.2
everyone likes forge because it makes modding easier for modders, and it makes installing them easy, there are also a few more reasons, but i'm too lazy to list them. and modloader is dead now the latest version is for 1.6.2
I know it is dead but how. And why do people care about the easiness of installing mods.
Well it isn't dead EXACTLY, but VERY little people use it now. I'm trying to download it for 1.5.2 but it won't work apparently.
I know it is dead but how. And why do people care about the easiness of installing mods.
Well it isn't dead EXACTLY, but VERY little people use it now. I'm trying to download it for 1.5.2 but it won't work apparently.
use multimc 5, it should work. and some people might not want to mess with the jar file, while forge uses a drag and drop system to install its mods, and most, if not ALL modloader mods can be recreated with forge, such as the biospheres mod
I saw the website. What does it exactly do?
Also, the forge one is a HORRIBLE version of it. I tried the forge version.
multimc 5 let's you install jar mods for 1.6 and up, and it also makes completely separate instances of minecraft (separate save folders, mod folders, etc)
multimc 5 let's you install jar mods for 1.6 and up, and it also makes completely separate instances of minecraft (separate save folders, mod folders, etc)
1. download multimc 5, 2. create a 1.5.2 instance, 3. click on edit instance, 4. click on install jar mod, 5. install modloader like you would normally
1. download multimc 5, 2. create a 1.5.2 instance, 3. click on edit instance, 4. click on install jar mod, 5. install modloader like you would normally
So I'm just wondering. As soon as forge came out, suddenly, ALMOST EVERYONE liked it and got it. Why is that?
Also, how on earth do you download modloader.
I'll explain the advantages and disadvantages of both APIs while keeping a non-bias opinion on it all.
Both are a mod which provides a framework for other mods to be loaded with decreased chance of conflicts. This means the user can install more mods in their game without things breaking.
The difference is how both APIs actually do this.
ModLoader is a simplistic API that really only provides the utmost necessary hooks, such as hooks to add blocks and items, recipes, names, entities (to an extent), etc. It also provides a simple hook to have some logic be performed every tick relative to a type of logic (so player and world ticks), so using this you could have some logic that is not bound to a block, item or entity. However, because ModLoader was formed before the official release of Minecraft, it was really only designed for a handful of mods to be used, as back then you would rarely see more than 20 or so mods at once (the mods were just incompatible with each other), so if you installed too many mods things just wouldn't work, at times even installing two mods had a 50/50 chance of breaking your game. The reason why was ModLoader simply "piggybacked" on functionality provided by the vanilla game. For a mod to add it's own textures, ModLoader provided a hook to inject a texture into the sheet object stored in memory, basically allowing a mod to add a texture to the vanilla spritesheet, without actually doing so (a tricky thing to wrap your head around if you're not a programmer). Minecraft spritesheets have 256 slots available (0 - 255), and Mojang probably used 2 thirds of it, so that left a third to be used by mods. Mods would fill the sheet up quickly, this is the first issue you can have with installing mods, running out of sprite indexes. The second issue was out-of-reach of ModLoader, however Forge included a patch to fix it up. Back then there was also only 256 available block IDs, installing too many mods would mean running out of block IDs. Someone made a patch that raised this to 4096, but IIRC it wasn't very compatible with ModLoader, however Forge included a modified version of the patch.
Then came Minecraft 1.0, I call this the modding revolution, about this time many players found the world of modding and starting playing around with mods. Because of this, instead of less than 20 mods installed, you'd often find players trying to use way more than 20 mods at a time. ModLoader was never designed with large-scale modding in mind, so most instances broke. Where I think ModLoader officially died was during the 1.2 -> 1.3 update, when client and server were merged. The reason? In my opinion, because ModLoader didn't exactly adopt the new paradigm that modding took onboard. ModLoader was a pure client-only API, there wasn't any server support in ModLoader officially, and any server mods had to use ModLoaderMP, which in itself could have been a hassle to get working properly.
So advantages? Small, lightweight, easy-to-install if you knew how to, not very many points of error within ModLoader itself, provided a simple means of both installing and loading mods into the game. Disadvantages? Limited, not very compatible with most things, wasn't network-supportive (you had to install a completely different API to have network functionality, and mods made using ModLoader had to be recoded to support this other API), all mods were largely incompatible unless a patch was made or the developer stayed away from base editing or used Forge, most mods required ModLoader, AudioMod, ModLoaderMP and any other APIs needed. All in all, ModLoader was a very good API for the time, and the flaws weren't exactly an issue as the mods installed back then were mostly simple and small, and not many players had many mods installed. However ModLoader was very limited in what it provided by hooks, and if a developer wanted to do something not directly supported by ModLoader (which occurred often), they had to base edit which meant certain incompatibility without compatibility patches.
Forge is a huge API that really provides all the hooks that a developer can use in a mod. Need to add some data to an entity when it spawns? Use the event provided. Want to change what a HUD element looks like? Subscribe to the event that is fired when the HUD is drawn, narrow your result down to the specific element you want, check to make sure it is can be cancelled, cancel it and use your own rendering code to draw your own. What if a feature you need isn't added to Forge as a hook? Either write the hook code out and submit it as a PR to the Forge repo, or use ASM to change the bytecode as a last resort.
All the hooks that ModLoader provides, Forge also provides, and many many more. With Forge, you can add your own blocks and items, names, recipes, smelting recipes, and you can also do things such as use Wavefront OBJ models for more complex modelling, use events to really do anything you want when a specific event occurs, and if you cannot do something, you can use ASM as a last resort to modify the bytecode of a class as it's being built to add your own code and/or replace existing code in a class, and if you do it properly you can use ASM in a way that makes it compatible with other mods. With Forge you literally do not and can not base edit, the Forge team shuns base editing as that's one of the main reasons for mod incompatibilities. Forge also provides ways for inter-mod-communications, so your mod can talk to and interact with another mod, and your mod can also change and add functionality based on if the user has another mod installed.
Forge rolls several different APIs up into itself, such as the Ore Dictionary (this is the main API that is responsible for the player being able to make an item from one mod using resources from a completely different mod), the fluid API (allows a developer to add new and exceedingly customisable fluids, a developer can make a fluid flow stupidly slow or fast, float, follow "realistic" laws by way of having a body of fluid realistically "split up" to fill empty spaces just like in real life, and much more), a powerful model API (allowing for both Minecraft-ish models and custom Wavefront OBJ models to be loaded and rendered into the game), the Event API (allowing for a mod to respond to many different events so that they can react to an event and apply some code to said event's parameters without base editing), IMC API (allows two or more mods to talk to each other and relay messages / instructions back and forth), the ASM API (allows a developer to modify a class (thus modifying the code of said class) in real time as it is being fed to the JVM to be built, thus allowing pretty much indirect base edits, but if done well enough bytecode manipulation can overall have much less compatibility issues than direct base editing), and more. Forge also patches the vanilla source code to provide more functionality within vanilla game code, for example Forge adds a bunch of methods to the Block class to allow a mod to change specific properties of their block without base editing or going into too much trouble for a simple edit.
All in all, Forge is another great API, it is big and bulky, but all that size means it both packs a serious punch in what it provides for the developer, and also stays as quiet as a mouse when it comes to mod conflicts. Advantages? Incredibly easy to install for 1.6 and later (literally a 5-step process, download installer, run vanilla game once, install, run Forge profile once, install mods), very powerful, virtually no mod conflicts aside from trivial things that Forge cannot control (IDs, mismatching mod versions, duplicate mods, etc), only need to install Forge, no other APIs needed for mods aside from APIs made by the developer (although now with CB's DepLoader, all dependencies / APIs are automatically downloaded for you). Disadvantages? Big, bulky, can give false output (Forge seems to output stuff to the console saying something is a severe error, when really it's either a warning or something the user doesn't need to worry about), 1.6 to mid-1.7 are incompatible with Java 8 (but the user can just install Legacy Java Fixer to fix this problem), suffers from something I call "project size inertia" (basically, the bigger a project is, the harder it is to both get a change or new feature going, and stop a new feature that simply was / is a bad idea, Forge suffers from this greatly).
Another difference between ModLoader and Forge is how mods are actually coded for either API. In ModLoader, your code MUST follow what ModLoader wants it to be, your main mod class MUST be called "mod_ModNameHere", your main mod class MUST extend "BaseMod", you must have a "load()" method in your main mod class, and your main mod class must be in "net.minecraft.src", any deviation from these rules or any other rules means ModLoader won't be able to load, or even detect, your mod. Forge however uses ASM and reflection to dynamically search for your classes / methods. With Forge, you can name your main mod class whatever you want, it can extend and implement whatever other classes / interfaces you want it to, and overall you have free reign over it. The only thing is, you must annotate your main mod class with "@Mod(modid = "theidofyourmodhere", name = "ModNameHere", version = "1.0.0")", version can be left out if you're declaring it in your mcmod.info file, but modid and name must be declared. You can also name your methods anything you want, but they must be non-static (AFAIK), they must have FMLPreInitializationEvent as a parameter (or any other initialisation event), and must be annotated with "@EventHandler". In simple terms, ModLoader expects your code to be set out and named in a specific way, Forge only has a few rules in place but for the most part will actually look for your code, rather than expect it to be there the way it wants it to be.
Also, how on earth do you download modloader.
Link Removed
I know it is dead but how. And why do people care about the easiness of installing mods.
Well it isn't dead EXACTLY, but VERY little people use it now. I'm trying to download it for 1.5.2 but it won't work apparently.
use multimc 5, it should work. and some people might not want to mess with the jar file, while forge uses a drag and drop system to install its mods, and most, if not ALL modloader mods can be recreated with forge, such as the biospheres mod
Also, the forge one is a HORRIBLE version of it. I tried the forge version.
multimc 5 let's you install jar mods for 1.6 and up, and it also makes completely separate instances of minecraft (separate save folders, mod folders, etc)
Im trying to get 1.5.2 Modloader, HOW?
1. download multimc 5, 2. create a 1.5.2 instance, 3. click on edit instance, 4. click on install jar mod, 5. install modloader like you would normally
If you have to ask, you probably wouldn't understand why.
Ok will try that. Thanks :P.
Hopefully it isn't a virus >:)
As I explained to you, you need to grow up. You can post things ABOUT mods.
But seriously. If I am not supposed to post here, then tell me WHERE?
Right near the top of the mod section of the forum
Mods Discussion
I'll explain the advantages and disadvantages of both APIs while keeping a non-bias opinion on it all.
Both are a mod which provides a framework for other mods to be loaded with decreased chance of conflicts. This means the user can install more mods in their game without things breaking.
The difference is how both APIs actually do this.
ModLoader is a simplistic API that really only provides the utmost necessary hooks, such as hooks to add blocks and items, recipes, names, entities (to an extent), etc. It also provides a simple hook to have some logic be performed every tick relative to a type of logic (so player and world ticks), so using this you could have some logic that is not bound to a block, item or entity. However, because ModLoader was formed before the official release of Minecraft, it was really only designed for a handful of mods to be used, as back then you would rarely see more than 20 or so mods at once (the mods were just incompatible with each other), so if you installed too many mods things just wouldn't work, at times even installing two mods had a 50/50 chance of breaking your game. The reason why was ModLoader simply "piggybacked" on functionality provided by the vanilla game. For a mod to add it's own textures, ModLoader provided a hook to inject a texture into the sheet object stored in memory, basically allowing a mod to add a texture to the vanilla spritesheet, without actually doing so (a tricky thing to wrap your head around if you're not a programmer). Minecraft spritesheets have 256 slots available (0 - 255), and Mojang probably used 2 thirds of it, so that left a third to be used by mods. Mods would fill the sheet up quickly, this is the first issue you can have with installing mods, running out of sprite indexes. The second issue was out-of-reach of ModLoader, however Forge included a patch to fix it up. Back then there was also only 256 available block IDs, installing too many mods would mean running out of block IDs. Someone made a patch that raised this to 4096, but IIRC it wasn't very compatible with ModLoader, however Forge included a modified version of the patch.
Then came Minecraft 1.0, I call this the modding revolution, about this time many players found the world of modding and starting playing around with mods. Because of this, instead of less than 20 mods installed, you'd often find players trying to use way more than 20 mods at a time. ModLoader was never designed with large-scale modding in mind, so most instances broke. Where I think ModLoader officially died was during the 1.2 -> 1.3 update, when client and server were merged. The reason? In my opinion, because ModLoader didn't exactly adopt the new paradigm that modding took onboard. ModLoader was a pure client-only API, there wasn't any server support in ModLoader officially, and any server mods had to use ModLoaderMP, which in itself could have been a hassle to get working properly.
So advantages? Small, lightweight, easy-to-install if you knew how to, not very many points of error within ModLoader itself, provided a simple means of both installing and loading mods into the game. Disadvantages? Limited, not very compatible with most things, wasn't network-supportive (you had to install a completely different API to have network functionality, and mods made using ModLoader had to be recoded to support this other API), all mods were largely incompatible unless a patch was made or the developer stayed away from base editing or used Forge, most mods required ModLoader, AudioMod, ModLoaderMP and any other APIs needed. All in all, ModLoader was a very good API for the time, and the flaws weren't exactly an issue as the mods installed back then were mostly simple and small, and not many players had many mods installed. However ModLoader was very limited in what it provided by hooks, and if a developer wanted to do something not directly supported by ModLoader (which occurred often), they had to base edit which meant certain incompatibility without compatibility patches.
Forge is a huge API that really provides all the hooks that a developer can use in a mod. Need to add some data to an entity when it spawns? Use the event provided. Want to change what a HUD element looks like? Subscribe to the event that is fired when the HUD is drawn, narrow your result down to the specific element you want, check to make sure it is can be cancelled, cancel it and use your own rendering code to draw your own. What if a feature you need isn't added to Forge as a hook? Either write the hook code out and submit it as a PR to the Forge repo, or use ASM to change the bytecode as a last resort.
All the hooks that ModLoader provides, Forge also provides, and many many more. With Forge, you can add your own blocks and items, names, recipes, smelting recipes, and you can also do things such as use Wavefront OBJ models for more complex modelling, use events to really do anything you want when a specific event occurs, and if you cannot do something, you can use ASM as a last resort to modify the bytecode of a class as it's being built to add your own code and/or replace existing code in a class, and if you do it properly you can use ASM in a way that makes it compatible with other mods. With Forge you literally do not and can not base edit, the Forge team shuns base editing as that's one of the main reasons for mod incompatibilities. Forge also provides ways for inter-mod-communications, so your mod can talk to and interact with another mod, and your mod can also change and add functionality based on if the user has another mod installed.
Forge rolls several different APIs up into itself, such as the Ore Dictionary (this is the main API that is responsible for the player being able to make an item from one mod using resources from a completely different mod), the fluid API (allows a developer to add new and exceedingly customisable fluids, a developer can make a fluid flow stupidly slow or fast, float, follow "realistic" laws by way of having a body of fluid realistically "split up" to fill empty spaces just like in real life, and much more), a powerful model API (allowing for both Minecraft-ish models and custom Wavefront OBJ models to be loaded and rendered into the game), the Event API (allowing for a mod to respond to many different events so that they can react to an event and apply some code to said event's parameters without base editing), IMC API (allows two or more mods to talk to each other and relay messages / instructions back and forth), the ASM API (allows a developer to modify a class (thus modifying the code of said class) in real time as it is being fed to the JVM to be built, thus allowing pretty much indirect base edits, but if done well enough bytecode manipulation can overall have much less compatibility issues than direct base editing), and more. Forge also patches the vanilla source code to provide more functionality within vanilla game code, for example Forge adds a bunch of methods to the Block class to allow a mod to change specific properties of their block without base editing or going into too much trouble for a simple edit.
All in all, Forge is another great API, it is big and bulky, but all that size means it both packs a serious punch in what it provides for the developer, and also stays as quiet as a mouse when it comes to mod conflicts. Advantages? Incredibly easy to install for 1.6 and later (literally a 5-step process, download installer, run vanilla game once, install, run Forge profile once, install mods), very powerful, virtually no mod conflicts aside from trivial things that Forge cannot control (IDs, mismatching mod versions, duplicate mods, etc), only need to install Forge, no other APIs needed for mods aside from APIs made by the developer (although now with CB's DepLoader, all dependencies / APIs are automatically downloaded for you). Disadvantages? Big, bulky, can give false output (Forge seems to output stuff to the console saying something is a severe error, when really it's either a warning or something the user doesn't need to worry about), 1.6 to mid-1.7 are incompatible with Java 8 (but the user can just install Legacy Java Fixer to fix this problem), suffers from something I call "project size inertia" (basically, the bigger a project is, the harder it is to both get a change or new feature going, and stop a new feature that simply was / is a bad idea, Forge suffers from this greatly).
Another difference between ModLoader and Forge is how mods are actually coded for either API. In ModLoader, your code MUST follow what ModLoader wants it to be, your main mod class MUST be called "mod_ModNameHere", your main mod class MUST extend "BaseMod", you must have a "load()" method in your main mod class, and your main mod class must be in "net.minecraft.src", any deviation from these rules or any other rules means ModLoader won't be able to load, or even detect, your mod. Forge however uses ASM and reflection to dynamically search for your classes / methods. With Forge, you can name your main mod class whatever you want, it can extend and implement whatever other classes / interfaces you want it to, and overall you have free reign over it. The only thing is, you must annotate your main mod class with "@Mod(modid = "theidofyourmodhere", name = "ModNameHere", version = "1.0.0")", version can be left out if you're declaring it in your mcmod.info file, but modid and name must be declared. You can also name your methods anything you want, but they must be non-static (AFAIK), they must have FMLPreInitializationEvent as a parameter (or any other initialisation event), and must be annotated with "@EventHandler". In simple terms, ModLoader expects your code to be set out and named in a specific way, Forge only has a few rules in place but for the most part will actually look for your code, rather than expect it to be there the way it wants it to be.
Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
My Github page.
The entire Minecraft shader development community now has its own Discord server! Feel free to join and chat with all the developers!