Some suggestions and practices for improvements.

[Exsaliver]

Greetings, forge community!

Before I get to the actual suggestions I wish to make I would like to say a few things that may or may not be important (preface), for you convenience I've made the post into sections and sub-sections for easy reading.

 

1. Preface

I will start off by expressing my appreciation to everything you have done so far, most poeple like to thing that you job is easy, "it's just a mod", well I know that it's comleately the opposite, not only you don't have documentation to work with, there is actually nothing to document (atleast at forge level) considering you are working with an un-obfuscated decompilation of java bytecode (or bitcode, can't remember what it's called). So having said that I want to be abosultly clear about one thing, I'm not criticising your work, I may have different ideas about how things should be done, but that's only my opinion which I formed over the years.

 

So as I implicitly stated, I have some experience with the sort of things forge is doing (not exactly the same things but close). Let me give you a little background - if I'm not mistaking I've started programming about 7 years ago as an hobbyist, I was working mainly on development frameworks rather that software, as I gained more experience I became more and more "obsessed" with extensibility. I started to develop more and more frameworks around that that subject, from plugin loaders (similarly to FML) to IoC frameworks. I learned what makes things work and what doesn't, and I'd love to share that with you.

 

2. General rules in making extensible software

The following list is a compilation of things I believe are necessary to make good extensible software.

 

2. 1. Plugins should not load themselves

I believe that once plugins are able to load themselves they have too much control over the system. In forge Mods are loaded through some sort of pipeline where they are first activated (in the sense of instance activation of the '@Mod' decorated classes) and then are "pre-initialized", "initialized" and "post-initialized". The concept behind this process seems right but in my opinion all that is is a glorified hook that lets Mods do whatever they wish to do. It seems that Forge is loading the Mods but in practice the mods are actually loading themselves - they register blocks, items, entities etc. by themselves.

 

2. 2. Inversion of Control is mandatory (almost)

Every time I made something plug-able I found IoC to the perfect solution, although is it not really mandatory (singletons and factories can achieve the same thing), it's just a joy for 3rd-parties to use the system, it's less error-prone and to be honest everyone is incorporating it into their software right now.

In forge I haven't seen IoC being used - singletons (like FMLCommonHandler.instance) and static classes (like GameRegistry) (static classes are much worse than singletons and should not be used in my opinion) are used instead.

 

2. 3. Never ever let 3rd-parties access internals

Well I know I'm unfair about that but 3rd-parties should never have access to internals and all interactions should be done through an API. I know that it's very difficult to achieve using forge because of Minecraft itself, so lets disregard that for now. The same goes for security and sandboxing.

 

2. 4. 3rd-parties have to ask first

To explain this point I'll tell about some framework I've made some time ago - "Overlay" is an Mvvm framework I made some time ago it's purpose was to completely separate Presentation code from Business Logic, controls are bound to data and events through properties by the framework. Some properties allow read-write access and some allow read-only access. That means that, for example, a Textbox bound to a read only property should not be editable - ever, initially code that was using the framework could changed any aspect of the control including its editable, if a Textbox that is bound to a read-only property is made editable and it attempts to change its underlying property an exception will be thrown resulting in a crush most likely. Another problem to arise are race conditions - say one plugin colors all the buttons blue by default and another plugin colors all the buttons inside valid forms green which one should take presence? Well the second one should but who's to overrule that?

These two problems made birth to the Aim framework which ask everyone to express their intents - i.e. changing the color of the button. All intents are given a priority and then the intent with the highest priority gets to act.

In forge this could solve mod conflicts and (partially) the need for the ore dictionary, each mod could express an intent to add copper ore and only one will ever be added.

 

2. 5. This is it for now

For now I can't think about more practices that should be integrated into forge, once I find more things to be improved I'll edit them into this section.

 

3. How I can help

I've read the post that asks for pull requests from those who can help with them, I absolutely can help with that but as you can see the features I'm suggesting may require significant effort and will most likely result in some API changes, so I really want to hear what you think first.

As I said I have a lot of the code base already written the only problem is that it needs to ported from .Net to JVM (C# to java).

Other then I'm on vacation for the next month or so after that I'll be gone for about 3 or 4 weeks and the then I'll be on a mostly standard 8 hours work schedule.

 

Thanks for reading!

 

P.S. while writing the post I noticed you don't have a 'WYSIWYG' editor in place, I once worked with PhpBB forums and I used CKEdit (completely free) for that, it's a grate tool .

[clienthax]

You do know the amount of access needed to create mods that aren't absolute piles of crap right?

[Exsaliver]

You do know the amount of access needed to create mods that aren't absolute piles of crap right?

 

I'm sorry, what?

[LexManos]

Your suggestions are good in theory on projects that have full control and want to provide all the abstraction out of modders hands.

 

This IS NOT what Forge is. Forge is spcifically desinged to go against this type of design.

 

If you want a abstraction layer and data orientated mods, youyou out of luck in the minecraft community. This may be something we introduce in the future (once i get forge and fml merged, get some of the update processes streamlimed, deal with other non-forge projects, and so forth). But for now not going to happen because that is not what this project is.

 

 

[Exsaliver]

I'm interested to know why Forge is against this kind of design, I understand the limitations coming from Minecraft, but other then that I don't see why IoC and intent oriented design won't fit, do you feel it's too much of a change or is there another reason?

[LexManos]

Because throwing buzzwords around has nothing to do with functional code. The parts that forge addss on top of minecraft are dictated by minecrafts style, compatibility with other mods, and just the samity of having to deal with mc/modders.

 

Forges goal is to be a small later on top of mc and to have modders work with mc directly. And the designs that forge and fml employ are what are needed to do this. Trying to restrict modders is just a futile effort due to the environment.

[Exsaliver]

I thought this "low level" layer was what FML is, regardless I have a few more things I'd like to discuses would you mind having a chat in a bit more convenient way (IRC, Skype whatever suites you)?

[LexManos]

If you havent noticed fromt my plethora of posts and tweets, i'm traveling right now so irc and the like dont work. However most of your comments and suggestioms cpuld probably be answered with "I know, but thats not how minecraft or the community works" Keep in mind ive been developing systems like this for 15 years, i know what im doing and there are reasons why the methods ive choses are what they are.