Allium v0.2.8a

Wiki: https://github.com/castledking/Allium/wiki

Highlights

• Deleted chat messages no longer reappear on second deletion — Fixed a thread-safety bug where PacketChatTrackerImpl captured resend packets as new chat history entries, causing deleted messages to resurface on subsequent /delmsg runs. Required a server restart to clear.
• Shared ChatMessage instances across collections — playerMessages and playerChatHistory now reference the same object for packet-tracked messages, so setDeleted(true) on one automatically affects the other.
• Faster chat clear — The invisible-character clear phase now batches 20 characters per message instead of sending 120-180 individual packets, cutting the clear from ~180 packets to ~9.

Technical Details

Thread-Safe Resend Suppression

The previous fix in v0.2.7a removed duplicate tracking from FormatChatListener, but a second bug remained: PacketChatTrackerImpl used a plain HashSet for playersBeingResent, and removed the player UUID immediately when resendChatHistoryToPlayer() returned. PacketEvents may process outgoing packets on a different thread or slightly later, so resend packets were captured as brand-new chat history entries with fresh IDs, deleted = false, and SYSTEM_UUID as the sender. The next /delmsg marked the original entries deleted, but the replay-generated copies survived and reappeared on the next resend. After 3+ seconds the duplicate-time-window check in deleteMessage could no longer catch them.

Fix (three layers):

1. playersBeingResent: HashSet → ConcurrentHashMap.newKeySet() (thread-safe).
2. suppressPacketTracking: New AtomicBoolean checked by all three packet handlers via shouldIgnoreTracking(). Set true for the duration of resendChatHistoryToAllPlayers() so no packets from the broadcast are tracked, regardless of per-player timing.
3. Delayed cleanup: Player UUID removal from playersBeingResent and guard release (resendAllInProgress, suppressPacketTracking) are delayed 1 tick via SchedulerAdapter.runLater, giving PacketEvents time to process the outgoing resend packets before tracking resumes.

DeleteMsg.resendInProgress also releases after a 1-tick delay to prevent rapid successive /delmsg commands from scheduling overlapping resends.

Shared ChatMessage Instances

PacketChatTrackerImpl previously called chatMessageManager.storeMessage() (which creates one ChatMessage in playerMessages) and then constructed a separate ChatMessage object for trackMessageForPlayer() (which stores in playerChatHistory + globalChatHistory). Two different objects for the same logical message meant setDeleted(true) on one did not affect the other.

New ChatMessageManager.storeMessageObject() returns the actual stored instance. PacketChatTrackerImpl now calls this method and passes the same reference to trackMessageForPlayer(), so both collections share one object. Setting deleted = true on it propagates everywhere.

Additionally, ChatMessage.deleted is now volatile for cross-thread visibility (PacketEvents handlers may run off the main thread).

Batched Chat Clear

The clear phase previously sent 120-180 individual player.sendMessage() packets, each containing a single invisible Unicode character. This was the dominant cost in the 2-3 second resend time due to per-packet network overhead.

Now characters are batched 20-per-message with \n separators into a single Component.text(). Minecraft renders the newlines as separate chat lines, so the visual effect is identical — old messages are pushed off-screen — but in ~9 packets instead of ~180. The same batching was applied to the DeleteMsg.clearChatFallback() path.

Unused imports (java.util.Collections, java.util.concurrent.ThreadLocalRandom) were cleaned up from both files.