Minecraft Java Prism Launcher (MultiMC Fork)

[anoraktrend]

What is the name of the app?

Minecraft Java Prism Launcher

(Optional) Where is the app hosted?

https://github.com/PrismLauncher/PrismLauncher

About the app

It's a MultiMC Fork without the issues of MultiMC's or PolyMC's Devs. Has some quality of life features that make it nicer than MultiMC.

Confirmations

• I have confirmed that this app is legal and not piracy.
• I have confirmed that this app has never been discussed in https://github.com/Botspot/pi-apps/issues and https://github.com/Botspot/pi-apps/pulls, and it is not in the Pi Apps app list.
• I have confirmed that this app can run on Raspberry Pi.

[anoraktrend]

PolyMC has a separate metarepo system.

[anoraktrend]

For now, here's the current metarepo. https://github.com/dada513/meta-polymc-arm64
There's also a pull request for a useful future feature here:
PolyMC/PolyMC#425

[Botspot]

This seems like your department, @theofficialgman.

[theofficialgman]

To avoid getting on peterix's bad side (aka, MultiMC upstream), I will not associate myself with PolyMC. He has already stated he will not accept contributions from those devs and does not like what they have done in regards to relicensing the codebase.

I was working on integrating armhf/arm64 windows, macos, and linux support to MultiMC upstream, and I have already made very significant progress in that regard, but that is currently on hold until I get free time this summer to continue it.

TLDR: I don't want more hacks across multiple projects, I want to implement a solution that works upstream, can be adopted by mojang (which my new work has potential to) that benefits everyone.

[glowiak]

But we do have some features that mmc does NOT have, like the mod downloader

[theofficialgman]

I'm aware of the features, I track the development over there. My stance is unchanged.

right now there are more pressing issues to me. Mojang has added ARM64 MacOS as a target today (22w16a), and I need to stay in contact with MultiMC developers to make sure the meta repo format from mojang and multimc stays as logical as possible for this change.

[anoraktrend]

PolyMC's meta repo system also has the advantage of not even touching the MultiMC servers, as it uses certain software straight from their sources. I still plan on keeping notes on PolyMC's arm compatibility because of this.

[theofficialgman]

PolyMC's meta repo system also has the advantage of not even touching the MultiMC servers

its not an advantage, you are a fork, MultiMC required polymc to host its own meta and files by denying access to MultiMC servers.

if you have actually looked at the meta that you linked already https://github.com/dada513/meta-polymc-arm64 , you would see that it already pulls from my binaries hosted on my github. dada513 can continue to do this of course, I leave them freely available so that other projects can use them at their disposal, but I will not guarantee function and that I will not update them in the future. We don't need the pi community to be in this polymc controversy as well... like I said, I'm working on a solution upstream which can be adopted by ALL minecraft launchers which will bring support for lwjgl2/3 armhf/arm64 macos, windows, and linux, but you will have to wait a little while longer for that to happen.

I don't want to support polymc because then the maintenance falls back on me, while also jeopardizing my name with other projects.

[d-513]

btw, that meta repo was purely experimental and I do not intend to keep it updated

[Heath123]

We don't need the pi community to be in this polymc controversy as well

If you don’t want controversy, there are two valid options: accept both launchers, or accept neither of them. PolyMC is a perfectly valid piece of software, and it’s only tainted by controversy as much as MultiMC is. You can’t just not include any software that has had controversy, since almost all big software has.

Disclaimer: I don’t really know what’s going on here, I just came here from a link

[Botspot]

@Heath123, While everyone's opinion is valued, at the end of the day it comes down to the maintainers of a project to decide what they want to personally prioritize.

You can’t just not include any software that has had controversy, since almost all big software has.

We are not a public company with an obligation to be fair. On the contrary, we are a small group of volunteers who work on Pi-Apps in our own free time. If none of us Pi-Apps maintainers want to be responsible for maintaining a particular app, that's our decision to make.

Several people in this thread are insisting that @theofficialgman do something that he doesn't want to do. It is illogical to insist that volunteer personnel complete work against their will. That is no longer "volunteer" work - it's slavery.

TL;DR If somebody else comes along and offers to submit this app themselves, and they offer to maintain it going forward, things may be different. The Lokinet app is a good example of this in practice.

[anoraktrend]

This is why I'm planning to continue documenting the progress of PolyMC's arm support. Half to attract attention of someone else who might want to do so and half to document it for myself for potential future use.

[anoraktrend]

It was not a request for gman to do anything, just documentation in case any future volunteer wanted to support it.

[Heath123]

@Heath123, While everyone's opinion is valued, at the end of the day it comes down to the maintainers of a project to decide what they want to personally prioritize.

You can’t just not include any software that has had controversy, since almost all big software has.

We are not a public company with an obligation to be fair. On the contrary, we are a small group of volunteers who work on Pi-Apps in our own free time. If none of us Pi-Apps maintainers want to be responsible for maintaining a particular app, that's our decision to make.

Several people in this thread are insisting that @theofficialgman do something that he doesn't want to do. It is illogical to insist that volunteer personnel complete work against their will. That is no longer "volunteer" work - it's slavery.

