ВЕРСИИ (6)

# SLS-LITE 0.1.0-rc.2.3 This narrow corrective release removes an implicit persistent-file backup policy and improves diagnostics for processes that fail after reaching readiness. Planned RC.3 features and architecture work remain out of scope. ## Persistent-File Publication - SLS-LITE no longer creates `internal/persistent-file-backups/` or retains a `previous.bak` before publishing a changed declared persistent file. - Publication remains atomic, so an interrupted write cannot expose a partial canonical file. - Single-writer ownership and conflict detection are unchanged. If the canonical and instance copies changed independently, SLS-LITE still preserves the canonical value, stores the instance value under `internal/persistent-file-conflicts/`, and requires an operator decision. - Backup and retention policy now belongs entirely to the operator. - Existing `internal/persistent-file-backups/` data from RC.2.2 or earlier is never deleted or modified during upgrade. Inspect, archive, or remove it manually while Velocity is stopped. This change affects only automatic backups made during persistent-file write-back. Transaction backups used temporarily to make a persistent instance reset recoverable remain required and are cleaned up after commit or startup reconciliation. ## Runtime Failure Diagnostics - A process that exits after successful readiness is now described as exiting `after readiness`; it is no longer mislabeled as a failed start or as exiting `before readiness`. - The report continues to record its exact exit code and `runtime` phase. - Oversized retained output now contributes its first 100 and last 100 lines, separated by an omission marker. Large Paper watchdog dumps therefore retain both their watchdog header and final shutdown result. - Existing report-count, redaction, confinement, per-line, and byte-size bounds remain unchanged. ## Living Documentation - Current manuals now describe the current supported behavior instead of carrying an accumulating RC-by-RC feature history. - Exact version references remain only where they identify the current artifact or tested compatibility stack, or define release/security mechanics. - Historical behavior, changes, and version-specific upgrade instructions remain available in release notes and in the documentation stored at each Git tag. - Canonical manuals now form a shallow topic tree rooted at `DOCS/README.md`. Setup, blueprints, operations, networking, integrations, compatibility, extensions, and development each have a focused branch landing page instead of sharing one crowded file layer. - Newcomer-facing pages now lead with short task-based paths. Host prerequisites, blueprint terminology, diagnostic retention mechanics, and contributor-only tooling remain available through focused references or expandable detail instead of interrupting the first working setup or recovery path. - Forwarding setup now treats the secret generated by Velocity or the hosting panel as authoritative. Operators are directed to reuse the configured file and matching relative path; manual secret creation is only a fallback when the file is genuinely absent. - GitHub community entry points now include root-level contributing, support, security, and conduct policies. Structured issue forms route ordinary bugs and feature requests separately from private security reports. - Reviewable Wiki source now mirrors the task-first documentation model, generated-forwarding-secret guidance, split backend-integration paths, and community support routes while keeping `DOCS/` canonical. - Backend-messaging documentation now includes a complete NPC/menu quick start: Paper sender setup, exact source authorization, direct matchmaking, optional allowlisted command relay, player-context requirements, and troubleshooting. It also documents the separate security and setup model for generic third-party command forwarders without depending on a particular plugin. A concise hub now routes operators to separate built-in and third-party guides. ## Upgrade From RC.2.2 1. Stop Velocity normally and confirm its managed child processes have exited. 2. Back up the complete `plugins/sls-lite/` directory and installed plugin JAR as one matching restore set. 3. Replace only the plugin JAR with `0.1.0-rc.2.3`; do not use a plugin hot-reloader. No configuration or blueprint migration is required. 4. Optionally inspect legacy `internal/persistent-file-backups/`. SLS-LITE will leave it untouched; remove it only if your own recovery policy no longer needs those files. 5. Start Velocity and review `/sls system`, blueprint readiness, and the detailed log. Verify persistent-file publication and one normal instance lifecycle before returning the host to service. Operators upgrading from RC.2.1 or earlier must also apply the RC.2.2 blueprint player-cap migration from `server.limits.max_players` to `annotations.sls-lite.max-players`. Do not attempt an in-place downgrade after persistent state has been used; stop the proxy and restore the matching data directory and JAR backup instead. ## Compatibility and Known Boundaries - The SLS-LITE Java API and blueprint schema are unchanged from RC.2.2. - Java 21 plugin bytecode remains supported on the tested Java 25 Velocity runtime. Host, storage, forwarding, protocol, and full-SLS compatibility boundaries are unchanged. - SLS-LITE reports and recovers managed child-process failures, but cannot prevent Paper watchdog exits caused by host suspension or resource starvation. - Cleanup of every unreachable directory after all possible failed or cancelled start phases remains assigned to RC.3 because it requires broader lifecycle and reconciliation work. Use the current [installation guide](https://github.com/Yeetoxic/SLS-LITE/blob/v0.1.0-rc.2.3/DOCS/Getting_Started.md), [migration guide](https://github.com/Yeetoxic/SLS-LITE/blob/v0.1.0-rc.2.3/DOCS/Migration.md), [compatibility matrix](https://github.com/Yeetoxic/SLS-LITE/blob/v0.1.0-rc.2.3/DOCS/Compatibility.md), and [troubleshooting guide](https://github.com/Yeetoxic/SLS-LITE/blob/v0.1.0-rc.2.3/DOCS/Troubleshooting.md). Report candidate issues with the SLS-LITE version, host capability summary, relevant detailed-log excerpt, and a minimal redacted configuration or blueprint.

