This is how LiteLoader worked from day one because Risu's "all mods inherit a base class" model isn't performant and doesn't scale beyond a few callbacks. I find it rubs a little that you're shouting about this like it's a new thing when it's exactly how I've worked from the outset and I've often encouraged you to look at my solutions to see if they can help. Now this leads me back to ask: "why not build your API on my loader"? Especially since you're now using exactly the same models.
Again, this is exactly how LiteLoader already works, albeit using compiled-in obfuscation tables and not dynamically obfuscating (which is a forge trick which I think is actually a bad thing, since it means that something which contractually cannot function can actually be loaded and then crash the game instead) but with the differences that my transformer base classes are public and any mod is allowed to use them to inject their own callbacks or custom code.
I also use ASM rather than Javassist because it's (by its own description) lighter-weight, simpler and more performant than other frameworks. There's also the benefit with ASM that because it's used by launchwrapper, it is available on the Mojang repo and thus doesn't need to be distributed with the loader.
So I still keep coming back to, why make a separate loader? Especially since it seems like now you're basically just re-implementing things that are already available to you. Why not build an API on top of LiteLoader, using the existing technologies that I've spent the time and effort developing, perfecting and polishing over the last 2 years?
Features which I have which you need not reimplement if you adopt this:
Version checking and vetting of packages prior to loading to avoid outdated mods crashing the game
Mod dependency declaration support so that a mod which requires another won't load if the dependency is missing
Mod disablement functionality (from ingame) allowing mods to be selectively disabled and enabled
Mod-to-container mappings, allowing metadata and other information to be retrieved about a mod's container
ASM-based injection transformers which are extremely easy to use and I am improving all the time, including CallbackInjectionTransformer, ClassOverlayTransformer and PacketTransformer
Pre-startup injections such as tweaker injections, classpath injections, and custom transformers
Modular mod discovery system so that mods can be discovered in various locations using neat, self-contained discovery modules
Mod metadata system allowing access to metadata of both unloaded (disabled or excluded) mods and also loaded mods
Clean, functional mod information panel with interface socket for mods to provide a "settings" panel which integrates into the same UI
Simple plugin channels support supporting both client and integrated server
All my existing interfaces and hooks, for everything from render callbacks to plugin channel handling
In-game log viewer with post-to-pastebin to aid with support and debugging
Established workflow and build system which doesn't require modifying MCP and is also going to be shortly supported officially by ForgeGradle
When BlazeLoader stood apart as its own technology I wasn't so bothered about this, but now it just seems like you're adopting all the same approaches that I already take, and I think it should at least be a consideration that instead of completely reinventing the wheel you use what I have and build a solid API on top of it - basically like Forge does with FML.
I guess what I'm really asking is what am I missing that you would really want, and can it be added? I've spent the last 2 years making a really solid platform with some nice features and good support, and it just seems a real raw deal to have tried to help you out all along and now you basically say "hey, I'm now recreating all your work myself from scratch because I don't want to use your product".
I can understand you wanting to have full vertical control of your stack, and if that's your final goal I respect that. What I don't understand is why there's such reluctance to use what I'm offering when you're basically just now using the exact same methods I've implemented, debugged, painstakingly tested and refined already.
I'll be around on IRC this evening if you'd like to discuss it.
I will be honest, I never really took the time to fully read through LiteLoader's source, aside from the tweaker system. If I had realized at the beginning that BL would end up changing this way then I probably would have used LiteLoader from the start. But the way it is now I don't think it would be very simple to port BL to run on top of LiteLoader, and I really would prefer not to add too many dependencies. But then again here I am adding dependencies on MCInject and Javassist, so I guess it actually would be simpler to instead have a single dependency on LiteLoader. Sorry that I seem to be re-implementing your stuff, I was not thinking (and honestly didn't realise) that you had already done much of this. Also I am not trying to push these new features as if they were brand new in modding, rather that they are new to BlazeLoader. I will join you on IRC.
Just a question, acomputerdog how long do you think it will take for blaze loader to gain server side abilities and how would you implement that?
The answer to the first question depends on the answer to the second, and I haven't put any thought into that yet. Although I don't think it will be so much an issue of time as it would be an issue of how many changes mods would have to make, and how effective the whole system is.
EDIT: Just to clarify I do want to add server support.
You realise that counter just shows the trailing year of commit stats and that WarriorDog's GitHub anniversary is actually on 26th of August right?
TIL I joined github on August 26
I have been meaning to PM you, I will be leaving IRC logged in whenever I am at the computer, so if you get on and I am named "acomputerdog" or "acomputerdog|AFK" then you can ping me and I should respond.
I have already done it, just saw that it was in the "Planned API:" list
I've tried to install the API, but it didn't work for meI'll try again laterI also wasn't able to override stone using blockRegistry.addObject(1...But that's probably because I used public void init(FMLInitializationEvent event)
I haven't really had any problems with Windows 8 (Except Skype opened in metro, I got it fixed though) But beside that, for me, it's just a faster version of Windows 7 with more features, most people would probably disagree. But I like Windows 8 once you get used to it. But you're probably right, it might be Windows 8 causing it Can I suggest that the batch file checks for the Libraries and if they're not there, guide the user on how to get them Using something like this
title Blazeloader Installer color ce :minecraftinstall if exist %APPDATA%\.minecraft\versions\1.6.2\ goto forgeinstall1 start bin\Minecraft echo Please install Minecraft 1.6.2, before continuing the installation! pause cls echo You didn't install Minecraft 1.6.2! goto minecraftinstall :forgeinstall1 cls :forgeinstall if exist %APPDATA%\.minecraft\versions\1.6.2-Forge9.10.0.804\ goto checkforgelibraries start javaw -jar bin\ForgeInstaller.jar //Maybe include it in the download echo Please install Minecraft Forge 804 before continuing the installation! pause cls echo You didn't install Forge! goto forgeinstall :checkforgelibraries cls if exist %appdata%\.minecraft\libraries\net...... goto installbl start C:\Users\Lucas\Desktop\Minecraft.exe //Or maybe include it in the download echo Please start Minecraft with the profile: "Forge"! pause goto checkforgelibraries :installbl cls echo You now got all the required libraries to install BlazeLoader pause java -jar installer-1.0.0-SNAPSHOT.jar
I just changed a private modpack installer I made for 1.6.2 so I'm not sure if it'll work. And you'll have to change it of course.
The batch setup scripts are not going to be kept, once the installer is finished they will go.
I was thinking of mentioning it here but decided not to. It was originally supposed to function more of an automatic obfuscation mapping generator and maybe include some loading functionality on the side or alternatively use an existing loader like blazeloader. While it cannot do any actual loading yet, it can generate a text file with some class mappings for classes like Block and Item. I tried hard to make sure I never directly reference a minecraft class. In fact, if compiled, it can even work against the 14w11b snapshot (the latest as of writing this) without recompiling.
[EDIT] for example, here are the generated mappings for 14w11b:
Block amq
Blocks amw
Material bbs
Item aga
Items agi
I'm interested to see how to use the compatibility package, is it for things like providing machine recipes? Like if someone makes an ore processor and another mod makes an ore, the processor mod can register to be notified of ores and the ore mod says that an ore has been registered?
I was thinking of mentioning it here but decided not to. It was originally supposed to function more of an automatic obfuscation mapping generator and maybe include some loading functionality on the side or alternatively use an existing loader like blazeloader. While it cannot do any actual loading yet, it can generate a text file with some class mappings for classes like Block and Item. I tried hard to make sure I never directly reference a minecraft class. In fact, if compiled, it can even work against the 14w11b snapshot (the latest as of writing this) without recompiling.
[EDIT] for example, here are the generated mappings for 14w11b:
Block amq
Blocks amw
Material bbs
Item aga
Items agi
Very interesting, if you were to keep a list of mappings for the snapshots then you would have a major bonus to your API.
I'm interested to see how to use the compatibility package, is it for things like providing machine recipes? Like if someone makes an ore processor and another mod makes an ore, the processor mod can register to be notified of ores and the ore mod says that an ore has been registered?
That is exactly what it is for! However most of the current system is very outdated and I will be updating it, probably using String compatibility types (with presets such as "ORE", "TOOL", etc.). Another big use of it would be to help large mods work together, for example if two mods try to register an ore processor they can both point "oreProcessor" (or something like it) to their ore processor block/item/TE/whatever. Then whichever mod loads second can see that the "oreProcessor" is already defined by another mod, and can skip loading its own (or even better load it's own as a pointer to the other) and then register it's ores with the other mod's processor.
Me and Big_Xplosion still have some work to do on it but it is ready for testing and traffic.
Note: Acomputerdog I need some documentation and downloads for versions so I can put them in the download pages!
Me and Big_Xplosion still have some work to do on it but it is ready for testing and traffic.
Note: Acomputerdog I need some documentation and downloads for versions so I can put them in the download pages!
I'm not active on these forums, so forgive me if I don't respond!
If you want to contact me, try going through Discord or you can find me on GitHub where I am still updating the below mods (and more):
I'm not active on these forums, so forgive me if I don't respond!
If you want to contact me, try going through Discord or you can find me on GitHub where I am still updating the below mods (and more):
I also read that Cuchaz is 'not' making his own modloader at some place where that link should point.
What? Huh?
I *am* making my own mod loader. I'm actually using it to do something really cool at the moment too, but I'm not ready to share any details yet. =) I'll eventually post a tech demo on YouTube when I'm ready to make an announcement.
Also, I thank you for considering me as a contributor to BlazeLoader, but I'm not sure that I've actually contributed anything, be it a minor contribution or otherwise. I'd say you don't have to list me as a contributor to BlazeLoader unless you really want to.
Although, I do eventually intend to eventually write an API to help organize chain loading of tweakers for Minecraft's Launchwrapper. BlazeLoader (or anyone else) would certainly be welcome to use the API, but I haven't actually done it yet, so I wouldn't count it as a contribution.
I *am* making my own mod loader. I'm actually using it to do something really cool at the moment too, but I'm not ready to share any details yet. =) I'll eventually post a tech demo on YouTube when I'm ready to make an announcement.
Also, I thank you for considering me as a contributor to BlazeLoader, but I'm not sure that I've actually contributed anything, be it a minor contribution or otherwise. I'd say you don't have to list me as a contributor to BlazeLoader unless you really want to.
Although, I do eventually intend to eventually write an API to help organize chain loading of tweakers for Minecraft's Launchwrapper. BlazeLoader (or anyone else) would certainly be welcome to use the API, but I haven't actually done it yet, so I wouldn't count it as a contribution.
Cuchaz, I was creating the website and this was a TYPO not a statement sorry if it was not clear, also I will still list you as a contributor because you given us valid input etc...
That is how it will work, since it is the hooks themselves that are obfuscated to match the current version.
I will be honest, I never really took the time to fully read through LiteLoader's source, aside from the tweaker system. If I had realized at the beginning that BL would end up changing this way then I probably would have used LiteLoader from the start. But the way it is now I don't think it would be very simple to port BL to run on top of LiteLoader, and I really would prefer not to add too many dependencies. But then again here I am adding dependencies on MCInject and Javassist, so I guess it actually would be simpler to instead have a single dependency on LiteLoader. Sorry that I seem to be re-implementing your stuff, I was not thinking (and honestly didn't realise) that you had already done much of this. Also I am not trying to push these new features as if they were brand new in modding, rather that they are new to BlazeLoader. I will join you on IRC.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThe answer to the first question depends on the answer to the second, and I haven't put any thought into that yet. Although I don't think it will be so much an issue of time as it would be an issue of how many changes mods would have to make, and how effective the whole system is.
EDIT: Just to clarify I do want to add server support.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumYou realise that counter just shows the trailing year of commit stats and that WarriorDog's GitHub anniversary is actually on 26th of August right?
That is a lot like how bukkit does it, actually. Are you suggesting I add that, or have you already done it?
TIL I joined github on August 26
I have been meaning to PM you, I will be leaving IRC logged in whenever I am at the computer, so if you get on and I am named "acomputerdog" or "acomputerdog|AFK" then you can ping me and I should respond.
But the first commit for BL was only 6 months ago: https://github.com/warriordog/BlazeLoader/commit/9b19bae6e947421e37fe8bbdb9d3985e278e0ead
What APIs are you using?
I am not sure I can help you with forge modding, the most I have done with forge is making my mods work with it and using the integrated ModLoader.
It works on my windows, probably because gaming is using windows 8
The batch setup scripts are not going to be kept, once the installer is finished they will go.
I was thinking of mentioning it here but decided not to. It was originally supposed to function more of an automatic obfuscation mapping generator and maybe include some loading functionality on the side or alternatively use an existing loader like blazeloader. While it cannot do any actual loading yet, it can generate a text file with some class mappings for classes like Block and Item. I tried hard to make sure I never directly reference a minecraft class. In fact, if compiled, it can even work against the 14w11b snapshot (the latest as of writing this) without recompiling.
[EDIT] for example, here are the generated mappings for 14w11b:
Very interesting, if you were to keep a list of mappings for the snapshots then you would have a major bonus to your API.
That is exactly what it is for! However most of the current system is very outdated and I will be updating it, probably using String compatibility types (with presets such as "ORE", "TOOL", etc.). Another big use of it would be to help large mods work together, for example if two mods try to register an ore processor they can both point "oreProcessor" (or something like it) to their ore processor block/item/TE/whatever. Then whichever mod loads second can see that the "oreProcessor" is already defined by another mod, and can skip loading its own (or even better load it's own as a pointer to the other) and then register it's ores with the other mod's processor.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumMe and Big_Xplosion still have some work to do on it but it is ready for testing and traffic.
Note: Acomputerdog I need some documentation and downloads for versions so I can put them in the download pages!
The link you say http://www.blazeloader.com/index.php
Great! I will get you versions as soon as I get them!
That looks very nice.
For the team page you can probably put in my country of origin (South Africa), and HTML/CSS, and Javascript for other details.
I also read that Cuchaz is 'not' making his own modloader at some place where that link should point.
If you want to contact me, try going through Discord or you can find me on GitHub where I am still updating the below mods (and more):
PRESENCE FOOTSTEPS - (github)
VOID FOG - (github)
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumOk I will update the team profiles later on today... Thanks for the info!
I will also look into Cuchaz's Modloader later on today as well
Oh no that's not what I meant. I read that on your site. I assume it's a typo.
If you want to contact me, try going through Discord or you can find me on GitHub where I am still updating the below mods (and more):
PRESENCE FOOTSTEPS - (github)
VOID FOG - (github)
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumWhat? Huh?
I *am* making my own mod loader. I'm actually using it to do something really cool at the moment too, but I'm not ready to share any details yet. =) I'll eventually post a tech demo on YouTube when I'm ready to make an announcement.
Also, I thank you for considering me as a contributor to BlazeLoader, but I'm not sure that I've actually contributed anything, be it a minor contribution or otherwise. I'd say you don't have to list me as a contributor to BlazeLoader unless you really want to.
Although, I do eventually intend to eventually write an API to help organize chain loading of tweakers for Minecraft's Launchwrapper. BlazeLoader (or anyone else) would certainly be welcome to use the API, but I haven't actually done it yet, so I wouldn't count it as a contribution.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumCuchaz, I was creating the website and this was a TYPO not a statement sorry if it was not clear, also I will still list you as a contributor because you given us valid input etc...