The reload after a live apply was a console "load", which in a session either ended it (a guest's
map going away is "your local map changed"), was refused (a guest without map rights), or moved
everyone (a server admin's load changes the server's map; a lobby host's reload sent every guest
through it too).
Now client_tick tells the session first (multiplayer::begin_local_reload) and loads the same map
locally with no multiplayer rule (queue_local_load). The session keeps the reload as travelling in
the same world: a guest keeps telling the host or server it is loading (world_ready, so it does not
time out) and that it is back; a host says it is not in the world for that long, so its guests wait
instead of moving, and nothing is a host map change. A reload refused by the loader is taken back
(cancel_local_reload); one that never starts ends after 20 s; in no state to reload (changing maps,
joining) the mods show at the next level load. The dedicated server already handles a player
reloading on their own.
The first level the game loads from the splash took San Vansterdam, and the startup commands'
"load" then loaded the start map over it. queue_menu_bam now takes the map from the front of
RESKATE_STARTUP_COMMANDS when it is installed and can load (its start point as the console's
"load" picks one), and the startup commands drop that "load" rather than run it again. A map that
cannot load then still leaves the game in San Vansterdam.
AyeZeeBB