Minecraft Forums

Quote from Mumfrey»

I basically ripped the core technology of liteloader out and turned it into a standalone project called Mixin which now powers Sponge as well as quite a few other mods which are adopting it since it's so powerful.

1. Let us apply an interface of our choosing to the target class at runtime
2. Let us insert a method implementation for any methods which are declared in the interface but are not present in the target class

OMG, you actually implemented Objective-C style categories to extend a class in Java!

Does this work with forge mods, or only with lite loader mods?

Does it work back in 1.7.10, or if not, what's the earliest working version?
i.e. -- how much is "mixin" tied to minecraft, and how much is it "generic java"?

Quote from Keybounce»

OMG, you actually implemented Objective-C style categories to extend a class in Java!

Does this work with forge mods, or only with lite loader mods?

Does it work back in 1.7.10, or if not, what's the earliest working version?
i.e. -- how much is "mixin" tied to minecraft, and how much is it "generic java"?

The type of mixing that I'm doing actually covers various different concepts from different programming languages, allowing for equivalents of extension methods, similar transformations to some AOP frameworks like AspectJ, traits, and various others. The main thing about Mixin is that it's designed with mod development in mind so support for obfuscated targets is built into it, much of this is achieved because Mixin itself is in two parts: the core library which does all the runtime work, and an Annotation Processor which manages all of the compile-time processing which ties into ForgeGradle.

Essentially, mixin is about 70% general-purpose and 30% specialised to the task of working with Minecraft. The general-purpose parts can of course be used stand-alone, so you could use it with any project and not leverage the parts of the framework which deal with obfuscation. The earliest version it will work with is not limited at all, any version which can be wrapped in launchwrapper could use it, right back to classic. However the limiting factor for development is the toolchain. Whilst you could use the AP with (for example) very old versions of MCP, you'd need to generate all the input data by hand and create a complex build process to gather the outputs and bundle them with the compiled artefact.

The oldest version of liteloader which supports mixin is 1.8.9, though much of the functionality was available before that in liteloader under different names, and the foundation of mixin is actually liteloader's legacy core transformers ripped out and made stand-alone.

Quote from Romaq»

The LiteLoader page needs an update for http://www.minecraftforum.net/forums/mapping-and-modding/minecraft-mods/1287646-uyjulians-x-ray-mod-1-12-1-no-patcher-required (1.12 and 1.12.1 are now available). There may be other updates needed, that just happened to be the one I noticed while checking for ones that have not updated yet. If anyone has a few more to add (or devs following this message thread that know they've updated) it would be useful for @Mumphrey to have a complete list. It is just unfortunate I'm short on time to double-check it right now.

Updated. I have had various pokes about other mods too so it should be mostly up to date.

Will a new tutorial be out soon? I would like to get started working with Liteloader, but I'm not sure exactly how I'm supposed to use it with MCP..

(I use IntelliJ)

U dont need MCP anymore for Liteloader

https://github.com/1337Zero/Zombe#i-dont-trust-you-and-want-to-build-my-own-version

not quite sure if u need liteloader, or not^^

basicly just do this

if not working look at mumfreys sponge tutorial which is nearly the same for liteloader

Using the JNI defeats the entire purpose of Java. it's supposed to be compile once, run anywhere. You can't do that with c. Not to mention the security risks that brings.

You can use the JNI if you want, but you have to make a custom launcher profile and manually load the natives.

Well, using the example mod on the site as a template, I managed to get a mod setup and everything seems to be working fine. Here's some snippets from the output when running the generated "Minecraft Client" run configuration:

[07:43:37] [main/INFO]: Inspecting jar metadata in 'mod-liteloadertest-1.0-mc1.12.1.litemod'
[07:43:37] [main/INFO]: Considering valid mod file: C:\Users\502ba\IdeaProjects\liteloadertest\run\mods\1.12.1\mod-liteloadertest-1.0-mc1.12.1.litemod
[07:43:37] [main/INFO]: Adding newest valid mod file 'C:\Users\502ba\IdeaProjects\liteloadertest\run\mods\1.12.1\mod-liteloadertest-1.0-mc1.12.1.litemod' at revision 11.0000

