General Cleanup

[FireController1847]

You ready boys? Here's the list of things I did. The diff is not very helpful, I'd recommend opening up the workspace if you can and seeing how everything has changed and is related. If I did good, it should feel more consistent, clean, and easy to work with. If you really want to see a diff, try checking it per-commit since each commit did its own set of cleanup.

Theoretically, little to no logic was changed in how things are handled. It should all be cosmetic except for a few minor changes I made.

• Biggest change was converting to Mojang's mappings. We should be using official mappings for consistency's sake. Most, if not all methods have names, and everything is working correctly from this change.
• Updated to Minecraft Forge 36.2.18
• Moved run directories into run/client, run/server, and run/data respectively. I've always found this to be cleaner for testing as it separates all the files on the client and the server in the run folder. I'd highly recommend you delete your current run configurations and run folder, then generate new ones, for cleanliness.
• Renamed versioning scheme to fall in line with semver and changes the archives base name to be all lowercase, for consistency.
• Renamed master package from "com.milamberBrass.brass_armory" to "com.milamber_brass.brass_armory" (to prevent a mix of snake_case and camelCase), for consistency.
• Removed all of Forge's template code. Feel free to re-download the MDK to view the most up-to-date template code if you need it, otherwise I'd recommend browsing Forge's decompiled code in your libraries of your IDE or using IntelliSense to find what you're looking for, for cleanliness.
• When referring to constants, I personally always insert the class name in front of it even if it's referring in the same class. Maybe that's just my OCD, but I made that change in the primary BrassArmory class, for cleanliness.
• I removed the unnecessary listener registration happening on classes to instead use the @EventBusSubscriber annotation, for cleanliness.
• Removed comments from mods.toml so it's readable, at the very least, and removed comments in pack.mcmeta since it's not necessary.
• Performed file formatting and general cleanliness cleanup to all files. Ensured newlines and whitespace is consistent on classes, added annotations as necessary for nonnull/nullable parameters and returns.
• The ArrowType#getModItemFor class was marked as nullable, but never returned null, so I fixed that as there was no return for default or empty cases (it would fall through to the next line, as in, default is dirt arrow, instead of returning null). Was this intentional logic? I need to revert this if it was.
• Made various file name changes for consistency across the board.
  • Appended the word "Item" to the end of each item to stay consistent with Minecraft's code (you have "block" on the end of blocks, but you didn't have "item" on the ends of items).
  • Removed the mixtures of Pascal_Case and CapitalCase in some classes (Spear_Entity to SpearEntity) for consistency with other classes (such as BABaseArrowItem).
  • Moved three registry classes outside of the groups, then moved all "custom" folders to their higher level packages (so I moved ModItems to the base package, and then all items from items.custom to items).
  • Renamed the registry classes from "ModItems" to "BrassArmoryItems." This is mostly personal preference, but if another mod were to ever depend on our mod, "ModItems" would be too generic and could cause clashes.
• Inserted various newlines across different files to keep them consistent with the approximate formatting of the specified file. What I mean by this is, if the registry wasn't newlined for items, then I made it not newlined for blocks. Or if there was a long string of methods that was newlined in one file but not another, I made it newlined in both.
• Changed the logger to register with the mod's mod id.
• Removed the manual reflection you had created. It was really cool and really good, but Forge already provides a class for that purpose exactly.

Most of the changes I made are entirely cosmetic, and so if you want me to revert any of the things listed above, go ahead and let me know and I will. Or if you want something else changed for consistency or cleanliness, I'd be more than willing to do that too. Otherwise, if it's good, then I'll continue work on the Quiver.

[JMilamber]

(it would fall through to the next line, as in, default is dirt arrow, instead of returning null). Was this intentional logic? I need to revert this if it was.

This was intentional logic so that if another mod (or some vanilla mechanic we didn't think of) calls an empty or default ArrowType it doesn't crash the game, but instead just gives the Dirt arrow stats/item. Minecraft is weird with null values sometimes and either passes over them or just dies lol.

[FireController1847]

Oh, thanks for doing that for me. Was gonna revert it tomorrow but that's even better haha