Topic category: Advanced modding
I've been using MCreator for almost a decade now and it has been a great tool for me, as learning code in the past has been difficult. However, after completing a programming unit (covering C) for my university course last semester, I have taken it upon myself to continue to learn more - deciding that transitioning from MCreator into coding mods on my own would be a great path to move down. To this sentiment, I have begun working on creating a plugin for this software.
The plugin would be able to create custom attributes (for now I am only using ranged attributes). Modifiers would also be able to be defined and instances of these would be applied to entities via procedures. From my (so far) half-week experience into the nekoyue forge docs, all 3 google search result pages for issues I have had, and the (very snazzy and cool and useful) MCreator github - I have three current questions that I would like addressed:
1. Registries - Through learning how to apply custom attributes, I understand that these should be registered via the DefferedRegister, RegistryObject, and <Registry Type>.register() declarations/methods. However, I am unsure where and how these should be used in terms of the scope of the function they are contained in. All of the examples I have seen of others' code involved declaring/calling from a function of public scope, however MCreator generates functions of private scope for procedure elements, wrapped in a public class declaration. I am wondering if the registries that are created within the private function would be accessable to the loading phase of the mod which, from what I have read, is when Register declarations take place (I have the procedure block responsible for registering the attribute on "When mod loaded server side" trigger).
2. Scope for generated code - While on the topic of scope - is there any way to 'escape' the private function generated for procedure block code, using the tools I have available for plugin development? This would only be necessary if the registry events cant be accessed by forge from the private function.
3. Global variable definitions - While learning how to create custom variable/data types, I was able to do this successfully for variables requiring the init, set, and get methods in the .yaml file that is read and converted to java code when needed by the generator. However, I am having issues with defining the read and write methods that are used in global variables. My attempts have either A) prevented the 1.18.2 generator from being loaded (can only open workspaces using the 1.16.5 generator) or B) prevented the ModVariables class from being re/generated after the custom variable has been used in a procedure; standard variable types work just as usual, but as soon as a custom variable is used in a procedure, the ModVariable class jsut stays the same even after these procedures are removed and variables are deleted via the Variables workspace tab. Looking through the MCreator github, I found [MCreator/src/main/java/net/mcreator/generator/GeneratorVariableTypes.java], which seems to be responsible for compiling the .yaml files of variable types. It logs whenever a variable type definition fails to load, which hasn't occured for me. This leads me to believe that the root of this issue is with my definition of how the variable should read/write - to test this, I tried to implement the ArrayList() data type found in Goldorion's 1.18.2 Array List plugin, including the mapping, and variable .yaml files and the arraylist_set_value java.ftl alongside the json and lang definitions for each of them. These only have global_session and local scope, so I copied the set and get definitions of the global_session scope and used WorldVariables instead of Variables - which is seen in the definitions of global_scope of existing data types in MCreator - and to no avail the results were very similar to the prior.
Edit - Forgot to include images for the registry code:
Also just for some general help - I'm using IntelliJ and this warning has been present for the entire time:
Unsupported JavaFX configuration: classes were loaded from 'unnamed module @130f889'
Everything seems to work - should I be more concerned about fixing this?