I tried to reference the LaunchWrapper source but it wants a ton of libraries. Do I need to go download them all? Or am I doing this wrong?
Well you can either run the gradle script and it'll pull down the dependencies for you, or just pull the launchwrapper 1.8 binary direct off mojang's servers which is what I tend to do. You'll find the other dependencies as part of your minecraft installation anyway, with the exception of ASM, which you'll want the debug-all binary for.
Well you can either run the gradle script and it'll pull down the dependencies for you, or just pull the launchwrapper 1.8 binary direct off mojang's servers which is what I tend to do. You'll find the other dependencies as part of your minecraft installation anyway, with the exception of ASM, which you'll want the debug-all binary for.
Thanks! I just downloaded the ASM source archive and added it, will that work?
The Meaning of Life, the Universe, and Everything.
Join Date:
10/27/2012
Posts:
383
Member Details
You should consider using LiteLoader to make it load the BlazeLoader ML API. Try not reinventing the wheel! It's wasted effort and the users will really appreciate the additional compatibility.
Actually, you could make the Blaze Mod Loader API independent of the loader. Which would benefit everyone.
You should consider using LiteLoader to make it load the BlazeLoader ML API. Try not reinventing the wheel! It's wasted effort and the users will really appreciate the additional compatibility.
Actually, you could make the Blaze Mod Loader API independent of the loader. Which would benefit everyone.
Or one version for each loader?
Or a thin layer between each loader.
This is kind of what I was suggesting in my first post above, since liteloader is really just a loader building an API on top of it and using the version-checking and metadata stuff I already have could be worthwhile. That said, given that people still don't seem to see the difference between FML and Forge, it could be that LiteLoader would just disappear under the API, which would be a shame.
...people still don't seem to see the difference between FML and Forge, it could be that LiteLoader would just disappear under the API, which would be a shame.
That's a confusion caused by the Forge by calling everything Forge. LiteLoader is already well know as a loader.
That's a confusion caused by the Forge by calling everything Forge. LiteLoader is already well know as a loader.
Heh, not sure about "well known", but yeah I take the point I guess FML was seen to be under the Forge umbrella. It still seems a bit unfair to cpw since FML is really powerful system and nobody seems to realise that it's available without the whole Forge API.
You should consider using LiteLoader to make it load the BlazeLoader ML API. Try not reinventing the wheel! It's wasted effort and the users will really appreciate the additional compatibility. Actually, you could make the Blaze Mod Loader API independent of the loader. Which would benefit everyone. Or one version for each loader? Or a thin layer between each loader.
That is something to consider, but I have already written a functioning loader (the 3rd iteration of the same basic load system, actually) that is somewhat deeply built into the API at this point.
Heh, not sure about "well known", but yeah I take the point I guess FML was seen to be under the Forge umbrella. It still seems a bit unfair to cpw since FML is really powerful system and nobody seems to realise that it's available without the whole Forge API.
That is something to consider, but I have already written a functioning loader (the 3rd iteration of the same basic load system, actually) that is somewhat deeply built into the API at this point.
Fair enough, although feel free to steal ideas from mine then Just be aware that ModLoader's biggest weakness was the lack of metadata, and this is more crucial than ever now that players can load multiple different versions at once with the new launcher.
Yes, FML is "Forge ModLoader", a replacement for ModLoader and manages loading mods and such as well as the client/server comms and whatnot. Minecraft Forge is the API and does all the heavy lifting in terms of providing hooks and classes for mods to use.
Of course, and FML already loads ModLoader mods, although that support will be dropped in 1.7 because it would basically need a complete ground-up rewrite and that's not really feasible for something that's inherently quite poorly designed from the outset.
Fair enough, although feel free to steal ideas from mine then Just be aware that ModLoader's biggest weakness was the lack of metadata, and this is more crucial than ever now that players can load multiple different versions at once with the new launcher.
Yes, FML is "Forge ModLoader", a replacement for ModLoader and manages loading mods and such as well as the client/server comms and whatnot. Minecraft Forge is the API and does all the heavy lifting in terms of providing hooks and classes for mods to use.
Of course, and FML already loads ModLoader mods, although that support will be dropped in 1.7 because it would basically need a complete ground-up rewrite and that's not really feasible for something that's inherently quite poorly designed from the outset.
I have some code in place to help handle wrong versions of mods (that was always one of ModLoader's and until recently Forge's biggest issues) by including methods to allow mods to check the version of BL before anything has loaded, and when loading mods the loader will detect duplicates of already loaded mods and either skip them or replace them if they are newer than the already loaded version.
I have some code in place to help handle wrong versions of mods (that was always one of ModLoader's and until recently Forge's biggest issues) by including methods to allow mods to check the version of BL before anything has loaded, and when loading mods the loader will detect duplicates of already loaded mods and either skip them or replace them if they are newer than the already loaded version.
Metadata is still a more robust method than error handling, especially when the errors that may occur might happen outside of your handling code. But at least you've addressed the problem which is more than Risugami ever did!
Time to forcefully update Matmos and LittleMaidMob to 1.6.4.
I have been releasing a modified version of ModLoader since 1.6.1 and Risugami never complained. Although that could be because he disappeared before I released it...
I have been releasing a modified version of ModLoader since 1.6.1 and Risugami never complained. Although that could be because he disappeared before I released it...
I honestly don't think he cared for the community at all any more, and was just doing the smallest amount of work possible that would keep his ad.fly revenue trickling in, that may be horribly unfair to him and it may be that real life just took over, but it's what I strongly (personally) suspect.
Metadata is still a more robust method than error handling, especially when the errors that may occur might happen outside of your handling code. But at least you've addressed the problem which is more than Risugami ever did!
An older project of mine (on my github account) used a "PluginInfo.txt" file to doublecheck mod compatibility, but that was one extra step I wanted to get rid of for BL. Now you can literally hit "Build JAR" and put the unmodified jar strait into the mods folder. Although I do see your point and I will likely add that if I ever have to deprecate the current loading system.
An older project of mine (on my github account) used a "PluginInfo.txt" file to doublecheck mod compatibility, but that was one extra step I wanted to get rid of for BL. Now you can literally hit "Build JAR" and put the unmodified jar strait into the mods folder. Although I do see your point and I will likely add that if I ever have to deprecate the current loading system.
The way I see it it's a minescule extra bit of pain for the mod developer that can unfold into a lot of mitigated pain for the mod user, and that last extra bit of pain is immediately ameliorated if using ant/gradle/maven to build your mod anyway (as anyone sensible really should be).
I honestly don't think he cared for the community at all any more, and was just doing the smallest amount of work possible that would keep his ad.fly revenue trickling in, that may be horribly unfair to him and it may be that real life just took over, but it's what I strongly (personally) suspect.
When I first downloaded ModLoader (in beta) his FAQ section of his post really made it seem like he didn't care, and it never got better. Also he has been modding for far, far longer than me and has only 110 posts. But it could just be he really doesn't have time to worry about modding, and he has just been maintaining ModLoader and his mods out of courtesy to his users.
When I first downloaded ModLoader (in beta) his FAQ section of his post really made it seem like he didn't care, and it never got better. Also he has been modding for far, far longer than me and has only 110 posts. But it could just be he really doesn't have time to worry about modding, and he has just been maintaining ModLoader and his mods out of courtesy to his users.
Without any official word from him we'll never really know, but I think it's up to community members still present to provide good avenues for players to follow in his stead. My biggest fear really is that someone will just make some half-assed "modloader reloaded" basically taking his stuff and recompiling it against the new codebase, I feel like that would be the most damaging thing given how creaky and outdated modloader is, keeping it on life support would seem to be the most damaging thing anyone could do, especially if it were just to grab glory for themselves without really caring about the community either.
That's why I'm actually really glad you're undertaking this and why I'm trying to offer you as much help as I can, choice is good, moving forward is good, and people respect you already for providing the modloader patches so I think they'll take your API seriously. This is all good, someone trying to keep modloader alive is the biggest potential bad waiting to happen.
The way I see it it's a minescule extra bit of pain for the mod developer that can unfold into a lot of mitigated pain for the mod user, and that last extra bit of pain is immediately ameliorated if using ant/gradle/maven to build your mod anyway (as anyone sensible really should be).
That's true, and I am planning to add at least an optional include-able file to specify main classes / versions and speed up mod loading. I actually included a class to handle this in my older project: https://github.com/warriordog/RedBlockServer/blob/master/Dev1.6.2/src/net/acomputerdog/RedBlock/plugin/PluginInfo.java. It handled IDs, versions, user-friendly names and versions, and mod dependencies. I can't remember if I ever implemented the dependency handling, but I had to include it because that class could never change without breaking compatibility.
Well you can either run the gradle script and it'll pull down the dependencies for you, or just pull the launchwrapper 1.8 binary direct off mojang's servers which is what I tend to do. You'll find the other dependencies as part of your minecraft installation anyway, with the exception of ASM, which you'll want the debug-all binary for.
Thanks! I just downloaded the ASM source archive and added it, will that work?
Actually, you could make the Blaze Mod Loader API independent of the loader. Which would benefit everyone.
Or one version for each loader?
Or a thin layer between each loader.
Normally you just want asm-debug-all-4.1.jar from this library rather than the sources.
This is kind of what I was suggesting in my first post above, since liteloader is really just a loader building an API on top of it and using the version-checking and metadata stuff I already have could be worthwhile. That said, given that people still don't seem to see the difference between FML and Forge, it could be that LiteLoader would just disappear under the API, which would be a shame.
That's a confusion caused by the Forge by calling everything Forge. LiteLoader is already well know as a loader.
Heh, not sure about "well known", but yeah I take the point I guess FML was seen to be under the Forge umbrella. It still seems a bit unfair to cpw since FML is really powerful system and nobody seems to realise that it's available without the whole Forge API.
That is something to consider, but I have already written a functioning loader (the 3rd iteration of the same basic load system, actually) that is somewhat deeply built into the API at this point.
Wait FML exists outside of forge? Wut?
Color me intrigued as well.
https://github.com/MinecraftForge/FML Can you use this one to port ModLoader mods cleanly?
Fair enough, although feel free to steal ideas from mine then Just be aware that ModLoader's biggest weakness was the lack of metadata, and this is more crucial than ever now that players can load multiple different versions at once with the new launcher.
Yes, FML is "Forge ModLoader", a replacement for ModLoader and manages loading mods and such as well as the client/server comms and whatnot. Minecraft Forge is the API and does all the heavy lifting in terms of providing hooks and classes for mods to use.
Of course, and FML already loads ModLoader mods, although that support will be dropped in 1.7 because it would basically need a complete ground-up rewrite and that's not really feasible for something that's inherently quite poorly designed from the outset.
You can download FML itself from here
I don't think Huricaaane would thank you for that
I have some code in place to help handle wrong versions of mods (that was always one of ModLoader's and until recently Forge's biggest issues) by including methods to allow mods to check the version of BL before anything has loaded, and when loading mods the loader will detect duplicates of already loaded mods and either skip them or replace them if they are newer than the already loaded version.
Metadata is still a more robust method than error handling, especially when the errors that may occur might happen outside of your handling code. But at least you've addressed the problem which is more than Risugami ever did!
I have been releasing a modified version of ModLoader since 1.6.1 and Risugami never complained. Although that could be because he disappeared before I released it...
I honestly don't think he cared for the community at all any more, and was just doing the smallest amount of work possible that would keep his ad.fly revenue trickling in, that may be horribly unfair to him and it may be that real life just took over, but it's what I strongly (personally) suspect.
An older project of mine (on my github account) used a "PluginInfo.txt" file to doublecheck mod compatibility, but that was one extra step I wanted to get rid of for BL. Now you can literally hit "Build JAR" and put the unmodified jar strait into the mods folder. Although I do see your point and I will likely add that if I ever have to deprecate the current loading system.
The way I see it it's a minescule extra bit of pain for the mod developer that can unfold into a lot of mitigated pain for the mod user, and that last extra bit of pain is immediately ameliorated if using ant/gradle/maven to build your mod anyway (as anyone sensible really should be).
When I first downloaded ModLoader (in beta) his FAQ section of his post really made it seem like he didn't care, and it never got better. Also he has been modding for far, far longer than me and has only 110 posts. But it could just be he really doesn't have time to worry about modding, and he has just been maintaining ModLoader and his mods out of courtesy to his users.
Without any official word from him we'll never really know, but I think it's up to community members still present to provide good avenues for players to follow in his stead. My biggest fear really is that someone will just make some half-assed "modloader reloaded" basically taking his stuff and recompiling it against the new codebase, I feel like that would be the most damaging thing given how creaky and outdated modloader is, keeping it on life support would seem to be the most damaging thing anyone could do, especially if it were just to grab glory for themselves without really caring about the community either.
That's why I'm actually really glad you're undertaking this and why I'm trying to offer you as much help as I can, choice is good, moving forward is good, and people respect you already for providing the modloader patches so I think they'll take your API seriously. This is all good, someone trying to keep modloader alive is the biggest potential bad waiting to happen.
Or maybe something like this
That's true, and I am planning to add at least an optional include-able file to specify main classes / versions and speed up mod loading. I actually included a class to handle this in my older project: https://github.com/warriordog/RedBlockServer/blob/master/Dev1.6.2/src/net/acomputerdog/RedBlock/plugin/PluginInfo.java. It handled IDs, versions, user-friendly names and versions, and mod dependencies. I can't remember if I ever implemented the dependency handling, but I had to include it because that class could never change without breaking compatibility.