COOP SUITEis a collection of mutators and an extensible framework. The mutators focus on providing modern conveniences for coop and the framework provides modders with a set of powerful tools that can be used to create or improve coop support of existing maps/campaigns by means of a mutator.

:MUTATORS:Coop BeaconThis creates a new HUD element for all players. Depending on how visible other players are, you will see the player's name, their health, and/or an icon.Player names are always displayed for players located (obstructed or not) in the field of view. Player health is only displayed if the player is in line-of-sight and somewhat close. Player icons are only displayed if the player is far away or not in line-of-sight (behind an object or behind you).By default the color of each player's beacon elements change dynamically to represent their current health. Custom color is client-side configurable (what the player sees, not how other players see them) but will disable the dynamic coloring system. The display of player names and health are also client-side configurable.

I Want You Inside MeThis disables (only) player collision, allowing players to pass through, for the following actors.Other players. Nali. Cows. Rabbits.Player, Nali, and wildlife collision is configurable via CoopSuite.ini.

Scale EnemiesThis mutator scales enemies based on difficulty level and player count. The movement speed and melee damage of enemies is increased based on the difficulty level. Enemy health is increased based on the number of players. Buffs are moderate and are only designed to offset the multiplicative advantage players receive in coop.The scaling of damage and health is configurable in CoopSuite.ini.

Spawn At PlayerThis is a new player spawning system in which each player serves as a PlayerStart. If a player dies, they may respawn near or where they died, or at another player's location. It includes failsafes to avoid spawning players in bad locations (lava, underwater, pits) or leaving an empty server with bad spawns. It also includes a system to equip new or respawning players with an inventory based on what is found in the map. Spawning players with weapons and how much ammo are configurable in CoopSute.ini. Since it may be resource consuming, checking map decorations (to decide what to give players) is also configurable.

Coop Weapon RespawnerFor TVCoop based games (ONP, Xidia, 7B, etc). Modifies respawn times of all weapons meant to respawn. Includes a more aggressive search by checking at intervals to catch weapons that are either spawned in later or may have been missed at startup. Respawn time, Aggressive Mode, and Interval is configurable in CoopSuite.ini.

:EXTENSIBLE FRAMEWORK:https://www.youtube.com/watch?v=3fpBsd4iPEoTypically, adding or improving coop support of a map or campaign would require directly modifying said maps and re-releasing them. This may be difficult if the map is late in its lifetime (propagation of the improved version will be slow) or if you are not the original author (not generally a good practice to modify and release someone else's work). The Coop Suite framework allows you to indirectly modify maps via mutator, completely avoiding the need to re-release maps. The framework is a mutator collection of functions designed to modify, remove, or create actors. Subclassed, you could use these functions to fix a multitude of common grievances. Skip incompatible cutscenes, create teleporters for players if an event makes an area unpassable, modify teleporters to skip credits maps, etc... What's more is as a mutator, it not only avoids direct modification of the map(s), it also avoids authoritative control. Several versions may be made for the same map/campaign without any one imposing authority over another (as direct map modifications do). The relatively small size and non-destructive modification of the source material allows the decision of what version to use to be a more personal one since it bears no consequence to the community.

Working on an update that I'll release next week. The Xidia maps have required me to do some things in the extension script to fix issues caused by the coop measures built into the pack. I believe the functions I've written into the extension could be of use to others so I'll be migrating them into the core framework in the next version along with a few other updates.

Planned features for CS6Beta:* Spawnable PlayerStart class. It normally isn't so I created one that can be used to spawn additional (or replacement) PlayerStarts.* PlayerStart disabling function. Maps like Xidia that have built in graduated (assault-style) player starts defeat the usefulness of CoopSuite weapon caches and checkpoints for players. I know they're well intended but they put players at a disadvantage when they die because they're then expected to kill the thing that killed them when they had weapons, without any weapons. This can be used to permanently disable the original PlayerStarts before spawning new ones to serve as a replacement. It can also be used if the original PlayerStarts are just in a bad place.* Graduated PlayerStarts. Similar to Checkpoints except instead of teleporting to them, you spawn there. Personally I don't think this is as useful as Checkpoints since those allow players to collect weapons before teleporting to them, I'm making it an option users can choose. This might be a better solution for admins that wanted to have a checkpoint system but weren't interested in providing weapon caches for players. In that case, since there's no weapon caches at the starting area, there's no point wasting time spawning players there.* Preemptive crash fixes/backward compatibility. I've noticed there could be (untested) a problem if the extension author fails to specify their checkpoint and weapon cache classes in their main mutator. If I add another class type (graduated player spawns) it could also break extensions written for previous versions. I'll be fixing this to prevent either of those two problems.

Removed old downloads. 5 was obsolete as I've been running 6 on my server the last three weeks while working on 7 the last two, which should be ready for testing this weekend and release after that. Updated the flavor text and included the most recent changelog in the first post.

