EssentialsX
added a config-entry to selectively ignore causes of the back-in-listener
Information
This PR aims to add a simple and very much non-invasive feature to Essentials. I didn't create an issue beforehand, seeing how it would be much easier to explain my requirements with a concrete implementation - one that only took a few minutes anyway.
Details
The existing config-entry register-back-in-listener allows to update the last-location of a player by not just internal features, but also by teleportation caused by external plugins. The issue I ran into was that this becomes either an "all" or "nothing" option, as the user cannot selectively exclude plugins. Teleporting players is such a ubiquitous action that it is virtually impossible to make all of these plugins talk to the Essentials API and provide an option for whether to affect the last-location themselves. It is much more reasonable to enable the user to selectively block plugins from indirectly modifying this state.
I've added descriptive comments to the newly introduced config-entry and hope that they properly explain the syntax. If they lack in clarity, I am always willing to improve them, given some feedback.
Last but not least, I wasn't quite able to follow on how Essentials migrates new keys into the existing config on the user's machine, so any hints would be much appreciated! The current setup of it simply being absent and requiring manual adding is not ideal.
Environments tested:
OS: Fedora Linux 42 (Workstation Edition)
Java version: 21.0.9
- [x] Most recent Paper version (1.XX.Y, git-Paper-BUILD)
- [ ] CraftBukkit/Spigot/Paper 1.12.2
- [ ] CraftBukkit 1.8.8
Demonstration:
There's not much to demonstrate here, other than the observation that if I add an entry of 'craftbook,elevator' to the ignore-list, players on our server will never /back to the location of a lift, which has been a real nuisance since we've tried to enable /back for other plugins, like shop-search, etc.
Please consider going into more detail on your suggestion of using an event, because with this little information, I'm afraid I cannot follow. As I've tried to convey already, there are countless plugins out there who do not integrate with Essentials and dispatch a teleportation on the regular. As of now, the user can simply use all of them, or none of them, to modify the last-location state.
My approach does not "break" on async teleports - the original callstack simply has been lost, so it will not trigger; no harm done whatsoever. Teleporting a player by first pre-loading the chunks asynchronously is a niche feature which most plugins that provide day-to-day conveniences do not make use of.
I really don't see why you'd rather have it remain an all-or-nothing option, in contrast to at least providing choice for like 80% of the plugins this would even affect in the first place.
Any news on an alternative solution? I still cannot see how one would otherwise exclude plugins which do not integrate with essentials natively already. I really don't see the damage of supporting this approach. Async teleports are irrelevant to most people.