xcl [Mod][XCL] X-Change Life Mod Loader Utility

[Nywrin]

Been meaning to ask this but can we delete the unpacked folder or does it serve some type of purpose? 

[togashikokujin]

13 hours ago, Nywrin said:

Been meaning to ask this but can we delete the unpacked folder or does it serve some type of purpose? 

The .unpacked folder is the thing that makes it all work. You're safe to delete the .zip and .twee mod files that you've already added to the mod loader, because it's taken what it needs and put it in that unpacked folder.

[Nywrin]

4 hours ago, togashikokujin said:

The .unpacked folder is the thing that makes it all work. You're safe to delete the .zip and .twee mod files that you've already added to the mod loader, because it's taken what it needs and put it in that unpacked folder.

 

Thanks. I still think it is nutty that the modded folder I have is 49.8 gigs and the unpacked is 40.7 gigs while my folder with only the most current versions (a few exceptions for some backups to certain iffy mods) is 40.1 gigs. 90 gigs even if I delete the downloaded mods is oof.

[Majorshepard]

I tried to use the newest jar version (2.4.0) and it says there was an error every time I try to open it. I then tried downloading it through the 2.3.1 version but instead of a jar file I got the rpm one which, after looking it up, is apparently for linux? I don't even use Linux.

[ds64]

same, the 2.4.0 gave me java exception error, but the old one (2.3.1) is just fine.

[Definitely Not Insane]

I am also getting this java error, and when using the previous loader to update, it downloaded the rpm instead of the jar.

Edited January 9 by ItsInfernal

[iguita123]

"x-change-life-mod-loader_2.4.0-1_amd64.deb" How about a little explanations of what is this?Tnx!

[RAAMPEAK]

new updated one keeps having a java error

[togashikokujin]

We've been working to make the mod loader less dependent on user-installed java since that's the most frequent type of problem we see people having. Ironically, the way we did it required upgrading the java version to 17, so that's a problem people are having. You can either upgrade your system java to 17+, or you can use the new installers depending on operating system. The .deb and .rpm files are for different flavors of Linux, .exe and .msi for Windows. We'll have .dmg and .app files as soon as we get our mac build up and running.

[Majorshepard]

I didn't even know there where other java versions, my one was still updating as it got an update a few months ago. To learn there's not only version higher than that but that it goes up to 25 is wild, surprised Java never tells anyone about this at all. I thought Java 8 was the only one and just called Java x-x Here's hoping upgrading doesn't break anything.

 

Edit: Just downloaded Java 21 and the jar file works now, in fact it goes a lot faster too. I dunno if its an issue but it didn't get rid of Java 8 so now i have 8 and 21 on the same pc, is that fine? Or do I need to remove 8 so I don't have issues?

Edited January 11 by Majorshepard

[Definitely Not Insane]

What’s also strange is that the latest version listed on java.com is still Java version 8; only oracle.com offers the newer versions. I discovered this after googling “Java download,” where Java.com came up as the first result. Anyone know why there are two sites? Not important, just curious.

Edited January 11 by ItsInfernal

[Definitely Not Insane]

2 hours ago, Majorshepard said:

I didn't even know there where other java versions, my one was still updating as it got an update a few months ago. To learn there's not only version higher than that but that it goes up to 25 is wild, surprised Java never tells anyone about this at all. I thought Java 8 was the only one and just called Java x-x Here's hoping upgrading doesn't break anything.

 

Edit: Just downloaded Java 21 and the jar file works now, in fact it goes a lot faster too. I dunno if its an issue but it didn't get rid of Java 8 so now i have 8 and 21 on the same pc, is that fine? Or do I need to remove 8 so I don't have issues?

Why install 21 and not 25? Also have both 8 and 21 installed should be fine, you can uninstall 8 to be safe, but it should be all good.

Edited January 11 by ItsInfernal

[Majorshepard]

21 hours ago, ItsInfernal said:

Why install 21 and not 25? Also have both 8 and 21 installed should be fine, you can uninstall 8 to be safe, but it should be all good.

