11.1.4 Compatibility Update

Updates CommandAPI to 9.53, enabling MC 1.21.1 support

11.1.3 Compatibility Fix

Fixed a compatibility issue in Paper 1.21

11.1.2 Compatibility Update

• Updates CommandAPI for compatibility with MC 1.21

11.1.1

• Paper's PR with a Brigadier API broke CommandAPI. They since updated their library, and the new one has been included with this update.
• Dependencies updated

11.1.0

Changes

• Minecraft 1.20.5 & 1.20.6 support
• Increment to API 11.1: TM:Core 11.1.0 is the new minimum expected version (download here). This update is backwards-compatible with previous API 11.0 extensions
• CommandAPI dependency now uses Mojang-Mappings: See below

Paper's Shift to Mojang-Mappings

Starting with 1.20.5, Paper switched its default JARs to use Mojang-mappings instead of Spigot-mappings. For servers running MC 1.20.5+ or a pre-1.20.5 server using Mojang-mappings, use TMSE-Paper-11.1.0.jar. For servers running 1.20.4 or lower, use TMSE-Paper-11.1.0-Spigot-Mappings.jar.

11.0.4 Bug Fix + Small Feature

• Fixed a bug where the internal version was not updated, causing the update checker in 11.0.3 to always say an update was available.
• Added /ticket as an alias to /ticket help

11.0.3 Bug Fix

• Fixed issue where TMSE-Spigot did not depend on TMCore and mandated LuckPerms (still required if no extension plugin for other permission systems is installed). This also ensures correct load order.
• Fixed issue where some users experienced notification spam in proxy mode.

11.0.2 Bug Fixes

This update fixes all currently known issues with the proxy mode:

• Fixed: PBE update checker now reports the correct information
• Fixed: Teleportation sends now sends players to the correct location (logic fixed).
• Fixed: Server name now shows when in proxy mode
• Fixed: Mass notifications across a network are implemented

11.0.1 Bug Fix

Fixed bug where the scheduled unread tickets notification accidentally reported the user's open tickets instead.

TicketManager 11: Full Release + A Reflection

TicketManager 11: Ultra-Modularization Update (AKA Update 10 Part 2: Electric Boogaloo)

I am pleased to finally release the long-awaited Update 11 to the TicketManager Ecosystem. Additionally, I've written a section with regards to the future of the project (spoiler: I'm not abandoning it, so don't worry). However, before continuing, we need to discuss the elephant in the room: TicketManager 10

Official Apology For TM 10

To say TM 10's launch was rough is an understatement—it was disastrous.
The update was riddled with issues from the very beginning, and it wasn't until version 10.0.5 or 10.0.6 that it met the standard to which users were acquainted. Further adding insult to injury, upgrading from version 9 either required dropping your previous ticket history or required a migration tool which was also plagued with problems.

I failed to perform due diligence during changes and testing, the result of which was a shitty product where the community was expected to treat full releases like a beta— an unreliable service. This without a doubt has marred the ecosystem's reputation and tarnished the trust the community had in me to consistently deliver a high-quality product. There's no one to blamee for this other than myself, and I am deeply sorry for it. TM 10 had a lot going for it, but it was held back by poor decision-making.

Starting in TM 11, all not-insignificant updates are pushed to a beta stream prior to full release. This beta stream is in the Discord channel and accessible to anyone. This way, users can maybe once again trust that full releases function without critical problems.

Changes

TicketManager 11 first and foremost does what TM 10 couldn't— it takes the feature-set and lessons learned from V10 and implements them into a second-gen, mature system, and then it greatly expands developer capabilities.

API, Extension, and Event System Overhaul

API 10 was carefully designed to be used in both Kotlin and Java. However, his parity restricted idiomatic usages and abilities. API 11 introduces a completely overhauled core interface written to be unapologetically Kotlin and leverage Kotlin-specific features. Other languages now rely on alternative API modules containing hooks and interfaces for the specific language.

API 11 contains a greatly expanded API with the ability to implement support for specific databases, permission systems, locales, augmenting command execution, and more. Additionally, the Event system has been completely rewritten and expanded. Finally, all entry points and the event bus can be accessed through a new static point. More information about the new API can be found on the TM:API wiki.

It is worth noting that API 10 extensions are not compatible with API 11.

More About The New Extension System

If you're a developer, this is not the section for you. You would be MUCH better served by the up-to-date API wiki just above. This section is targeted towards end-users with the goal of briefly explaining some of the behaviour of the extension system applicable to them.

The new extension system pervades throughout the plugin, and so it is highly recommended to have a high-level knowledge of the topic. There are 2 types of extension behaviours: overriding and augmenting.

