* Configure mod-publish-plugin
* Configure actions to run mod-publish-plugin
To publish a release:
- Set the mod version to x.x.x(-beta.x) in gradle.properties and commit
- Create a git tag named vx.x.x(-beta.x) (note the v prefix)
- Push commit, push tag
- Manually create a (pre-)release for the tag on GitHub web ui. The release notes will be reused for modrinth and CF.
The release creation will trigger the workflow and publish to modrinth and CF.
The build script will check for when the version contains `-beta.` and mark it as a beta on modrinth and CF.
After publishing a release, it's good practice to bump the version and add -SNAPSHOT, i.e. after releasing 0.0.1, push a commit changing the version to 0.0.2-SNAPSHOT. This ensures people downloading action artifacts have correct version numbers.
This commit also updates gradle/actions/setup-gradle which removes the need for a separate wrapper validation action (it is included in setup-gradle v4)
* Set project IDs
With ConcurrentUtil 0.0.2, we can make all thread pools
(worker+I/O) have their thread counts configurable on the fly.
The new I/O system splits the compression/decompression work
from the I/O. The compression/decompression is ran on the worker
pool, while the I/O is ran on the I/O pool. This allows for
better cpu utilisation control on systems with low core counts,
and allows higher read/write speeds on systems with higher
core counts.
Additionally, the I/O scheduling for thread counts > 1 is also
improved as it longer selects a thread to schedule based on the
chunk location.
Change all interfaces used in mixins to have methods prefixed
with "moonrise" or "starlight", to remove risk of conflicting
with Vanilla or other mods methods
Add new patch for optimising ticking block entity removal
- Similar to Paper's patch for this but uses an in-place removal
method
Remove most of the fluid mixins:
- May not be effective, but are a big maintenance problem
