The new database API introduced a lot of breaking changes and changed behaviour sadly.
When migrating this plugin to the new API these were not taken into account properly and
essentially broke the whole database/storage layer of the plugin.
* SQL statements that were valid in SQLite but are not in H2, which is now the default
* H2 jdbc driver not being shaded into the final jar
* catching exceptions, logging a message, and then continuing code execution (in the core)
* introducing race conditions
* ...
These fixes sometimes rely on the non-multi-threaded APIs provided now which will most certaintly
come with a performance hit on larger servers.
But at least it works again... tbh I do not really want to spend too much time fixing this stuff...
A potential issue that still exists in the use of `DataManager#getNextId` in `AnchorManagerImpl`.
Right now it returns a value based on the largest ID currently in the database – Completely circumventing
the whole auto_increment characteristic of the table schema...
This is another changed behaviour that gets introduced opening the possibility for conflicting IDs
*outside* of the database table itself. The ID can be used as a reference in other places
We have a new template for compiling projects and publishing them but it hasn't really been designed
with API modules in mind yet and needs some smaler adjustments before being used in all projects.
I don't want to manually update all projects if I change the template workflow file.
I tried creating a usable API module containing everything important without introducing
too many changes that cost time and might confuse people when migration to the new module.
We have limited time right now and need to push the 1.20 update... So no additional thoughts on
the API design (so I can regret it in the somewhat near future \o/)
When a user was inside a given chunk with a spawner, the spawner might not trigger because
of the activation range.
Anchors are supposed to ignore this limit - This change makes sure, spawners are always active.
The hack to not tick chunks with players in them is only in there because of the randomTicks done.
But this can still cause chunks to get double the randomTicks they are supposed to because
there is no good way (that I know of) to check when the server did them on a given chunk.
The image URL (and marketplace URLs that I didn't change) contain the new product ID.
The ID changed sadly but I think they will be some work done to restore the old IDs,
so I'm not updating them for now.
Based on craftaro/GH-Commons
These new workflows bring a lot of nice things - For example:
* signed jars
* Auto-Deploy to Maven Repo
* Using songoda.sprax.dev/repo/ as proxy for most repos/dependencies
* ...
This file was automatically generated by a bot.
Co-authored-by: songoda-plugins-overview[bot] <111250264+songoda-plugins-overview[bot]@users.noreply.github.com>
