Add documentation for the mod

[TechPro424]

Please add documentation for the mod
I saw the mod on modrinth, and then came to the repo, where the readme mentions that it has gui and config utilities, which would be really useful for me right now
Hence, I'm looking to use this mod, but don't know where to start

[TheCSDev]

Hello, and thank you for showing interest in using this API mod!

The reason it has no documentation is because its main purpose was supposed to be for helping me out with my own code for my mods, aka in other words, common code shared among my mods. Another main reason is because of how frequently the code changes in the API, so I don't really feel like documenting each change/update/feature for each game version.
Also, the mod mainly focused on GUI, however recently a started using Architectury API and adding extra events and hooks as well.

However if you wish to use this API anyways, I can give you a quick head-start on how to use the API.

• First you will need to embed the mod JAR file into your mod project and add implement it in build.gradle as well.
• • Also because my Forge FML knowledge is limited, testing Forge mods with this mod embedded doesn't work at all, and instead crashes the game due to obfuscation issues in the development environment, so I just test Forge mods after building instead.
• • As for Fabric MC, don't forget to name the jar in the jars:[] section in fabric.mod.json and list it in "depends":{}
• Also if the lack of proper documentation slows you down, at least know that I'm the type of developer that loves commenting every single line I write (maybe not literally, but still), so feel free to visit this repo to check the JavaDocs and comments in the mod's source code if you are having a hard time understanding something, or you can just ask me instead.

After you've embedded the mod, you're now good to move on:

All API classes are found in the io.github.thecsdev.tcdcommons.api package.
And altho my main focus is on io.github.thecsdev.tcdcommons.api.client.gui, there is also io.github.thecsdev.tcdcommons.api.config, which I've never used or tested before. The config API is meant to be like a config-type thing where you can define properties dynamically by simply declaring fields in classes and then getting/setting the values of those fields.

Also as for that Architectury API thing, the following packages may be of help as well:

• io.github.thecsdev.tcdcommons.api.client.events - For client-side events
• io.github.thecsdev.tcdcommons.api.client.hooks - For client-side hooks aka Mixin accessors
• io.github.thecsdev.tcdcommons.api.events - For common events that take place on both logical sides (client and server)

As for the GUI part

• Your main focus is on io.github.thecsdev.tcdcommons.api.client.gui.screen.TScreen, which you can think of as like a "remix" of net.minecraft.client.gui.screen.Screen
• While Minecraft Screens use net.minecraft.client.gui.Element, TScreens use io.github.thecsdev.tcdcommons.api.client.gui.TElements.
• A full list of widgets I made for TScreens can be found in io.github.thecsdev.tcdcommons.api.client.gui.widget. Also the text field widget feature is incomplete and lacks a lot of features Minecraft's text boxes have, as you can't even type properly in them...
• The main reason I made TScreens is because Minecraft's GUI system is way too limited and garbage to work with and lacks the "scrolling" and "scissors" capabilities I needed. Sure you can "fake"/"imitate" scrolling and "scissors" with Screens, but that's not what I wanted. Hence why I made io.github.thecsdev.tcdcommons.api.client.gui.panel.TPanelElement (don't forget to add a scroll bar and link it to the panel after adding the panel tho).
• Another reason I made TScreens is because in my GUI system, "children" can have "children", whereas in Screens, you can not add an element inside of another element (but you can "fake" the effect of it).

Important to keep in mind, Screens use addSelectableChild and addDrawableChild. Don't use those when working with TScreens, as TScreens use addTChild instead.

Also, here's an example code snippet for creating your own TScreens

To display a TScreen on the user's screen, just do what you'd do with a regular Screen. Create an instance of the TScreen you made, and then use MinecraftClient#setScreen (or Minecraft#setScreen on Forge iirc).

So yeah, that should be a brief rundown of the GUI API I made for my mods. Keep in mind that things may change in the code, and the last thing I want is to accidentally break someone else's mod. As for the AutoConfig API, I have completely forgotten about it and how I made it work, as I haven't used it before. Good thing I place comments literally everywhere tho (edit: almost everyhwere).

Again, thanks for showing interest in using this API and for suggesting a documentation. If you have further questions or need help with using API, feel free to ask (as for Forge tho, Forge is a mess of a rushed port, I have no idea how to mod on Forge).

Have a great day!
Edit: fixing typos

[TechPro424]

I don't plan on making Forge mods, only Fabric, so the Forge-related issues aren't a problem.

I'm trying to make a config structure with a suitable GUI that is similar to this one:

This image is the config of the mod AutoReconnect

You can multiple "AutoMessages objects" to the AutoMessages config option, give each of the objects a name, and add multiple messages to each object

How do I make a config and a corresponding GUI similar to this one using the TCDCommons API?

[TheCSDev]

Yes, I can try to help you out there.

• The config mod you've shown on that picture is called Cloth Config API (edit: i think, i'm not 100% sure as there are multiple of such mods that look very similar).
• You may find instructions on how to add it to build.gradle here. You may also find instructions on how to use the mod's API on their wiki page that may be out of date a bit (well, it was when I tried using it).
• Just keep in mind that your mod will then depend on Cloth Config API, and people will have to install it to use your mod.