While the design goals remain the same, several changes/additions have been made over the past week that greatly affect the original design implementation of Coop Suite. With the addition of a new spawning system, the method of using a checkpoint system as a primary means of transporting players is obsolete, as is the weapon cache system for providing weapons for players. While their usefulness is now greatly reduced, these systems will remain in place to fill in other gaps of the coop experience.

New Features:CoopSuite.iniContains all server and client-side configurable options.

Spawn at PlayerNew spawning system for coop. If there are any players on the server, all original PlayerStarts are disabled, removing them as candidates to spawn at. A viable PlayerStart is attached to each player, making all players potential spawn points for other players (and themselves). If a player dies, their attached PlayerStart is temporarily moved to the closest PathNode (in case they fell into some destructive area or drowned, anywhere you shouldn't spawn). If a PathNode can't be found, the original PlayerStarts are re-enabled until the player respawns. If a player leaves the server, their attached PlayerStart is destroyed. If all players leave the server, the original PlayerStarts are re-enabled to provide a valid PlayerStart for later joining players.

Config option bSpawnWithWeapons (default True). If enabled, it will add weapons to the inventory of players with no more than a dispersion pistol. The map is scanned for ammo and weapons, which are then rated on a cumulative scale based on the typical order (in which weapons appear in campaigns). Players will receive weapons, starting with the highest tier the search found, and everything below. This means early maps with only clips and stinger ammo will provide the player with a stinger and automag, while a small, late level where the only pickup might be single rifle round, will provide the player will all weapons. This system is designed to provide players joining mid map/campaign or players that have just died, with weapons that under normal circumstances, they are expected to have, but would not otherwise have any means of obtaining. It does not affect a player's inventory during servertravel (map changes).

todo:Currently the spawning system functions really well. Unfortunately the way in which it's designed severely disrupts game balance in favor of the player by removing nearly every risk imposed by death. I've been brainstorming several ideas like adding a respawn delay or requiring the player to have at least 1 kill since they spawned to be able to respawn at player. My favorite so far is requiring the enemy that killed the player to be killed before they can respawn since this promotes teammwork in coop. We'll see.

Scale EnemiesA new, modern-ish, enemy scaling system to augment the existing difficulty system of the game.Let's face it. Unreal, by large, is balanced for single player. Even though filters exist to switch actors depending on how the game is played, they've very rarely ever used and if so, even more rarely used to any significant effect. Even the difficulty scaling already performed by the game is balanced for single player. Once you start adding more players to the game, the challenge drops dramatically. Enemy scaling compensates by increasing the challenge based on both the difficulty level and number of players in the game.Enemy scaling has two configurable features.bEnableDamageScaling (default True) enables a system the scales enemy damage and movement/reaction speed based on the set difficulty of the game. For every difficulty level above easy, damage is increased by 25% and speed by 16.6%.

bEnableHealthScaling (default True). This enables scaling of enemy health based on the current number of players in the game. If there is more than one player, health is increased by the HealthMultiplier (configurable, default 1.5) for every player in the game. With two players, health is increased 33%. With six it goes up by 300%!percentage scale = ((PlayerCount/HealthMultiplier)-1)*100)Scaling works both ways. It goes up as players join, and if any leave, down to adjust to the number of remaining players. While there is no upper limit, enemy health will never go below its original amount. As more players enter the game it will become more important to work together, cooperatively, in a coop game that now behaves like one.

todo:Enemy fire projectiles and enemies spawned via CreatureFactories are currently giving me problems. Currently scaling for these is disabled in live versions of CoopSuite but the plan is to include them later.

Existing Feature Updates:Coop BeaconBehavior changes and feature additions.- Player names are now always displayed for all players, obstructed or not, within the field of view.- Player health will now display for any close, non-obstructed players within the filed of view.- Player beacons will only display on players that are very far away, obstructed at any distance, or outside the field of view.- Coop Beacon HUD elements now have an auto-color system that changes color based on the player's health.- Client-side configurable options to show/hide player names and player health.- Client-side configurable option to disable auto-color and use a custom color.

Future Plans:Spawn-at-Players was the original plan I had for improving the biggest problems I had with coop but when I started CoopSuite I didn't have the experience to create a system like that which is how Checkpoints came about. SAP is better than Checkpoints in almost every way, with the biggest advantage being that it isn't dependent on writing support for every map, or any map, for it to function. This kind of makes Checkpoints and Weapon Caches obsolete as transportation and inventory systems. While I have considered removing them entirely, I do still see some use for them, and for CoopSuite's utility as a framework. Take for example, Xidia. Granted the bulk of its CoopSuite extension is Checkpoint and Weapon Cache data, there are a few instances where it uses different functions of the framework to fix issues some maps have in coop. Even if checkpoints and weapon cache systems are removed, there will still be a need to fix areas that become impossible to re-enter, triggers that wont trigger, or final exit teleporters that don't send players back to the beginning. Checkpoints and Weapon Caches will not be in any versions of Coop Suite going forward but under a different name, their ability to add and alter specific actors in specific maps for the purpose of fixing a broken coop experience will remain.

