Jump to content

Some suggestions and practices for improvements.


Exsaliver

Recommended Posts

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 :).

Link to comment
Share on other sites

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.

 

 

I do Forge for free, however the servers to run it arn't free, so anything is appreciated.
Consider supporting the team on Patreon

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

I do Forge for free, however the servers to run it arn't free, so anything is appreciated.
Consider supporting the team on Patreon

Link to comment
Share on other sites

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.

I do Forge for free, however the servers to run it arn't free, so anything is appreciated.
Consider supporting the team on Patreon

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.



  • Recently Browsing

    • No registered users viewing this page.
  • Posts

    • Hello all! I'm currently trying to make the Biomes o' Plenty mod (1.12.2 version) compatible with my shaderpack (BSL v8.5). Even after I've already inserted a "shaders" folder with a correctly-formatted blocks.PROPERTIES file within the assets folder of the .jar, it still does not wave the textures from the mod. I definitely thought this was going to work since I noticed the 1.19.2 version of the mod laid it out exactly like that and it worked perfectly when my PC was able to run 1.19.2 Forge... ^^;;; Could there be some missing link I'm not getting at here?
    • After much experimentation I finally realised why this doesn't work and how to fix it. The critical component to understand here, is that ItemCraftedEvent is called before the crafting ingredients are purged from the crafting slots; this all happens in ResultSlot.java's onTake method: We can see here the first line fires checkTakeAchievements, this is what fires the ItemCraftedEvent (after a few method calls). Then we can see the purge behaviour. I worked around this by creating a CarverItem class, which uses hasCraftingRemainingItem and getCraftingRemainingItem to hook into ResultSlot.onTake: Now, I reconstruct my ItemCraftedEvent handler, and using some smart tags (which I omit for brevity), I handle two cases: 1. When crafting a carved item, I damage the tool used in the recipe 2. When crafting a carving tool from a repair recipe, I manually purge the input tools as with the new CarverItem class, as otherwise items would be duplicated   This has now greatly improved implementation, beyond my expectations, for the standard crafting table and the user's inventory crafting grid. A user can now click or shift-click 'carve' items, with no duplication or issues that I have spotted so far.  
    • Hi, I'm having issues launching my Forge 1.20.1 installation (47.2.0). I keep getting error code 1, and all the logs abruptly pause with the game attempting to open GL 4.6. Latest Crash: https://pastebin.com/zsP5Wipk Debug (No idea what the real name is) Log: https://pastebin.com/CzvqhNq0   Thanks for the help!
    • In the most up to date version of Allthemods 6 (v1.9.2) the stoned bee is not able to be interacted with apart from putting it into an empty bee jar. I can't breed the bee or put it into my aviary breeder. When I try to put it into the breeder it says import unsuccessful. The stoned bee is one of the most important bees for advancing in the mod so it is rather unfortunate that it is not working as intended.
    • Everytime I try to run the Forge 1.20.1 - 47.1.0 Installer, only appears an a black window and then closes. I don't appear the installing menu anymore.
  • Topics

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.