Using LogManager instead of FMLRelaunchLog to access the logger instance.
Added logging of the name of failed exports instead of exception.
Improved crafting log to include issuer including their location and the
requested item.
Removed superfluous FMLRelaunchLog instance.
Removed superfluous parameters for PlayerData constructor.
Closes#2009
Refs #2069
Reduces the visibility of all fields to private and create setters/getters
when necessary. Exceptions are fields with GuiSync as these need to be
public.
Reduces the visibility of internal methods to private/protected/default when possible.
Mostly used for the recipe system, but can also be used for debugging purposes. Debug options needs to be ticked to use the full information gain. Recipes only require the normal localization and the specific name plus metadata.
Shifted the recipes into a recipes folder where the CSV will also reside. This will also elevate the copying of the readme to the user directory since it can reside in the recipes folder.
Fixed a bug where the copier would copy the would also copy empty folders
The recipes are now structured into multipe subfolder and split into more
distinct files, so the names are more appropriate and are better at
hinting which items the actually contain.
It also extends the RecipeResourceCopier to now handle the folder
recursively and extract all subdirectories and their files.
"import=" is currently requiring a relative path to the root directory
of the recipes. This would require a larger rewrite/refactoring, thus it
is kept for now until a potentially later changer.
This reverts splitting the oredict entries into their own directory and
moves them back into the recipes folder, as it currently is causing a
couple of issues like not being able to resolve the aliases or is not
working indev. But to keep it seperate it is now its own recipe file.
Fixes#1791
Reverts #1635
Applied English Locale where localization is not expected as in internal recipe handling and IMC handling, basically which interacts with public API where we either require to enforce the incoming text with regex ([a-z0-9]) or just expect proper usage of the API, but with just using upper cases in recipe files it would break in Turkish Locale like
ALIAS
another option would have been to use `equalsIgnoreCase` in some cases, but not all applicable
LordMZTE
