[Feature Request] LWJGL 3.3.0 Support about polymc HOT 30 CLOSED

Alright, I suppose if PolyMC does have enough desired features such that a good portion of M1 players would like to switch to it, then you could work with us on that. Thank you!

from polymc.

Will do, this would help for shilling like you said

from polymc.

So the documentation for the MultiMC meta scripts is non-existent so we need to figure out what is going on in any of it.

from polymc.

M1 macs are already handled well in the ManyMC multimc fork (about one month old now https://github.com/MinecraftMachina/ManyMC)

they maintain a custom meta repo for arm64 macos as well on that github as well
consider joining their discord: https://discord.gg/CcFxPaDnjv

from polymc.

AFAIK the Metas scripts repo needs configured with keys to 2 other repos in config folder, the scripts will push to them and you use github pages on the 2 other repos

from polymc.

AFAIK the Metas scripts repo needs configured with keys to 2 other repos in config folder, the scripts will push to them and you use github pages on the 2 other repos

I'm aware of that. I'm just not sure how to add an LWJGL version.

For now we could include that meta repository as the default for ARM Macs.

from polymc.

AFAIK the Metas scripts repo needs configured with keys to 2 other repos in config folder, the scripts will push to them and you use github pages on the 2 other repos

I'm aware of that. I'm just not sure how to add an LWJGL version.

For now we could include that meta repository as the default for ARM Macs.

You can't just "add a version" of lwjgl. To be more specific, yes you can add a version but that doesn't change what version multimc selects to use. Every single Minecraft json has the lwjgl version hardcoded into it

from polymc.

You're able to change the version of LWJGL. example:

All of these versions are the ones available in the MultiMC-meta repository.

from polymc.

You're able to change the version of LWJGL. example:

@binex-dsk
incorrect, you can try to change lwjgl version all you want there, it will not change when you launch. I would know, since I already host my own arm64/armhf linux meta repo. https://github.com/theofficialgman/meta-multimc
Its an oversight in the multimc gui, you can select it all you want, but it will not change when you launch

If you want more info, go to my meta repo linked here, or join the ManyMC discord where this has been discussed in depth

from polymc.

each minecraft version has its own " "requires": [" version of lwjgl, you can see right here in the 1.18.1.json as an example

https://github.com/MultiMC/meta-multimc/blob/c4135c30c1345cad5e7767457508aed4d1904c0e/net.minecraft/1.18.1.json#L408

from polymc.

Alright, with that being said; is it possible to allow for LWJGL 3.3.0 to be used here?

from polymc.

Alright, with that being said; is it possible to allow for LWJGL 3.3.0 to be used here?

Multimc does not support multiple cpu architectures in the launcher, it only has the capacity to read natives-linux natives-macos and natives-windows from the meta. so until that is fixed in the launcher (which peterix has already told me he will not do and will not accept PRs for until minecraft itself supports arm), then you will have to use a totally separate meta repo for arm64 macos than the default multimc meta (so that you point to the arm64 natives with natives-macos instead of the default x86-64 natives)

using lwjgl 3.3.0 itself doesn't solve anything, its just that lwjgl 3.3.0 added building arm64 macos and windows natives, lwjgl 3.2.3 allowed for building arm64/armhf linux natives

the easiest way to use these natives is to use the manymc meta repo which already overwrites lwjgl 3.1.2, 3.1.6, 3.2.2 x86_64 with lwjgl 3.3.0 arm64 from the maven repos: https://github.com/MinecraftMachina/meta-multimc-arm64
My guess is @ViRb3 would rather just have people use ManyMC rather than your fork here

from polymc.

My guess is @ViRb3 would rather just have people use ManyMC rather than your fork here

@ViRb3 ManyMC doesn't appear to have a license, you have to retain at-least the rights of Apache2 from MultiMC on a fork, or switch to a compatible license, Unlicensed is All Rights Reserved and that is not compatible.

from polymc.

Oh hello, first time I am coming across this project.

Regarding M1 Mac support, I would really prefer to keep M1 players at ManyMC for now. Everything is as stable as it gets, and my daily driver is a M1 Mac, so I can provide, in my opinion, very high quality support over at ManyMC. I could be interested in collaborating with PolyMC, depending on a lot of technical details, but that can come as a separate conversation. For now, I will be thankful if we don't split the M1 community even more.

Regarding the license, I will have to investigate that a bit. I am by no means a lawyer, but my understanding is that since MultiMC is licensed under Apache 2.0, and the license explicitly permits sublicensing (section 2), I don't see why a temporary "All Rights Reserved" at ManyMC would be a problem for now. I definitely don't plan to keep it this way, but I am also unsure what license to settle on.

from polymc.

Oh hello, first time I am coming across this project.

Regarding M1 Mac support, I would really prefer to keep M1 players at ManyMC for now. Everything is as stable as it gets, and my daily driver is a M1 Mac, so I can provide, in my opinion, very high quality support over at ManyMC. I could be interested in collaborating with PolyMC, depending on a lot of technical details, but that can come as a separate conversation. For now, I will be thankful if we don't split the M1 community even more.

Regarding the license, I will have to investigate that a bit. I am by no means a lawyer, but my understanding is that since MultiMC is licensed under Apache 2.0, and the license explicitly permits sublicensing (section 2), I don't see why a temporary "All Rights Reserved" at ManyMC would be a problem for now. I definitely don't plan to keep it this way, but I am also unsure what license to settle on.

So if I interpret this correctly; you'd rather we not implement this for now, and redirect M1 players to ManyMC for now (maybe until LWJGL 3.3.0 is officially supported by the launcher?)

from polymc.

If that's the case then maybe just 3.3 without arm support, 3.3 is still highly needed for anyone with a high polling keyboard

from polymc.

Fyi 3.3 introduces multiple breaking changes. One of which will cause the sodium mod to crash (mods expect you to use the version of lwjgl that Minecraft ships with).

from polymc.

@binex-dsk Indeed, I would rather you send all M1 players to ManyMC for now. There are more changes than just LWJGL 3.3.0 to get Minecraft working properly on M1, so if you want to properly support it, you'd have to essentially duplicate ManyMC. If something changes in the future, I am happy to redirect all players again.

from polymc.

Thank you for the understanding! Feel free to join the ManyMC Discord and get in touch with me for any reason at all.

from polymc.

I would like to point out lwjgl 3.3 isn't just for Mac support, it fixes a major issue with high polling keyboards that causes massive key drop, even if polymc doesn't add arm support, 3.3 support should still be considered for this reason

from polymc.

@ShayBox

Fyi 3.3 introduces multiple breaking changes. One of which will cause the sodium mod to crash (mods expect you to use the version of lwjgl that Minecraft ships with).

This will be an issue. I think the correct approach here would be to fork LWJGL and backport the polling fix to each version, but that's not exactly trivial.

from polymc.

@ShayBox

Fyi 3.3 introduces multiple breaking changes. One of which will cause the sodium mod to crash (mods expect you to use the version of lwjgl that Minecraft ships with).

Yeah that's fair, but it's not supposed to be a default setting. It's used as a fix for people that need it, I can't play minecraft at all unless I update it to 3.3, which means I can't play old versions of minecraft at all.

from polymc.

Yeah that's fair, but it's not supposed to be a default setting. It's used as a fix for people that need it, I can't play minecraft at all unless I update it to 3.3, which means I can't play old versions of minecraft at all.

the build changes necessary for building lwjgl3 on arm64 macos can be backported to all versions of lwjgl (3.1.6, 3.2.1, and 3.2.2 included which is what versions of minecraft use), its just that nobody has done it (see my github for the armhf/arm64 linux backports for those versions https://github.com/theofficialgman/lwjgl3/tree/3.2.2-arm binaries are in another repo).

lwjgl 2.9.4 (for minecraft 1.12 and earlier) has already been built as well, that is pretty trivial (see manymc meta repo)

from polymc.

You should get that back ported and put into manymc for the arm users that want to play older versions of minecraft.

I need lwjgl 3.3.0 to play minecraft on amd64 period, the game drops too many inputs to be playable on my keyboard and nobody is going to backport the high polling fix to older versions of lwjgl, mojang doesn't even know there's an issue and I doubt lwjgl fixed it intentionally, I haven't found any reference to the fix.

Nobody knows about this issue outside of a hand full of people, mostly wooting and razer keyboard owners that play minecraft.

from polymc.

Nobody knows about this issue outside of a hand full of people, mostly wooting and razer keyboard owners that play minecraft.

lwjgl itself doesn't handle inputs (well not since lwjgl3 at least), that comes from the library included in lwjgl, GLFW which is a totally separate project (https://github.com/glfw/glfw). LWJGL3 includes and updates GLFW in its own source periodically. They don't copy the comment history from GLFW in LWJGL which is why you probably missed it.

I'm assuming this was a windows only issue that was fixed in this commit on glfw glfw/glfw@7da3e52
these changes were first included in the lwjgl 3.3.0 release

were you referring issues with your keyboard on macos, windows, or linux (because there have been other bugfixes for those other platforms in GLFW)?

from polymc.

If the issue is with GLFW then, if you have an up-to-date GLFW installed systemwide it should work perfectly fine to set PolyMC to use the system GLFW, which should fix the polling rate.

from polymc.

for context, binex-dsk is referring to this:

you can check the GLFW box and see if the issue goes away

from polymc.

The glfw box does not fix it, it's on windows and Linux (unsure about Mac)

from polymc.

The glfw box does not fix it, it's on windows and Linux (unsure about Mac)

@ShayBox your system almost certainly does not have a high enough GLFW version to contain the fixes
the fixes are currently only in the glfw master branch, they do not have a release candidate yet

you would need to compile glfw3 from the master branch source and install that on your system rather than use the package manager
no clue if windows even has a system GLFW, so your testing there probably isn't any help

from polymc.

I believe this should be reopened, we are in a position to actually implement this as metaserver is polymc's now

from polymc.