The way I understood it was that 21 has more of an archive than 25, 25 is very recent as it only came out in September. 21 might also be more compatible, However I may have been misinformed as I gave a basic glance at a handful of posts about it.

 

But thanks for the info

[Definitely Not Insane]

1 hour ago, Majorshepard said:

The way I understood it was that 21 has more of an archive than 25, 25 is very recent as it only came out in September. 21 might also be more compatible, However I may have been misinformed as I gave a basic glance at a handful of posts about it.

 

But thanks for the info

I didn't realise that 25 was that new, probably best to stick with 21 then.

[rrh]

Quote

You can either upgrade your system java to 17+, or you can use the new installers depending on operating system.

It would be helpful if you put this info right into the What's New in Version 2.4.0 description. Then people see this right away and don't have to spend time on the error and then reading this on the Support page.

[Luna Muffin]

new update still causing Java Exception.

[Definitely Not Insane]

3 hours ago, Luna Muffin said:

new update still causing Java Exception.

You need Java version 17 or newer. Download it from oracle.com, not java.com, since java.com isn’t up to date for some reason.

[Definitely Not Insane]

What does the fix bugs button do, and why can't I click it? Every time I try to, it moves away from my cursor.

Edited January 20 by Definitely Not Insane

[ObedientCat]

I giggled a bit at the fix bugs button, but it will get old fast as I mouse over it to get to another button, and that changes the position of the button I intended to click on.

 

Edit:

Spoiler

Lol, it can be turned off in preferences.

 

Edited January 20 by ObedientCat
got gud

[ObedientCat]

2.4.1 actually breaks the interface for me, I had to downgrade to 2.4.0. Getting two `-->` under my character portrait.

[rrh]

Is there a reason that the img and aud folders now contain links to the files instead of the actual files?

Edited January 21 by rrh
Fixed typo

[togashikokujin]

17 hours ago, rrh said:

Is there a reason that the img and aud folders now contain links to the files instead of the actual files?

It seems like with either the installation or the upgrade to java 17, Windows is now allowing the mod loader to create soft links. The new setting to prefer hard links over soft links should restore it to the old behavior if it doesn't work right for you with the links.

[QiNaga]

With the new shift to shipping native installers for the modloader, I feel I need to weigh in on the choice of direction change...

 

Doesn't this just create more unnecessary development overhead for the developers, now having to maintain multiple versions instead of just a single .jar version (which is truly cross-platform and has been working well enough for me on Linux since I made the switch from Windows)? It seems like a strange choice... but of course not unappreciated.

 

As for the Linux-versions specifically - it would be absolutely awesome if the Linux version could be made available as an appimage or flatpak instead (if not in addition).

 

The native .rpm and .deb packages are nice to have, and on par with the MacOS and Windows native installers, but given the nature of the Linux landscape, I fear these formats might be too distro-specific, therefore inadvertently excluding some Linux-users. They're also a chore to get working on immutable systems such a Bazzite, for instance, as that requires layering which kinda defeats the purpose of immutability in the first place (and thus defeats the purpose of providing more convenience than just sticking to Java-versions).

 

Because of these factors, there's a slow but definite trend in the Linux-world toward containerization rather than native packages. AppImage is servicable on every Linxu distro out there, pretty much out of the box. And Flatpaks can be installed on any distro so long as the user activates flathub, which is easy enough to do, well documented, and very likely to already have been done by the respective user interested in the modloader. So these formats are thus truly distro agnostic, The defacto standard for Linux is becoming Flatpak...

 