# SLS-LITE 0.1.0-rc.2.2 This compatibility follow-up aligns omitted blueprint capacity with current full-SLS/vSLS behavior and begins the planned shared blueprint-shape migration. The implementation is otherwise frozen; RC.3 feature and architecture work remains out of scope for this candidate. ## Blueprint Capacity - A blueprint that omits player capacity now defaults to `10000` public player slots per instance. - A blueprint that omits its instance cap now uses `2147483647`, displayed to operators as `unlimited`. Configured host memory, managed-process, and port budgets still limit actual local concurrency. - Explicit finite capacity values remain unchanged. - Established `annotations.vsls.matchmaking.maxPlayers` and `annotations.vsls.max-instances` remain supported as upstream-compatible fallbacks when the corresponding SLS-LITE settings are omitted. ## Breaking Blueprint Migration The SLS-LITE public player cap moved from `server.limits.max_players` to `annotations.sls-lite.max-players`: ```yaml server: limits: memory_limit: 1536 max_instances: 1 annotations: sls-lite: max-players: 100 ``` The removed field is not accepted or silently translated. Blueprint reload reports an actionable error naming the replacement. Zero, negative, fractional, textual, overflowing, and malformed namespace input is rejected with the exact annotation path. `server.limits.max_instances` intentionally remains in the general limits section. The internal SLS-LITE annotation reader is now shared by capacity, lifecycle, queue, crash-recovery, and process-timeout policies so namespace and primitive validation remain consistent. ## Upgrade From RC.2.1 1. Stop Velocity normally and confirm its managed child processes have exited. 2. Back up the complete `plugins/sls-lite/` directory and installed plugin JAR as one matching restore set. 3. Before startup, replace every `server.limits.max_players` declaration with `annotations.sls-lite.max-players`. Preserve the same positive integer value. 4. Replace only the plugin JAR with `0.1.0-rc.2.2`; do not use a plugin hot-reloader. No `config.yml` rewrite is required. 5. Start Velocity and review the startup checklist, `/sls system`, blueprint `action needed` entries, and the detailed log. 6. For `save: true` blueprints whose annotation tree changed during this migration, review the reported definition drift and use the normal reset path before reuse. Reset reconstructs the instance from its current blueprint sources; back up operator-owned state first. 7. Verify a finite-cap blueprint and an omitted-cap blueprint through reload, creation or matchmaking, direct join, restart, and a full proxy restart. Operators upgrading directly from RC.2 should also read the RC.2.1 lifecycle and malformed-blueprint fixes in the repository history. If RC.2 persistent file state has been used, do not attempt an in-place downgrade: stop the proxy and restore the matching data-directory and JAR backup instead. ## Compatibility - The SLS-LITE Java API remains compatible with the published RC.2 API contracts; this candidate adds no extension API surface. - The full-SLS compatibility baseline continues to follow upstream `main` without embedding a release or commit pin in operator documentation. - Java 21 plugin bytecode remains supported on the tested Java 25 Velocity runtime. Existing host, storage, forwarding, and protocol boundaries are unchanged. ## Known Boundaries - SLS-LITE manages one host allocation. It does not reproduce full-SLS nodes, containers, HTTP control plane, or distributed resource enforcement. - Host permissions determine which storage strategies and child-process features are available. Portable copy remains the universal fallback unless the operator excludes it. - Existing configuration, software profiles, blueprints, volume sources, and saved instances remain operator-owned. SLS-LITE reports ambiguous or incompatible state instead of deleting or merging it automatically. - Cleanup of every unreachable directory after all possible failed or cancelled start phases remains assigned to RC.3 because it requires broader lifecycle and reconciliation work. Use the current [installation guide](https://github.com/Yeetoxic/SLS-LITE/blob/v0.1.0-rc.2.2/DOCS/Getting_Started.md), [migration guide](https://github.com/Yeetoxic/SLS-LITE/blob/v0.1.0-rc.2.2/DOCS/Migration.md), [compatibility matrix](https://github.com/Yeetoxic/SLS-LITE/blob/v0.1.0-rc.2.2/DOCS/Compatibility.md), and [troubleshooting guide](https://github.com/Yeetoxic/SLS-LITE/blob/v0.1.0-rc.2.2/DOCS/Troubleshooting.md). Report candidate issues with the SLS-LITE version, host capability summary, relevant detailed-log excerpt, and a minimal redacted configuration or blueprint.