Overriding extensions outright replace behaviour with their own. Think of plugins which provide a service normally provided by the plugin, like support for an unofficial locale, a particular database type, or a specific permission plugin. For these, only one of the same type can ever be active at once, and it's determined by whichever first successfully registers with the plugin. For this reason, it is highly recommended that you only install one per extension type (i.e. don't install 2 database extensions).

Augmenting extensions, on the other hand, merely augment or alter existing behaviour. A fantastic example of these are the cooldown feature. Despite adding functionality, it merely listens for TM commands and decides if the command should be allowed or blocked. Command-based extensions and repeating timers are examples of this. Augmenting extensions are not limited in number, and thus multiple plugins of this type may be safely used together (ignoring incompatibilities between the 2).

Note: TM Event Listeners are not an extension. They are not registered like an extension and lack the ability to alter the plugin. However, like augmenting extensions, multiple may be used across the same plugin or multiple plugins.

TM:Core Plugin Requirement

TicketManager Core (TM:Core) is a new and required part of the TicketManager ecosystem. It provides a critical decoupling of the components developers use and the functionality TM:SE consumes/provides. To install the new plugin or to learn more about why this new plugin is required, visit the release page here.

TicketManager: Past, Present, & Future

The Past

TicketManager has been my baby since 2021, back when it was just TM 1.0.0 on a small server called Broncin I used to work for. I'll tell you, that code was a piece of hot garbage! But, it was the spark of what I wanted TicketManager to be: a flexible ticket system pleasant to use for both players and staff alike, without the wretched chest GUI.

I worked with it every day while moderating and administrating, and the server was decently active at the time, so feedback and better ideas were always flowing. It got to the point that I dreamed about TicketManager. I dreamed of the code and how certain design choices would just nag at me. That nag would spark mass rewrites in pursuit of something that felt right.

Eventually version 2 made its way around, and I decided I would try making it public. I distinctly remember telling myself that if I could get 10 people to download and use it, that I would be happy. To my shock, people actually started to download it! TicketManager hit 10! In hindsight it doubt many or any of them kept using it, but it inspired me to create the "perfect" ticket plugin. I dreamed of making something that could work for the smallest friend servers to the largest networks. I wanted something that could work for everyone.

After version 3 was both when I decided to make the switch to Kotlin and when I received my first piece of guidance from someone outside of Broncin. This time period is probably one of the most vivid memories I have of the project. I worked with a guy named SlimeDog to improve the plugin, and I used my Kotlin-learning as an excuse to rewrite the entire project from scratch in Kotlin. I remember visiting friends in Oklahoma, and because they didn't wake up until noon, I was on my laptop programming away with so many ideas until they woke up.... and I was supposed to be on vacation, haha. I also remember that for TM 4, I quickly whipped up a logo and banner in photoshop in under 30 minutes.... I would update it, but it's kinda grown on me~

Anyways, as more people installed the plugin over the next year and had suggestions, I realized that my fast and footloose approach to updating wasn't gonna cut it anymore. I needed to make something that people could consistently rely on (spoiler: I've thrown this out the window... multiple times). The next several major updates focused on performance, compatibility, proxy support, and more. (In case you were wondering, why yes, I did in fact mostly rewrite every major version from scratch, using the previous version as a guide).

However, that nagging way back from TM 2 never went away. With each version, I was always disgusted by something that would inevitably spark yet more tens to hundreds of hours of work doing rewrites, testing, and pondering.

Eventually my fixation became extendability— I wanted users who were not satisfied with a particular plugin behaviour to be able to change it. This desire started around the time proxy support became a thing, but I never had the ability to do it... until TM 10. We all know how TM 10 went (hint: cataclysmic disaster), so I won't speak too much on it since I already spoke about it in my apology. In summary, I'm ashamed of how TM 10 went, but it did teach me lots of good lessons, which I've put my heart and soul into for TM 11.

The Present

Incredible and beautiful are the only two words which come close to describing the life of this project. What was once a small, custom project for a small server I worked on has become a fully-fledged support ticket software built on thousands of hours of determination, tribulations, and successes. At the time of writing, TM has thousands of downloads across 150 known servers. This project has been a beautiful learning experience, and I am so damn proud of what has been accomplished.

The Future?

For once, I feel at piece with the state of TicketManager. Sure there are small improvements that I am entertaining, but that strong nagging feeling which drove every previous rewrite is gone. The core of TicketManager's code just feels... right.

This is where the melancholic part starts: I want to move on. That isn't to say I'm abandoning this project. I will continue to push bug fixes, make compatibility updates, and occasionally post minor feature updates, whether it be to TM:SE directly or via an extension, but the days of major feature additions feels over to me. I just don't have a desire to add large features to TM:SE or TM:API when I feel that everything is as it should be. Instead, I'd like to place my primary focus on other personal interests and/or commitments.

This is where I believe the community comes in. I've put thousands of hours of work into making this project what it is now. Now that there's a wonderful system in place for developers, I have the confidence to take a step back a...