Will this be multiplatform (Mac?) I hope so, sounds amazing!
it's java, so yes.
Quote from flying sheep »
we really need some centralization here.
i think everyone here is reasonable, so instead of pumping out various systems we should gater and talk about who would use what and why.
we need one of the following:
[*:1zyih3gy]a modloader on steroids, allowing everyone to hook in everything they need for their mods. McMod wants to be this, but the support among mod developers is low. why.
[*:1zyih3gy]a patcher system which can undo it’s changes, even if another patcher altered the same class file.
and some way to handle mods consisting of changed and redistributed class files.
what if some mod patches a class, which another one replaces the same? either the patched class gets overwritten, or (if installed the other way round) the restoring of the replaced class will revert the changes made to it by the patcher.
tl;dr: the best for everyone would be a unified hook system like McMod, which every mod uses, combined with a simple dependency resolving package manager.
mcpkg already takes care of that. it uses binary patching, and so the patch cannot be applied to a file that has already been altered. as such, it must do a checksum before installing, meaning that conflicts will be shown to the user before the game is even started.
..there is a bug in the first release where checksum errors are ignored ...
Rollback Post to RevisionRollBack
Link Removed
Stupidity on the rise with a 40% chance of shitstorms.
I really should read the whole thread before posting, but..
I love this idea. I use Linux often and the Windows way of installing things feels strange to me. Modding even more-so. So being able to get my mods from a repository? Fantastic!
I do have a few questions. Will there be a GUI? If not, will we be able to use apt-get, aptitude, or yum to install mods (just the essence of the command, for those who have it as a habit)? Also, will you there be an option to make it all require a password?
Edit:
Read more, my GUI/command line question was answered. So will we be able to use Linux commands to install, though? Continuing reading..
tl;dr: the best for everyone would be a unified hook system like McMod, which every mod uses, combined with a simple dependency resolving package manager.
mcpkg already takes care of that. it uses binary patching, and so the patch cannot be applied to a file that has already been altered. as such, it must do a checksum before installing, meaning that conflicts will be shown to the user before the game is even started.
..there is a bug in the first release where checksum errors are ignored ...
is it possible to include multiple versions?
e.g. the current patcher of the wild grass mod detects modloader and/or better light/grass. if one of these are installed, it works differently.
tl;dr: the best for everyone would be a unified hook system like McMod, which every mod uses, combined with a simple dependency resolving package manager.
mcpkg already takes care of that. it uses binary patching, and so the patch cannot be applied to a file that has already been altered. as such, it must do a checksum before installing, meaning that conflicts will be shown to the user before the game is even started.
..there is a bug in the first release where checksum errors are ignored ...
is it possible to include multiple versions?
e.g. the current patcher of the wild grass mod detects modloader and/or better light/grass. if one of these are installed, it works differently.
That would certainly be the ideal way of doing things. Maybe doable by assigning an ID to each mod which then stays consistent?
There's also the issue of mods from the same author using the same files. A way to tell the program that "it's okay, it's the same file" would be needed. Though that might already be taken care of by simply checking whether the files are identical... hm.
e.g. the current patcher of the wild grass mod detects modloader and/or better light/grass. if one of these are installed, it works differently.
That would certainly be the ideal way of doing things. Maybe doable by assigning an ID to each mod which then stays consistent?
There's also the issue of mods from the same author using the same files. A way to tell the program that "it's okay, it's the same file" would be needed. Though that might already be taken care of by simply checking whether the files are identical... hm.
true.
to clarify: wild grass uses the terrain.png for block textures, if modloader isn’t installed, else it uses external textures. if bl/bg is installed, it has to patch one or two class files already modified by mr messiah in a different way than the vanilla versions (i think).
I really should read the whole thread before posting, but..
I love this idea. I use Linux often and the Windows way of installing things feels strange to me. Modding even more-so. So being able to get my mods from a repository? Fantastic!
I do have a few questions. Will there be a GUI? If not, will we be able to use apt-get, aptitude, or yum to install mods (just the essence of the command, for those who have it as a habit)? Also, will you there be an option to make it all require a password?
Edit:
Read more, my GUI/command line question was answered. So will we be able to use Linux commands to install, though? Continuing reading..
with some bash aliasing, yes.
Quote from flying sheep »
is it possible to include multiple versions?
e.g. the current patcher of the wild grass mod detects modloader and/or better light/grass. if one of these are installed, it works differently.
not in one package. what you would do is make a metapackage, which is what the users install. it recommends both of the versions, which then conflict with each other, and depend on various packages.
Quote from enenra »
That would certainly be the ideal way of doing things. Maybe doable by assigning an ID to each mod which then stays consistent?
There's also the issue of mods from the same author using the same files. A way to tell the program that "it's okay, it's the same file" would be needed. Though that might already be taken care of by simply checking whether the files are identical... hm.
it already checks if they match. it then promptly throws that data away at present, because I quite simply forgot to implement it. I've been busy all day, when I get back to it I can fix this stuff and fill out what's there.
Rollback Post to RevisionRollBack
Link Removed
Stupidity on the rise with a 40% chance of shitstorms.
- I assume the installer will be able to display descriptions for mods. If so, it would be good to also include a link to the mod's forum topic. Design wise ideally not in the description but as some kind of button. No big priority but stuff like that will be useful for users and even keep down some spam on the forum as most would hopefully post in the topic and not open up a new one. :smile.gif:
Maybe also a "Technical Help"-button, which would then first display a FAQ the modder adds to his package and only at the end have again a link to the forum topic of the mod.
- Another nice-to-have would be the possibility of including a few screenshots in the package. As far as I've understood, the users will get the mods from a database and not from the forums. Thus it would be good for the modders to be able to present their mod with some screenshots.
- Modders being able to assign predefined tags to their mod packages, users being able to search only packages that have been marked with certain tags or also exclude all those with a certain tag.
- I assume the installer will be able to display descriptions for mods. If so, it would be good to also include a link to the mod's forum topic. Design wise ideally not in the description but as some kind of button. No big priority but stuff like that will be useful for users and even keep down some spam on the forum as most would hopefully post in the topic and not open up a new one. :smile.gif:
Maybe also a "Technical Help"-button, which would then first display a FAQ the modder adds to his package and only at the end have again a link to the forum topic of the mod.
- Another nice-to-have would be the possibility of including a few screenshots in the package. As far as I've understood, the users will get the mods from a database and not from the forums. Thus it would be good for the modders to be able to present their mod with some screenshots.
- Modders being able to assign predefined tags to their mod packages, users being able to search only packages that have been marked with certain tags or also exclude all those with a certain tag.
again, I'm already ahead of you. the full index spec is at https://github.com/lahwran/mcpkg/blob/master/packageindexspec.
it's easy to add stuff to it later, since the parser completely ignores anything it doesn't recognize, so for instance if we add a "nicename" field (which I will be), then we can use it now, and it will be ignored by versions of mcpkg that don't understand it.
Rollback Post to RevisionRollBack
Link Removed
Stupidity on the rise with a 40% chance of shitstorms.
I had an idea for something similar a while ago. What i was thinking of is a system were the class files that need changing are decompiled and deobfuscation then have a patch applied, reobfuscation and complied. It's possible the MCP already does this. So the developer would only have to write the mod once and focus on updates not keeping with the obfuscation
I had an idea for something similar a while ago. What i was thinking of is a system were the class files that need changing are decompiled and deobfuscation then have a patch applied, reobfuscation and complied. It's possible the MCP already does this. So the developer would only have to write the mod once and focus on updates not keeping with the obfuscation
such a thing is possible, and something along those lines is planned. no decompilation needed for use, however.
edit: fifth time reading that, I realized that you are talking about exactly what mcp does.
Quote from camperdave »
I was actually looking to start my own project to do this yesterday, and someone kindly pointed me in your direction.
How can I best help? I'm fluent with java, and anxious to make this a reality :tongue.gif:
get on irc, irc.esper.net channel #risucraft, and ping me. we can work it out there. I am godawful at doing anything serious in non-live communication.
Rollback Post to RevisionRollBack
Link Removed
Stupidity on the rise with a 40% chance of shitstorms.
I have been working on the same bugs since when I should have released yesterday, hence why I am releasing a -dev of it with the bugs, to show what I have. these bugs will take a while to squash, looks like. not going to specify when I'll be done because I really don't know. hopefully soon.
Rollback Post to RevisionRollBack
Link Removed
Stupidity on the rise with a 40% chance of shitstorms.
testing release - not as likely to blow up in your face as the last one, but is still testing. back up your .minecraft because while this is unlikely to damage it, it is still a testing version. however, it's unlikely that it will damage your saves or screenshots, so you *should* be safe skipping those if they're too big.
to use: just doubleclick and run. make sure your .minecraft is vanilla before trying to use the run minecraft button. also contains commandline version, use java -cp mcpkg-0.0.2.jar mcpkg.Main to run that.
to make a package (if you're a modder):
1. Run mcpkg
2. Click the "make package" button
3. get your archives.
- if you modify .minecraft (for instance, adding to resources/) you should have an archive that contains your changes/new files to go in .minecraft
- if you modify the minecraft jar (most of us do) then you should have an archive that contains your modified files and new files for the jar
4. fill these in on the make package window
5. get your .minecraft and minecraft.jar ready - unless you change files from other mods, both should be 100% vanilla!!
6. find a place to save your mod package, put that in the output field, click ok, and then reply here.
if you want to make a repository, the repository index format can be found on by github. more on this in a bit.
Rollback Post to RevisionRollBack
Link Removed
Stupidity on the rise with a 40% chance of shitstorms.
I guess "manage Repos" is deactivated intentionally.
So, I tried creating a package with my Mod ConvenientInventory, which overwrites one MC class-file and adds another. First thing I noticed, the "minecraft.jar patch (optional)" field needs an absolute file path, but when I use the file chooser "browse ..." it only enters the filename into the form without its path, which leads to a rather obscure FileNotFound-Exception. The same is true for the "Output package" field.
Once I used absolute paths for both, it worked. At least I got an archive out of it with contents that look legit:
I really look forward to when repo-management is working :smile.gif:
you, sir, have found me a bug! thank you!
turns out I was using .getName() instead of .getAbsolutePath() to get the name for those fields ... fail :tongue.gif:
made a silent update to fix it.
Rollback Post to RevisionRollBack
Link Removed
Stupidity on the rise with a 40% chance of shitstorms.
it's java, so yes.
mcpkg already takes care of that. it uses binary patching, and so the patch cannot be applied to a file that has already been altered. as such, it must do a checksum before installing, meaning that conflicts will be shown to the user before the game is even started.
..there is a bug in the first release where checksum errors are ignored ...
Stupidity on the rise with a 40% chance of shitstorms.
I love this idea. I use Linux often and the Windows way of installing things feels strange to me. Modding even more-so. So being able to get my mods from a repository? Fantastic!
I do have a few questions. Will there be a GUI? If not, will we be able to use apt-get, aptitude, or yum to install mods (just the essence of the command, for those who have it as a habit)? Also, will you there be an option to make it all require a password?
Edit:
Read more, my GUI/command line question was answered. So will we be able to use Linux commands to install, though? Continuing reading..
e.g. the current patcher of the wild grass mod detects modloader and/or better light/grass. if one of these are installed, it works differently.
That would certainly be the ideal way of doing things. Maybe doable by assigning an ID to each mod which then stays consistent?
There's also the issue of mods from the same author using the same files. A way to tell the program that "it's okay, it's the same file" would be needed. Though that might already be taken care of by simply checking whether the files are identical... hm.
to clarify: wild grass uses the terrain.png for block textures, if modloader isn’t installed, else it uses external textures. if bl/bg is installed, it has to patch one or two class files already modified by mr messiah in a different way than the vanilla versions (i think).
with some bash aliasing, yes.
not in one package. what you would do is make a metapackage, which is what the users install. it recommends both of the versions, which then conflict with each other, and depend on various packages.
it already checks if they match. it then promptly throws that data away at present, because I quite simply forgot to implement it. I've been busy all day, when I get back to it I can fix this stuff and fill out what's there.
Stupidity on the rise with a 40% chance of shitstorms.
- I assume the installer will be able to display descriptions for mods. If so, it would be good to also include a link to the mod's forum topic. Design wise ideally not in the description but as some kind of button. No big priority but stuff like that will be useful for users and even keep down some spam on the forum as most would hopefully post in the topic and not open up a new one. :smile.gif:
Maybe also a "Technical Help"-button, which would then first display a FAQ the modder adds to his package and only at the end have again a link to the forum topic of the mod.
- Another nice-to-have would be the possibility of including a few screenshots in the package. As far as I've understood, the users will get the mods from a database and not from the forums. Thus it would be good for the modders to be able to present their mod with some screenshots.
- Modders being able to assign predefined tags to their mod packages, users being able to search only packages that have been marked with certain tags or also exclude all those with a certain tag.
again, I'm already ahead of you. the full index spec is at https://github.com/lahwran/mcpkg/blob/master/packageindexspec.
it's easy to add stuff to it later, since the parser completely ignores anything it doesn't recognize, so for instance if we add a "nicename" field (which I will be), then we can use it now, and it will be ignored by versions of mcpkg that don't understand it.
Stupidity on the rise with a 40% chance of shitstorms.
How can I best help? I'm fluent with java, and anxious to make this a reality :tongue.gif:
such a thing is possible, and something along those lines is planned. no decompilation needed for use, however.
edit: fifth time reading that, I realized that you are talking about exactly what mcp does.
get on irc, irc.esper.net channel #risucraft, and ping me. we can work it out there. I am godawful at doing anything serious in non-live communication.
Stupidity on the rise with a 40% chance of shitstorms.
I am in singapore.
Stupidity on the rise with a 40% chance of shitstorms.
http://dl.dropbox.com/u/16327181/mcpkg/ ... .2-dev.jar
WARNING: still has major bugs and will likely damage your .minecraft! use at your own risk.
I have been working on the same bugs since when I should have released yesterday, hence why I am releasing a -dev of it with the bugs, to show what I have. these bugs will take a while to squash, looks like. not going to specify when I'll be done because I really don't know. hopefully soon.
Stupidity on the rise with a 40% chance of shitstorms.
testing release - not as likely to blow up in your face as the last one, but is still testing.
back up your .minecraft because while this is unlikely to damage it, it is still a testing version. however, it's unlikely that it will damage your saves or screenshots, so you *should* be safe skipping those if they're too big.
to use: just doubleclick and run. make sure your .minecraft is vanilla before trying to use the run minecraft button. also contains commandline version, use java -cp mcpkg-0.0.2.jar mcpkg.Main to run that.
to make a package (if you're a modder):
1. Run mcpkg
2. Click the "make package" button
3. get your archives.
- if you modify .minecraft (for instance, adding to resources/) you should have an archive that contains your changes/new files to go in .minecraft
- if you modify the minecraft jar (most of us do) then you should have an archive that contains your modified files and new files for the jar
4. fill these in on the make package window
5. get your .minecraft and minecraft.jar ready - unless you change files from other mods, both should be 100% vanilla!!
6. find a place to save your mod package, put that in the output field, click ok, and then reply here.
if you want to make a repository, the repository index format can be found on by github. more on this in a bit.
Stupidity on the rise with a 40% chance of shitstorms.
you, sir, have found me a bug! thank you!
turns out I was using .getName() instead of .getAbsolutePath() to get the name for those fields ... fail :tongue.gif:
made a silent update to fix it.
Stupidity on the rise with a 40% chance of shitstorms.