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.

[Grahmindol]

The check fail but in work on my machine....

How can we get logs ?

I’ve completed all the requested changes. Everything should be good to go now—let me know if anything else needs tweaking!

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

[Grahmindol]

Can we now discuss the fate of OpenPrinter?

I would at least like to understand your vision for the matter.

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.

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

[Grahmindol]

Okay, I understand that point of view.

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). Personally, I speak Italian and French, and I'm still looking for other friends to proofread and verify the other languages.

I'd like to add a feature I'd already tried to implement as a mod addon, but I couldn't develop it further due to a lack of control over machine.scala.
(If you want to see my attempt, check out https://www.curseforge.com/minecraft/mc-mods/openstuff)

But if there are higher priorities, I still have about ten days of free time to dedicate to this.

EDIT:
By the way, I apologize in advance if I come across as a bit blunt in my writing; I don't speak English, so I might make mistakes.

In any case, please know that I love your work. I’ve tried porting it to a modern version several times in the past, but I always hit a wall.

Even with Java, I’m not a professional—I’m a C developer—so I still have a lot to learn.

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

[Grahmindol]

Good evening,

Regarding the use of AI:

• On one hand, having learned C long before the advent of LLMs, I’ve seen the damage caused by their misuse.
  On the other hand, I know that this port was largely created using AI. That said, LLMs excel at translation, and—as I mentioned—I am actively looking for humans to proofread and verify the languages ​​I don't know.

• There was never any intention to "vibe-code" anything. just to translate.Personally, I am French and have dysorthographia; while I can verify the meaning of the documentation, I wouldn't be able to write it in French myself.(I actually use LLM to search the documentation for me and correct my spelling mistakes.)

Regarding the team...

I WANT IN.

It's my favorite mod, and thanks to my mastery of C, I handle Java well; plus, I view Scala as a blend of OCaml and Java, so it suits me fine.

Plus, I need to learn how to use GitHub properly, and there's no better way to do that than by actually using it.

[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, a method would need to be added to li.cil.oc.api.Items.java.

kind of :

// in 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);
    }

// in  li.cil.oc.common.init.OCItems.scala
def registerStack(stack: ItemStack, id: String, section_id : String): ItemStack = {
    val immutableStack = stack.copy()
    ITEM_TO_SECTION.put(id, section_id);
    descriptors += id -> new ItemInfo {
      override def name: String = id

      override def block = null

      override def createItemStack(size: Int): ItemStack = {
        val copy = immutableStack.copy()
        copy.setCount(size)
        copy
      }

      override def item: Item = immutableStack.getItem
    }
    stack
  }

However, this entails a significant change to the API.

A comment in li.cil.oc.api.CreativeTab should be used to explain how to register items in a section.

(It doesn't seem ideal to me, but if it works for you, it works for me.)
(I haven't committed anything for this yet because I'm waiting to see if you have a better idea.)
Thanks for the review!