# SLS-LITE 0.1.0-rc.2.1 This temporary hotfix candidate addresses release-blocking lifecycle and diagnostic problems reported against RC.2. It is intentionally narrow; the planned RC.3 feature work remains deferred. ## Fixes - Saved instances are no longer silently replaced with newly generated IDs. Start and creation paths identify an existing retained instance and require an explicit restart, reset, or deletion instead of leaving duplicate storage. - Matchmaking and the managed lobby resume their single retained persistent instance after a full proxy restart. If legacy storage contains multiple retained copies for one blueprint, startup refuses to choose arbitrarily. - Startup reconciliation quarantines ambiguous persistent copies without publishing any copy's managed files. It names the conflicting instance IDs so an operator can preserve the wanted copy and remove the others safely. - Reset and replacement cleanup retain the exact persistent instance identity, preserve unresolved file-conflict candidates, and avoid accumulating stale directories after interrupted or failed lifecycle operations. - Malformed blueprints now appear in the normal `action needed` workflow at startup and after reload. `/sls blueprint <rejected-path>` exposes the exact parser or validation failure, including suggestions for recognizable typos such as `state.volunes` instead of `state.volumes`. - `/sls console` is exclusively managed-server console input. Live output is available only through `/sls logs <server|this> --follow` and targetless `/sls logs --unfollow`. ## Compatibility and Documentation - The full-SLS compatibility baseline now follows the upstream `main` branch instead of a pinned release or commit. Documentation avoids repeating upstream version identifiers that become stale between audits. - The SLS-LITE Java API remains compatible with the RC.2 API contracts. This hotfix does not introduce a new extension API surface or configuration generation. - Java 21 plugin bytecode remains supported on the tested Java 25 Velocity runtime. Existing RC.2 host, storage, forwarding, and protocol boundaries are unchanged. ## Upgrade From RC.2 1. Stop Velocity normally and confirm its managed child processes have exited. 2. Back up the complete `plugins/sls-lite/` directory and installed RC.2 plugin JAR as one matching restore set. 3. Replace only the plugin JAR with `0.1.0-rc.2.1`; do not use a plugin hot-reloader. No configuration rewrite is required. 4. Start Velocity and review the startup checklist, `/sls system`, blueprint `action needed` entries, and the detailed log. 5. If more than one saved instance is reported for a persistent blueprint, preserve a backup and delete only the unwanted copies before starting that blueprint. SLS-LITE deliberately will not select one on your behalf. 6. Exercise a representative saved server through start or matchmaking, restart, reset where appropriate, and a full proxy restart. If RC.2 persistent-file state has been used, do not attempt an in-place downgrade. Stop the proxy and restore the matching data-directory and JAR backup instead. ## Known Boundaries - SLS-LITE manages one host allocation. It does not reproduce full SLS nodes, containers, HTTP control plane, or distributed resource enforcement. - Host permissions determine which storage strategies and child-process features are available. Portable copy remains the universal fallback unless the operator excludes it. - Existing configuration, software profiles, blueprints, volume sources, and saved instances remain operator-owned. The hotfix reports ambiguous state instead of deleting or merging it automatically. Use the current [installation guide](https://github.com/Yeetoxic/SLS-LITE/blob/v0.1.0-rc.2/DOCS/Getting_Started.md), [migration guide](https://github.com/Yeetoxic/SLS-LITE/blob/v0.1.0-rc.2/DOCS/Migration.md), [compatibility matrix](https://github.com/Yeetoxic/SLS-LITE/blob/v0.1.0-rc.2/DOCS/Compatibility.md), and [troubleshooting guide](https://github.com/Yeetoxic/SLS-LITE/blob/v0.1.0-rc.2/DOCS/Troubleshooting.md). Report candidate issues with the SLS-LITE version, host capability summary, relevant detailed-log excerpt, and a minimal redacted configuration or blueprint.