Important to know:
Cloth Config API is a GUI mod only.
What I mean by that is, it will not handle the config saving / loading logic for you. All Cloth Config API does is it allows the user to modify the config values of your mod in memory (RAM), but you are still responsible for saving those changes to files and then loading them later when needed.

Here's an example code snippet I used in my No Unused Chunks mod for letting users modify its config values. Tho, I have since moved on from Cloth Config API and wrote my own GUI so people don't have to download Cloth Config API to configure my mod.

Also, as for that config feature I have in my own TCDCommons API mod.. That feature's goal is to handle config logic and to let you "dynamically" define config values by just simply declaring fields, and apparently it uses JSON (I forgot).
If I remember correctly, you still have to handle saving/loading by yourself there as well.
The reason I wrote that config API in my API mod is because I no longer felt like manually saving each and every config value I define in my mods, so my thinking was to just have a config API where whenever I call saveToFile, it uses java.lang.reflect aka reflection to automatically collect and store the values of all fields I have defined in a config class.

Tho I wouldn't really recommend you use TCDCommons API for handling configs, as Shidaniel has far better mods that aim to do the same thing, plus they are maintained consistently.

And, for handling config logic, I'd also recommend you look into how Auto Config API works.
Keep in mind that it got merged with Cloth Config API, so I believe you may access that mod's APIs by just simply installing Cloth Config API.

[TechPro424]

yes, I do know that it uses Cloth Config API
The reasons why I don't want to use it are:

1. It seems that shedaniel doesn't want people to start using Cloth Config API, as per this screenshot that has been linked in YACL's description
2. I looked into AutoReconnect's code, and apparently it uses NestedListListEntry and MultiElementListEntry to achieve that config, which is not mentioned in the wiki at all, and I don't want to go into shedaniel's Discord and start asking for support when they've mentioned that they do not want new people using the mod

[TheCSDev]

Oh. I was not aware of the things you brought up to me. Thanks for letting me know.
So, you wish for a way to recreate a similar GUI yourself?

Edit:
I never used YACL before. My mods typically don't rely on configs, and when they did, I used Cloth Config until I wrote my own simple GUI.

[TechPro424]

So, you wish for a way to recreate a similar GUI yourself?

Exactly

[TheCSDev]

Hmm, I just took a look at Auto Reconnect out of curiocity, and it turns out they too use Cloth Config API.
Given that Cloth Config API shouldn't be used, I am not really sure as to what you should do to achieve a similar thing.

Thing is, as for my TCDCommons mod, I have not yet implemented any config GUI related features. Initially I did plan on making a TPanelElement for the config script I've written, and have it dynamically create elements for config properties, but never went along with it because I never needed such a feature as of right now. So if you do decide on using this mod, you'd have to write the GUI yourself by placing elements (aka widgets) manually.

I also guess you could have a look a look at YACL if you haven't? I never used it before, so I don't know the usefulness of it.

[TechPro424]

Yes, I am actually trying to accomplish it with YACL right now, but I have to use an entirely different approach as YACL does not support nested lists
And I'm having problems with the value in the GUI not saving to disk
And the dev seems to be busy (probably porting the mods to 1.19.4), so I'm at a dead end for now as I'm unable to get a reply from him on how to resolve the issue

[TheCSDev]

It may have taken me a year, but I have decided to finally start implementing a documentation for my mods.
It currently does lack a lot of information that needs working on, but hopefully it will eventually have more useful information.
I have decided to publish and host the JavaDocs over on the https://javadoc.thecsdev.com/ domain (https://thecsdev.github.io/javadoc is the alternative URL).

[Stankye]

It may have taken me a year, but I have decided to finally start implementing a documentation for my mods. It currently does lack a lot of information that needs working on, but hopefully it will eventually have more useful information. I have decided to publish and host the JavaDocs over on the https://javadoc.thecsdev.com/ domain (https://thecsdev.github.io/javadoc is the alternative URL).

These links would be great to have on the readme!

[TheCSDev]

Hello!
It appears I forgot about this GitHub Issue as well, so I forgot to mention this here;
Not long ago, I also published some documentation pages on https://thecsdev.com/docs/, and I plan on writing guides on how to use my APIs there. So it's not just gonna be JavaDoc-s, but actual proper guides on how to use the APIs and make stuff with them.

Right now I am working on a BSS update, so I'll focus on writing the documentations after that.