As an example of what is possible to do using Coop Suite's framework, I'm making a 7Bullets extension.I've only gotten so far as to making doors solid (so coop players cant just walk through them) and re-enabling access to areas previously inaccessible in coop only. This is all done without altering the map and as an example of how easy making an extension is, here is the uscript so far.Main mutator. Class loaded in command line.

Example of a CoopSuite extension in action, before and after.https://www.youtube.com/watch?v=JogedbytRWsThe lights/sounds (not part of the original game) and re-enabling the Scarred One (7B specific pawn) required some additional programming but just getting the scene working in coop required very little. CoopSuite has all the functions so all an extension author needs to do is call the function and give it any values needed as a default property. Minus the custom lights/sound/SO code, here is how simple it is to get this scene working for coop with a CoopSuite extension.

Updated the OP to be more representative of the current state of CoopSuite.

After a couple more weeks testing and having some AFK'rs and some maps with bad pathing highlight a couple flaws with Spawn-at-Player, I've written a few more conditions for how spawns are handled.

Players that haven't moved in a [configurable] time are marked as AFK for the purpose of disabling them as a PlayerStart. By removing AFK players as a potential PlayerStart, it prevents active players that have died from being pulled back to the AFK player's location (which could be way behind) to respawn. To avoid disabling all viable spawns (bad), this only happens if there is at least one other active PlayerStart. If for some reason players leave a server with one or more AFK'rs, their PlayerStarts are re-enabled so others will be able to join.

I've also modified the way a dead player's PlayerStart behaves so that if a pathnode cannot be found, it is more likely to respawn the player at another player's location instead of at the beginning of the map. When a player dies, their PlayerStart moves to the closest Pathnode. This still has the highest priority since (if the map is decently pathed) it will safely spawn the player closest to where they died. If no Pathnodes could be found (2048 radius), the original PlayerStarts are re-enabled, creating the possibility for the player to respawn back at the beginning. Now, if a pathnode can't be found a check is made for other players and if they are alive and not AFK the dead player will always respawn at a live player's location. This should greatly reduce the number of times players respawn at the beginning.

As for spawning in not yet reached portions of maps, I can't (won't) fix bad pathing.

Added another mut for tvcoop and derived games (ONP, Xidia, etc..). Based on Kea's CoopWeapRespawner for 7Bullets, I made one that checks for all weapons (not just UT) that have a respawn time greater the configurable amount. Since the original only checks in PostBeginPlay, it misses weapons like the supershock that are spawned for the 7B Titan arena battle. There (at least in ONP and 7B) also seems to be a bug that makes it unreliable, missing several placed weapons. I suspect the engine hasn't finished compiling the actor list when entering PBP causing placed weapons to be missing on several occasions. To remedy this I've added a secondary set of checks that can be enabled and set to run at a configurable interval. This doesn't work in Coopgame2 though as ithe game type is actually written to override weapon respawn times at all times...

Created a subclass of CoopGame2 to expose the respawntime of weapons through an ini. Not really ideal but when respawntime is hardcoded into the original gametype (preventing changes via mutator) there's not much else you can do. Between this and the respawner mut, out-of-the-box functionality should be covered for maps using the default coop gametype, coopgame2, TVCoop and derivatives of TVCoop. Maps with custom gametypes extended from Coopgame2 (DejaVu) should be easy enough to support with an extension.

Modified another function of Coopgame2/TVCoop gametype derivatives to remove the rule preventing players from spawning at Playerstarts in water zones. Since Spawn-at-players attaches playerstarts to players, this creates a major issue where the only valid playerstarts may be underwater, preventing players from respawning or entering the game. I'm really not keen on making a gametype required to use a mutator so I'll have to look into what I can do to move this functionality into the mut itself.

The only remaining bug with spawning is in a game with multiple players, some players after servertravel will spawn in completely wrong locations. I think this is an effect of the position update frequency of the attached playerstarts which are on a 1 second delay (to keep net use low). Normally players enter a game at vector 0,0,0 before being move to a playerstart to spawn. They're getting an attached playerstart while this happens, which due to their update frequency, leaves a 1 second window for any following players to actually spawn at vector 0,0,0. I can probably solve this by spawning each player's attached playerstart at the location of an original playerstart instead of at the owner player's location.

The only other plans I have for spawning is the make the spawn with weapons system more robust so that it can be modified to fit different campaigns via ini rather than having to write a new one for each (different weaps/ammo for Unreal, xidia, onp, etc...). I had originally planned to add items to this but the respawnable pickups via the gametype makes this redundant. Speaking of, respawning items are going to be made to function as coop-weapon-mode only. My original goal for this was to fix the pickup system and placement that was obviously only balanced for single player. Being able to camp on or refill pickups is a little too much though so I'm looking at it being a once per spawn thing.