TL;DR If somebody else comes along and offers to submit this app themselves, and they offer to maintain it going forward, things may be different. The Lokinet app is a good example of this in practice.

Oh, I assumed he was saying "PolyMC can't be included here because it would make the MultiMC maintainer annoyed"

[theofficialgman]

Several people in this thread are insisting that @theofficialgman do something that he doesn't want to do. It is illogical to insist that volunteer personnel complete work against their will. That is no longer "volunteer" work - it's slavery.

I'd just like to add that I also took the posts from these users as well as the multiple downvotes on my responses to also mean they insist on me doing sometime I have already stated I do not want to do for the reasons I already outlined.

I could for sure go out and make each and every open source launcher out there compatible with armhf/arm64, but ultimately if I do that, then people will expect me to maintain them, provide help for them even if its not related to the work I did for armhf/arm64, etc.

This already happens for MultiMC and I'm ok with dealing with that for one launcher but more is just too many. This is why I want to and am working on upstreamable support, something that benefits every launcher that chooses to adopt the changes.

As botspot and I already outlined, nothing stops another user from creating their own automatically updating meta repo for PolyMC, creating a build/install script, and providing user support and maintenance.

As of last week, mojang has already made a significant change that makes future versions of minecraft almost immediately compatible with armhf/arm64 linux, macos, and windows, and thats the change to lwjgl 3.1.1 which already supports these targets.

[anoraktrend]

Polymc is already compatible with arm64/armhf, they just lack the meta setup for it. It can be built on arm64/armhf in a way similar to multimc, they just need to use original dev's binaries (which exist and is better than relying petrix's hosted binaries in general). My current intent is to keep information up to date as polymc is rapidly changing, unlike multimc.

[anoraktrend]

Recent updates to polymc: multiarch meta is close. Support for multiarch has been PR'd. It's looking like it's coming soon.
Built and tested it on my RPI400. It looks like it's coming soon because there is a new channel in the PolyMC discord for it.

[theofficialgman]

multiarch meta is merged and the launcher is updated for support in code.
however I still don't have intentions to create or maintain build for it in pi-apps.
The quote from @Botspot here still applies:

TL;DR If somebody else comes along and offers to submit this app themselves, and they offer to maintain it going forward, things may be different.

Due to polymc's very high system requirements, someone will need to build it statically with qt 5.15 or 6.X bundled with it, utilizing modern gcc (with full CPP 17 support), as well as a fairly recent cmake. Ideally, this static build would be made with no or very low GLIBC requirements (maintaining compatibility with stretch as a goal and bionic and buster is a requirement while also working on new OSs like jammy and bullseye). Anything that doesn't satify those requirements will be rejected from inclusion (they are an extension of the app eligibility rubric)

It also only supports ARM64 and they (polymc) have no intention of adding ARMhf to their repos

[DioEgizio]

Due to polymc's very high system requirements, someone will need to build it statically with qt 5.15 or 6.X bundled with it, utilizing modern gcc (with full CPP 17 support), as well as a fairly recent cmake.

qt 5.12 should work fine too

[theofficialgman]

qt 5.12 should work fine too

yes I am aware. minecraft itself will run just fine on debian stretch, debian buster, ubuntu bionic, and older distros that do not even have QT 5.12. So for the sake of building, using QT 5.12 would make no sense as it could be any day that the polymc maintainers decide to throw out support for older QT again.

[Scrumplex]

So for the sake of building, using QT 5.12 would make no sense as it could be any day that the polymc maintainers decide to throw out support for older QT again.

Dropping Qt 5 support is in fact planned. But we are probably talking about years here. I think Plasma 6 would need to establish Qt 6 on the Linux desktop first, and we would need to wait until the ecosystem has shifted to primarily using Qt 6.

About C++17: We did that fairly recently to be able to get rid of some code. I have to admit that there hasn't been much thought, at least on my end, about support for older platforms. We might revert to C++11, if it isn't a huge issue on our end.

In any case, most system requirements are soft limits. You would probably need to change a few lines in CMakeLists.txt to bypass those. Of course, stuff might not build, but that should be solvable with a few smaller patches.

armhf support is totally doable. I think we wouldn't even need to change anything in the code, as it can handle any architecture now, not just aarch64, amd64 and i386/i686. We mainly focused on aarch64, as the selection of armhf hardware powerful enough to run Minecraft isn't that huge anyway. If you want to help, feel free to create a PR at https://github.com/PolyMC/meta. You would just need to extend the file at static/mojang/library-patches.json with the necessary library entries.

[theofficialgman]

@Scrumplex I would greatly appreciate if it could be reverted to C++11. The hosts having to have libstdc++ 9.1 or newer (for #include filesystem) currently is an annoying issue as it requires including libstdc++ binaries with the launcher and building with host libstdc++ updated.

Including QT 5.15 along with the build has proven to be quite simple now that I figured it out so I'm ok enough with that.

edit: this repo works great for systems without std::filesystem, I hope it gets pulled into PolyMC https://github.com/flowln/PolyMC/tree/og_mac