# SLS-LITE 0.1.0-rc.2 This second release candidate turns the first external-testing feedback into a safer, clearer operator experience. It remains intended for controlled single-host Velocity networks while the release-candidate testing period continues. ## Highlights Since RC.1 - Non-destructive configuration generation 2 diagnostics. Existing `config.yml` files remain operator-owned and are never rewritten; omitted new options receive safe defaults and the startup checklist points to the exact current reference. - Optional host-wide `software.auto_accept_eula`, disabled by default, alongside the existing per-software-profile EULA choice. - A focused first-run checklist, production and isolated-development forwarding walkthroughs, blueprint readiness diagnostics, a copyable canonical config, and a visual blueprint recipe book. - Bounded `state.persistent_files` mappings for root files such as Paper whitelist, operator, ban, and icon files. They use single-writer ownership, atomic write-back, backups, conflict detection, and crash reconciliation without privileged mounts or symbolic links. - Discoverable live output through `/sls logs <server|this> --follow` and `/sls logs --unfollow`, with bounded delivery and compatibility aliases for the older console forms. - vSLS-compatible administrator force joining with backend-safe capacity headroom, plus live managed-instance memory, CPU, player, and lifecycle metrics in the `/sls debug` action bar. - Correct modern forwarding across old and current Paper configuration layouts, authoritative generated SLS-Limbo settings, and protected fallback/automatic lobby return during owned lobby outages. - Player-visible preparation phases for slow installs and starts, plus clearer restart-versus-reset guidance when definitions change. - Additive Java extension API 1.2 with readiness and diagnostic contributions, graceful administrative operations, maintenance controls, and exact-instance routing. API 1.0 and 1.1 consumer compatibility remains covered. - Clean Paper installations now use a 60-second graceful shutdown allowance. Existing generated software profiles remain operator-owned and are not silently changed. ## Compatibility Baseline - Java 21 plugin bytecode on the tested Java 25 Velocity runtime. - Exact Velocity 4.1.0 API snapshot pinned in `pom.xml`; the exercised local proxy runtime is recorded in `DOCS/Compatibility.md`. - Stable Minecraft/Paper through 26.2 where the documented provider, Java, plugin, forwarding, and real-client requirements are satisfied. - With compatible ViaVersion installed, Minecraft 26.2 is the forward-client minimum rather than a maximum. Newer clients are allowed when that installed ViaVersion build reports support for them; this does not qualify their worlds, plugins, or gameplay behavior. - NanoLimbo 1.13.0 at revision `d192d57d1d4a5fdc7b87643f453d82cb7b9b4242` for SLS-Limbo. Minecraft 26.3 is still an upstream snapshot line and is not release-qualified. Snapshots may be tested only with a compatible ViaVersion build and disposable data. ## Upgrade From RC.1 1. Stop Velocity normally and confirm managed children have exited. 2. Back up the complete `plugins/sls-lite/` directory and the installed RC.1 plugin JAR as one matching restore set. 3. Read [Migration](https://github.com/Yeetoxic/SLS-LITE/blob/v0.1.0-rc.2/DOCS/Migration.md), replace only the plugin JAR, and start Velocity normally. Do not use a plugin hot-reloader. 4. Review the compact setup/migration diagnostics, `/sls system`, and the detail log. An unversioned RC.1 configuration is treated as generation 1; SLS-LITE does not rewrite it or create a duplicate reference file. 5. Compare operator-owned configuration and software profiles with the current documented defaults, then deliberately add or acknowledge wanted changes. 6. Run a representative start, join, restart, and stop. Adding or changing `state.persistent_files` on an existing persistent instance requires an explicit reset; ordinary restart correctly rejects definition drift. If RC.2-only state has been used, do not attempt an in-place downgrade. Stop the proxy and restore the complete matching RC.1 data-directory and JAR backup. ## Known Boundaries - SLS-LITE manages one host allocation. It does not reproduce full SLS nodes, containers, HTTP control plane, or distributed resource enforcement. - Host permissions determine which storage strategies and child-process features are available. Portable copy remains the universal fallback unless the operator excludes it. - Vanilla backends cannot use modern Velocity forwarding. - Server software or ViaVersion protocol availability does not guarantee compatibility of arbitrary worlds, plugins, Java versions, or game behavior. - Existing configuration, software profiles, blueprints, and volume sources are operator-owned. Release upgrades report required changes instead of silently normalizing custom or extension-owned fields. Use the current [installation guide](https://github.com/Yeetoxic/SLS-LITE/blob/v0.1.0-rc.2/DOCS/Getting_Started.md), [migration guide](https://github.com/Yeetoxic/SLS-LITE/blob/v0.1.0-rc.2/DOCS/Migration.md), [compatibility matrix](https://github.com/Yeetoxic/SLS-LITE/blob/v0.1.0-rc.2/DOCS/Compatibility.md), and [troubleshooting guide](https://github.com/Yeetoxic/SLS-LITE/blob/v0.1.0-rc.2/DOCS/Troubleshooting.md). Report candidate issues with the SLS-LITE version, host capability summary, relevant detailed-log excerpt, and a minimal redacted configuration or blueprint.

Update 2.1.2 - 09/07/2024 11:11pm PT --> Changes from V-2.1.1HF: ### 1. Fixed [sls] prefix appearing twice: > * [SLS] prefix would appear twice when the info command was ran with no servers running > * Example output: _"[SLS] [SLS] No servers are currently online"_ ### 2. Fixed "/sls info" cmd not appearing for users without the "sls.command.admin" tag. ### 3. Updated console text to be more informative. ### 4. Added proxy shutdown message in console.

Changes from V-2.0.1: 1. Fixed loading process for config files 2. Updated Internal Java version provided by pom.xml -> JDK 17 3. Added in-game text formatter of "[SLS]" before any in-game message to prevent confusion. 4. Cleaned-up unused dependencies & code. 5. Updated pom.xml to run properly 6. Migrated Code Base to the Velocity API. 7. Updated backend & Upgraded internal systems to be more efficient. 8. Added a multi-registry system for organizing server types. ----------------- - This update is a complete overhaul of the original SLS plugin; This plugin now runs off of Velocity ([Which you can find here](https://papermc.io/software/velocity))!