Random Playerstart Locations mutator for UT2004
Compatibility: tested with UT2004 build 3369
This mutator enables player spawns at any navigation node (admin-selectable, by node type) throughout a map level.
In team games, players will spawn "on their team's side" of the map, unless ini option specifies that 'neutral areas' of the map are acceptable spawn locations.
Works with team-based gametypes as well as with Deathmatch.
Works with any map (DM / CTF/ VCTF / AS / INV / ONS / BR / DOM / *etc* ) but before enabling it for AS / ONS, think carefully in selecting the options.
===================
Reasons a "Random PlayerStart Locations" mutator is needed, and the benefits it provides:
-- thwarts the practice of spawn camping (staking out spawn points and picking off emerging players)
-- adds variety, via a degree of unpredictability, to the gameplay. (Most DM maps contain fewer than 20 hardcoded "player spawn points". Many maps have only 6 or 8!)
-- a number of ONS- and AS- native maps have been "converted" (forced, via UCL... or renamed, WITHOUT additional editing) into DM use. A characteristic of these maps, regardless of their large (huge) terrain, is that all playerStart nodes are typically clumped/grouped into 2 small areas of the map.
=======================
Don't care to RTFM? That's okay...
Although the mutator contains several configurable options, it works fine even you don't bother to change any of them.
All options are configurable via the "ConfigureMutators" GUI, and a description plus helptext/suggestion is displayed for each.
Here's a brief runthrough:
In addition to existing playerstart nodes (and/or triggeredplayerstart nodes), you can separately elect to utilize assaultpath nodes, jumpspots, roadpath nodes, inventoryspot nodes (pickups), and generic (apple) nodes as valid PlayerStart locations.
During team-based gametypes (using maps designed for team games) you can select whether or not nodes in 'neutral' areas of the map will be valid as randomly-selected start locations.
The "MinPlayerDistance" setting (default=1000) steers how far away from other players the mutator should attempt to spawn a player. For reference, in the game a player stands about 90uu tall. In case you choose a low value... and its a match in a small map with a lot of players, the
"MaxNumPlacementAttempts" value tells the mutator when to "bail" during a given respawn and defer to the game engine's native behavior in choosing a spawn location. At the default value (100), you should not expect to see any delay. At 1000, in a small crowded arena, you might notice a delay... identical to what you'd notice with the native code.
TRAINER MODE:
The "bDisplayPathnodeIcons" isn't intended for everyday use.
It renders the selected types of node icons visible in-game ( as they are via the editor via View}Paths )
=======================
For local installation, place the following in your ~UT2004\System directory:
RPS.ini
RPS.u
RPS.int
RPS.ucl
For server installation: also add a ServerPackages=RPS line to your ini
Note: the provided ini contains options enabled as suggested for DM, TeamDM, BR, CTF gametypes.
For other gametypes, use your discretion in choosing suitable options.
=======================
Additional notes:
The mutator doesn't pick the FARTHEST point from other players. It ignores any nodes which are too close other players each time it builds the spawnpoint picklist. During team-based gameplay (regardless of the specifics of the map in use) it ignores any nodes which are too close to opposing team players each time it builds the spawnpoint picklist... and chooses a node at random from those remaining in the picklist.
Although 4-way TeamDM competitions exist, they are rare. This mutator only supports two-team gameplay.
With the RPS mutator active, a lot more potential locations for player spawns become available, but the waiting-to-spawn players scenario can occurr with, or without, the mutator running. One reason for this is that, upon spawning, bots may immediately go into a 'stakeout' routine (crouching atop the spawn point). Neither the native code, nor the mutator code, can place another player until the node becomes unoccupied (er, until a 44uu collision radius is clear, in which to place the new spawn)... else you'd wind up with the first-spawned player 'getting telefragged'.
FileFront download:
http://www.filefront.com/17286543/Ra...ts_mutator.zip
Compatibility: tested with UT2004 build 3369
This mutator enables player spawns at any navigation node (admin-selectable, by node type) throughout a map level.
In team games, players will spawn "on their team's side" of the map, unless ini option specifies that 'neutral areas' of the map are acceptable spawn locations.
Works with team-based gametypes as well as with Deathmatch.
Works with any map (DM / CTF/ VCTF / AS / INV / ONS / BR / DOM / *etc* ) but before enabling it for AS / ONS, think carefully in selecting the options.
===================
Reasons a "Random PlayerStart Locations" mutator is needed, and the benefits it provides:
-- thwarts the practice of spawn camping (staking out spawn points and picking off emerging players)
-- adds variety, via a degree of unpredictability, to the gameplay. (Most DM maps contain fewer than 20 hardcoded "player spawn points". Many maps have only 6 or 8!)
-- a number of ONS- and AS- native maps have been "converted" (forced, via UCL... or renamed, WITHOUT additional editing) into DM use. A characteristic of these maps, regardless of their large (huge) terrain, is that all playerStart nodes are typically clumped/grouped into 2 small areas of the map.
=======================
Don't care to RTFM? That's okay...
Although the mutator contains several configurable options, it works fine even you don't bother to change any of them.
All options are configurable via the "ConfigureMutators" GUI, and a description plus helptext/suggestion is displayed for each.
Here's a brief runthrough:
In addition to existing playerstart nodes (and/or triggeredplayerstart nodes), you can separately elect to utilize assaultpath nodes, jumpspots, roadpath nodes, inventoryspot nodes (pickups), and generic (apple) nodes as valid PlayerStart locations.
During team-based gametypes (using maps designed for team games) you can select whether or not nodes in 'neutral' areas of the map will be valid as randomly-selected start locations.
The "MinPlayerDistance" setting (default=1000) steers how far away from other players the mutator should attempt to spawn a player. For reference, in the game a player stands about 90uu tall. In case you choose a low value... and its a match in a small map with a lot of players, the
"MaxNumPlacementAttempts" value tells the mutator when to "bail" during a given respawn and defer to the game engine's native behavior in choosing a spawn location. At the default value (100), you should not expect to see any delay. At 1000, in a small crowded arena, you might notice a delay... identical to what you'd notice with the native code.
TRAINER MODE:
The "bDisplayPathnodeIcons" isn't intended for everyday use.
It renders the selected types of node icons visible in-game ( as they are via the editor via View}Paths )
=======================
For local installation, place the following in your ~UT2004\System directory:
RPS.ini
RPS.u
RPS.int
RPS.ucl
For server installation: also add a ServerPackages=RPS line to your ini
Note: the provided ini contains options enabled as suggested for DM, TeamDM, BR, CTF gametypes.
For other gametypes, use your discretion in choosing suitable options.
=======================
Additional notes:
The mutator doesn't pick the FARTHEST point from other players. It ignores any nodes which are too close other players each time it builds the spawnpoint picklist. During team-based gameplay (regardless of the specifics of the map in use) it ignores any nodes which are too close to opposing team players each time it builds the spawnpoint picklist... and chooses a node at random from those remaining in the picklist.
Although 4-way TeamDM competitions exist, they are rare. This mutator only supports two-team gameplay.
With the RPS mutator active, a lot more potential locations for player spawns become available, but the waiting-to-spawn players scenario can occurr with, or without, the mutator running. One reason for this is that, upon spawning, bots may immediately go into a 'stakeout' routine (crouching atop the spawn point). Neither the native code, nor the mutator code, can place another player until the node becomes unoccupied (er, until a 44uu collision radius is clear, in which to place the new spawn)... else you'd wind up with the first-spawned player 'getting telefragged'.
FileFront download:
http://www.filefront.com/17286543/Ra...ts_mutator.zip
Comment