[07:43:53] [main/INFO]: Successfully injected mod file 'C:\Users\502ba\IdeaProjects\liteloadertest\run\mods\1.12.1\mod-liteloadertest-1.0-mc1.12.1.litemod' into classpath

However, when it finishes opening, my mod does not show up in the mod list, and the onTick in the mod isn't being run.

What's even stranger is, if something is invalid like, say, I put the wrong mcversion, it DOES show in the menu and says the incorrect version that the mod supports. But as soon as I fix that, it no longer shows up.

Quote from Trophonix»

Well, using the example mod on the site as a template, I managed to get a mod setup and everything seems to be working fine. Here's some snippets from the output when running the generated "Minecraft Client" run configuration:

[07:43:37] [main/INFO]: Inspecting jar metadata in 'mod-liteloadertest-1.0-mc1.12.1.litemod'
[07:43:37] [main/INFO]: Considering valid mod file: C:\Users\502ba\IdeaProjects\liteloadertest\run\mods\1.12.1\mod-liteloadertest-1.0-mc1.12.1.litemod
[07:43:37] [main/INFO]: Adding newest valid mod file 'C:\Users\502ba\IdeaProjects\liteloadertest\run\mods\1.12.1\mod-liteloadertest-1.0-mc1.12.1.litemod' at revision 11.0000

[07:43:53] [main/INFO]: Successfully injected mod file 'C:\Users\502ba\IdeaProjects\liteloadertest\run\mods\1.12.1\mod-liteloadertest-1.0-mc1.12.1.litemod' into classpath

However, when it finishes opening, my mod does not show up in the mod list, and the onTick in the mod isn't being run.

What's even stranger is, if something is invalid like, say, I put the wrong mcversion, it DOES show in the menu and says the incorrect version that the mod supports. But as soon as I fix that, it no longer shows up.

The logs indicate that the container is valid, so if you make the container invalid then it will show that up as an error. However if the container is valid but doesn't contain any valid mod classes, then it's not going to show up in the list. The relevant part of the log is where it says "Discovering mods in valid mod files...", if it shows no results then it's because your jar doesn't actually contain any valid mods.

For a mod class to be valid it must:

• Start with the prefix LiteMod
• Implement one or more of the Liteloader listener interfaces

I suggest you start with the ExampleMod and check that you can get it building, and then move from there. If in doubt, please provide the whole startup log since it's difficult to tell exactly what's going on from looking at only snippets.

Quote from Mumfrey»

The logs indicate that the container is valid, so if you make the container invalid then it will show that up as an error. However if the container is valid but doesn't contain any valid mod classes, then it's not going to show up in the list. The relevant part of the log is where it says "Discovering mods in valid mod files...", if it shows no results then it's because your jar doesn't actually contain any valid mods.

For a mod class to be valid it must:

• Start with the prefix LiteMod
• Implement one or more of the Liteloader listener interfaces

I suggest you start with the ExampleMod and check that you can get it building, and then move from there. If in doubt, please provide the whole startup log since it's difficult to tell exactly what's going on from looking at only snippets.

Ohh I failed to realize the class had to start with "LiteMod". It's always something so simple haha. Thanks a lot!

Quote from wischi_chr»

Hi Guys.

I'm using Liteloader mainly to run WorldDownloader to save my Multiplayerbuilding locally and it works like a charm (on the servers I'm currently working) but I read online that some servers dislike LiteLoader and WorldDownloader and have ways to detect it because LiteLoader is sending a modlist to the server on login.

So here my question for the devs: Is it true, that liteloader sends the modlist to the server? or the protocol is altered in a way so the server is able to detect it or are those detections based on heuristics?

There is obviously no need to hide anything from the server, because if you're abiding by the server rules then there's really no issue. Servers can identify LiteLoader and possibly WDL if they wish to, though there are much better ways to control this kind of thing for a server's point of view.

• LiteLoader installed alone will change the client "brand" to "LiteLoader" which is sent to the server when you log in
• LiteLoader does not send a mod list to the server (what would be the point?)
• Any mods which support ClientPermissions such as VoxelMap or Macro/Keybind mod will send a permissions request packet to the server when you log in, this means these mods are easily detectable, but the whole point of permissions is that if (for example) the server wants to allow or disallow the entity radar in VoxelMap, they can simply do so using permissions
• Mods are of course free to send their own custom packets to the server, for example WorldEdtCUI sends a handshake packet to the server if WorldEdit is installed
• Whilst WorldDownloader doesn't use ClientPermissions, it does provide a server plugin which can be used to disable, control or enhance its functionality, so if a server is running this plugin then it can interact with WDL on your client. I'm not sure if WDL advertises itself in any other way. I would imagine it does not, other than maybe registering the custom payload channel, which would of course be visible from the server.

As for your original question. I don't know of any servers that would have a legitimate reason to dislike liteloader since, like forge, it's just a platform for mods to actually load, and any servers which disliked liteloader would have identical reasons to dislike forge. Also, liteloader does not send a modlist to the server because it would be pretty pointless, but certain other network traffic could be used to identify specific mods as described above. I'm not sure "heuristics" is the right word for this kind of detection, because straightforward examimation of the incoming payload would make it obvious exactly which mod is involved.

Honestly if you adhere to any guidelines made by the server as to whether certain things are allowed or not, then there likely won't be a problem.

an alternative to the extend from forge option is to click "extract" in the liteloader installer and place the new file in your mods folder, which forge will load as any other mod.

Use the extract option in the installer and copy it to your mods folder. This should work with any forge install. If that doesn't work, there may be an incompatibility and we'll need your game log.

So I have pushed the 1.12.2 artefacts up to the repo, this is an interesting version bump and most if not all 1.12.1 mods will load under 1.12.2 with no changes. The following notes are for mod developers:

• I have set the 1.12.2 LiteLoader to support the 1.12.r2 version string because most mods for 1.12.1 will load under this version, so as per my standard of using the r-numbers I have set 1.12.2 to support r2 but for the purposes of mods who are not compatible with 1.12.2, 1.12.2 also supports r-number r3 in case a 1.12.4 comes out which is also compatible.
In short, mods which have deployed using the r-number for 1.12.1 (which includes my mods macros and wecui) will work without changes on 1.12.2. Those deploying without the r-number can either make a release with the r-number if they are compatible, can make a release with r3 if they know they are not compatible, or can make a release using straight-up 1.12.2 if they know they're likely to break with even minor changes.


• For reference, the changes I was able to easily observe between 1.12.1 and 1.12.2 are (direct from my notes) as follows:

Notch  Searge                                              Notes
aex    net/minecraft/entity/item/EntityEnderPearl          Method "changeDimension" added
aqn    net/minecraft/block/BlockFarmland                   Minor changes to "turn to dirt" logic
blj    net/minecraft/client/gui/GuiDownloadTerrain         Keepalive logic removed, moved into NetHandler
blr    net/minecraft/client/gui/GuiMainMenu                Added "edition" field and edition overlay
blt    net/minecraft/client/gui/GuiWinGame                 Added "edition" field and edition overlay
jd     net/minecraft/network/play/server/SPacketKeepAlive  keepalive id int to long
lj     net/minecraft/network/play/client/CPacketKeepAlive  keepalive id int to long
pa     net/minecraft/network/NetHandlerPlayServer          keepalive logic changes




• Mixin was bumped to 0.7.4 but these are internal changes which don't affect anything really.

In short, most stuff should "just work" unless it's touching any of the stuff above. The obf did not change other than the added methods, 1.12.1 and 1.12.2 are obf-compatible.