Q: Would an abstract ForgeMod class be useful?

[jeffryfisher]

While making my five mods (in 1.7.10), I caught myself doing some of the same things again and again. For a while now, I've thought that some generic mod features could be codified in one place to be inherited by every mod I start. As I work to upgrade all my mods to 1.8, I am side-tracking to encapsulate as much of the required repetition as I can in a package of abstract classes that will do just that (become parents to all my mods/client proxies).

 

It occurs to me that I might be able to generalize my own mod-series parents into something generally useful: an abstract class from which anybody could extend a new mod. So, if/when I get my mods working in MC1.8, should I share my package with its abstract classes, or just keep it for my own development? If I shared, where (I don't know jack about github, please point to *its* tutorial)

 

Cheers,

 

Uncle Jeff, Vancouver WA

[LexManos]

We decided against this when we developed the @Mod system.

Having a generic abstract base class is mainly just bloat and limits functionality.

Using annotations allow for expansion, mix/matching and expansion without breaking mods.

So no, this is something we specifically decided against in the beginning.

[jeffryfisher]

Aha, I surmised as much (that it wouldn't be flexible enough to be incorporated into Forge itself). However, there may be a sample-mod or tutorial place where my package could give a head start to new modders attempting their first run-of-the-mill mods.

 

If I end up with code that actually accelerates my next new mod (after I'm done with upgrades to 1., then I may yet find such a modders' forum and share the source there.

 

-- Uncle Jeff, Vancouver WA

 

[LexManos]

So you teach modders how to do it wrong and then call yourself a good tutorial.. No

Teach them the system not your addon tools.