Custom Title

[YoungSoulluoS]

Good evening, really wanted this thing. You are sure to find the best solution, but as a starter, here you go.

Custom Title: (#70)

• title.name
• title.style (including #1f4d27)
• title.json
  

if there is a json, then all others are cancelled out

The only drawback so far is that inventories like BEACON, VILLAGER have text in more than just the title. Apparently it is necessary to create exceptions & new mixins.

Fixes:

• villager.type ([BUG] villager.type #89)

[opekope2]

Hi there!
Thanks for being more active than I am right now 😆

I share my time among university, multiple Minecraft mods, and some other stuff.

Some notes about your PR and the future of OptiGUI:

1. Next time, please split commits (one for the villager selector bugfix, the other for the feature implemented).

2. I appreciate the villager type fix. Please open a new PR only containing this fix.

3. OptiFine support is there only for compatibility. I no longer add extensions to it after I introduced the OptiGUI INI format.
   OptiGUI is no longer an OptiFine custom GUI reimplementation. It is a custom GUI mod with its own RP format, with OptiFine RP support included.

4. I didn't think of adding a selector for replacement title. The replacement title is specified by the RP maker, so it feels pointless. text colours  #70 describes a problem of unreadable text color, so I think mixing into HandledScreen.drawForeground and its subclasses (where title is rendered) and changing the title or its color while rendering is sufficient.

5. I plan to add yet another format in OptiGUI 2.4.0, which is more versatile than INI is. It will support specifying the text color per texture (like a metadata), as I described in #70.

I don't want to add many new features to OptiGUI 2.3.0 (maybe a couple new selectors and the saddle selector's refactor). Instead, I want it to be a stable release for Minecraft 1.20.2+ (and possibly backported to 1.20) with less tech debt than all the previous 2.x.y versions as soon as my time allows it.

Later, I can add new features to 2.4.0 based on this refactored code (which is, btw, smaller than most, maybe all previous 2.x.y codebase)