nitrogenez commented 1 year ago

The What

What's this needed for? The answer is simple. Easier maintenance. Yes. MCL or MTG are not rapid-developing projects, and they don't have massive API changes that are hard to keep up with. However, even though depending on these projects makes it a little harder to maintain MC, as we need to check for dependency presence and build from that.
We could've just used, e.g, depends = default, but this leaves no possible way to play with MC in any other game, e.g MCL, as MCL doesn't have the default package.

The Why

Why do I care? Well, I am a C/C++ programmer, so I am, of course, pretty much sick of depending on anything if it takes nothing to make what I need myself. And also the reasons above. Being a dependency-less project MC achieves the goal to be playable in any game.

My solution

So far things that depend on other mods are crafting recipes. We can, and I think should, add new ore types. Exactly: Aluminum and Silicon as the first step. Make aluminum and silicon generate naturally, balance that, and then just use other items (e.g ingots and plates) to build a computer. This could make things more interesting, balanced, and fun. This change in the recipe will actually force the player in deep dive into the caves to find and mine all the required resources for the computer.

Let me know your thoughts on that. Thank you.

JamesClarke7283 commented 1 year ago

Thank you for your contribution to the discussion. Your proposal is insightful, but I have several concerns that need to be addressed.

1. Mod Conflicts (Stylistic and Actual)

Introducing new ore types could potentially override existing game mechanics or styles, causing conflicts with other mods that already implement aluminum and silicon. This could create confusion for users, especially since our mod doesn't primarily deal with ores.

2. Modularity

Mandating ores within this mod removes the flexibility for users to disable them without altering the code or a setting. A more dynamic approach would be preferable, where the availability of certain craft recipes is contingent upon the presence of specific mods.

3. Scope Expansion

Incorporating ore generation necessitates balanced management alongside our mod's primary objectives, thereby broadening the project scope and increasing the workload.

4. Code Bloat

The additional settings and interactions with other mods would enlarge the codebase, making it more cumbersome to manage.

Alternate Solutions

Support for Existing Mods: Collaborate with existing mods like MTG, MCG, NodeCore, or moreores that already have the required ore implementations.
Separate Mod for Ores: Develop a distinct mod for ore implementation and establish it as an optional dependency, reducing the possibility of bloat within our project.
Hybrid Approach: Combine both alternate solutions to leverage the benefits of existing mods while extending our own.

Project Scope

Our aim is to ensure compatibility with a myriad of mods and game environments. Addressing the recipe challenge is a common task for mod developers, and I appreciate your initiative in seeking a resolution.

Conclusion

Transitioning towards a "game dependency-free" rather than "mod dependency-free" model seems plausible. Our existing mod dependency, "item_tracking," serves a crucial purpose of managing orphaned motherboard inventories. Your suggestions have ignited a fruitful discourse, and I am keen on hearing your thoughts on the alternate solutions provided.