Kitsune Paint Unlocked

Bug fix
Fixes save-reload crash reported on NexusMods: "Index was outside the bounds of the array" when loading a savegame with 255+ paint textures.
Root cause: BlockTextureData.list wasn't sized for 10-bit paint IDs (512+) before the game accessed saved texture data on reload.
Changes
Pre-size BlockTextureData.list to 1024 at mod init and during XML loading
Handle null list edge case in BlockTextureData.Init safety patch
Add double-encoding guard to prefab texture re-encoder (defense in depth)

Server-authoritative paint ID sync
Fixes the issue where clients see wrong/missing custom textures after a server restart unless they fully quit and relaunch the game.
How it works: The server sends its paint ID mapping to each client on connect via a pu_sync console command. The client reshuffles its BlockTextureData.list to match the server's IDs before any chunk data arrives. No more stale paint caches.
Changes
PaintIdSyncManager — builds mapping after texture init, serializes as base64, sends via NetPackageConsoleCmdClient on RequestToEnterGame
ConsoleCmdPaintSync — client-side handler that deserializes and remaps paint IDs
OcbPaintLimitPatch.ResetCounterTo() — keeps allocation counter consistent after remap

Fixes client disconnect on connect / painting.xml crash
The 8-to-10-bit texture re-encoding prefix was corrupting prefab data on fresh worlds,
causing immediate client disconnect when loading chunks. The 10-bit IL transpilers
already handle bit-width at the storage level, so the repack was redundant.
This fixes:
"Index was outside the bounds of the array" on painting.xml
Client disconnect immediately after connecting to a server with custom paint packs
Save corruption on worlds with PyroPaints, CK Textures, or other custom paint packs
Tested with: PyroPaints + CK Textures (139 custom textures) on Navezgane.
Paints persist across disconnect/reconnect and full server restart.

Fixes empty paint menu on listen server (P2P) reload
When hosting a P2P game and quitting to menu then reloading, custom paints disappeared
from the paint menu and painted blocks lost their textures. The paint ID counter wasn't
resetting between world loads within the same game session.
This fixes:
Empty paint menu after quit-to-menu + reload on listen servers
Lost paint textures on hosted/P2P games after reload
Paint ID counter drift causing ID mismatch on session reload
Works on: Dedicated servers AND listen servers (P2P hosted games).

Fixes POI textures on fresh worlds + listen server paint persistence
v1.0.3 and v1.0.4 had a regression: POI buildings on fresh worlds showed garbled/wrong textures. The 8→10 bit texture re-encoding for prefab placement was disabled to fix a connect crash, but that crash was actually caused by a different issue (empty client Mods folder). The re-encoding is now re-enabled for POI prefab data.
Also includes v1.0.4 fix: Paint menu no longer empties out after quit-to-menu + reload on listen servers (P2P hosted games).
What's fixed
POI buildings render with correct textures on fresh worlds (tested with Fluffy Panda POI pack)
Custom paints persist across disconnect/reconnect on both dedicated and listen servers
Custom paints persist across full game restart
Paint ID counter properly resets on world reload
Important
Both mods must come from this zip (0_PaintUnlocked + OcbCustomTextures)
Fresh world required — worlds created without PaintUnlocked will show garbled textures
Install mods before creating your world

Existing worlds are now supported
Previously, installing PaintUnlocked required starting a brand new world — existing saves had chunk texture data in vanilla's 48-bit format, and PaintUnlocked needs 64-bit storage to handle paint IDs above 255. This release adds an automatic migration step that runs once when a pre-PaintUnlocked world is loaded for the first time. All chunks on disk are scanned, repacked from the 8-bit-per-face vanilla format to the 10-bit-per-face PaintUnlocked format, and written back. A marker file (`paintunlocked.migrated`) is then written to the save folder so subsequent loads skip the scan.
What you'll see
The first load of an existing world pauses for a moment while the migration runs. Server log shows lines like:
[PaintUnlocked] Migration sentinel NOT found — treating world as legacy 8-bit
[PaintUnlocked] EagerMigrator: starting scan of N chunks
[PaintUnlocked] EagerMigrator: scan complete in Xms. N migrated, 0 failed
[PaintUnlocked] Migration complete. Sentinel written
For a small world (~300 chunks) this takes about a second. For big multi-region worlds it can take several seconds to a minute. After it's done, the world is permanently in the 10-bit format and loads normally from then on.
One caveat
If you were using custom paint packs (PyroPaints, CK Textures, KitsunePaints, etc.) before installing PaintUnlocked, those paints register at different IDs once PaintUnlocked is enabled — vanilla's allocation puts them at 154-255, but PaintUnlocked's GPU atlas requires custom paints to start at ID 512. Migration preserves the chunk storage but can't follow paints to their new IDs, so previously-painted custom-paint blocks will appear unpainted after migration. Just repaint them with the same paint pack — all your packs still work, the paints just have new IDs now. Vanilla paints (IDs 0-153) survive the migration intact.

Existing worlds are now supported
Previously, installing PaintUnlocked required starting a brand new world — existing saves had chunk texture data in vanilla's 48-bit format, and PaintUnlocked needs 64-bit storage to handle paint IDs above 255. This release adds an automatic migration step that runs once when a pre-PaintUnlocked world is loaded for the first time. All chunks on disk are scanned, repacked from the 8-bit-per-face vanilla format to the 10-bit-per-face PaintUnlocked format, and written back. A marker file (`paintunlocked.migrated`) is then written to the save folder so subsequent loads skip the scan.
What you'll see
The first load of an existing world pauses for a moment while the migration runs. Server log shows lines like:
[PaintUnlocked] Migration sentinel NOT found — treating world as legacy 8-bit
[PaintUnlocked] EagerMigrator: starting scan of N chunks
[PaintUnlocked] EagerMigrator: scan complete in Xms. N migrated, 0 failed
[PaintUnlocked] Migration complete. Sentinel written
For a small world (~300 chunks) this takes about a second. For big multi-region worlds it can take several seconds to a minute. After it's done, the world is permanently in the 10-bit format and loads normally from then on.
One caveat
If you were using custom paint packs (PyroPaints, CK Textures, KitsunePaints, etc.) before installing PaintUnlocked, those paints register at different IDs once PaintUnlocked is enabled — vanilla's allocation puts them at 154-255, but PaintUnlocked's GPU atlas requires custom paints to start at ID 512. Migration preserves the chunk storage but can't follow paints to their new IDs, so previously-painted custom-paint blocks will appear unpainted after migration. Just repaint them with the same paint pack — all your packs still work, the paints just have new IDs now. Vanilla paints (IDs 0-153) survive the migration intact.

Existing worlds are now supported
Previously, installing PaintUnlocked required starting a brand new world — existing saves had chunk texture data in vanilla's 48-bit format, and PaintUnlocked needs 64-bit storage to handle paint IDs above 255. This release adds an automatic migration step that runs once when a pre-PaintUnlocked world is loaded for the first time. All chunks on disk are scanned, repacked from the 8-bit-per-face vanilla format to the 10-bit-per-face PaintUnlocked format, and written back. A marker file (`paintunlocked.migrated`) is then written to the save folder so subsequent loads skip the scan.
What you'll see
The first load of an existing world pauses for a moment while the migration runs. Server log shows lines like:
[PaintUnlocked] Migration sentinel NOT found — treating world as legacy 8-bit
[PaintUnlocked] EagerMigrator: starting scan of N chunks
[PaintUnlocked] EagerMigrator: scan complete in Xms. N migrated, 0 failed
[PaintUnlocked] Migration complete. Sentinel written
For a small world (~300 chunks) this takes about a second. For big multi-region worlds it can take several seconds to a minute. After it's done, the world is permanently in the 10-bit format and loads normally from then on.
One caveat
If you were using custom paint packs (PyroPaints, CK Textures, KitsunePaints, etc.) before installing PaintUnlocked, those paints register at different IDs once PaintUnlocked is enabled — vanilla's allocation puts them at 154-255, but PaintUnlocked's GPU atlas requires custom paints to start at ID 512. Migration preserves the chunk storage but can't follow paints to their new IDs, so previously-painted custom-paint blocks will appear unpainted after migration. Just repaint them with the same paint pack — all your packs still work, the paints just have new IDs now. Vanilla paints (IDs 0-153) survive the migration intact.

Diagnostic logging
PaintChangeTrackerPatch logs every paint change (block position, face, old paint ID, new paint ID) to help correlate "random paint shift" reports with specific events. Capped at 5000 entries per session to prevent log bloat.

Diagnostic logging
PaintChangeTrackerPatch logs every paint change (block position, face, old paint ID, new paint ID) to help correlate "random paint shift" reports with specific events. Capped at 5000 entries per session to prevent log bloat.

Diagnostic logging
PaintChangeTrackerPatch logs every paint change (block position, face, old paint ID, new paint ID) to help correlate "random paint shift" reports with specific events. Capped at 5000 entries per session to prevent log bloat.

7DTD v3.0 compatibility (new in 1.4.0)
The 4-layer paint-limit break (255 → 1023) is fully intact in 3.0 — verified, not just recompiled: