* Lazily fill out the ItemList for network delta updates
* Implement a new api for looking up a single stored item to optimize network monitor updates
* Update buildscript
* Add Nonnull annotation to the argument
- Sets a configurable limit on the number of simulation steps and the size of the serialized tree to prevent DDOS
- Culls invisible parts of the tree when rendering, tested to maintain high fps on requests with 200k+ individual steps
- Displays the machines that are responsible for crafting via interfaces, with an API to override the displayed itemstack (for GT hatches to point to their multiblock when implemented)
More features, such as searching, filtering the tree etc. might come in future PRs.
* Update buildscript
* Add a simple gt5u tool crafting unittest
* Fix child requests going missing when duplicates of the same item are present in the pattern
* Fix typo causing complex patterns to never attempt simulation
* Add a heuristic to better avoid requesting duplicate gt tools
* Add more complex tool crafting tests for the scenarios in <https://github.com/GTNewHorizons/GT-New-Horizons-Modpack/issues/12685>
* Fix getContainerItem to match vanilla in max damage handling
* Use the shared ae2 getContainerItem instead of a custom copy
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
Split dependency logic on the BuildCraft modules.
Config needs to be reset, if BuildCraft was disabled actively,
because now there are 3 BC modules to be taken account of
Every Block had a call to its super, passing its own class.
This can easily be simulated by calling `this.getClass()` in the super class.
Also this was basically only used as using a name.
In the future it might be advisable to not use such methods,
since they are prone to refactoring.
Provides a new configuration `mods` which can be used on Maven Artifacts. That way, we can install them without affecting them on runtime (less load time)
Put the optional tasks into `optional.gradle` where a install task is just a copy task and the deinstall task a delete task
Added maven local to the repositories, if for some reason somebody uses a local maven
The proper way to use gradle is to actually use the gradle.properties. It will be automatically read without using a self defined config slurper.
The gradle.properties adds additional convenient options e.g. regarding the VM options and parallel calculation or daemons
Martin Robertz