Port OpenComputers to Minecraft 1.16.5

[KosmosPrime]

This is a port of the 1.12 branch (as it appeared in May) for Minecraft 1.16.5. I've done some testing on the OC features to make sure they work (the mod is very much playable), but it's a big mod so I haven't tested every case yet (similar with mod compat: it works but it might behave differently in some cases).
There are some things I've had to change, for example, GUI input works differently in Minecraft and so the semantics of the keyboard are different as well. Because of this, OPPM packages might be incompatible (but I've not removed/looked into that issue yet) and there have been some changes to the API.
By the way, I'm making this as a pull request for the 1.12 branch (because that's what it's based on) but the intent is to create a new branch.

[asiekierka]

To be honest, given that the OpenComputers development team has de facto disbanded, with me not having been an original member at any time and not feeling confident enough to touch some parts of the codebase... I think your best option might be to make a fork (like CC:Tweaked forked off ComputerCraft).

[Lockl00p]

To be honest, given that the OpenComputers development team has de facto disbanded, with me not having been an original member at any time and not feeling confident enough to touch some parts of the codebase... I think your best option might be to make a fork (like CC:Tweaked forked off ComputerCraft).

I was actually about to say the same thing! You (the pull request author) should make a fork (like maybe OC Rebuilt). If You do, I'll fork that to make a restitched version.

[KosmosPrime]

The original intent was to port OC to have something while OC2 isn't ready for production yet. OC2 was more active at the time and I thought a port would be good for the time being. If I'd designed for a fork I would have probably rewritten the mod around some challenging aspects (I'm not very good with scala, IDs and metadata are no longer a thing, library changes, datapack support, etc.). So I settled for a port because I felt that a fork would also imply being maintained parallel to OC2's existence.
As mentioned I'm fine with maintaining the 1.16 branch, maybe later a 1.18/1.19 too, but I'm unsure where to take this from here.

[embeddedt]

I'd like to see this get a release even with the keyboard bug still present (as it may not even really be OC's fault). That's infinitely better than no post-1.12 release at all.

[alexhorner]

The original intent was to port OC to have something while OC2 isn't ready for production yet. OC2 was more active at the time and I thought a port would be good for the time being. If I'd designed for a fork I would have probably rewritten the mod around some challenging aspects (I'm not very good with scala, IDs and metadata are no longer a thing, library changes, datapack support, etc.). So I settled for a port because I felt that a fork would also imply being maintained parallel to OC2's existence.
As mentioned I'm fine with maintaining the 1.16 branch, maybe later a 1.18/1.19 too, but I'm unsure where to take this from here.

OC2 being completely different, it'd be a shame to set OC aside once OC2 becomes production ready, unless of course OC2 suddenly brings in full compatibility with OC however I don't see that happening considering they take two completely different stances on the backend (Linux Vs Lua APIs)

[Lockl00p]

The original intent was to port OC to have something while OC2 isn't ready for production yet. OC2 was more active at the time and I thought a port would be good for the time being. If I'd designed for a fork I would have probably rewritten the mod around some challenging aspects (I'm not very good with scala, IDs and metadata are no longer a thing, library changes, datapack support, etc.). So I settled for a port because I felt that a fork would also imply being maintained parallel to OC2's existence.
As mentioned I'm fine with maintaining the 1.16 branch, maybe later a 1.18/1.19 too, but I'm unsure where to take this from here.

If you’re planning to set it aside I could attempt to start developing it instead. Maybe add datapack support.

[Mai-Lapyst]

If you’re planning to set it aside I could attempt to start developing it instead. Maybe add datapack support.

I tried to port it to a higher MC version (as well as to java) some time back but I lack experience in Scala and OC's backend code is heavily make use of Scala features; If the port is being made in Java (which would be more of a rewrite than a plain port) I would see If I can help with development.

It would really be a shame to not have the lua / script-based OC available in modern versions of mc.

[Lockl00p]

If you’re planning to set it aside I could attempt to start developing it instead. Maybe add datapack support.

I tried to port it to a higher MC version (as well as to java) some time back but I lack experience in Scala and OC's backend code is heavily make use of Scala features; If the port is being made in Java (which would be more of a rewrite than a plain port) I would see If I can help with development.

It would really be a shame to not have the lua / script-based OC available in modern versions of mc.

Wait it uses scala? Oh god, guess I won’t be porting it.

[Piripe]

I'd like to see this get a release even with the keyboard bug still present (as it may not even really be OC's fault). That's infinitely better than no post-1.12 release at all.

@embeddedt You can download the latest release here.

[Lockl00p]

Any attempt to compile it, throws an error, saying

Failed to notify project evaluation listener.
Cannot mutate content repository descriptor 'BUNDELED_-174096774(file:/C:/Users/me/.gradle/caches/forge_gradle/bundled_deobf_repo)' after repository has been used
Could not find method prepareRuns() for arguments [build_dj7izmay26m3csqhkflr0jpl3$_run_closure14$_closure50@164c1d85] on root project 'OpenComputers' of type org.gradle.api.Project.

Was that due to gradle version or something?

[asiekierka]

Yes. With ForgeGradle and other Gradle-based modding solutions, you must use the same major Gradle version as the project, due to how much they tend to need to hack into the internals of Gradle.

Try using the ./gradlew script, not your system's Gradle installation.

[Lockl00p]

Yes. With ForgeGradle and other Gradle-based modding solutions, you must use the same major Gradle version as the project, due to how much they tend to need to hack into the internals of Gradle.

Try using the ./gradlew script, not your system's Gradle installation.

But I did, and it still threw the error. I ran gradlew and it did not work.

[Lockl00p]

Yes. With ForgeGradle and other Gradle-based modding solutions, you must use the same major Gradle version as the project, due to how much they tend to need to hack into the internals of Gradle.

Try using the ./gradlew script, not your system's Gradle installation.

I have found the issue. He was trying to pr his master:1.16.5 so I figured that was where he did his work on. It was on his catchup-1.16.5 branch.

[KosmosPrime]

The reason for that is that every time I push to master now, it'll update this PR, requiring a re-run of the CI (and possibly requesting a new review). The catchup branch merges changes from the 1.12 branch since I started the port.
I see that compiling the master branch locally or through github CI does produce this error now... I have no idea what it means though, and it certainly didn't use to do that. It's also not just the gradle version, same happens if I select gradle 7.6.1 instead, but the catchup branch is somehow fine.

[kristibektashi]

Any news in this?

[finnaminope]

Someone needs to take this on or the mod will die. i dont know any java tho

[PublicVoidUpdate]

speak for yourself, i still actively use java 1.12.2 mods, and only play newer versions in modpacks.

[PublicVoidUpdate]

also gregtech new horizons is still on 1.7.10 and its not dying anytime soon.

[kristibektashi]

@asiekierka @KosmosPrime so the changes got approved. Is this enough to get this PR merged?

[KosmosPrime]

After a pull request is opened, anyone with read access can review and comment on the changes it proposes.

This isn't the first such review and I don't know what motivates it. Github doesn't show it under "Show all reviewers" at the bottom anyway.

Unless this person has write access, #3709 probably still applies.

[asiekierka]

I thought I have made it clear, but: with the retirement of all of the project's lead developers, this PR will not be merged, because there's nobody to maintain it regardless. For minor fixes, at least I or someone else can step in to handle the existing codebase, but this is a relatively large change which would require us to re-learn the codebase.

I continue to encourage KosmosPrime to start a fork to carry it on. Call it LibreComputers or something like that. I will do my best to point people to it if it proves itself to be reliable.

[finnaminope]

I Am Thinking That Maybe We Could Make An OpenComputers Like Mod For Luanti. Similar Mods Already Exist So We May Be Able To Make It Work. I Would Also Want It To Be Mostly Compatible With The Existing OpenComputers Lua API.

[uis246]

I continue to encourage KosmosPrime to start a fork to carry it on. Call it LibreComputers or something like that. I will do my best to point people to it if it proves itself to be reliable.

Maybe upstream it, but separate maintainers for new versions? I mean something similar to how linux-next and linux LTS kernels work, where first is maintained by Linus, while older versions by Greg. Here it would be old team does versions up to 1.12.2 and new team does higher versions.

[kristibektashi]

I continue to encourage KosmosPrime to start a fork to carry it on. Call it LibreComputers or something like that. I will do my best to point people to it if it proves itself to be reliable.

Maybe upstream it, but separate maintainers for new versions? I mean something similar to how linux-next and linux LTS kernels work, where first is maintained by Linus, while older versions by Greg. Here it would be old team does versions up to 1.12.2 and new team does higher versions.

My understanding is that the older team is gone, and they may not want to give control to the repo to someone else. Forking is probably the best idea, for now at least.