this fixes#3906.
TimingsHandler will now be automatically destroyed when there are no TimingsRecord referencing it and its owner has no references left to it.
TimingsRecord will be automatically destroyed at the end of the timings session (if active).
This fixes records from temporary timers being lost after the timings handlers are removed, while also fixing TimingsHandlers piling up regardless of whether timings are running or not.
This opens the doors to have more volatile timers, such as per-player/per-session timers, which are destroyed on player quit, but which won't result in the timings disappearing from the final timings result.
this was used for 2 things:
- to notify parent permissibles on recalculate permissions (not needed anymore thanks to callbacks)
- subscription to chat broadcast permissions (now handled separately, again using callbacks)
therefore, it's no longer needed for PermissibleBase to reference its parent, meaning that we can have one less circular dependency in our lives.
relying on permission subscriptions for this was unreliable (a permissible is not always subscribed to a permission even when it does have it), and also difficult to control (for example there have been various bugs in the past where a Player ended up subscribed to broadcast permissions when it didn't expect to be, thanks to permission recalculation happening too early).
In addition, we might in the future want to have broadcast receivers which are not permissibles (i.e. a more general interface than CommandSender (why does a broadcast receiver need to also be a command sender, anyway?)), which the permission system wouldn't be suitable for.
this is an impressively dumb idea.
the playerdata is not used here in any capacity so it doesn't make sense to load it, especially considering that it takes a significant amount of time.
closes#3910
the existing naming was misleading, and many plugin devs assumed that it returns an exact match. However, this is not guaranteed, and it's possible for two different players to match the same prefix.
- There is no defined behaviour for what happens when multiple players can equally match a prefix (e.g. 'fr' could match 'fred' or 'frog' equally, because the name lengths are the same)
- A prefix might match a different player at a different time (e.g. 'fr' could match 'freddie' before 'fred' joins, after which it will match 'fred' instead)
With these flaws in mind, it's better to break compatibility on this to make the intent more clear, and to make plugin developers reassess their usages of this method. In most non-command use cases, they should likely be using getPlayerExact() instead.
this fixes#3200.
This causes permissions to be registered before plugin load, which changes some behaviour, but after discussions on #internals-dev we couldn't see any reason to keep the behaviour the way it was, and several reasons to change it to be something like this.
