Removes now-unreachable #ifdef _WIN32 branches across Common/ and the three
server binaries (all builds are Linux-only), deletes the entirely unused
SEH exception-handling shim and an orphaned vendored MySQL client header.
Enables LTO and -march=x86-64-v2 in Release builds for a small free perf win.
Also seeds a default GM account (gmadmin/changeme) via
database sql files/gm_account.sql so a fresh deploy has something to log
into the web admin panel with, switches the MariaDB data directory from a
Docker named volume to a host bind mount for visibility/backup, and expands
the README with a fuller Docker deployment walkthrough.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Docker SDK drives login/char/worldserver containers via docker.sock (mounted
read-only into webadmin); live logs stream over SSE with nginx buffering
disabled so lines arrive in real time. Broadcast/kick go through a new
admin_queue DB table that the world server polls every ~2s in its existing
WorldProcess tick loop, avoiding a second IPC channel to the game server.
GetNewDrop's weighted item-index selection used a do-while that
increments before its first RunningTotal check, so index 0 (the first
item slot in every drop table) could never be selected -- for the 51
drop tables that only populate item slot 1 (all others zero), this
silently discarded every roll ("item at itemindex does not exist"),
so those mobs/maps never dropped an item at all. Switch to a pre-check
while loop so index 0 is reachable.
Also: battle.cpp's kill-drop loop runs GetDrop()/AddDrop() exactly
Stats->itemdroprate + Config.DROP_RATE times, not as a probability --
with the shipped drop_rate=2 every kill produced two independently
rolled drops (hence always-doubled Zuly boxes for characters with no
item-drop-rate gear). Default drop_rate to 1 so a kill yields one
roll by default; gear/GM commands that raise itemdroprate still grant
extra rolls as designed.
Also default dropdelay to 0: the killed-monster's loot became visible
to clients only after Config.DropDelay (1s) *plus* the next
VisualDelay tick (200ms), giving a ~1.2s lag before drops appeared.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
accounts.lastlogin/logtime had no defaults and were NOT NULL, but the
auto-create-account INSERT never set them, so new accounts failed
under MariaDB strict mode (silently accepted under the old MySQL
5.0 target). Insert explicit empty/zero values and give lastlogin a
default; also widen it to varchar(32) to match the runtime.sql fix
already applied to the starttime column.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- runtime.sql: widen starttime to varchar(32). ctime() produces 25 chars;
MariaDB's default strict mode rejects the 20-char column instead of
silently truncating like the original MySQL 5.0 target did.
- SocketServer.cpp/SocketBase.cpp: the accept-loop's select() used `maxfd`
set only from `sock`, never updated for the ISC sockets (sckISC/sckISCII).
Any fd beyond nfds is left however FD_SET last set it, since select()
never examines it -- so those bits stayed permanently "set", and the
server treated them as always-ready. For the login server specifically
this was fatal: its sckISC is created but never listen()'d (the login
server has no inbound ISC use), so accept() on it returned EINVAL on
every single loop iteration, spinning the login server's CPU and
spamming the log without ever getting to the real client-facing accept()
in a timely way. Root-caused with a real client connecting for the first
time (this path was never exercised end-to-end before). Fixed by
including the ISC sockets in maxfd and skipping the ISC accept branch
entirely for the login server. Also initialize sckISC/sckISCII to
INVALID_SOCKET in the constructor -- they were previously left
uninitialized for server types that never touch them.
- tools/rose_login_test.cpp: protocol-level login smoke test. Links
directly against Src/Common/rosecrypt.cpp (the server's own encryption
code) rather than reimplementing the crypto, so there's no risk of a
second, subtly-wrong implementation. Documents the wire handshake
(0x703 encryption request -> 0x7FF -> 0x708 login, password[32]+username[16]
payload) for future reference.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
