LiteLoader / LiteLoader · Issues

I think this may be the case in earlier versions, too. In 1.7.10, I've heard user complaints on how liteloader increases the modpack load time by a figure around 30%.

I found the reason:

http://develop.liteloader.com/liteloader/LiteLoader/blob/1.12.2/src/client/java/com/mumfrey/liteloader/client/LiteLoaderEventBrokerClient.java#L275

I edited that line out and tested, LL works fine still (for our purpose (WorldEditCUI)) and it no longer does the double stitch.

I did some git archaeology and the resource reload in LiteLoader comes from "LiteLoader 1.6.2 - register mod files as resource packs" here.

I'm not sure if it's needed any more, it's worth taking a look at. We removed the startup Resource Reload from Forge in 1.12 here.

@mezz could it be the fact that forge has this special behaviour that's causing the weird interaction that causes the issue in #53 do you think?

The resource reload used to be needed but are you basically saying that if forge is present then it's not the case? If so I can simply detect forge (which I do already) and selectively disable the resource reload.

I don't think that is the cause of the issue 53. It may cause something different and weird to happen with JEI but I haven't investigated that fully yet.

Forge used to trigger an extra resource reload like LiteLoader does, but when we looked at it more closely we realized we didn't really need to any more. It was taking a long time at startup so we removed it and so there is no special behavior from Forge any more.

I'm not sure why LiteLoader adds an extra resource reload, but I think it would be nice to remove it if possible because of the performance impact.

I'm not sure why LiteLoader adds an extra resource reload, but I think it would be nice to remove it if possible because of the performance impact.

As far as I know it shouldn't trigger an "extra" resource reload, it just triggers a resource reload when mod initialisation is done. What I'm saying is if Forge already does this at the right time (or has an alternative solution that fixes the issues with not doing this) then I can simply omit the resource reload when Forge is present.

The "extra" one you might be referring to is that the sound manager is excluded from the post-init reload and then reloaded separately once the main menu is reached. This was to fix an issue with the sound system getting thread locked that happened on 32 bit systems.

I mean "extra" compared to vanilla Minecraft, which does not trigger a resource reload at the end of loading.

Forge hasn't fixed anything, we just didn't need to trigger a resource reload any more and so it was removed.

So I have found the following: LiteLoader is loading its own internal resource pack in the LiteLoader: namespace. This is done within onPostInit, which takes places after Forge's first texture stitch. Due to this fact all of LiteLoaders resources are never loaded, such as the textures and language files.