I am working on a package manager, designed somewhat similarly to the debian linux apt and dpkg tools, to make things easier for all parties - modders, users, and mojang alike.
note that the first release will just be a proof of viability, for the most part; it won't be worthy of serious use until the second release at least. expect late feb, early march.
Features currently planned and in progress:
For modders (I probably forgot some):
[*:27hncrab] Distributed repository system - the main repository can include your repository, allowing you to deal with keeping your mods up to date yourself
[*:27hncrab] You only have to maintain one method of distribution - if you don't want to use the repository, you can distribute packages without using a repository, and the package manager will still be able to understand them.
[*:27hncrab] Dependency resolution - no need to package mods that you depend on with your mods
[*:27hncrab] Conflict prevention - you won't get users complaining to you that your mod doesn't work. Instead, they will know which mod it doesn't work with and be able to give you useful information to resolving this (if they so choose)
[*:27hncrab] Binary patching - no need to distribute whole class files, therefore dealing with a large portion of the problem Mojang has with client mods
These will not be in the first release, but are planned:
[*:27hncrab] Bytecode patching - if a mod changes the same class file, there is a fair chance it won't conflict with yours
[*:27hncrab] Automatic repository management - a way to generate repository index files. for the first release, they will be completely manual.
[*:27hncrab] Remote control from in-game - this will be for when more client modders get into server modding, the server will be able to tell the client "a server mod needs you to install X client mod" and then it will ask the user if this is ok, to try to play on the server without it, or to not play on the server.
For users (notice the similarities - again I probably forgot some):
[*:27hncrab] Repository system for mods. This means that the only download link you will click is the one for the package manager; then you run the package manager, tell it you want (for instance) "humans+", it searches for Humans+ and offers to install it next time you start Minecraft.
[*:27hncrab] Dependency resolution - if Humans+ needs Modloader, you don't have to tell it so; you just tell it you want Humans+ and it deals with the rest for you.
[*:27hncrab] Conflict prevention - if mods conflict, then it will warn you. if they have a hard conflict, aka they're not possible to install over each other, then it won't try.
[*:27hncrab] Conflict resolution (won't be in the first release) - if two mods use the same file, then they might still work together.
[*:27hncrab] Patching - mod packages will not contain notch's code, so you don't have to worry that you're breaking any laws by downloading a mod
[*:27hncrab] Nicer upgrade management - will tell you when there is an upgrade to one of your mods, and offer to install it. Same with minecraft. When an upgrade is available, it will offer to install it.
[*:27hncrab] There will be a commandline and a gui version available - most users will prefer the gui version, but for techies the command line version will likely prove valuable.
[*:27hncrab] Possible feature - It might allow you to play directly in offline mode
[*:27hncrab] (probably not in first release) click links that start with mcpkg:// and it will autoinstall the package for you
[*:27hncrab] (probably not in first release) a way to get detailed console error logs, so that when something does go wrong, you can send the error to the modder who needs to see it
#mcpkg on irc.esper.net is the channel for mcpkg. It is NOT a user support channel, don't join expecting end-user support.
For those who are curious and who know Java, my git repo is at https://github.com/lahwran/mcpkg - feel free to poke around it and make fun of, or even give useful suggestions about, my code.
Note about the source repository: mercurial is set up because I was using mercurial, switched to git, tried to remove it, but on start of Eclipse, .hg reappeared. :ohmy.gif:
contributers:
me (lahwran) - main author, have done nearly all the code so far
TLUL, Silasary - were doing the same thing, have given a lot of suggestions for design
population of #risucraft - various design suggestions
sonicrules1234 (a friend of mine) - not a modder, helped with design, reminded me to make sure it understands ssl
various tech bloggers found on google - code snippets
if I forgot you, then it means I am an evil person trying to make you look bad. that or I really just missed you.
Rollback Post to RevisionRollBack
Link Removed
Stupidity on the rise with a 40% chance of shitstorms.
Sounds great. Although there are quite a few mod managers by now, if everything (or even just most of it) works as advertised, I'm sure quite a few people will use this. :smile.gif:
Quote from TomFromCollege »
Screeny? :smile.gif:
Oh and "bytecode patching" won't be feasible :wink.gif:
Why? (Not that I understand much about it anyway but I'm fairly sure lahwran would appreciate some more input.) :smile.gif:
yes, cydia is based off of apt as well. it actual uses apt instead of rewriting it, but since we're speaking in java I can't do that. verysadface.
Quote from TomFromCollege »
Screeny? :smile.gif:
Oh and "bytecode patching" won't be feasible :wink.gif:
I haven't started on the UI yet. been working on the internals. I'm a little worried said first release will have no gui :s
"won't be feasible" - lol oh really? I've already had it working once, it just wasn't differential. meaning, you would have to write your mod to use it, which is something I find annoying. If you have something specific to say, by all means say it. Do you mean that binary patching of individual functions won't be feasable? ...Because, again, it's easier than it sounds, assuming no variables changed. If they did, then that's why javassist has a variable mapping as part of the function alteration call.
And just to make it extra clear, one of the main goals is that there not be much modders have to do to make their mod compatible; just download the package manager, make a package index describing what they need (this is where you say if you need modloader or not for instance), put the mc.jar files in mc.jar/ and the .minecraft files in main/, and then feed it through the package manager, which would then automatically create a patch that not only doesn't include notch's code, but no code from mods that it changes, either.
Rollback Post to RevisionRollBack
Link Removed
Stupidity on the rise with a 40% chance of shitstorms.
probably going to be late tomorrow, I'll get a console release out that demos what it will be able to do. dunno if it will have dependency resolution, had a hard time in the 10 minutes I spent on that the other day.
Rollback Post to RevisionRollBack
Link Removed
Stupidity on the rise with a 40% chance of shitstorms.
late "tomorrow" indeed. I have not slept yet, I'm going to now, and something is nullpointering. *sigh* ... won't be too hard when I wake up most likely
Rollback Post to RevisionRollBack
Link Removed
Stupidity on the rise with a 40% chance of shitstorms.
aaand here we go! I'm going to call this a testing release, because it's half broken, missing many major features, the repository is empty at the moment, and is command line only. BACK UP YOUR .minecraft BEFORE TRYING THIS RELEASE
Link Removed <<< this is the executable jar. you have to run it on the command line at the moment! if you do not know how to do this, then wait until I get a gui working.
usage:
#searches package names and descriptions for <string>
#multiple arguments are merged into one string - "mcpkg search mod loader" searches for "mod loader" (probably means no hits)
mcpkg search <string>
#add and cache repo
mcpkg addrepo <mainrepourl>
#delete repo, do not uncache
mcpkg delrepo <repo #/url>
#shows list of repos in repo file, including number in in repo file
mcpkg list repos
#list sections
mcpkg list sections
#list of ALL packages and their short descriptions
mcpkg list packages
#list all cached packages.
mcpkg list cached
#show packages that are queued for install next time minecraft is started
mcpkg list queue
#dump packageinfo for package
mcpkg show <packagename>
#clear the repo cache
mcpkg clean repos
#queues package named to be installed next run.
mcpkg queue <name/filename>
#remove package <name> from queue to install (effectively uninstalling it)
mcpkg unqueue <name>
#run actual install
#if .minecraft contains an unmodded minecraft that is newer than the latest backup, backs it up.
#then builds a new modded minecraft based on queued packages and latest backup.
mcpkg run
major known problems:
--no gui!
--horrible, horrible error handling
--ordering is broken
--NO DEPENDENCY RESOLUTION YET
--repository is empty at time of release
--install will probably fail if you have no packages queued
if you find a bug, please report it; that's the whole purpose of a testing release.
will post an explanation of how to create a package for it soon, right now I'm explaining it to the guys on IRC. I'll probably just paste the log.
Rollback Post to RevisionRollBack
Link Removed
Stupidity on the rise with a 40% chance of shitstorms.
Also, suggesting that you provide for "apply-before" or "apply-after" metadata in mods, that way a mod that is not dependent but should apply differently can do so, and it can be either mod which alerts mcpkg.
one (or more) steps ahead of you, that has been in the index spec since we first started pulling it together :wink.gif:
Quote from Evenprime »
Definitely something I'll be watching and using. I really love package Managers like apt and would definitely use it to distribute my mod.
sweet! :biggrin.gif:
Rollback Post to RevisionRollBack
Link Removed
Stupidity on the rise with a 40% chance of shitstorms.
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:
[*:2q8u0370]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.
[*:2q8u0370]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.
Minecraft Mod Package Manager
Third release testing
note that the first release will just be a proof of viability, for the most part; it won't be worthy of serious use until the second release at least. expect late feb, early march.
Features currently planned and in progress:
For modders (I probably forgot some):
[*:27hncrab] Distributed repository system - the main repository can include your repository, allowing you to deal with keeping your mods up to date yourself
[*:27hncrab] You only have to maintain one method of distribution - if you don't want to use the repository, you can distribute packages without using a repository, and the package manager will still be able to understand them.
[*:27hncrab] Dependency resolution - no need to package mods that you depend on with your mods
[*:27hncrab] Conflict prevention - you won't get users complaining to you that your mod doesn't work. Instead, they will know which mod it doesn't work with and be able to give you useful information to resolving this (if they so choose)
[*:27hncrab] Binary patching - no need to distribute whole class files, therefore dealing with a large portion of the problem Mojang has with client mods
These will not be in the first release, but are planned:
[*:27hncrab] Bytecode patching - if a mod changes the same class file, there is a fair chance it won't conflict with yours
[*:27hncrab] Automatic repository management - a way to generate repository index files. for the first release, they will be completely manual.
[*:27hncrab] Remote control from in-game - this will be for when more client modders get into server modding, the server will be able to tell the client "a server mod needs you to install X client mod" and then it will ask the user if this is ok, to try to play on the server without it, or to not play on the server.
For users (notice the similarities - again I probably forgot some):
[*:27hncrab] Repository system for mods. This means that the only download link you will click is the one for the package manager; then you run the package manager, tell it you want (for instance) "humans+", it searches for Humans+ and offers to install it next time you start Minecraft.
[*:27hncrab] Dependency resolution - if Humans+ needs Modloader, you don't have to tell it so; you just tell it you want Humans+ and it deals with the rest for you.
[*:27hncrab] Conflict prevention - if mods conflict, then it will warn you. if they have a hard conflict, aka they're not possible to install over each other, then it won't try.
[*:27hncrab] Conflict resolution (won't be in the first release) - if two mods use the same file, then they might still work together.
[*:27hncrab] Patching - mod packages will not contain notch's code, so you don't have to worry that you're breaking any laws by downloading a mod
[*:27hncrab] Nicer upgrade management - will tell you when there is an upgrade to one of your mods, and offer to install it. Same with minecraft. When an upgrade is available, it will offer to install it.
[*:27hncrab] There will be a commandline and a gui version available - most users will prefer the gui version, but for techies the command line version will likely prove valuable.
[*:27hncrab] Possible feature - It might allow you to play directly in offline mode
[*:27hncrab] (probably not in first release) click links that start with mcpkg:// and it will autoinstall the package for you
[*:27hncrab] (probably not in first release) a way to get detailed console error logs, so that when something does go wrong, you can send the error to the modder who needs to see it
#mcpkg on irc.esper.net is the channel for mcpkg. It is NOT a user support channel, don't join expecting end-user support.
For those who are curious and who know Java, my git repo is at https://github.com/lahwran/mcpkg - feel free to poke around it and make fun of, or even give useful suggestions about, my code.
Note about the source repository: mercurial is set up because I was using mercurial, switched to git, tried to remove it, but on start of Eclipse, .hg reappeared. :ohmy.gif:
contributers:
me (lahwran) - main author, have done nearly all the code so far
TLUL, Silasary - were doing the same thing, have given a lot of suggestions for design
population of #risucraft - various design suggestions
sonicrules1234 (a friend of mine) - not a modder, helped with design, reminded me to make sure it understands ssl
various tech bloggers found on google - code snippets
if I forgot you, then it means I am an evil person trying to make you look bad. that or I really just missed you.
Stupidity on the rise with a 40% chance of shitstorms.
and your releasing it 1 day before my birthday :smile.gif:
so happy :DD
gives you hahhahas
Why? (Not that I understand much about it anyway but I'm fairly sure lahwran would appreciate some more input.) :smile.gif:
It is not the weapon that makes the warrior, but the warrior that makes the weapon.
yes, cydia is based off of apt as well. it actual uses apt instead of rewriting it, but since we're speaking in java I can't do that. verysadface.
I haven't started on the UI yet. been working on the internals. I'm a little worried said first release will have no gui :s
"won't be feasible" - lol oh really? I've already had it working once, it just wasn't differential. meaning, you would have to write your mod to use it, which is something I find annoying. If you have something specific to say, by all means say it. Do you mean that binary patching of individual functions won't be feasable? ...Because, again, it's easier than it sounds, assuming no variables changed. If they did, then that's why javassist has a variable mapping as part of the function alteration call.
And just to make it extra clear, one of the main goals is that there not be much modders have to do to make their mod compatible; just download the package manager, make a package index describing what they need (this is where you say if you need modloader or not for instance), put the mc.jar files in mc.jar/ and the .minecraft files in main/, and then feed it through the package manager, which would then automatically create a patch that not only doesn't include notch's code, but no code from mods that it changes, either.
Stupidity on the rise with a 40% chance of shitstorms.
Stupidity on the rise with a 40% chance of shitstorms.
Stupidity on the rise with a 40% chance of shitstorms.
I sure hope so. but the first release is sure not gonna be the one to do it. I'm surprised I got anything complete enough to release together ...
Stupidity on the rise with a 40% chance of shitstorms.
BACK UP YOUR .minecraft BEFORE TRYING THIS RELEASE
Link Removed <<< this is the executable jar. you have to run it on the command line at the moment! if you do not know how to do this, then wait until I get a gui working.
usage:
#searches package names and descriptions for <string>
#multiple arguments are merged into one string - "mcpkg search mod loader" searches for "mod loader" (probably means no hits)
mcpkg search <string>
#add and cache repo
mcpkg addrepo <mainrepourl>
#delete repo, do not uncache
mcpkg delrepo <repo #/url>
#shows list of repos in repo file, including number in in repo file
mcpkg list repos
#list sections
mcpkg list sections
#list of ALL packages and their short descriptions
mcpkg list packages
#list all cached packages.
mcpkg list cached
#show packages that are queued for install next time minecraft is started
mcpkg list queue
#dump packageinfo for package
mcpkg show <packagename>
#clear the repo cache
mcpkg clean repos
#queues package named to be installed next run.
mcpkg queue <name/filename>
#remove package <name> from queue to install (effectively uninstalling it)
mcpkg unqueue <name>
#run actual install
#if .minecraft contains an unmodded minecraft that is newer than the latest backup, backs it up.
#then builds a new modded minecraft based on queued packages and latest backup.
mcpkg run
major known problems:
--no gui!
--horrible, horrible error handling
--ordering is broken
--NO DEPENDENCY RESOLUTION YET
--repository is empty at time of release
--install will probably fail if you have no packages queued
if you find a bug, please report it; that's the whole purpose of a testing release.
will post an explanation of how to create a package for it soon, right now I'm explaining it to the guys on IRC. I'll probably just paste the log.
Stupidity on the rise with a 40% chance of shitstorms.
one (or more) steps ahead of you, that has been in the index spec since we first started pulling it together :wink.gif:
sweet! :biggrin.gif:
Stupidity on the rise with a 40% chance of shitstorms.
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:
[*:2q8u0370]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.
and some way to handle mods consisting of changed and redistributed class files.[*:2q8u0370]a patcher system which can undo it’s changes, even if another patcher altered the same class file.
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.