I've been recently developing a addon mod for Create, but I have run into various problems regarding the visibility and modifiers of various fields/methods/classes forcing me to use reflection and mixins. Changing the visibility/modifiers of some of these would not only make developing my mod easier. but make any future addon mod, in development or otherwise, much easier to develop.

Here is a non-exhaustive list of some fields/methods/classes that changing the visibility/modifiers on would help with the aforementioned cause, with reasons as to how and why:

1. All Recipe Category fields in the CreateJEI class from: protected final -> public static final
   This would allow addon mods to add in catalysts to recipe types, which is necessary in any case to correctly add in a block that processes recipes added by create. Changing this would make the process much easier as well as less time consuming and straightforward. As it stands right now, it is virtually impossible to add in a catalyst for a recipe without using mixins. Reflection does not work as the fields are not static.

2. The capacities and impacts fields in the CStress class from: private -> public/public static
   (Alternatively a method could be created to access these)
   Currently, there is no way to add in stress impacts or speed requirements for a new block without using Reflection or mixins.
   Changing the visibility and modifiers of these fields would allow mod creators to give any new mechanical block a proper tooltip, (With stress impact and speed requirements shown). This tooltip would be something that any new mechanical block should have (To fit in with the ones from create) .

3. Changing the visibility and modifiers of methods in the AllRecipeTypes enum would not achieve anything, due to it being a
   enum. So changing the enum to a class, changing the existing values from enum values to a instances of the class, and
   putting them all inside a public static final list would solve this. Similar to how AllBlockPartials is currently.
   (public enum -> public class w/ public static final list of RecipeTypes)
   This change would allow mod creators to add in new recipe types very easily, while having them natively work with all the methods currently provided by the AllRecipeTypes class, and all methods that need a value of AllRecipeTypes as a parameter.

4. Refactoring some of the RotationPropagator code (Mainly the isConnected method, getPotentialNeighbourLocations method, and the getConveyedSpeed method in order to facilitate more special connections.
   As it stands now, the only way to create a custom block with custom rotation properties is to use mixins on the RotationPropagator class. A simple refactor of the code could change this:
   (Example of how they could be refactored)
   By changing these methods to check if the tile entity implements a special interface, say "SpecialConnection", the previously mentioned methods could then call 2 methods from SpecialConnection in order to facilitate special rotation behavior, these being addSpecialPropagationLocations and isSpecialConnected. addSpecialPropagationLocations would return a list of locations that the block can propagate to (Used by getPotentialNeighbourLocations) , and isSpecialConnected would return whether the current block is connected to a location. (Used by isConnected) isSpecialConnected the result of isSpecialConnected would be returned immediately.
   Making these changed, or changes like them, would allow for much more flexibility in what mod creators can do regarding specially rotating blocks without the use of mixins or reflection in their code.

5. AllBlockPartials constructors (get, getEntity) from: private static to public static
   Using the current code, there is no way to register a custom AllBlockPartials instance without using reflection. A Modder might want to register one because of the methods that a AllBlockPartials instance is able to use/be used with. This change would help modders make custom Partials in a very straightforward way.

6. All ProcessingRecipeParams fields from: protected -> public.
   This change would allow for the access of ProcessingRecipeParams outside of its package, meaning that any modder would be able to access them. This would make the creating a custom processing recipe much easier to accomplish without using reflection or mixins.

7. While I have not delved into the ponder feature yet, I suspect that it will have issues similar to ones listed here. Any modifications to make it easier to use by modders would be great.

These changed would also be accomplished via a api. Im sure that all modders looking to or actively creating a addon for the Create mod would greatly appreciate any of these changes. This list is also not-exhaustive, but contains some of the issues that I ran into while coding which could either be solved by visibility or modifier changes, or a quick refactor of existing code, which would benefit all addon modders significantly.

Number 5 was fixed in 0.3.2

Ponder has a really good API, though it would be nice to have a better way of generating lang. This is how I do it but that's not ideal because I have to include my mod id in each ponder id

Most of these have been addressed by this point. Here's an explanation:

1. As far as I know this is not necessary because a new JEI plugin can be made that adds catalysts separately.
2. I think this change was made, but I was not the one who did it so I'm not sure.
3. It was concluded this would result in some messy code on Create's side and since there is not much code anyway, it's fine to copy it if needed. I did make a change to allow one method to become public static, though.
4. The RotationPropagator might receive a large refactor eventually, so I didn't touch it.
5. Done in 0.3.2.
6. The fields were changed from package-private to protected so addons can now extend the class.
   7/8. I did a ponder namespace refactor a few days ago that added full support for custom namespaces and made it much easier to do ponder language datagen.

This issue has been marked as stale because it has been inactive for 3 weeks. It will be closed if it remains inactive for another 3 weeks.

This issue has been closed since it has been inactive for 3 weeks since it was marked as stale.