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.

[embeddedt]

The events seem to be correlated with respect to each time a GUI frame is rendered, at least with this simple test code. (Both keyPressed and charTyped print the same frame number.) Do you see the same behavior?

import com.mojang.blaze3d.matrix.MatrixStack;
import net.minecraft.client.gui.screen.Screen;
import net.minecraft.util.text.ITextComponent;
import net.minecraft.util.text.StringTextComponent;
import org.lwjgl.glfw.GLFW;

public class TestScreen extends Screen {
    protected TestScreen() {
        super(new StringTextComponent("hello world"));
    }

    public int frame = 0;

    @Override
    public void render(MatrixStack p_230430_1_, int p_230430_2_, int p_230430_3_, float p_230430_4_) {
        super.render(p_230430_1_, p_230430_2_, p_230430_3_, p_230430_4_);
        this.frame++;
    }

    @Override
    public boolean charTyped(char ch, int p_231042_2_) {
        System.out.println("frame " + frame + " char " + ch);
        return false;
    }

    @Override
    public boolean keyPressed(int pKeycode, int pScancode, int pModifiers) {
        System.out.println("frame " + frame + " keycode " + GLFW.glfwGetKeyName(pKeycode, pScancode));
        return false;
    }
}

Output:

[18:49:00] [Render thread/INFO] [STDOUT/]: [TestScreen:keyPressed:30]: frame 342 keycode d
[18:49:00] [Render thread/INFO] [STDOUT/]: [TestScreen:charTyped:24]: frame 342 char d
[18:49:01] [Render thread/INFO] [STDOUT/]: [TestScreen:keyPressed:30]: frame 368 keycode d
[18:49:01] [Render thread/INFO] [STDOUT/]: [TestScreen:charTyped:24]: frame 368 char d

[KosmosPrime]

Not from within the OC branch, no. In fact, using render over tick makes it much less likely to recognize characters (from 50% to less than 1%).
(Do note that I have to use these separate hooks and generate a single key_down event with both key & char.)

[kristibektashi]

I have since reproduced the issue in a Ubuntu VM (was surprised to see it even supporting holograms & shaders) and as expected, the issue is that char events get delivered too late. However, looking at the GLFW code I don't see why this happens, the key (except duplicates) and char events get delivered at the same time, and during the glfwPollEvents method. I could allow events to appear a tick late but that's hardly a fix: high frame-rate could require a higher delay, which negatively impacts low frame-rate situations.

Minecraft on Linux has a bug where key presses are sometimes sent twice, this is also why sometimes the letter 't' (or whatever your keybind for chat is) appears in the chatbox when you open chat. This is a vanilla bug and happens on all versions afaik

[embeddedt]

Ah, good point! I assume MC-122477 is the issue you're referring to? There is a good writeup here about it and it does sound related.

[kristibektashi]

Any progress?

[kristibektashi]

Ah, good point! I assume MC-122477 is the issue you're referring to? There is a good writeup here about it and it does sound related.

Yea that's the one. What is interesting is that it doesn't happen when using MultiMC but often happens when using the vanilla launcher

Source: I use Linux and the bug stopped happening when I switched to MultiMC from vanilla launcher

[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.