Download File

## 1.8.1-hotfix-1 ### 💿 Discs stopped going missing out of jukeboxes A jukebox's queue lived in memory and nowhere else. The world stores the one disc physically shown inside the block; the other 41 cells existed only for as long as the server was up, so a restart — or a crash, or a `/reload` — deleted every disc anybody had loaded into a jukebox, with nothing to get them back from. Nobody watching it happen could have guessed the cause: the discs were put somewhere the plugin itself displayed them, and they were gone the next morning. [Issue #6](https://github.com/valkdzx/CDisc-Issues/issues/6) Queues are written to `plugins/CDisc/queues.yml` now, next to the file that already remembered what was playing. They are saved a couple of seconds after anything changes and again on the way out, and read back the first time something asks after a jukebox — so a queue comes home when a player walks up to it, rather than everything at once on startup. A jukebox that was mid-track picks its queue back up along with its position, without the disc it was playing turning into two. Two other ways a disc could disappear are closed with it: - **A break somebody else refused.** The break handler ran at normal priority and ignored cancellation, so a protection plugin turning the break down still left the queue drained, the record cleared, and a jukebox full of the owner's discs lying on the ground for whoever was standing there. It now runs last and not at all on a refused break. - **Queues nobody had emptied.** Every jukebox anyone had ever opened stayed in memory for the life of the server. Empty ones are let go now, unless somebody is looking at that jukebox's screens. ### 🔁 And the ways a disc could become two A hopper under a jukebox empties it — a jukebox has been a container since 1.21 — and only a right-click ever told the queue that its disc had physically left. The disc went into the hopper and stayed in the queue as well, so breaking the jukebox afterwards dropped a second one. No timing and no trick involved: a hopper, a jukebox, and time. Double-clicking a disc in your own inventory gathers every matching stack in the window onto the cursor, the queue cells included. That is the one way into those cells that never arrived as a click on one, so nothing wrote the change back — the disc left the screen while the queue still held it, and the next repaint put it back into the cell it had just come out of. ### 🎵 The playlist screen no longer eats discs on a reload Blank discs handed to the playlist writer are held by the screen rather than left in the window, because it pages. They were held in memory alone, so a `/reload` or a shutdown with that screen open destroyed every one of them: by the time the player is kicked, the close that hands them back has nobody left to run it. The screens are shut on the way out now, which returns them the ordinary way. The discs are also handed over a tick after the window closes rather than during it, so a client tearing that window down doesn't miss them. ### 📻 Carried jukeboxes A carry that ended with no item to fold its discs into simply discarded them, and it takes no unusual settings to end one that way — logging out with the jukebox on your cursor rather than in a slot is enough, because the search for it only ever looked at inventory slots. The discs come back as a jukebox at the carrier's feet now, or where it was picked up from if they have already gone. Servers that raise `portable-jukebox.max-per-player` above 1 had two more. Putting one jukebox down dropped *every* carry its owner had, leaving the others as items nothing answered to — never settled, never handed back. Logging out or dying settled only the most recently picked up, and left the rest playing to an empty world. Shuffle is kept when a carried jukebox goes back down somewhere else — it was the one setting the move forgot.