Adds the FourKit .NET 10 plugin host as a second dedicated server
build flavour alongside the existing vanilla server. Both flavours
build from the same source tree, with FourKit gated by the
MINECRAFT_SERVER_FOURKIT_BUILD preprocessor define.
Build layout:
Minecraft.Server vanilla, no plugin support, no .NET dep
Minecraft.Server.FourKit FourKit-enabled, ships with bundled
.NET 10 self-contained runtime in runtime/
and an empty plugins/ folder
Both produce a Minecraft.Server.exe in their own per-target output
dir. The variant identity lives in the directory name, not the
binary name, so either flavour can be shipped as a drop-in.
Native bridge (Minecraft.Server/FourKit*.{cpp,h}):
* FourKitRuntime: hosts CoreCLR via hostfxr's command-line init API
(the runtime-config API does not support self-contained components)
* FourKitBridge: ~50 Fire* event entry points, with inline no-op
stubs for the standalone build so gameplay code can call them
unconditionally
* FourKitNatives: ~80 native callbacks the managed side invokes
for player/world/inventory mutations
* FourKitMappers: type and enum mapping helpers
Managed plugin host (Minecraft.Server.FourKit/):
* Bukkit-style API: Player, World, Block, Inventory, Command,
Listener, EventHandler attribute, ~54 event classes
* PluginLoader with per-plugin AssemblyLoadContext
* FourKitHost as the [UnmanagedCallersOnly] entry point table
* Runtime resolves plugins relative to the host process so they
always live next to Minecraft.Server.exe regardless of where the
managed assembly itself is loaded from
Engine hooks (Minecraft.Client/, Minecraft.World/):
* Player lifecycle (PreLogin, Login, Join, Quit, Kick, Move,
Teleport, Portal, Death) wired into PendingConnection and
PlayerConnection without disturbing the cipher handshake or
identity-token security flow
* Inventory open/click/drop hooks across every container menu type
* Block place/break/grow/burn/spread/from-to hooks across the
full tile family
* Bed enter/leave, sign change, entity damage/death, ender pearl
teleport hooks
Regression fixes preserved while applying donor diffs:
* ServerPlayer::die() retains the LCE-Revelations hardcore branch
(setGameMode(ADVENTURE) + banPlayerForHardcoreDeath) in both the
FourKit and non-FourKit code paths
* ServerLevel::entityAdded() retains the sub-entity ID reassignment
loop required by the client's handleAddMob offset, fixing Ender
Dragon and Wither boss multi-part hit detection
* LivingEntity::travel() retains the raw Player* cast and the
cached frictionTile, both Revelations perf wins that the donor
silently reverted
* ServerLogger.cpp keeps the file-logging code donor stripped
* PlayerList.cpp end portal transition fix and UIScene_EndPoem
bounds-check are intact
Build system:
* Top-level CMakeLists.txt adds the Minecraft.Server.FourKit
subdirectory and pulls in the new shared cmake/ServerTarget.cmake
helper
* Minecraft.Server/cmake/sources/Common.cmake is now location
independent (uses CMAKE_CURRENT_LIST_DIR) so the source list
can be consumed from either server target's CMakeLists.txt
* The seven FourKit*.cpp/h files live in their own
_MINECRAFT_SERVER_COMMON_SERVER_FOURKIT variable so the
standalone target omits them
* configure-time .NET 10 SDK check fails fast with a clear
download link if the SDK is missing
* global.json pins the SDK to 10.0.100 with latestFeature
rollforward
Sample plugin (samples/HelloPlugin/) demonstrates the loader and
the PlayerJoinEvent listener pattern.
CI:
* nightly.yml builds both server flavours, ships
LCE-Revelations-Server-Win64.zip and
LCE-Revelations-Server-Win64-FourKit.zip, attests both, and
updates release notes for the dual-flavour layout
* pull-request.yml pulls in actions/setup-dotnet so the FourKit
publish step works in PR validation
* All zip artifacts and the client zip are renamed from
LCREWindows64 to LCE-Revelations-{Client,Server}-Win64
Documentation:
* COMPILE.md gets a VS 2022 quick start, .NET 10 prereq section,
server flavours explanation, and a troubleshooting section
* docs/FOURKIT_PORT_RECON.md captures the file-by-file recon that
drove the port
* docs/FOURKIT_PARITY.md is the canonical reference for which
events FourKit fires
Docker:
* docker-compose.dedicated-server.yml MC_RUNTIME_DIR default points
at the vanilla CMake output. The FourKit Docker image is
intentionally NOT shipped yet because hosting .NET 10 self
contained inside Wine has not been smoke-tested
Renames release artifacts, Docker image, container/service names,
and shell wrappers from the legacy LCRE prefix to LCE-Revelations.
* Banner asset: LCRE-banner.png to LCE-Revelations-banner.png
* Docker compose service and container: minecraft-lce-dedicated-server
to lce-revelations-dedicated-server
* ghcr image: ghcr.io/itsrevela/minecraft-lce-dedicated-server to
ghcr.io/lce-hub/lce-revelations-dedicated-server
* Dockerfile MC_RUNTIME_DIR default points at the CMake build output
path now that the legacy x64/ MSBuild path is no longer produced
* README and helper shell scripts updated to match
Workflow rename for nightly.yml release notes is folded into the
FourKit commit because the FourKit CI changes overwhelm the diff.
Matches the packet size limit used by the plugin-api fork. Our 512KB
limit caused "Connection lost" when their server sent large packets
(e.g. chunk data) that exceeded our cap.
Reverts workflow revert (#c4c4c08b), BACKPORTING.md (#5e584910),
and CONTRIBUTING.md backporting link (#7dfe46aa) that were
unintentionally included via the upstream merge commit.
* Working New portal checks
fixed x axis portal with obsidian on z axis
* Removed Debug code
* Remove unnecessary code
removed PortalTile:: from PortalTile::validPortalFrame
* Remove more debug code
Chunk loading now batches up to 16 nearest-first requests per player per
tick on dedicated server (client stays at 1), improving tick recovery
time after player join.
Reverts the async save system -- the background thread snapshot/compress
path added complexity without measurable benefit. Autosave on Windows64
server now uses the standard synchronous flush like client, in
preparation for a proper async implementation from upstream.
DLL injector + Python GUI for real-time server metrics.
Hooks into tick loop, chunk generation, and player chunk map
to collect timing data over TCP, displayed in a tkinter dashboard.
Includes bot spawner for load testing.
* Working New portal checks
fixed x axis portal with obsidian on z axis
* Removed Debug code
* Remove unnecessary code
removed PortalTile:: from PortalTile::validPortalFrame
* Remove more debug code
The previous IQNet cleanup in handleRemoveEntity fired on every entity
despawn, which happens both when a player goes out of tracking range
and when they disconnect. This caused players to vanish from the Tab
list whenever they moved beyond render distance.
Introduce two custom payload channels (MC|ForkHello, MC|ForkPLeave) so
the client can distinguish "out of range" from "actually left":
- Server sends MC|ForkHello during login to identify itself as a fork
- Server sends MC|ForkPLeave with the player's gamertag on disconnect
- Client skips IQNet cleanup in handleRemoveEntity on fork servers
- Client cleans up IQNet only when MC|ForkPLeave arrives
Fully backwards-compatible: no existing packet wire formats changed.
Upstream clients ignore the unknown channels, fork clients on upstream
servers fall back to the old entity-tracking-based cleanup.
Rewire the SWF focus chain via Iggy so VSync, Fullscreen, and Render
Distance are reachable with keyboard/gamepad navigation.
Cap render distance slider at 16 chunks. Shift graphics menu layout
up 60px for better centering.
Fix skin preview walk/attack animations running too fast with VSync
off by scaling per-frame increments by delta time relative to 60fps.
The walking and attack animations in the Change Skin menu were
frame-rate-dependent, advancing per render call with no delta time
scaling. With uncapped FPS they ran proportionally too fast.
Add time-based scaling relative to a 60fps baseline. The scale is
computed once per frame (cached for 0.5ms) so multiple skin previews
rendered in the same frame all animate at the correct speed.
StorageManager.SaveSaveData() blocks until the disk write completes.
Calling it from the game thread caused 2.5s freezes. Now it only runs
from TickCoreSystems() on the ServerMain thread, which operates
independently of the game tick loop.
Move StorageManager.AllocateSaveData() back under the save lock (called
on the game thread before releasing). Background thread now only does
pure zlib compression with no StorageManager calls.
Add CommitPendingAsyncSave() to both the game thread tick and
TickCoreSystems() to ensure saves commit during bootstrap, normal
gameplay, and shutdown.
Autosave previously froze the main thread for 2-6 seconds while
compressing the entire save file with zlib. Now the save buffer is
snapshotted under the lock (~18ms), then compression runs on a
background thread. The compressed data is committed to StorageManager
on the next main-thread tick via CommitPendingAsyncSave().
Also skip redundant full chunk saves during autosave on the dedicated
server -- chunks are already persisted by the per-tick trickle save.
Only entity data is flushed, matching Xbox/Orbis behavior.
Added per-step timing to the autosave handler for diagnostics.
