Now, for those who have enabled map voting in Sourcemod or otherwise use Sourcemod to set the next map (for example, just using the sm_nextmap command) and want the server to show the CORRECT next map in a chat message when the map ends and the server goes to intermission, here's a plugin I wrote to fix that:
https://forums.alliedmods.net/showthread.php?p=1793152 It intercepts and block's the CS:GO server engine's automatic Next Map: chat message, and prints one from SourceMod to all connected non-bot players with the CORRECT next map instead. (where correct = the map SourceMod thinks will be next, and the map SM is going to change the map to) This doesn't invalidate the information I posted previously (quoted below with a couple of clarifications) - you still need to keep your +mapcyclefile (csgo/mapcycle.txt or the custom one you are defining) and the maps in the map group you're running identical. It's just that with map voting or other SM-initiated changes of the next map, the CS:GO server engine doesn't know SM has changed which map it is going to load next, so it will print the wrong map in that end-of-map chat message. > I won't tell you this is the only correct way to do this or necessarily > the best way, but it does work for me very reliably: > > 1. create a mapcyclefile named whatever you want to call it in your csgo/ > directory (where you'll find one already named mapcycle.txt) - putting the > maps you want to run in that cycle in the order you want them. > > 2. Add a +mapcyclefile <filename> to the server startup command line, > pointing to this file. An explicit path isn't necessary as long as you > put it in the server's csgo/ directory. Note that since the "stock" > mapcycle.txt file will get overwritten by an update, you really WANT to > custom-define mapcyclefile to a different filename so it won't get > overwritten when an update is released. This is especially important for > sourcemod, see below. > > 3. In either your "main" GamesModes_Server.txt file, or if you're > custom-defining the file per-server with -gamemodes_serverfile <filename> > on the server cmdline, you define the map group the server will run > containing EXACTLY the same maps you put in the mapcyclefile in EXACTLY > the same order. > One clarification HERE: ("the *map* that will actually be loaded next", I accidentally said mapcycle previously): > NOTE: the map that will actually be LOADED next is what you define > to be next in the config for that mapgroup, although the server will TELL > you (correct or not) at the end of the current map (ingame chat Next Map: > <whatever> that the next map will be whatever is listed to be next in the > mapcyclefile. I tested this out last weekend. Not trying to ruffle any > feathers or start any arguments about whether mapcyclefile is still > followed by the server engine or not, I'm just telling you what I proved > by testing myself without MM/SM even loaded. > > 4. For sourcemod, it's notion of the mapcycle and thus what it thinks the > next map will be if somebody says "nextmap", etc. comes from > addons/sourcemod/configs/maplists.cfg. I've gotten into the habit of > reconfiguring this file a bit anyway, because I don't like players being > able to vote a map in that I know will empty the server out, etc. So what > I do is this, and it works well for CS:GO as well: > > In maplists.cfg, the default contents set the key named "default" to a > file named mapcycle.txt: > > /** > * Default requests go right to the mapcyclefile. > */ > "default" > { > "target" "mapcyclefile" > //"file" "mapcycle.txt" > } > > Do what I did instead in the example above -- comment the "file" out, and > create a line saying "target" "mapcyclefile" instead. This tells > sourcemod, whatever the server thinks the mapcycle file is (by the > mapcyclefile cvar), use this as the default target. > > Wanting to be sure what it thought the mapcyclefile was, I also > specifically defined it above the entry excerpted above: > > "mapcyclefile" > { > "file" "mymapcycle_se.txt" > } NOTE: If you ever change a server's mapcyclefile cvar to point to a different mapcycle.txt-like file (maybe you run different mapcycles/mapgroups at different times of day) then you probably won't want to hard-code a mapcyclefile "file" definition in maplists.cfg - just skip that -- the re-definition of "default" to "mapcyclefile" 2 snips above is probably enough to fully handle this anyway and will probably accomodate changes of the mapcyclefile server cvar. > > Since everything else in maplists.cfg can be set to use "target" > "default", or already is by default, you can end up with a config that > basically enforces sourcemod and the server (mapcyclefile-using parts of > the server AND the mapchange part that really obeys the mapgroup config) > to all be on the same page. > > enjoy. > > > >> A response from IRC if anyone wants to get any info on this. >> >> <@asherkin> karil, I dont know about the game's, but you can disable >> SourceMod's easily >> <@asherkin> we're hoping to get them synced in the future - SRCDS >> originally didn't have built-in nextmap tracking, and that part of SM >> hasn't changed since the ep1 days, so they conflict more and more as >> time >> goes o >> _______________________________________________ >> Csgo_servers mailing list >> Csgo_servers@list.valvesoftware.com >> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers > > > _______________________________________________ > Csgo_servers mailing list > Csgo_servers@list.valvesoftware.com > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers > _______________________________________________ Csgo_servers mailing list Csgo_servers@list.valvesoftware.com https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers
