Feature/creative tab

[Grahmindol]

feat(creative-tab): Better Creative Tab & OpenPrinter Reimplementation

---

Description

This PR overhauls the creative tab organization and deeply integrates OpenPrinter directly into OpenComputers.

Inspired by the section-based layout in Create: Aeronautics, the goal was to streamline item organization and make browsing mod content far more intuitive. What initially seemed like a simple tab reorganization revealed deeper architectural differences in how OpenPrinter was structured compared to OpenComputers. To make OpenPrinter feel like a native, seamless part of the OpenComputers ecosystem rather than an externally grafted addon, OpenPrinter was reimplemented directly into the main codebase.

Key Changes

• New creative tab.
• Merging of opencoputer and openprinter codebase
• more general PortableStorageMenu/Inventories for futher usage

[Grahmindol]

Here we are !

[CaitlynMainer]

The Creative tab rewrite is a nice change, and I do think something along those lines is needed.

The OpenPrinter changes are the part I’m not comfortable merging, though. OpenPrinter was intentionally integrated while still being kept separate internally, including remaining in Java, so porting it to Scala and folding it directly into the main codebase goes against that structure.

If you’d like to remove the OpenPrinter changes and resubmit the Creative tab work on its own, I’d be happy to review that.

[Grahmindol]

Regarding OpenPrinter, I'd appreciate a quick clarification: when I suggested removing it from the mod, I understood from your response that OpenPrinter is intended to be integrated directly into OpenComputers.

Is the plan to make OpenPrinter a standalone/independent mod again in the long term, or will it remain folded into the main repository?

if OpenPrinter is meant to remain inside the repository long-term, what is the reasoning behind keeping it internally separated (and in Java) rather than fully integrating it into the main Scala codebase?

Why should OpenSecurity remain a separate mod while OpenPrinter has to stay in this awkward state?

Is your discomfort more about the change of language, or the change of structure?

As a quick piece of feedback on OpenPrinter: having worked on it, I found that maintaining two very distinct architectural patterns and languages (Java and Scala) in the same repository creates noticeable friction. Aligning it with the rest of the codebase would make maintenance much easier moving forward.

Before I touch anything, I want to make sure I fully understand so we can avoid this kind of issue in the future.

[CaitlynMainer]

I’ll merge this once you resolve the conflict introduced by the latest PR merge in OCItems.scala and remove the unrelated Machine.scala async-beep change, which had already been removed before this fork. I can handle the remaining issues separately.

[Grahmindol]

Unrelated Machine.scala async-beep change removed !

Conflict introduced by the latest PR merge in OCItems.scala removed !

Hemaining issues handled by an other PR !

[SquidDev]

To be clear, I don't think anybody is arguing that OpenPrinters is in a perfect state, but more that it's very low on the priority list. There's a lot of larger parts of the main mod which need modernising first.

I'd rather have to port all of OpenComputers to Java

There's definitely a desire to have more (possibly eventually all) of the mod in Java, but moving away from that is going to have to be an incremental process. There's a lot of places relying on traits for instance, which will obviously not work on Java, so needs a bit of a rethink.

[RobertCochran]

I've tasked a friend with translating the doc/ file and the .lang files into the languages ​​using AI (with a Python script and Ollama).

Please do not add more AI back into this fork. We are working hard to remove as much of it as we possibly can. I fully acknowledge that this port started from someone using AI and that we have anything usable at all as a result of said use, but given the sentiment around the use of AI in creative endeavors like these in general, I'd recommend thinking long-term and not burning bridges. Besides, IME, if you are not qualified to do whatever it is yourself, you are probably not qualified to direct an AI to do it.

Personally, my issue lies with the OCDevice, DeviceMenu, and DeviceScreen classes.
In an object-oriented language that supports inheritance, having a "kind" field followed by a "switch" statement in every method goes against my religion.

Anyway, I might have a compulsive urge to make everything uniform..........
To be honest, I'd rather have to port all of OpenComputers to Java than stay in this state.

Keep several things in mind here:

• The base version of OpenComputers has been in maintenance mode for years. There has been little to no development work going on there, thus we have a large degree of bit-rot as the world changes around it. Remember that Minecraft 1.12 is 10 years old, and the OpenComputers codebase as a whole is older than that.
• The 1.20 vibeport - in several senses - did not help the matter (see previous statement about being qualified to do something) and introduced many many issues of its own. That is driving the effort to remove a lot of the questionable things introduced there.
• End users largely do not care about code quality as long as it doesn't cause them material issues while playing (ie they would only care if poor code led to lag in-game). The most important thing is that the mod works and can be played with. If you don't have those things, you do not have user interest. If you don't have user interest, you are going to struggle to attract contributors to help you with the mod and things will stay status quo. Working mod > pretty code mod. The major exception to 'largely do not care' these days is that a lot of people want nothing to do with AI-generated works, for understandable reasons (see above). This is another factor in wanting to remove all of the AI stuff still present.
• This port is still extremely early days and we're in the process of trying to rebuild a dev team. It's only existed like 2-3 weeks. Michiyo is doing the overwhelming bulk of the work, followed by SquidDev helping with modernization aspects, and I have done some small fixing (I'm not an experienced Java/Scala dev and thus not an experienced Minecraft mod dev, so my contributions are limited in the code-slinging department) and reporting of bugs. We have had some drive-by contributors (thanks folks!), but 99% of the work on this mod is being done by 3 people. We have to be smart about allocating our resources during this seed period of trying to get the mod back into shape and rebuild the audience.

[Daydrain]

I agree with not using Al in the development of the mod, because if you don't know how to do something yourself, you can't ask an Al to do it and be sure it's correct. However, I don't know anyone who could translate from English into Italian, French, Mexican Portuguese, European Portuguese, Traditional Chinese, Simplified Chinese, and German. On the other hand, language models are specifically designed to "understand" and "express" themselves fluently in all these languages. To me, translation is one of the only areas where it [makes sense to use them].

[Grahmindol]

That said, that’s not the subject of this PR—it’s finished!

[CaitlynMainer]

Attempted to load class net/minecraft/client/gui/GuiGraphics for invalid dist DEDICATED_SERVER

CreativeTab is loaded on both Client and Server, you can't have client rendering code in a common location.

[CaitlynMainer]

Also with this PR in place I am no longer able to register floppies directly from external mods, all floppy names seem to be forced to their internal name, and I am unable to register an item to the OC creative tab from another mod.

[Grahmindol]

The renderBannersn method wasn't even being called, but that simple declaration was what caused the error—I never would have guessed. So, I moved it.

[Grahmindol]

Normally, you can continue adding items to the end of the tab just as before, since I’m not adding padding at the end.

When using the API, floppy disks and EEPROMs should already appear in the tab.
To be able to add items to a section,I added a method to li.cil.oc.api.Items.java.

public static void registerStack(ItemStack stack, String name, String section_id) {
        if (API.items != null)
            API.items.registerStack(stack, name, section_id);
    }

Thanks the reviewing!

[Grahmindol]

The floppy API isn't clear on this point.

In li.cil.oc.api.Items.java, there was no option for display name.

While Loot strangely adds it after normal creation.

So I updated OCItem to accept it directly during creation, and I didn't change the API signature for backward compatibility reasons.

That being said, at this stage of the project, backward compatibility isn't a major issue.

In short, all the functionality is back; floppy items aren't the subject of this pull request.

(This will certainly be my next pull request if no one else takes care of it.)