I start with the lightloader jar and manually add my mods into the jar. It seems that the file structure of the WECUI doesn't contain a .class in the root. I tried copying the wecui and org folders into the root of the jar, but that evidently doesn't work. With so many subdirectories in the wecui folder, I felt uneasy about simply adding that whole mess to the root of the jar.
How do we go about adding this mod directly into our jar?
I start with the lightloader jar and manually add my mods into the jar. It seems that the file structure of the WECUI doesn't contain a .class in the root. I tried copying the wecui and org folders into the root of the jar, but that evidently doesn't work. With so many subdirectories in the wecui folder, I felt uneasy about simply adding that whole mess to the root of the jar.
How do we go about adding this mod directly into our jar?
-Peas
Well putting mods in the jar isn't really supported from 1.6 onwards, you can try it and there's no reason that it shouldn't work, just be aware that it's not supported and obviously involves invalidating the jar signature, which isn't really required any more.
If you were to do this you just put the whole contents of the litemod into the jar (folders and all) except for the mod metadata file (litemod.json). Obviously there are no .class files in the root, litemods are completely base clean so there will be no classes in the default package at all.
Be aware that placing mods in the classpath is not supported though, and invalidating the jar signature is not supported, recommended or even necessary.
EDIT: can I ask why you want to do this? It really doesn't achieve anything at all. It doesn't make it portable, it doesn't make it more efficient. All it does is make installation harder and strip the metadata, neither of which seems like a particularly good reason for doing this so I can't help but wonder why?
If you were to do this you just put the whole contents of the litemod into the jar (folders and all) except for the mod metadata file (litemod.json). Obviously there are no .class files in the root, litemods are completely base clean so there will be no classes in the default package at all.
I didn't even find a litemod.json file. The only files in the .litemod file was a version.text and Configuration.yml, then two folders. I did copy the entire contents into the .jar root, but the WECUI mod did not show up during worledit operations. I can only assume that the mod did not load correctly.
EDIT: can I ask why you want to do this? It really doesn't achieve anything at all. It doesn't make it portable, it doesn't make it more efficient. All it does is make installation harder and strip the metadata, neither of which seems like a particularly good reason for doing this so I can't help but wonder why?
Well, I have several mods that I use that I have to mod the .jar for. So I'm pretty much stuck doing this anyway.
Also, I have several machines here in the house, with several family users that do and don't have much computer experience. It's much easier for me to pass them all a .jar file and have them put it in their versions folder, than it is to have me walk each of them through installing all the mods that they want.
I also help a few friends out in this way, so it's much easier for me to share a .jar file with them than it is to do a screen share with each of them, to get their individual machines configured with all the mods that we use.
I didn't even find a litemod.json file. The only files in the .litemod file was a version.text and Configuration.yml, then two folders. I did copy the entire contents into the .jar root, but the WECUI mod did not show up during worledit operations. I can only assume that the mod did not load correctly.
Oh good grief, okay. Please if you're using ancient versions of stuff please mention it next time: I will naturally expect people to be using the latest version of things unless specified otherwise and you must be using a really old version (> 7 months!) if you still have version.txt.
Okay well the same still applies, the mod will work if you copy the whole contents of the litemod into the minecraft jar but naturally be aware that liteloader for versions prior to 1.6 will only work with the old minecraft launcher and will not work with launchwrapper when running in the new launcher for obvious reasons.
Well, I have several mods that I use that I have to mod the .jar for. So I'm pretty much stuck doing this anyway.
Again if you'd specified that you were using a really old version at the outset this could have removed some confusion. Prior to 1.6 jar modding was still necessary so this makes sense and you can ignore everything I said about it not being needed.
Also, I have several machines here in the house, with several family users that do and don't have much computer experience. It's much easier for me to pass them all a .jar file and have them put it in their versions folder, than it is to have me walk each of them through installing all the mods that they want.
I also help a few friends out in this way, so it's much easier for me to share a .jar file with them than it is to do a screen share with each of them, to get their individual machines configured with all the mods that we use.
This is pretty common for pre-1.6, obviously this method isn't really viable with 1.6 and later since there's just too much that physically won't run when dumped in the jar (forge, liteloader, etc).
+1 with Wh1rledPeas, I too would rather have a traditional JAR/ZIP than a LiteMod.
Not because I want to manually put mods into the game's JAR any more, but because I use MagicLauncher to pick and choose which mods I want to run. (this is pretty much just a graphical way of shoving mods into a temporary game JAR) Not been doing manual mod stuffing since MagicLauncher arrived.
MagicLauncher also doesn't need to do any signature verifications or whatever stuff the latest official launcher does, so I'd guess it's launching Minecraft in the same way as the 1st and 2nd official launchers did.
+1 with Wh1rledPeas, I too would rather have a traditional JAR/ZIP than a LiteMod.
*sigh*. As I've said several times, there's nothing stopping you putting the classes in the jar, but I strongly recommend against it. .litemod files are just .zips with a custom extension so you can open them with winrar or 7zip.
Not because I want to manually put mods into the game's JAR any more, but because I use MagicLauncher to pick and choose which mods I want to run. (this is pretty much just a graphical way of shoving mods into a temporary game JAR) Not been doing manual mod stuffing since MagicLauncher arrived.
There are other 3rd-party launchers which are better than MagicLauncher but if you want to use it that's fine. It actually does use the same technology as the new launcher, it has to because 1.6 and later require the new launching method. In fact, MagicLauncher doesn't even work without everything being properly set up in the real launcher because it treats launcher versions (the JSON recipes for launching the game which the real launcher uses) as "environments" which it just bootstraps in exactly the same way. What I don't really understand is why people aren't using the native profiling capabilities in the official launcher rather than using potentially insecure third-party launchers. It's perfectly possible to have sets of mods and in fact even entirely different game setups in the real launcher, so all you're really achieving by using MagicLauncher is giving up the new, much more secure authentication system known as Yggdrasil.
But I do respect that it's a choice, and liteloader does support loading mods which are patched directly into the jar, I could remove that functionality but I'm not going to because some people still want to use that method and I see no reason to prevent them from doing so.
However I do still recommend against using third-party launchers for security reasons.
MagicLauncher also doesn't need to do any signature verifications or whatever stuff the latest official launcher does, so I'd guess it's launching Minecraft in the same way as the 1st and 2nd official launchers did.
Not at all, as I mentioned above it has to use the new bootstrapping method because 1.6 and later require this to be the case. I think all it does to allow mods to be "turned on and off" is just temporarily rename them during game startup, it doesn't really have any other way of effectively controlling which mods are loaded because that's at the discretion of the loader (FML or liteloader or similar). Besides jar-patching mods which can be selectively added to the classpath, obviously it's pretty simple to control the loading of those, but to be honest everything should be moving away from jar patching now anyway since it's really not necessary and was a far from ideal solution in the first place of course.
Oh good grief, okay. Please if you're using ancient versions of stuff please mention it next time: I will naturally expect people to be using the latest version of things unless specified otherwise and you must be using a really old version (> 7 months!) if you still have version.txt.
That was a dyslexic moment for me. I'm sorry. I grabbed 1.4.6 instead of 1.6.4.
I am indeed using 1.6.4 I'll try the CORRECT download this time and hope for better success....
My bad...
EDIT: All working fine now. I really derped that one up. Sorry for wasting your time Mumfrey!
I did notice (from guesswork) that your litemod files were just ZIP's. I just did some unpacking, moving around, and repacking to produce a new ZIP that MagicLauncher could use.
Which launchers would you recommend over MagicLauncher? I've been using it for quite a few months now and its' been doing what I wanted brilliantly. (just handling the JAR building from the mods I want to use at any time)
EDIT: I've done some more research and it seems that the Gui gets rendered behind blocks when I join the world. The gui has to be small and it must fit in the window.
It vanishs behind the blocks if it gets (nearly, like itemframes) out of the screen or when I look up or down (without parts the cui getting out of the screen)
EDIT2: Ok I can't get a consistent image of the bug. On the most servers I tested it it happens, but on my main server it works properly.
The only difference between the servers is that I join the server on which it works properly over a bungeecoord. It has the bug on the lobbyserver but when I connect to this one server it works just fine... I can not think of anything serverside that would lead to such different behaviour.
EDIT3: Ok, i cannot recognize any pattern... now it also happened to vanish behind blocks on the server where it worked before. Out of nowhere, while I was using it. Strange.
EDIT4: It does not happen in third person mode and it also seems to be depending on the direction from where I am looking at the selection:
I think I know the bug you're describing too, I've noticed it too, with no apparent pattern.
I did notice (from guesswork) that your litemod files were just ZIP's. I just did some unpacking, moving around, and repacking to produce a new ZIP that MagicLauncher could use.
Yep that's all fine and dandy, note that from 1.7 onwards this will probably not work though because the litemod metadata becomes more important in 1.7 and separating it will likely cause things to stop working.
Which launchers would you recommend over MagicLauncher? I've been using it for quite a few months now and its' been doing what I wanted brilliantly. (just handling the JAR building from the mods I want to use at any time)
I'd recommend using the real launcher to be honest, learn about the profiles capability (specifically, the ability to have each profile run in a separate base directory) and just enjoy the better security and regular updates.
Any idea how to get this working with the Feed The Beast launcher? LOVE the mod but so far I've struck out with everything I've tried. Thanks for the mod and any help!
Love the mod and have used it some time before, was never disappointed.
The only problem, is since I recently got back into worldedit, I wanted to use this mod again. But I cannot get it to work, I seem to have installed LiteLoader correctly (don't know how to check [I run the LiteLoader Profile when launching minecraft]). I play on a personal Server (only myself, MCPC+ Server) on version 1.6.4. I only downloaded this for the client only, as this is a "Client-Side" mod.
I cannot check if it fails in SSP, because I don't have singleplayer commands.
Much Help would be appreciated,
Skinner 3212
EDIT - Never mind everything I said, the mod started working spontaneously when relaunching minecraft launcher for the 5th time (have no idea what changed...)
I love this mod but there's one problem: I can't seem to get it to accept my new config files. I'd prefer it to use a different color set as defined in the config files (i changed all i could find) but in the 1.6 versions at least, there was no change; it reverts back to the original red/blue/green color scheme. In the 1.7.2 version, it might have used my new config, but I'm still using 1.6.2/4 for the most part.
Is there a way to get WECUI to accept/load my new config in 1.6 or must I wait for 1.7?
Good thing its updated for 1.7.2, but I don't think ill go back in 1.7.2 because of flipped texture bugs, got my skin mod working with MCP 1.7.2Beta (With your fix) but did someone done a fix? oh ill check if it exists, awesome mod Mumfrey.
I'm using 1.7.4, so why MCP didn't planned to work on 1.7.4 instead of 1.7.2? ugh 1.8 is coming soon modders time for 1.7.2/4 is wasted... daaamn..
Rollback Post to RevisionRollBack
MagicLauncher is the best launcher I ever used! Hoping the developer would update for 1.13.x and 1.14.x
Also, for the record, I am using a mac.
I start with the lightloader jar and manually add my mods into the jar. It seems that the file structure of the WECUI doesn't contain a .class in the root. I tried copying the wecui and org folders into the root of the jar, but that evidently doesn't work. With so many subdirectories in the wecui folder, I felt uneasy about simply adding that whole mess to the root of the jar.
How do we go about adding this mod directly into our jar?
-Peas
Well putting mods in the jar isn't really supported from 1.6 onwards, you can try it and there's no reason that it shouldn't work, just be aware that it's not supported and obviously involves invalidating the jar signature, which isn't really required any more.
If you were to do this you just put the whole contents of the litemod into the jar (folders and all) except for the mod metadata file (litemod.json). Obviously there are no .class files in the root, litemods are completely base clean so there will be no classes in the default package at all.
Be aware that placing mods in the classpath is not supported though, and invalidating the jar signature is not supported, recommended or even necessary.
EDIT: can I ask why you want to do this? It really doesn't achieve anything at all. It doesn't make it portable, it doesn't make it more efficient. All it does is make installation harder and strip the metadata, neither of which seems like a particularly good reason for doing this so I can't help but wonder why?
I didn't even find a litemod.json file. The only files in the .litemod file was a version.text and Configuration.yml, then two folders. I did copy the entire contents into the .jar root, but the WECUI mod did not show up during worledit operations. I can only assume that the mod did not load correctly.
Well, I have several mods that I use that I have to mod the .jar for. So I'm pretty much stuck doing this anyway.
Also, I have several machines here in the house, with several family users that do and don't have much computer experience. It's much easier for me to pass them all a .jar file and have them put it in their versions folder, than it is to have me walk each of them through installing all the mods that they want.
I also help a few friends out in this way, so it's much easier for me to share a .jar file with them than it is to do a screen share with each of them, to get their individual machines configured with all the mods that we use.
Oh good grief, okay. Please if you're using ancient versions of stuff please mention it next time: I will naturally expect people to be using the latest version of things unless specified otherwise and you must be using a really old version (> 7 months!) if you still have version.txt.
Okay well the same still applies, the mod will work if you copy the whole contents of the litemod into the minecraft jar but naturally be aware that liteloader for versions prior to 1.6 will only work with the old minecraft launcher and will not work with launchwrapper when running in the new launcher for obvious reasons.
Again if you'd specified that you were using a really old version at the outset this could have removed some confusion. Prior to 1.6 jar modding was still necessary so this makes sense and you can ignore everything I said about it not being needed.
This is pretty common for pre-1.6, obviously this method isn't really viable with 1.6 and later since there's just too much that physically won't run when dumped in the jar (forge, liteloader, etc).
Not because I want to manually put mods into the game's JAR any more, but because I use MagicLauncher to pick and choose which mods I want to run. (this is pretty much just a graphical way of shoving mods into a temporary game JAR) Not been doing manual mod stuffing since MagicLauncher arrived.
MagicLauncher also doesn't need to do any signature verifications or whatever stuff the latest official launcher does, so I'd guess it's launching Minecraft in the same way as the 1st and 2nd official launchers did.
*sigh*. As I've said several times, there's nothing stopping you putting the classes in the jar, but I strongly recommend against it. .litemod files are just .zips with a custom extension so you can open them with winrar or 7zip.
There are other 3rd-party launchers which are better than MagicLauncher but if you want to use it that's fine. It actually does use the same technology as the new launcher, it has to because 1.6 and later require the new launching method. In fact, MagicLauncher doesn't even work without everything being properly set up in the real launcher because it treats launcher versions (the JSON recipes for launching the game which the real launcher uses) as "environments" which it just bootstraps in exactly the same way. What I don't really understand is why people aren't using the native profiling capabilities in the official launcher rather than using potentially insecure third-party launchers. It's perfectly possible to have sets of mods and in fact even entirely different game setups in the real launcher, so all you're really achieving by using MagicLauncher is giving up the new, much more secure authentication system known as Yggdrasil.
But I do respect that it's a choice, and liteloader does support loading mods which are patched directly into the jar, I could remove that functionality but I'm not going to because some people still want to use that method and I see no reason to prevent them from doing so.
However I do still recommend against using third-party launchers for security reasons.
Not at all, as I mentioned above it has to use the new bootstrapping method because 1.6 and later require this to be the case. I think all it does to allow mods to be "turned on and off" is just temporarily rename them during game startup, it doesn't really have any other way of effectively controlling which mods are loaded because that's at the discretion of the loader (FML or liteloader or similar). Besides jar-patching mods which can be selectively added to the classpath, obviously it's pretty simple to control the loading of those, but to be honest everything should be moving away from jar patching now anyway since it's really not necessary and was a far from ideal solution in the first place of course.
That was a dyslexic moment for me. I'm sorry. I grabbed 1.4.6 instead of 1.6.4.
I am indeed using 1.6.4 I'll try the CORRECT download this time and hope for better success....
My bad...
EDIT: All working fine now. I really derped that one up. Sorry for wasting your time Mumfrey!
Which launchers would you recommend over MagicLauncher? I've been using it for quite a few months now and its' been doing what I wanted brilliantly. (just handling the JAR building from the mods I want to use at any time)
I think I know the bug you're describing too, I've noticed it too, with no apparent pattern.
Click Here To Check Out The Server Forums
Server IP: play.pokemonserver.net
Ah, see now that all makes sense! Glad you got it working.
Yep that's all fine and dandy, note that from 1.7 onwards this will probably not work though because the litemod metadata becomes more important in 1.7 and separating it will likely cause things to stop working.
I'd recommend using the real launcher to be honest, learn about the profiles capability (specifically, the ability to have each profile run in a separate base directory) and just enjoy the better security and regular updates.
I'm looking into this, it seems to be related to when certain blocks/entities are on the screen, haven't determined which yet.
Love the mod and have used it some time before, was never disappointed.
The only problem, is since I recently got back into worldedit, I wanted to use this mod again. But I cannot get it to work, I seem to have installed LiteLoader correctly (don't know how to check [I run the LiteLoader Profile when launching minecraft]). I play on a personal Server (only myself, MCPC+ Server) on version 1.6.4. I only downloaded this for the client only, as this is a "Client-Side" mod.
I cannot check if it fails in SSP, because I don't have singleplayer commands.
Much Help would be appreciated,
Skinner 3212
EDIT - Never mind everything I said, the mod started working spontaneously when relaunching minecraft launcher for the 5th time (have no idea what changed...)
Is there a way to get WECUI to accept/load my new config in 1.6 or must I wait for 1.7?
I'm using 1.7.4, so why MCP didn't planned to work on 1.7.4 instead of 1.7.2? ugh 1.8 is coming soon modders time for 1.7.2/4 is wasted... daaamn..
...is it? Got a source there? :s