When a game starts, the Mutator (XMaps.Control) hijacks the map list type used by the type of game you're playing (specifically DeathMatchPlus(Level.Game). MapListType) in the call to Mutator.PostBeginPlay(). The Mutator sets up the map list by calling Initialise() during this function; each of XMaps' map list classes then override MapList.GetNextMap() to achieve extended list support, random cycling or random map selection as necessary.

So, if you're playing a mod that overrides GetNextMap() from the standard MapList class, it won't be called. It is, however, extremely unlikely that a mod would need to override GetNextMap().

If you're putting together a mod and want to support XMaps, it's most likely that it will work transparently - if you don't override GetNextMap(), XMaps will do it's job alongside your mod. If you do need to override GetNextMap(), you may wish to export the XMaps source and add your enhancements to the GetNextMap() functions defined in each of the descendants of MapList there. If you do, please check the Legal Bit.

To enable game switching, the XMaps mutator (XMaps.XMapsControl) jumps in during the Mutator.HandleEndGame() call and sets DeathMatchPlus(Level.Game).bDontRestart true so that it can handle the switch. This means that any Mutator expecting to control restarts won't get control if XMaps is loaded first ... similarly, if XMaps is loaded after a Mutator that traps the restart, it won't be able to switch games.

Version 203 was the first release of XMaps to support game switching - if you find there are any problems with XMaps 'co-operating' with another Mutator - or vice-versa - let me know and I'll see if there's anything I can do about it.

Once thing I noticed during my testing, when XMaps was running on a dedicated server, was that the game switching didn't work exactly as I expected if a software firewall was preventing UT from accepting incoming connections. Once the firewall was configured to let UT act as a server, everything worked fine ... if you get any similar problems, you may want to try this out.

There was also a problem in versions earlier than 206, where a dedicated server INI file may be missing a MutatorList entry in a [UTMenu.UTStartGameCW] section - or even missing the section altogether. In this case, if XMaps was loaded via a command-line but then switched game types, it wouldn't reload itself (XMaps uses the MutatorList key to set up the list of Mutators that should be loaded).

As of version 206, XMaps automatically adds itself to the game-start command to make sure it re-loads if it was loaded by the server starter.

Beginning with XMaps 201, XMaps matches game types by checking the name of the game class (specifically DeathMatchPlus(Level.Game).Class). So, Extended and Favourites lists for the mods XMaps used to support by name can only be upgraded if the mod's game class is recognised by XMaps. Specifically, map lists for the following mod versions will be upgraded automatically when upgrading XMaps from versions earlier than 201:

Conquest 1.21 (game type 'Conquest121.Conquest')
DTF 0.1 (game type 'DominateTheFlagV01.DTFGame')
Flag Domination (game type 'FlagDom.FDGame')

Any Strike Force lists will automatically be removed by XMaps during the upgrade.

Beginning with XMaps 201, XMaps matches game types by checking the name of the game class (specifically DeathMatchPlus(Level.Game).Class). The value is used determine which Extended and/or Favourites list to use in the game.

When Map Selection is set to one of the Extended options, and no Extended map list exists for the game type, XMaps searches for an Extended List that is configured for the same map prefix as the game type that's playing and uses that list.

When XMaps Selection is set to Random maps, XMaps uses the map prefix set in the Favourites page of the Game Options window to determine which types of map to load. If a prefix hasn't been set by the user, then XMaps uses the prefix specified by the game.

If 'Use Favourites' is on, then the Favourites list for the game type that's playing is used in addition to the Map Selection, if one exists.

Beginning with XMaps 225, XMaps supports the addition of named bots via the HUD menu. This is possible because of the code in the original ChallengeBotInfo class.

Prior to version 413 of UnrealTournament, there was a problem with the selection of bots that meant only the first sixteen of the thirty-two available were ever selected by UT. This problem was initially addressed by a mutator, Bot32, but was then fixed in UT in version 413. Unfortunately, Bot32 didn't support the use of the DesiredName variable when it came to selecting bots, so if the Bot32 mutator is loaded, XMaps won't be able to add bots by name.

The solution is to make sure you're running UT 413 or later, and to remove Bot32 from your installation. If you're running UT 413 or later, the Bot32 mutator simply isn't necessary.