So, while I thank the foresight of the devs to make Linux-versions available at all, it might actually be of benefit to them to simply make the modloader available as an appimage instead, or else flatpak (I wouldn't suggest doing both, as that would be largely redundant). This would result in the least amount of problems for the end-users in Linux-land, and possibly help to reduce development overhead for the devs, allowing them to only focus on one Linux-format.

 

So that would be a strong recommendation from me as a user of Linux Mint, Bazzite, and Aurora. Personally I'd go with Flatpak first, if available, then appimage, and only then I'd consider native packages like .deb or .rpm since, on my primary systems (Bazzite and Aurora), that would require something like Distrobox or layering to get working, which in my view kinda defeats the purpose of trying to make it more convenient than just sticking to Java... 

 

I would definitely NOT remove the .jar version at all if there's not a .appimage or .flatpak version available instead. Having Linux versions available in ONLY .deb or .rpm WILL exclude some less tech-savvy Linux users... for sure. The future of Linux lies in containerisation, and the dominant force on that front is Flatpak.

[Ainz Ooal Dong]

hey i have a problem with the new mod loader idk if it's just not compatible with 23.5 but i downloaded the 2.4.2 and i downloaded java 17 from oracle and any time i try to open the mod loader it opens a window very briefly and closes the menu right away so i'm not sure what's up

[togashikokujin]

10 hours ago, QiNaga said:

With the new shift to shipping native installers for the modloader, I feel I need to weigh in on the choice of direction change...

 

Doesn't this just create more unnecessary development overhead for the developers, now having to maintain multiple versions instead of just a single .jar version (which is truly cross-platform and has been working well enough for me on Linux since I made the switch from Windows)? It seems like a strange choice... but of course not unappreciated.

 

As for the Linux-versions specifically - it would be absolutely awesome if the Linux version could be made available as an appimage or flatpak instead (if not in addition).

 

The native .rpm and .deb packages are nice to have, and on par with the MacOS and Windows native installers, but given the nature of the Linux landscape, I fear these formats might be too distro-specific, therefore inadvertently excluding some Linux-users. They're also a chore to get working on immutable systems such a Bazzite, for instance, as that requires layering which kinda defeats the purpose of immutability in the first place (and thus defeats the purpose of providing more convenience than just sticking to Java-versions).

 

Because of these factors, there's a slow but definite trend in the Linux-world toward containerization rather than native packages. AppImage is servicable on every Linxu distro out there, pretty much out of the box. And Flatpaks can be installed on any distro so long as the user activates flathub, which is easy enough to do, well documented, and very likely to already have been done by the respective user interested in the modloader. So these formats are thus truly distro agnostic, The defacto standard for Linux is becoming Flatpak...

 

So, while I thank the foresight of the devs to make Linux-versions available at all, it might actually be of benefit to them to simply make the modloader available as an appimage instead, or else flatpak (I wouldn't suggest doing both, as that would be largely redundant). This would result in the least amount of problems for the end-users in Linux-land, and possibly help to reduce development overhead for the devs, allowing them to only focus on one Linux-format.

 

So that would be a strong recommendation from me as a user of Linux Mint, Bazzite, and Aurora. Personally I'd go with Flatpak first, if available, then appimage, and only then I'd consider native packages like .deb or .rpm since, on my primary systems (Bazzite and Aurora), that would require something like Distrobox or layering to get working, which in my view kinda defeats the purpose of trying to make it more convenient than just sticking to Java... 

 

I would definitely NOT remove the .jar version at all if there's not a .appimage or .flatpak version available instead. Having Linux versions available in ONLY .deb or .rpm WILL exclude some less tech-savvy Linux users... for sure. The future of Linux lies in containerisation, and the dominant force on that front is Flatpak.

Definitely lots of good points in there. I appreciate the feedback, and there are some nuances that might help the decisions make a little more sense.

 

The development overhead to also ship the installers is minimal. It's still all one version, we're just packing it into installable bundles that include the necessary Java runtime and libraries. With JDK 17+ the jpackage utility allows us to create the installers easily, and there's a great Gradle plugin that makes it pretty simple.

 

The immediate impetus for the change is to move away from requiring users to understand Java versions and ensure they have the right one, since they don't even need an external JRE installed to run them. The majority of problems people report in the Discord have to do with incorrect versions of Java or file associations not being set up correctly to run the jar file itself.

 

The formats being distributed currently are simply the ones that are built for us with the initial configuration. jpackage should be able to make appimages with the right configuration, we just haven't gotten that working yet. Once we do we will probably stop bothering with the .deb and .rpm files, we just made those available since they were already being built for us.

 

The jar version will always be an option as well, no reason to take that choice away when at the end of the day all the installers are just wrappers around the jar anyway.