Conflict resolution summary:
- .gitignore: kept dedicated-server-specific ignore entries (tmp*/, _server_asset_probe/, server-data/) and also kept main-side entries (*.user, /out).
- Minecraft.Client/Common/Network/GameNetworkManager.cpp: kept int64_t seed from main and preserved dedicatedNoLocalHostPlayer logic from dedicated-server.
- Minecraft.Client/Windows64/Network/WinsockNetLayer.cpp: preserved dedicated-server shutdown flow and also included main-side cleanup for s_smallIdToSocketLock.
- Add client-side host disconnect handling in CPlatformNetworkManagerStub::DoWork() for _WINDOWS64.
- When in QNET_STATE_GAME_PLAY as a non-host and WinsockNetLayer::IsConnected() becomes false, trigger g_NetworkManager.HandleDisconnect(false) to enter the normal disconnect/UI flow.
- Use m_bLeaveGameOnTick as a one-shot guard to prevent repeated disconnect handling while the link remains down.
- Reset m_bLeaveGameOnTick on LeaveGame(), HostGame(), and JoinGame() to avoid stale state across sessions.
* Multiplayer 8 to max byte increase.
Made-with: Cursor
* Server chunk optimizations for large player counts, server full notification fix, added to server.properties.
* fix: fix multiplayer player data mix between different players bug
Fixes a Win64 multiplayer issue where player data (`players/*.dat`) could be mismatched because identity was effectively tied to connection-order `smallId` XUIDs.
Introduces a deterministic username-derived persistent XUID and integrates it into the existing XUID-based save pipeline.
- Added `Windows64_NameXuid` for deterministic `name -> persistent xuid` resolution
- On Win64 login (`PlayerList`), set `ServerPlayer::xuid` from username-based resolver
- Aligned local player `xuid` assignment (`Minecraft`) for create/init/respawn paths to use the same resolver
- Added Win64 local-self guard in `ClientConnection::handleAddPlayer` using name match to avoid duplicate local remote-player creation
- Kept `IQNet::GetPlayerByXuid` compatibility fallback behavior, while extending lookup to also resolve username-based XUIDs
- Moved implementation to `Minecraft.Client/Windows64/Windows64_NameXuid.h`; kept legacy `Win64NameXuid.h` as compatibility include
Rename migration is intentionally out of scope (same-name identity only).
* fix: preserve legacy host xuid (base xuid + 0) for existing world compatibility
- Add legacy embedded host XUID helper (base + 0).
- When Minecraft.Client is hosting, force only the first host player to use legacy host XUID.
- Keep name-based XUID for non-host players.
- Prevent old singleplayer/hosted worlds from losing/mismatching host player data.
* update: migrate Win64 player uid to `uid.dat`-backed XUID and add XUID based duplicate login guards
- Replace Win64 username-derived XUID resolution with persistent `uid.dat`-backed identity (`Windows64_Xuid` / `Win64Xuid`).
- Persist a per-client XUID next to the executable, with first-run generation, read/write, and process-local caching.
- Keep legacy host compatibility by pinning host self to legacy embedded `base + 0` XUID for existing world/playerdata continuity.
- Propagate packet-authoritative XUIDs into QNet player slots via `m_resolvedXuid`, and use it for `GetXuid`/`GetPlayerByXuid` with legacy fallback.
- Update Win64 profile/network paths to use persistent XUID for non-host clients and clear resolved identity on disconnect.
- Add login-time duplicate checks: reject connections when the same XUID is already connected (in addition to existing duplicate-name checks on Win64).
- Add inline compatibility comments around legacy/new identity coexistence paths for easier future maintenance.
* update: ensure uid.dat exists at startup in client mode for multiplayer
* Code to read servers.txt
* logging (still doesnt work)
* server names load properly hooray
* remove logger as it only spews out nonsense anyways
* Do not use _countof, use sizeof(label)/sizeof(wchar_t) or make label std::array<wchar_t, 128> and call .size()
* Fix memory leak by listing info pointers
* C++ style cast (i think)
* this throws a RAV but why
* why oh why
* I just assume infos get deleted elsewhere otherwise idk why it breaks no matter what i do
* they get deleted all this time ohhhhhh
---------
Co-authored-by: Siepert123 <createlegacy69@gmail.com>
