Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature currently requires accessing the site using the built-in Safari browser.
Please make sure you are familiar with the forum rules. You can find them here: https://forums.tripwireinteractive.com/index.php?threads/forum-rules.2334636/
Major revamp of the ZedList replacement system. Now includes global Squad definitions, a custom Monster Collection creation system that can load from the .ini file, a VASTLY improved functionality for Invasion game mode which includes just about everything you could want. This new system automatically generates wave masks on the fly during map changes, and can support different wave sets by difficulty, game length, map, and more.
New Features Guide is updated with new information on the ZedList system and its use.
Fixes
Moved logging functions for debugging the ZedList system to SRZedList_Debug, so they won't clutter your logs unless you enable them.
Fixed a few bugs and optimized a couple of functions for speed in execution.
Delegate assignment now occurs client-side, fixing a bug with "no perks" and "can't hold weapons"
Fixed an error with the Monster Collection generator which would occur with more than 9 new Zeds (New maximum is unlimited)
Fixed the issue with text messages showing player's names twice in the HUD
Debugging/Testing
Please change your ZombieListClass variable in ServerPerksX.ini to "ServerPerksXMut.SRZombieList_Debug" if you encounter any bugs, and send me the log files afterwards. I'll fix things as soon as possible.
While I try to make these releases as bug-free as possible, I can only test so much on my own. Thanks in advance for any log files or bug reports!
ServerPerksX v1.1 Changelog
Spoiler!
New Features
KFPCServ and SRHumanPawn now utilize delegate function assignments to dynamically call correct superclass functions for the current game mode. What this means to you is that you can now extend ServerPerksX's playercontroller (KFPCServ) and pawn (SRHumanPawn) directly, with any code which was previously compliant with ServerPerks, and achieve full functionality and Story Mode support, with no new code.
This new system does not affect the HUD, which will be coming in the next version. Reworking the HUD will take more time, however, since memory management issues with assets being loaded are significant here. The current in-development version, though working, is not reasonably efficient yet (and eats up too much memory to be considered worthwhile). If you do not use a custom HUD, this will not affect you. If you DO use a custom HUD, you'll have to get by with using SRKillingFloorHUD_Story for now.
Fixes
Optimization to the ZedList replacement system making it load faster.
Fixed a bug in the ZedList causing replacement problems in Invasion mode.
The default Field Medic perk uses medic nades now.
Marco has given his permission for this mutator.
As the StoryGame mode is obviously new and heavily logged, so too is this mutator. I'll try to keep it updated as much as possible until StoryMode is relatively stable. Let me know if you encounter any bugs, and please send me your KillingFloor.log file if you do! This is especially helpful while StoryMode is still so heavily logged.
Thanks.
ServerPerksX New Features
StoryGame (Objective) Mode Support
Dynamic Server-Side MonsterCollection selection AND creation
Support for custom game modes through dynamic PlayerController/HUD specification
Dynamic Server-Side Zed Replacement System for even more customized Story Maps
Dynamic Map/Global zed wave generator for specifying which zeds spawn on which wave on which map
Old Features
See this thread. This mutator merely enhances the functionality of Marco's original mutator.
Installation and Use Installation
Simply extract the files into your KillingFloor/System directory
This mutator does not overwrite any of the original ServerPerks files, and may be installed simultaneously
Use
This mutator may be considered a replacement for ServerPerks, and retains all of the original functionality of ServerPerks while adding new features.
ServerPerksX is a completely self-contained mutator and does not extend the original ServerPerks files. If you wish to extend ServerPerksX in your own mod, simply subclass ServerPerksX instead of ServerPerks and recompile. Handily, all of the class definitions are the same. For instance, let us assume that you had previously subclassed KFPCServ in your own mod. With ServerPerksX, all you'll need to do for a successful compile is change EditPackages=ServerPerks to EditPackages=ServerPerksX in your KillingFloor.ini file, and recompile your mod.
ServerPerksX cannot be loaded as an active mod at the same time as ServerPerks, this will cause conflicts because ServerPerksX uses the same class definitions. However, you may have both mutators installed at the same time if you'd like to test their differences.
If it worked with ServerPerks, it will work with ServerPerksX.
If it didn't work with ServerPerks, it probably won't work with ServerPerksX, but I'm willing to fix any bugs from the original ServerPerks anyone brings to my attention.
New Features Guide New Variables in ServerPerksX.ini
MonstersCollection - Somewhat self-explanatory. Leave this blank to let Killing Floor select its own MonsterCollection, otherwise define the classname thusly:
MonstersCollectionType="KFMod.KFMonstersCollection"
This definition will become the Default monstercollection, which can be overridden and modified dynamically with the ZedList system, explained further below.
ZombieListClass - This defines the subclass of SRZombieList which will be used to load customized spawn waves/replacements. You can freely subclass SRZombieList to any server-side package, whether sent to clients or not, if you wish to offload its functionality. If you define a ZombieList in your own mod, your package will be imported dynamically at runtime with no need of a mutator. ServerPerksXMut.SRZombieList is defined by default.
GameTypeAssociates - It's unlikely you'll want to dick with these unless you're making a new game mode, have your own mod which uses GameType-specific HUDs or PlayerControllers, or just want to swap out what HUD/PlayerController is used without compiling ****. In any case, feel free to modify these. In a defined Associate, GameType specifies the associated GameType for the replacement, ClassType specifies the type of class to be replaced (only "HUD" and "PlayerController" are currently supported), ClassName specifies the path to the class used to replace these default classes. Again, any classes defined here will have their packages automatically loaded at runtime without the need of a mutator.
Explaining the ZedList replacement system
Essentially, this sub-system allows server-admins to specify what zeds they want to spawn on which maps without compiling any code, and merely modifying values in the ServerPerksX.ini file. The StoryMode squad system is quite sophisticated compared to older KF code (That Alex Quick guy is pretty good!), so messing with any of it directly could potentially be a nightmare for modders. And because the new spawning system is offloaded to the level designers almost entirely, it compounds the issue of trying to fiddle with the code in order to get the results you want. My hope is that this mutator will stop the almost certain problem of incompatibility between mods which all try to stick their fingers into that pie. This sub-system is modular, and allows modders to make their own replacement systems subclassing ServerPerksXMut.SRZombieList (which is the default, included module)
As of the v1.3 release of ServerPerksX, the ZedList system has been widely expanded for Invasion mode, allowing dynamic, map/difficulty/gamelength based modifications of waves without the need to mess with wavemasks, which the ZedList now generates on the fly every time a map loads.
SRZombieList
A moderately simple module for modifying spawn waves in both game modes. This is the default mode, and intends to be as capable as possible for the majority of people's needs.
Custom Monster Collection
ServerPerksX can now dynamically create and load in a Monster Collection at runtime, which allows you, the modder, to specify new or replacement monsters by simply changing a line in the ServerPerksX.ini file. Monster Collections are the basic list of zombies used by both game modes to spawn waves of zeds in the game, and any modifications to this will be global. The ServerPerksX Monster Collection replacement module lets you selectively specify replacements, or completely override the default MonsterCollectionClass. Default values in ServerPerksX.ini represent the vanilla KFMod version of the Monster Collection, with all the classic zeds.
Spoiler!
In order to customize your server's loadout of zombies, you have a great deal of options available. First, if you've already created your own Monster Collection, you can load it as the default collection by specifying it in the MonsterCollectionClass variable of the .ini file. Or, if you'd prefer, you can leave this variable definition empty and let Killing Floor load its own Monster Collection (handy if you want events, such as the sideshow/halloween zeds to affect the later portions).
Next, you can modify this default Monster Collection, whether defined by you or left up to Killing Floor, by setting the bCustomMonsterCollection under [ServerPerksX.SRZombieList] header to true. By doing this, you will activate the following variables:
Monster - An array of Monsters which can all be defined
Letter - The ID of the Zed, cap sensitive! Must be a single character, but can be any valid unicode character. Best stick with letters, unless you have over 26 Zeds on your server. A, B, C, D, E, F, G, H, and I are associated with internally-recognized Zeds, represented correctly by their default properties in the .ini file.
MClass - The location of the class associated with this Zed. The default .ini file configuration uses the classic Killing Floor Zeds.
BossMonster - The class of the patriarch (or patriarch replacement). The default value represents the classic Patriarch.
FallbackMonster - The class of the zed that will be spawned when no others can be, due to size restrictions in a small spawn area most likely. Stalkers are a good choice for this.
By removing the values for any of these, you will allow the default Monster Collection to take precedence. You can also freely add new Monster definitions without affecting the defaults loaded in by the default Monster Collection. If, however, you define a Monster with any of the letters A-I, it will override the default monster held there.
For instance, let us assume that the Summer Sideshow event is taking place and while you like most of the new Zeds you think the Sirens are too ugly, and want to change them to the default. This is what your .ini file should look like:
Simple, no? If you have any questions, feel free to ask.
Invasion Squads
The Invasion spawning mechanic in ServerPerksX is capable of handling almost any kind of customized spawning patters for Invasion Mode. You may define squads, squad sets, waves, and wave information for both global use and map-specific use. Waves may be targeted at specific game lengths, difficulty modes, or maps, and may define the total number of zeds that wave, the set of monsters which spawn at the beginning of the wave, and even the zeds who accompany the patriarch.
Spoiler!
First thing's first if you want to use the ZedList system to modify your zombie spawns. You must define some squads. By default, the .ini file provides all of the default KF monster squads. You may edit them freely.
required string SquadName - The user-friendly name of the squad. Make it whatever you want, but it cannot be blank and it must be unique (although there will be no errors if they aren't unique, but the ZedList will only use the first one defined).
required string Zeds - A string defining the Zeds in this squad. Each character alternatively represents a Number To Spawn and Zed ID. You may thus define up to 9 Zeds of any kind at a time. If you want a squad with 10 clots, the proper definition is "9A1A", not "10A". Using the latter definition will cause you to load 1 Zed of type 0, and int(A) Zeds of type none - which may be what you want, who the hell knows? But for sanity's sake, just stick to the prescribed definitions. The Letter ID corresponds to the Letter used in the previously discussed Monster Collection.
Once you've defined your squads, you may choose to simply have your squads be injected into the existing WaveMasks (which control which squads spawn and when) by changing the bOverrideInvasionSquads variable to true. Once this is done, your squads will be eligible for spawning.
Next, provided you're still feeling adventurous, you can start defining custom squads, squad sets, waves, and wave informations. This part of the ZedList, enabled by the bOverrideInvasionWaves variable, allows you to set up waves for various game conditions.
First, I'll discuss SquadSets. SquadSets are not absolutely necessary in order to modify waves. They are simply a grouping mechanism allowing you to organize similar squads together in order to maximize your versatility in defining squads for specific conditions. Some parts of the waves do require SquadSets, however, such as the OpeningSet (the zeds which spawn at the start of the wave).
SquadSet
required string SetName - Just a handy name for the set. Must be unique and cannot be blank.
required string array Squads - A list of squad names to use in this set. ("Squad1","Squad2","Squad3") etcetera. You can load as many of these into a set as you wish.
Once you have a couple of SquadSets planned out, you can move on to defining some Waves. Waves are definitions for a single dynamic Wave which is called by the GlobalWaves and MapWaves under specific conditions. Think of the generic wave, then, as the spawning mechanics for any given wave of Killing Floor.
Wave
required string WaveName - The name of the wave, must be unique.
optional string array Sets - A list of set names to use in this wave.
optional string array Squads - If you'd prefer to add single squads, you may specify their names in this list. This can be used as an adjunct to Sets, so you can load squads from both Sets and individual Squads in the same wave.
optional string OpeningSet - The name of the set that is spawned at the start of the wave (and again if the entire rotation is depleted).
Now that you've defined a few waves, you can go on to plugging them into the GlobalWaves and MapWaves as you see fit. GlobalWaves and MapWaves are essentially a list of conditions under which to spawn the previously defined Waves. GlobalWaves, obviously, apply to every map. MapWaves are Map-Specific, and will override any Globals if their conditions are met. The order of precedence for definitions goes as follows:
MapWaves
GlobalWaves
Game Defaults
So if you leave any conditions empty here, Killing Floor's defaults will be allowed to take over. Handy if you only want to change one or two things.
GlobalWaves
required int WaveNum - Which wave number to spawn on. Values from 0-10 are valid. 0 represents the Patriarch wave, and if 0 is selected then only the OpeningSet of the associated Game Length will be used to spawn the monsters which accompany the boss. Waves 1-4 are used for Short games, 1-7 for Normal, and 1-10 for Long.
optional string Short - The name of the wave applicable for Short games. If left undefined, this definition will be skipped for Short games of that Wave Number.
optional string Normal - The name of the wave applicable for Normal games
optional string Long - The name of the wave applicable for Long games.
optional int MinDifficulty - The difficulty level that is required for these waves to take effect. 1=Beginner, 2=Normal,4=Hard,5=Suicidal,7=HoE (don't blame me, I didn't define them). If left undefined, it will always meet this requirement.
optional int NumZeds - How many Zeds to spawn this wave. This value is modified by game-code later depending on number of players and difficulty scaling. If left undefined, it will use the game's defaults for that WaveNum.
MapWaves are identical to GlobalWaves with the exception of being able to define maps for them.
MapWaves
required string MapName - The name of the map to apply this definition to, e.g. "KF-WestLondon". This is not cap sensitive.
required int WaveNum - Which wave number to spawn on. Values from 0-10 are valid. 0 represents the Patriarch wave, and if 0 is selected then only the OpeningSet of the associated Game Length will be used to spawn the monsters which accompany the boss. Waves 1-4 are used for Short games, 1-7 for Normal, and 1-10 for Long.
optional string Short - The name of the wave applicable for Short games. If left undefined, this definition will be skipped for Short games of that Wave Number.
optional string Normal - The name of the wave applicable for Normal games
optional string Long - The name of the wave applicable for Long games.
optional int MinDifficulty - The difficulty level that is required for these waves to take effect. 1=Beginner, 2=Normal,4=Hard,5=Suicidal,7=HoE (don't blame me, I didn't define them). If left undefined, it will always meet this requirement.
optional int NumZeds - How many Zeds to spawn this wave. This value is modified by game-code later depending on number of players and difficulty scaling. If left undefined, it will use the game's defaults for that WaveNum.
Story Mode Squads
So as I mentioned, this spawning system is much more sophisticated. Thus, I won't go into terrible details on it in this thread. As the system is still very new and capable of being altered by Tripwire, it wouldn't make much sense to do so now anyway. Let's just get right into it, then.
Spoiler!
In order to modify the Story Mode Squads, you must change bOverrideStorySquads to true in the ServerPerksX.ini file. This will enable the ZombieList replacement system for Story Mode. There are some default, do-nothing values defined which you will need to replace (but you can leave them there if you want a handy reference since they don't actually do anything).
StorySquadReplacements
This method of changing zed spawns is quite simple and straightforward. Like the other methods, it can be map-specific or global. This method will simply replace a percentage of existing Zeds in every squad with the ones you want.
Variables:
Optional string MapName - If left undefined, this replacement's definition will apply to all Story Mode maps. If defined, this replacement will only occur on the defined map.
Optional string ZedTypeToReplace - "Custom" by default. Defines the type of basic Zed to replace with your defined class. This variable is valid for all standard Zeds, "Gorefast", Bloat, "Fleshpound", "Scrake", "Patriarch" etc. You can also set this value to "Custom" to replace any dumb custom Zeds level designers decide to shove in their piece of **** maps, but this will have no effect on KFO-Steamland (or most maps, for that matter). So just stick to defining a normal Zed type in most cases.
Required string ReplaceClass - The class definition of the Zed to replace the specified ZedType with.
Optional float PercentReplaced - Valid range from 0.0 to 1.0, 1.0 if left undefined. The percentage of these Zeds to be replaced with the replacement class
Let's consider an example case where I want half of the Crawlers on KFO-Steamland converted to Clots.
Code:
Start with the simplest definition, where we define that we want to replace things
on the map KFO-Steamland
StorySquadReplacements=(MapName="KFO-Steamland")
[list]
[*]Add that we want to replace crawlers
StorySquadReplacements=(MapName="KFO-Steamland",ZedType=ZED_Crawler)
[*]Add that we want to replace crawlers those crawlers with clots
StorySquadReplacements=(MapName="KFO-Steamland",ZedType=ZED_Crawler,ReplaceClass="KFChar.ZombieClot")
[*]Add that we want half of those crawlers to be replaced
StorySquadReplacements=(MapName="KFO-Steamland",ZedType=ZED_Crawler,ReplaceClass="KFChar.ZombieClot",PercentReplaced=0.5)
[/list]
That's it, copy it to the ServerPerksX.ini file
StorySquadAdditions
This method of changing zed spawns is intended to tack extra Zeds onto existing squads, or as an adjunct to StorySquadReplacements, as it is applied sequentially after the previous method. So we can use this method to further edit previously modified squads.
Variables:
Optional string MapName - If left undefined, this addition's definition will apply to all Story Mode maps. If defined, this addition will only occur on the defined map.
Required string SpawnsWithClass - The class of Zed we want our new Zed to come in with. Since this is applied AFTER StorySquadReplacements, we can even add some Zeds to squads which previously had replacements.
Required string SpawnClass - The class of Zed we want to accompany our SpawnsWithClass
Optional float PercentChance - Valid range from 0.0 to 1.0, 1.0 if left undefined. The chance that this addition will occur when it has the chance to happen.
Let's consider an example case where I want those crawlers from the previous example to be accompanied by a Bloat 50% of the time.
Code:
Start with the simplest definition, where we define that we want to replace things
on the map KFO-Steamland
StorySquadAdditions=(MapName="KFO-Steamland")
[list]
[*]Add that we want to accompany crawlers
StorySquadAdditions=(MapName="KFO-Steamland",SpawnsWithClass="KFChar.ZombieCrawler")
[*]Add that we want Bloats to be the accompaniment
StorySquadAdditions=(MapName="KFO-Steamland",SpawnsWithClass="KFChar.ZombieCrawler",SpawnClass="KFChar.ZombieBloat")
[*]Add that we want this to occur 50% of the time that crawlers show up
StorySquadAdditions=(MapName="KFO-Steamland",SpawnsWithClass="KFChar.ZombieCrawler",SpawnClass="KFChar.ZombieBloat",PercentChance=0.5)
[/list]
That's it, copy it to the ServerPerksX.ini file
StoryNewSquads
The most complicated way to add new Zeds to story maps. This is for those who can't be satisfied by simply manipulating existing squads, and want more control over how Zombies spawn. This array's definitions will create wholly new squads for placement on the defined maps.
Variables:
Optional string MapName - If left undefined, this squad's definition will apply to all Story Mode maps. If defined, this squad will only show up on the defined map.
Optional string SquadName - Most often you should leave this blank, as the ZombieList system will assign a unique SquadName on generation. If you choose to define the squad's name for any reason, it must be unique! This includes any squads currently on any maps it is applied to.
Optional string WaveTags array - Level designers define WaveTags for each new wave they create, and you'll have to look these up in the Editor to find out what they are (or log them with code). In any case, you probably want to find these out so you can tell your new squad which waves to spawn in. Define it here. You can optionally leave this blank and give this squad's PercentChanceAddToAll variable a value above 0, giving it a chance to spawn in every wave (explained below).
Optional string SpawnTags array - Like WaveTags, designers can specify tags for multiple spawn conditions within a wave. In KFO-Steamland this is only done for the Boss (who is associated with the Wave1Spawn WaveTag). Most of the time this appears to be left blank. If you do not define a SpawnTag for your new squad, it will be added to all wavecontrollers within any Wave it gets into (at the time of writing this, that's generally a good thing. To be clear, at this time, you probably want to leave this blank).
Optional SpawnPriority - Normal if left blank. Other valid values are VeryLow, Low, High, and VeryHigh (do not use quotation marks). This ostensibly controls the desirability of a wavecontroller to spawn this squad when given the chance. Doesn't make a huge difference at the time of writing this.
Optional bool bIgnoreMaxZeds - If left blank, defaults to false. If true, this squad will spawn even if its wavecontroller is at capacity.
Optional float PercentChance - Any value between -1.0 and 1.0, representing the percentage chance that this squad will show up AT ALL when the map loads. This is to give you a lot more control over the variety of monsters that'll show up each match, increasing replayability. A value of 0.0 (default) is interpreted as a value of 1.0. So you can leave this value empty if you want the squad to always load for processing.
Optional float PercentChanceAddToAll - Valid from 0.0 to 1.0, this variable defines the liklihood of this squad being added to EACH wave individually. So if you don't define a WaveTag for it, it'll have this much of a chance to be added to every wave. By default this is 0.
Optional float MinTimeBetweenSpawns - The minimum time, in seconds, that must pass for this squad to be respawned in a given wave.
Required struct SquadInfo array -
Required string SpawnClass - Definition of the type of monster to spawn.
Required int NumToSpawn - The amount of these Zeds to spawn
Optional float PerZedChance - Valid range from 0.0 to 1.0, 1.0 if left undefined. Modifies the NumToSpawn value, giving each individual Zed 100*PerZedChance% chance of showing up in its squad. By default, all of the Zeds will show up.
Optional float PercentChance - Valid range from 0.0 to 1.0, 1.0 if left undefined. Chance that this squad will show up AT ALL in each wave it can spawn in.
Well, if you want to add your own squads to the game code-side, there you go. It's not nearly as complicated as it seems, however. I'll go through a couple of examples. First, let's consider the practical case that I would like to add a squad of 3-5 Stalkers, 1 Siren, and either 0 or 2 Crawlers to the KFO-Steamland map, and I would like them to only spawn during the Breaker wave (the one where you have to weld up the breaker boxes) and Escort wave (When that bastard says "Gooh, Bloody Knee!" a thousand times).
To do this, I'll start with a basic definition of the item that will go into the end of the ServerPerksX.ini file:
Code:
StoryNewSquads=( SquadInfo=( () , () ) )
[LIST]
[*]First, add the MapName. Since I'll be defining a specific wave for it to spawn in, it won't be relevant for any other maps:
StoryNewSquads=( Mapname="KFO-Steamland", SquadInfo=( () , () ) )
[*]Add the WaveTag to specify the Breaker wave, as defined in the KFO-Steamland map.
StoryNewSquads=( Mapname="KFO-Steamland", WaveTags=("BreakerSpawns","EscortSpawns") SquadInfo=( () , () ) )
[*]Add my Stalker definition, with 5 Stalkers, each having a 0.8 chance to spawn (80%).
StoryNewSquads=( Mapname="KFO-Steamland", WaveTags=("BreakerSpawns","EscortSpawns") SquadInfo=( (SpawnClass="KFChar.ZombieStalker",NumToSpawn=2,PerZedChance=0.8) , () ) )
[*]Add my Siren
StoryNewSquads=( Mapname="KFO-Steamland", WaveTags=("BreakerSpawns","EscortSpawns") SquadInfo=( (SpawnClass="KFChar.ZombieStalker",NumToSpawn=2,PerZedChance=0.8) , (SpawnClass="KFChar.ZombieSiren",NumToSpawn=1) ) )
[*]Add my Crawlers, giving them a number of 2, and a chance of 0.5 to show up. So we have a 50% chance to get 2 of them, or they aren't there at all.
StoryNewSquads=( Mapname="KFO-Steamland", WaveTags=("BreakerSpawns","EscortSpawns") SquadInfo=( (SpawnClass="KFChar.ZombieStalker",NumToSpawn=2,PerZedChance=0.8) , (SpawnClass="KFChar.ZombieSiren",NumToSpawn=1) , (SpawnClass="KFChar.ZombieCrawler",NumToSpawn=2,PercentChance=0.5) ) )
[/LIST]
Now copy that **** to the .ini
Next, let's consider that I want to add a squad of 5 Shivers to every Story Mode map, and I want them to always show up in every wave. This is quite simple!
Again, start with the simplest definition:
Code:
StoryNewSquads=( SquadInfo=( () ) )
[LIST]
[*]Since we want this to be on every map, all the time, in every wave, the
only thing we need to define here is the PercentChanceAddToAll variable, and
the SquadInfo. Start with the simple variable:
StoryNewSquads=( PercentChanceAddToAll=1.0, SquadInfo=( () ) )
[*]Now just tack on the Squad definition
StoryNewSquads=( PercentChanceAddToAll=1.0, SquadInfo=( (SpawnClass="MyPackage.ZombieShiver",NumToSpawn=5) ) )
[/LIST]
And that's it.
SRSimpleList
An extremely simple replacement system designed to outright replace all occurences of one zombie type with another. Still under development.
Feedback, comments, suggestions, ideas, remarks, etcetera are all very welcome!
Medics can have medicnades... you just set the return value on their GetNadeType function to KFMod.Medicnade in your perk class. You want me to change that in the default classes for ServerPerks? I can do that I guess, I'll put it on the list.
Hey there Surly! This looks really interesting; going to have to play around with this. Also since its based off ServerPerks I assume it will not be compatible side by side with poosh's scrnbalance mod(Also based off serverperks)? If people wanted it, it would be interesting to see the features of these two combined or run parallel until everything is stabilized.
It should be with very, very, very minor tweaks (if any). I'm not familiar with ScrNBalance's code, but the changes here are minimal. It's quite likely they'd be compatible just by changing the GameAssociates in the ServerPerksX.ini file.
It would, however, require a recompile of the code to extend the ServerPerksX classes.
This is actually just a modification to the source of ServerPerks, which is renamed to prevent version mismatch errors. I didn't want to just release a 7.0 version of ServerPerks because it'd be kind of in poor taste, but I could quite easily recompile this as ServerPerks 7, and it would be fully compatible with everything that uses ServerPerks.
Oh and to comment on this, yes, you could run them in tandem... though honestly, compatibility was one of my primary concerns. If you're using ServerPerks6.1, this can be a drop in replacement and will cause absolutely no bugs (well, theoretically) in Invasion mode. All of the additional changes are modular, and do not affect the native functionality of ServerPerks6.1. In fact, using the default GameAssociates defined in the ini file packed with it, all of the code for Invasion mode is identical. It just adds the ability to swap out new PlayerControllers and HUDs for the new GameMode on the fly (which you can also extend with no incompatibility).
The Controllers are fully branched for forward-compatibility with new gamemodes.
Now, hypothetically, I could do a:
KFPC -> KFPlayerController -> KFPlayerController_Story -> KFPCServ_DualMode
Which would just work for either... but that class would be awfully ugly and hackish, overloading all of KFPlayerController_Story's functions and calling up to KFPlayerController on Super calls depending on the game mode.
When modding, I guess you have to do ugly things sometimes. I don't know though, that's pretty awful. On the plus side, though, any existing mod could just extend that KFPCServ_DualMode class and have full compatibility with both modes with no new work.
I guess I'll do that for the next version, maybe. If I can get over how god awful it is.
Explaining the ZedList replacement system
Essentially, this sub-system allows server-admins to specify what zeds they want to spawn on which maps without compiling any code, and merely modifying values in the ServerPerksX.ini file. The StoryMode squad system is quite sophisticated compared to older KF code (That Alex Quick guy is pretty good!), so messing with any of it directly could potentially be a nightmare for modders. And because the new spawning system is offloaded to the level designers almost entirely, it compounds the issue of trying to fiddle with the code in order to get the results you want. My hope is that this mutator will stop the almost certain problem of incompatibility between mods which all try to stick their fingers into that pie. This sub-system is modular, and allows modders to make their own replacement systems subclassing ServerPerksXMut.SRZombieList (which is the default, included module)
This is amazing. I've been looking for a system like this to dynamically replace zeds for a looong time. I run a custom server and really don't want to use sandbox, so much of my modding has been put on hold until I could work out a way to do this. Even thought of building a KF version of the UT2004 Monster Manager myself, but having the functionality built right into ServerPerks is far more ideal.
This makes Sandbox mode obsolete, there's really no reason to use Sandbox with this. You still CAN if you want, but the Zed Replacement system here just inserts your zeds directly into the normal game modes.
This is amazing. I've been looking for a system like this to dynamically replace zeds for a looong time. I run a custom server and really don't want to use sandbox, so much of my modding has been put on hold until I could work out a way to do this. Even thought of building a KF version of the UT2004 Monster Manager myself, but having the functionality built right into ServerPerks is far more ideal.
I just re-uploaded the .rar archive since the original one had a typo in the .ini file causing crashes (PlayerController was defined as SKFPCServ, should have been KFPCServ). Oops. Fixed now. If you find anything wonky about loading up the defaults, I'd suggest redownloading it.
Marco didn't said he won't update ServerPerks himself. He's just offline. And it is July after all - best month for vacation. Maybe he'll return soon and give us ServerPerks7.
You've done big and good job, but the way you did it is wrong. You've made 2 versions of each base class: one extending class from KFMod, another - from KFStoryGame. For example, you have Marco's KFPCServ extending KFPlayerController and KFPCServ_Story extending KFPlayerController_Story, which in turn extends KFPlayerController. Now imagine that I'll make ScrnBalance to use ServerPerksX. Then I'll be supposed to make 2 classes too: ScrnPlayerController and ScrnPlayerController_Story. But here the chain doesn't end. There are plenty of modded servers, who are extending ScrnBalance, e.g. Forrestmark's and Brutus servers. Each of them also will be supposed to duplicate their code in two classes.
So in the result we will have 2 versions of KFPCServ, 2 versions of ScrnPlayerController and 2 versions of modded ScrnPlayerController. Double amount of classes, which have copy-pasted bodies from each other and without being able to use benefits from object-oriented design. And this is only one class. There are also modified human pawn, HUD etc. Each of them will require the same job to be done.
But at this point the scary story I'm telling you doesn't ends Now imagine Tripwire will make some radical changes in KFMod or KFStoryGame packages. And they like to do that. Take, for example, ScoredHeadshot() from the last patch. All modders will be supposed to make changes in their mods and do it TWICE, because they'll have 2 copies of practically the same class.
Don't worry, Surly, it isn't your fault. Tripwire introduced bad, modder-non-friendly concept (again!), which you just continued. TWI shouldn't create story subclasses of player controller, human pawn, HUD etc. at all! All work should be done in KFMod's base classes, when we (modders) wouldn't have problems at all.
The solution is hard, requires extra work, but it is worth of it. You need to create one, unified subclass again, which will support both normal and objective modes.
This is an example, how to make function compatible with both normal and story modes:
Code:
class KFPCServ extends KFPlayerController_Story;
simulated function UpdateHintManagement(bool bUseHints)
{
if ( KFStoryGameInfo(Level.Game) != none) {
// objective mode
super.UpdateHintManagement(bUseHints);
}
else {
// normal mode - bypass KFPlayerController_Story
super(KFPlayerController).UpdateHintManagement(bUseHints);
}
}
This template can be used for all functions that aren't extended in ServerPerks. Modifying extended functions will be harder.
It is a hard job, but if done right, it will bring advantages in the future.
But before doing that job I'm suggesting you to wait for Marco's response.
And one more thing: if ServerPerks will be properly updated to support both normal and objective mode, I'll promise that I'll make ScrnBalance objective-compatible too. I'm tired of stupid AI that can be tricked with simple moves like weld boxes, don't attack the zeds, and they'll won't attack you; or as zerker kite away zed horde far away from the mission objective.
Hi Poosh, I already commented that this is a possibility, but is not forward compatible with future (or even current, like GunGame) game modes since KFPlayerController is the point at which the classes branch.
As I mentioned, in the next version I will include a playercontroller/pawn set which work with both Invasion and Story game modes so that you can Drop-In the replacement if you want. This, however, is a lazy solution to be used as a convenience.
The solution is hard, requires extra work, but it is worth of it. You need to create one, unified subclass again, which will support both normal and objective modes.
This is an example, how to make function compatible with both normal and story modes:
Code:
class KFPCServ extends KFPlayerController_Story;
simulated function UpdateHintManagement(bool bUseHints)
{
if ( KFStoryGameInfo(Level.Game) != none) {
// objective mode
super.UpdateHintManagement(bUseHints);
}
else {
// normal mode - bypass KFPlayerController_Story
super(KFPlayerController).UpdateHintManagement(bUseHints);
}
}
This template can be used for all functions that aren't extended in ServerPerks. Modifying extended functions will be harder.
That is also not the proper way to do what you're suggesting, since it will force TypeCasting. The "proper" way to do this is with delegates, and I'm presently doing that (it's done, actually, but I'm still considering what to do with the HUD). But again, I have to mention that this is not an elegant, or correct way of doing things. The correct way is follow the class branching structure of the source material. While I agree that Killing Floor's source is poorly organized, complaining about the reality of the situation doesn't do you much good.
So at that, yes, the next version of this will include a Dual-Mode playercontroller and pawn which will work for both Invasion and Story modes, for the sake of convenience. However, the GameTypeAssociate system will remain intact to support more game modes. Just because Killing Floor's class hierarchy isn't planned well doesn't mean mine has to be the same way.
GunGame isn't an extension of KFGameType, but Story mode is.
Using delegate functions could be the best, but IIRC UE2 doesn't support them. Purely virtual Object class could be used instead, but I'm not sure, if it would be right in this situation. I used such to make ScrnBalance compatible with SuperZombies mutator (when it used own human pawn class), but it was harder to maintain.
Using "if then else" constructions instead of class hierarchy count lame... in theory. But in practice it will be much easier to maintain, believe me. Theory is one thing, but in real live things happen differently. For example, if you'll design a SQL database, which passes all normalization levels, its performance will be near to zero.
Right, which is why there needs to be a way to define new playercontrollers as necessary. That's all I meant. Still, if KF gets another game mode in the future we can probably expect it to extend KFGameType again, and in that case... no matter how clever you are, you're screwed for compatibility unless you do something different.
Using delegate functions could be the best, but IIRC UE2 doesn't support them. Purely virtual Object class could be used instead, but I'm not sure, if it would be right in this situation. I used such to make ScrnBalance compatible with SuperZombies mutator (when it used own human pawn class), but it was harder to maintain.
Well, it's how I handled the issue. I'm far more familiar with UE3 than 2, but delegates were introduced in 2. It wasn't until UE3 that they were capable of being stored as variables, though. That would have been REALLY nice for this particular assignment, but it worked out. Oh, I just uploaded the new version. There is only a single KFPCServ and SRHumanPawn class in it now, which works for both modes, and can be extended exactly as they could be in ServerPerks6.1 with the added benefit of working for Story Mode.
As an added benefit, anyone extending these new classes will have the option of overloading GameMode-Specific functions, or the Global function (default) to apply to both. In other words, previously extended code is applied to both modes. All without bogging things down with State code or TypeCasting every single time a function is called. The delegates are set up via replication at the creation of pawns and controllers.
Using "if then else" constructions instead of class hierarchy count lame... in theory. But in practice it will be much easier to maintain, believe me. Theory is one thing, but in real live things happen differently. For example, if you'll design a SQL database, which passes all normalization levels, its performance will be near to zero.
Right, well, thanks for the suggestion and comments. It was most helpful to see that there is demand for a true drop-in replacement rather than something which merely provides a means of defining playercontrollers for various game modes. This new version is as efficient as such a thing can be in UE2 and only eats up about 10kb more memory. As far as performance, it's undetectable. So I guess it's a success.
I did this, but altered it a little to make it a little easier to load projectile assets while we're at it (I had something similar in a mod I'm working on, so I just made SPX compatible with it). Here's the alterations, I don't think it should make any difference to custom weapons (I just split the projectile loading/unloading to a separate function):
Spoiler!
Code:
simulated function PreloadFireModeAssets(class<WeaponFire> WF)
{
local class<Projectile> P;
if ( WF == none || WF == Class'KFMod.NoFire' )
return;
if ( class<KFFire>(WF) != none && class<KFFire>(WF).default.FireSoundRef != "" )
class<KFFire>(WF).static.PreloadAssets(Level);
else if ( class<KFMeleeFire>(WF) != none && class<KFMeleeFire>(WF).default.FireSoundRef != "" )
class<KFMeleeFire>(WF).static.PreloadAssets();
else if ( class<KFShotgunFire>(WF) != none && class<KFShotgunFire>(WF).default.FireSoundRef != "" )
class<KFShotgunFire>(WF).static.PreloadAssets(Level);
// preload projectile assets
P = WF.default.ProjectileClass;
if ( P != none )
PreloadProjectileAssets(WF.default.ProjectileClass);
}
simulated function PreloadProjectileAssets(class<Projectile> P)
{
if( class<SRProjectile>(P) != none )
class<SRProjectile>(P).static.PreloadAssets();
else if ( class<CrossbuzzsawBlade>(P) != none )
class<CrossbuzzsawBlade>(P).static.PreloadAssets();
else if ( class<LAWProj>(P) != none && class<LAWProj>(P).default.StaticMeshRef != "" )
class<LAWProj>(P).static.PreloadAssets();
else if ( class<M79GrenadeProjectile>(P) != none && class<M79GrenadeProjectile>(P).default.StaticMeshRef != "" )
class<M79GrenadeProjectile>(P).static.PreloadAssets();
else if ( class<HealingProjectile>(P) != none && class<HealingProjectile>(P).default.StaticMeshRef != "" )
class<HealingProjectile>(P).static.PreloadAssets();
else if ( class<CrossbowArrow>(P) != none && class<CrossbowArrow>(P).default.MeshRef != "" )
class<CrossbowArrow>(P).static.PreloadAssets();
else if ( class<M99Bullet>(P) != none )
class<M99Bullet>(P).static.PreloadAssets();
else if ( class<PipeBombProjectile>(P) != none && class<PipeBombProjectile>(P).default.StaticMeshRef != "" )
class<PipeBombProjectile>(P).static.PreloadAssets();
}
simulated function UnloadFireModeAssets(class<WeaponFire> WF)
{
local class<Projectile> P;
if ( WF == none || WF == Class'KFMod.NoFire' )
return;
if ( class<KFFire>(WF) != none && class<KFFire>(WF).default.FireSoundRef != "" )
class<KFFire>(WF).static.UnloadAssets();
else if ( class<KFMeleeFire>(WF) != none && class<KFMeleeFire>(WF).default.FireSoundRef != "" )
class<KFMeleeFire>(WF).static.UnloadAssets();
else if ( class<KFShotgunFire>(WF) != none && class<KFShotgunFire>(WF).default.FireSoundRef != "" )
class<KFShotgunFire>(WF).static.UnloadAssets();
// Unload projectile assets only if refs aren't empty (i.e. they have been dynamically loaded)
P = WF.default.ProjectileClass;
if ( P != none && P.default.StaticMesh == none )
UnloadProjectileAssets(P);
}
simulated function UnloadProjectileAssets(class<Projectile> P)
{
if ( class<SRProjectile>(P) != none )
class<SRProjectile>(P).static.PreloadAssets();
if ( class<CrossbuzzsawBlade>(P) != none )
class<CrossbuzzsawBlade>(P).static.UnloadAssets();
else if ( class<LAWProj>(P) != none && class<LAWProj>(P).default.StaticMeshRef != "" )
class<LAWProj>(P).static.UnloadAssets();
else if ( class<M79GrenadeProjectile>(P) != none && class<M79GrenadeProjectile>(P).default.StaticMeshRef != "" )
class<M79GrenadeProjectile>(P).static.UnloadAssets();
else if ( class<HealingProjectile>(P) != none && class<HealingProjectile>(P).default.StaticMeshRef != "" )
class<HealingProjectile>(P).static.UnloadAssets();
else if ( class<CrossbowArrow>(P) != none && class<CrossbowArrow>(P).default.MeshRef != "" )
class<CrossbowArrow>(P).static.UnloadAssets();
else if ( class<M99Bullet>(P) != none )
class<M99Bullet>(P).static.UnloadAssets();
else if ( class<PipeBombProjectile>(P) != none && class<PipeBombProjectile>(P).default.StaticMeshRef != "" )
class<PipeBombProjectile>(P).static.UnloadAssets();
}
simulated function ClientWeaponSpawned(class<Weapon> WClass, Inventory Inv)
{
local class<KFWeapon> W;
local class<KFWeaponAttachment> Att;
//super.ClientWeaponSpawned(WClass, Inv);
W = class<KFWeapon>(WClass);
// preload assets only for weapons that have no static ones
// damned Tripwire's code doesn't bother for cheking is there ref set or not!
if ( W != none) {
//preload weapon assets
if ( W.default.Mesh == none )
W.static.PreloadAssets(Inv);
Att = class<KFWeaponAttachment>(W.default.AttachmentClass);
// 2013/01/22 EDIT: bug fix
if ( Att != none && Att.default.Mesh == none ) {
if ( Inv != none )
Att.static.PreloadAssets(KFWeaponAttachment(Inv.ThirdPersonActor));
else
Att.static.PreloadAssets();
}
PreloadFireModeAssets(W.default.FireModeClass[0]);
PreloadFireModeAssets(W.default.FireModeClass[1]);
}
}
simulated function ClientWeaponDestroyed(class<Weapon> WClass)
{
local class<KFWeapon> W;
local class<KFWeaponAttachment> Att;
//super.ClientWeaponDestroyed(WClass);
W = class<KFWeapon>(WClass);
//if default mesh is set, then count that weapon has static assets, so don't unload them
// that's lame, but no so lame as Tripwire's original code
if ( W != none && W.default.MeshRef != "" && W.static.UnloadAssets() ) {
Att = class<KFWeaponAttachment>(W.default.AttachmentClass);
if ( Att != none && Att.default.Mesh == none )
Att.static.PreloadAssets();
UnloadFireModeAssets(W.default.FireModeClass[0]);
UnloadFireModeAssets(W.default.FireModeClass[1]);
}
}
Both are reflected in the ServerPerksXv1.11 download, and the source now.
can this mutator up the LV to254URL="https://dl.dropboxusercontent.com/u/175212805/ServerPerksX_v13.rar"]Download ServerPerksX v1.30[/URL][/SIZE] Download ServerPerksX v1.30 Source
Major revamp of the ZedList replacement system. Now includes global Squad definitions, a custom Monster Collection creation system that can load from the .ini file, a VASTLY improved functionality for Invasion game mode which includes just about everything you could want. This new system automatically generates wave masks on the fly during map changes, and can support different wave sets by difficulty, game length, map, and more.
New Features Guide is updated with new information on the ZedList system and its use.
Fixes
Moved logging for debugging the ZedList system to SRZedList_Debug, so they won't clutter your logs unless you enable them.
Fixed a few bugs and optimized a couple of functions for speed in execution.
Debugging/Testing
Please change your ZombieListClass variable in ServerPerksX.ini to "ServerPerksXMut.SRZombieList_Debug" if you encounter any bugs, and send me the log files afterwards. I'll fix things as soon as possible.
While I try to make these releases as bug-free as possible, I can only test so much on my own. Thanks in advance for any log files or bug reports!
ServerPerksX v1.1 Changelog
Spoiler!
New Features
KFPCServ and SRHumanPawn now utilize delegate function assignments to dynamically call correct superclass functions for the current game mode. What this means to you is that you can now extend ServerPerksX's playercontroller (KFPCServ) and pawn (SRHumanPawn) directly, with any code which was previously compliant with ServerPerks, and achieve full functionality and Story Mode support, with no new code.
This new system does not affect the HUD, which will be coming in the next version. Reworking the HUD will take more time, however, since memory management issues with assets being loaded are significant here. The current in-development version, though working, is not reasonably efficient yet (and eats up too much memory to be considered worthwhile). If you do not use a custom HUD, this will not affect you. If you DO use a custom HUD, you'll have to get by with using SRKillingFloorHUD_Story for now.
Fixes
Optimization to the ZedList replacement system making it load faster.
Fixed a bug in the ZedList causing replacement problems in Invasion mode.
The default Field Medic perk uses medic nades now.
I sent Marco a PM about updating ServerPerks a few days ago for the new game mode, and let him know that I would be happy to do so if he had no plans on it. Given his lack of response, I imagine that means he has no intentions to do so.
So I've taken the liberty of updating ServerPerks v6.1 for the new StoryGame mode. This modification of ServerPerks also expands its features by adding a new system for servers to modify Zed waves in both Invasion and Story game modes, specify GameMode-Specific PlayerController and HUD classes, specify a MonsterCollection (to enable event zeds if you want), and specify a ZombieList sub-system (if you want to write your own Zed-Replacement class). All of this while retaining all of the original ServerPerks functionality and adding no new client-side files other than the new HUD and PlayerController classes.
As the StoryGame mode is obviously new and heavily logged, so too is this mutator. I'll try to keep it updated as much as possible until StoryMode is relatively stable. Let me know if you encounter any bugs, and please send me your KillingFloor.log file if you do! This is especially helpful while StoryMode is still so heavily logged.
Thanks.
ServerPerksX New Features
StoryGame (Objective) Mode Support
Dynamic Server-Side MonsterCollection selection
Support for custom game modes through dynamic PlayerController/HUD specification
Dynamic Server-Side Zed Replacement System for even more customized Story Maps
Old Features
See this thread. This mutator merely enhances the functionality of Marco's original mutator.
Installation and Use Installation
Simply extract the files into your KillingFloor/System directory
This mutator does not overwrite any of the original ServerPerks files, and may be installed simultaneously
Use
This mutator may be considered a replacement for ServerPerks, and retains all of the original functionality of ServerPerks while adding new features.
ServerPerksX is a completely self-contained mutator and does not extend the original ServerPerks files. If you wish to extend ServerPerksX in your own mod, simply subclass ServerPerksX instead of ServerPerks and recompile. Handily, all of the class definitions are the same. For instance, let us assume that you had previously subclassed KFPCServ in your own mod. With ServerPerksX, all you'll need to do for a successful compile is change EditPackages=ServerPerks to EditPackages=ServerPerksX in your KillingFloor.ini file, and recompile your mod.
ServerPerksX cannot be loaded as an active mod at the same time as ServerPerks, this will cause conflicts because ServerPerksX uses the same class definitions. However, you may have both mutators installed at the same time if you'd like to test their differences.
If it worked with ServerPerks, it will work with ServerPerksX.
If it didn't work with ServerPerks, it probably won't work with ServerPerksX, but I'm willing to fix any bugs from the original ServerPerks anyone brings to my attention.
New Features Guide New Variables in ServerPerksX.ini
MonstersCollection - Somewhat self-explanatory. Leave this blank to let Killing Floor select its own MonsterCollection, otherwise define the classname thusly:
MonstersCollectionType="KFMod.KFMonstersCollection"
This definition will become the Default monstercollection, which can be overridden and modified dynamically with the ZedList system, explained further below.
ZombieListClass - This defines the subclass of SRZombieList which will be used to load customized spawn waves/replacements. You can freely subclass SRZombieList to any server-side package, whether sent to clients or not, if you wish to offload its functionality. If you define a ZombieList in your own mod, your package will be imported dynamically at runtime with no need of a mutator. ServerPerksXMut.SRZombieList is defined by default.
GameTypeAssociates - It's unlikely you'll want to dick with these unless you're making a new game mode, have your own mod which uses GameType-specific HUDs or PlayerControllers, or just want to swap out what HUD/PlayerController is used without compiling ****. In any case, feel free to modify these. In a defined Associate, GameType specifies the associated GameType for the replacement, ClassType specifies the type of class to be replaced (only "HUD" and "PlayerController" are currently supported), ClassName specifies the path to the class used to replace these default classes. Again, any classes defined here will have their packages automatically loaded at runtime without the need of a mutator.
Explaining the ZedList replacement system
Essentially, this sub-system allows server-admins to specify what zeds they want to spawn on which maps without compiling any code, and merely modifying values in the ServerPerksX.ini file. The StoryMode squad system is quite sophisticated compared to older KF code (That Alex Quick guy is pretty good!), so messing with any of it directly could potentially be a nightmare for modders. And because the new spawning system is offloaded to the level designers almost entirely, it compounds the issue of trying to fiddle with the code in order to get the results you want. My hope is that this mutator will stop the almost certain problem of incompatibility between mods which all try to stick their fingers into that pie. This sub-system is modular, and allows modders to make their own replacement systems subclassing ServerPerksXMut.SRZombieList (which is the default, included module)
As of the v1.3 release of ServerPerksX, the ZedList system has been widely expanded for Invasion mode, allowing dynamic, map/difficulty/gamelength based modifications of waves without the need to mess with wavemasks, which the ZedList now generates on the fly every time a map loads.
SRZombieList
A moderately simple module for modifying spawn waves in both game modes. This is the default mode, and intends to be as capable as possible for the majority of people's needs.
Custom Monster Collection
ServerPerksX can now dynamically create and load in a Monster Collection at runtime, which allows you, the modder, to specify new or replacement monsters by simply changing a line in the ServerPerksX.ini file. Monster Collections are the basic list of zombies used by both game modes to spawn waves of zeds in the game, and any modifications to this will be global. The ServerPerksX Monster Collection replacement module lets you selectively specify replacements, or completely override the default MonsterCollectionClass. Default values in ServerPerksX.ini represent the vanilla KFMod version of the Monster Collection, with all the classic zeds.
Spoiler!
In order to customize your server's loadout of zombies, you have a great deal of options available. First, if you've already created your own Monster Collection, you can load it as the default collection by specifying it in the MonsterCollectionClass variable of the .ini file. Or, if you'd prefer, you can leave this variable definition empty and let Killing Floor load its own Monster Collection (handy if you want events, such as the sideshow/halloween zeds to affect the later portions).
Next, you can modify this default Monster Collection, whether defined by you or left up to Killing Floor, by setting the bCustomMonsterCollection under [ServerPerksX.SRZombieList] header to true. By doing this, you will activate the following variables:
Monster - An array of Monsters which can all be defined
Letter - The ID of the Zed, cap sensitive! Must be a single character, but can be any valid unicode character. Best stick with letters, unless you have over 26 Zeds on your server. A, B, C, D, E, F, G, H, and I are associated with internally-recognized Zeds, represented correctly by their default properties in the .ini file.
MClass - The location of the class associated with this Zed. The default .ini file configuration uses the classic Killing Floor Zeds.
BossMonster - The class of the patriarch (or patriarch replacement). The default value represents the classic Patriarch.
FallbackMonster - The class of the zed that will be spawned when no others can be, due to size restrictions in a small spawn area most likely. Stalkers are a good choice for this.
By removing the values for any of these, you will allow the default Monster Collection to take precedence. You can also freely add new Monster definitions without affecting the defaults loaded in by the default Monster Collection. If, however, you define a Monster with any of the letters A-I, it will override the default monster held there.
For instance, let us assume that the Summer Sideshow event is taking place and while you like most of the new Zeds you think the Sirens are too ugly, and want to change them to the default. This is what your .ini file should look like:
Simple, no? If you have any questions, feel free to ask.
Invasion Squads
The Invasion spawning mechanic in ServerPerksX is capable of handling almost any kind of customized spawning patters for Invasion Mode. You may define squads, squad sets, waves, and wave information for both global use and map-specific use. Waves may be targeted at specific game lengths, difficulty modes, or maps, and may define the total number of zeds that wave, the set of monsters which spawn at the beginning of the wave, and even the zeds who accompany the patriarch.
Spoiler!
First thing's first if you want to use the ZedList system to modify your zombie spawns. You must define some squads. By default, the .ini file provides all of the default KF monster squads. You may edit them freely.
required string SquadName - The user-friendly name of the squad. Make it whatever you want, but it cannot be blank and it must be unique (although there will be no errors if they aren't unique, but the ZedList will only use the first one defined).
required string Zeds - A string defining the Zeds in this squad. Each character alternatively represents a Number To Spawn and Zed ID. You may thus define up to 9 Zeds of any kind at a time. If you want a squad with 10 clots, the proper definition is "9A1A", not "10A". Using the latter definition will cause you to load 1 Zed of type 0, and int(A) Zeds of type none - which may be what you want, who the hell knows? But for sanity's sake, just stick to the prescribed definitions. The Letter ID corresponds to the Letter used in the previously discussed Monster Collection.
Once you've defined your squads, you may choose to simply have your squads be injected into the existing WaveMasks (which control which squads spawn and when) by changing the bOverrideInvasionSquads variable to true. Once this is done, your squads will be eligible for spawning.
Next, provided you're still feeling adventurous, you can start defining custom squads, squad sets, waves, and wave informations. This part of the ZedList, enabled by the bOverrideInvasionWaves variable, allows you to set up waves for various game conditions.
First, I'll discuss SquadSets. SquadSets are not absolutely necessary in order to modify waves. They are simply a grouping mechanism allowing you to organize similar squads together in order to maximize your versatility in defining squads for specific conditions. Some parts of the waves do require SquadSets, however, such as the OpeningSet (the zeds which spawn at the start of the wave).
SquadSet
required string SetName - Just a handy name for the set. Must be unique and cannot be blank.
required string array Squads - A list of squad names to use in this set. ("Squad1","Squad2","Squad3") etcetera. You can load as many of these into a set as you wish.
Once you have a couple of SquadSets planned out, you can move on to defining some Waves. Waves are definitions for a single dynamic Wave which is called by the GlobalWaves and MapWaves under specific conditions. Think of the generic wave, then, as the spawning mechanics for any given wave of Killing Floor.
Wave
required string WaveName - The name of the wave, must be unique.
optional string array Sets - A list of set names to use in this wave.
optional string array Squads - If you'd prefer to add single squads, you may specify their names in this list. This can be used as an adjunct to Sets, so you can load squads from both Sets and individual Squads in the same wave.
optional string OpeningSet - The name of the set that is spawned at the start of the wave (and again if the entire rotation is depleted).
Now that you've defined a few waves, you can go on to plugging them into the GlobalWaves and MapWaves as you see fit. GlobalWaves and MapWaves are essentially a list of conditions under which to spawn the previously defined Waves. GlobalWaves, obviously, apply to every map. MapWaves are Map-Specific, and will override any Globals if their conditions are met. The order of precedence for definitions goes as follows:
MapWaves
GlobalWaves
Game Defaults
So if you leave any conditions empty here, Killing Floor's defaults will be allowed to take over. Handy if you only want to change one or two things.
GlobalWaves
required int WaveNum - Which wave number to spawn on. Values from 0-10 are valid. 0 represents the Patriarch wave, and if 0 is selected then only the OpeningSet of the associated Game Length will be used to spawn the monsters which accompany the boss. Waves 1-4 are used for Short games, 1-7 for Normal, and 1-10 for Long.
optional string Short - The name of the wave applicable for Short games. If left undefined, this definition will be skipped for Short games of that Wave Number.
optional string Normal - The name of the wave applicable for Normal games
optional string Long - The name of the wave applicable for Long games.
optional int MinDifficulty - The difficulty level that is required for these waves to take effect. 1=Beginner, 2=Normal,4=Hard,5=Suicidal,7=HoE (don't blame me, I didn't define them). If left undefined, it will always meet this requirement.
optional int NumZeds - How many Zeds to spawn this wave. This value is modified by game-code later depending on number of players and difficulty scaling. If left undefined, it will use the game's defaults for that WaveNum.
MapWaves are identical to GlobalWaves with the exception of being able to define maps for them.
MapWaves
required string MapName - The name of the map to apply this definition to, e.g. "KF-WestLondon". This is not cap sensitive.
required int WaveNum - Which wave number to spawn on. Values from 0-10 are valid. 0 represents the Patriarch wave, and if 0 is selected then only the OpeningSet of the associated Game Length will be used to spawn the monsters which accompany the boss. Waves 1-4 are used for Short games, 1-7 for Normal, and 1-10 for Long.
optional string Short - The name of the wave applicable for Short games. If left undefined, this definition will be skipped for Short games of that Wave Number.
optional string Normal - The name of the wave applicable for Normal games
optional string Long - The name of the wave applicable for Long games.
optional int MinDifficulty - The difficulty level that is required for these waves to take effect. 1=Beginner, 2=Normal,4=Hard,5=Suicidal,7=HoE (don't blame me, I didn't define them). If left undefined, it will always meet this requirement.
optional int NumZeds - How many Zeds to spawn this wave. This value is modified by game-code later depending on number of players and difficulty scaling. If left undefined, it will use the game's defaults for that WaveNum.
Story Mode Squads
So as I mentioned, this spawning system is much more sophisticated. Thus, I won't go into terrible details on it in this thread. As the system is still very new and capable of being altered by Tripwire, it wouldn't make much sense to do so now anyway. Let's just get right into it, then.
Spoiler!
In order to modify the Story Mode Squads, you must change bOverrideStorySquads to true in the ServerPerksX.ini file. This will enable the ZombieList replacement system for Story Mode. There are some default, do-nothing values defined which you will need to replace (but you can leave them there if you want a handy reference since they don't actually do anything).
StorySquadReplacements
This method of changing zed spawns is quite simple and straightforward. Like the other methods, it can be map-specific or global. This method will simply replace a percentage of existing Zeds in every squad with the ones you want.
Variables:
Optional string MapName - If left undefined, this replacement's definition will apply to all Story Mode maps. If defined, this replacement will only occur on the defined map.
Optional string ZedTypeToReplace - "Custom" by default. Defines the type of basic Zed to replace with your defined class. This variable is valid for all standard Zeds, "Gorefast", Bloat, "Fleshpound", "Scrake", "Patriarch" etc. You can also set this value to "Custom" to replace any dumb custom Zeds level designers decide to shove in their piece of **** maps, but this will have no effect on KFO-Steamland (or most maps, for that matter). So just stick to defining a normal Zed type in most cases.
Required string ReplaceClass - The class definition of the Zed to replace the specified ZedType with.
Optional float PercentReplaced - Valid range from 0.0 to 1.0, 1.0 if left undefined. The percentage of these Zeds to be replaced with the replacement class
Let's consider an example case where I want half of the Crawlers on KFO-Steamland converted to Clots.
Code:
Start with the simplest definition, where we define that we want to replace things
on the map KFO-Steamland
StorySquadReplacements=(MapName="KFO-Steamland")
[list]
[*]Add that we want to replace crawlers
StorySquadReplacements=(MapName="KFO-Steamland",ZedType=ZED_Crawler)
[*]Add that we want to replace crawlers those crawlers with clots
StorySquadReplacements=(MapName="KFO-Steamland",ZedType=ZED_Crawler,ReplaceClass="KFChar.ZombieClot")
[*]Add that we want half of those crawlers to be replaced
StorySquadReplacements=(MapName="KFO-Steamland",ZedType=ZED_Crawler,ReplaceClass="KFChar.ZombieClot",PercentReplaced=0.5)
[/list]
That's it, copy it to the ServerPerksX.ini file
StorySquadAdditions
This method of changing zed spawns is intended to tack extra Zeds onto existing squads, or as an adjunct to StorySquadReplacements, as it is applied sequentially after the previous method. So we can use this method to further edit previously modified squads.
Variables:
Optional string MapName - If left undefined, this addition's definition will apply to all Story Mode maps. If defined, this addition will only occur on the defined map.
Required string SpawnsWithClass - The class of Zed we want our new Zed to come in with. Since this is applied AFTER StorySquadReplacements, we can even add some Zeds to squads which previously had replacements.
Required string SpawnClass - The class of Zed we want to accompany our SpawnsWithClass
Optional float PercentChance - Valid range from 0.0 to 1.0, 1.0 if left undefined. The chance that this addition will occur when it has the chance to happen.
Let's consider an example case where I want those crawlers from the previous example to be accompanied by a Bloat 50% of the time.
Code:
Start with the simplest definition, where we define that we want to replace things
on the map KFO-Steamland
StorySquadAdditions=(MapName="KFO-Steamland")
[list]
[*]Add that we want to accompany crawlers
StorySquadAdditions=(MapName="KFO-Steamland",SpawnsWithClass="KFChar.ZombieCrawler")
[*]Add that we want Bloats to be the accompaniment
StorySquadAdditions=(MapName="KFO-Steamland",SpawnsWithClass="KFChar.ZombieCrawler",SpawnClass="KFChar.ZombieBloat")
[*]Add that we want this to occur 50% of the time that crawlers show up
StorySquadAdditions=(MapName="KFO-Steamland",SpawnsWithClass="KFChar.ZombieCrawler",SpawnClass="KFChar.ZombieBloat",PercentChance=0.5)
[/list]
That's it, copy it to the ServerPerksX.ini file
StoryNewSquads
The most complicated way to add new Zeds to story maps. This is for those who can't be satisfied by simply manipulating existing squads, and want more control over how Zombies spawn. This array's definitions will create wholly new squads for placement on the defined maps.
Variables:
Optional string MapName - If left undefined, this squad's definition will apply to all Story Mode maps. If defined, this squad will only show up on the defined map.
Optional string SquadName - Most often you should leave this blank, as the ZombieList system will assign a unique SquadName on generation. If you choose to define the squad's name for any reason, it must be unique! This includes any squads currently on any maps it is applied to.
Optional string WaveTags array - Level designers define WaveTags for each new wave they create, and you'll have to look these up in the Editor to find out what they are (or log them with code). In any case, you probably want to find these out so you can tell your new squad which waves to spawn in. Define it here. You can optionally leave this blank and give this squad's PercentChanceAddToAll variable a value above 0, giving it a chance to spawn in every wave (explained below).
Optional string SpawnTags array - Like WaveTags, designers can specify tags for multiple spawn conditions within a wave. In KFO-Steamland this is only done for the Boss (who is associated with the Wave1Spawn WaveTag). Most of the time this appears to be left blank. If you do not define a SpawnTag for your new squad, it will be added to all wavecontrollers within any Wave it gets into (at the time of writing this, that's generally a good thing. To be clear, at this time, you probably want to leave this blank).
Optional SpawnPriority - Normal if left blank. Other valid values are VeryLow, Low, High, and VeryHigh (do not use quotation marks). This ostensibly controls the desirability of a wavecontroller to spawn this squad when given the chance. Doesn't make a huge difference at the time of writing this.
Optional bool bIgnoreMaxZeds - If left blank, defaults to false. If true, this squad will spawn even if its wavecontroller is at capacity.
Optional float PercentChance - Any value between -1.0 and 1.0, representing the percentage chance that this squad will show up AT ALL when the map loads. This is to give you a lot more control over the variety of monsters that'll show up each match, increasing replayability. A value of 0.0 (default) is interpreted as a value of 1.0. So you can leave this value empty if you want the squad to always load for processing.
Optional float PercentChanceAddToAll - Valid from 0.0 to 1.0, this variable defines the liklihood of this squad being added to EACH wave individually. So if you don't define a WaveTag for it, it'll have this much of a chance to be added to every wave. By default this is 0.
Optional float MinTimeBetweenSpawns - The minimum time, in seconds, that must pass for this squad to be respawned in a given wave.
Required struct SquadInfo array -
Required string SpawnClass - Definition of the type of monster to spawn.
Required int NumToSpawn - The amount of these Zeds to spawn
Optional float PerZedChance - Valid range from 0.0 to 1.0, 1.0 if left undefined. Modifies the NumToSpawn value, giving each individual Zed 100*PerZedChance% chance of showing up in its squad. By default, all of the Zeds will show up.
Optional float PercentChance - Valid range from 0.0 to 1.0, 1.0 if left undefined. Chance that this squad will show up AT ALL in each wave it can spawn in.
Well, if you want to add your own squads to the game code-side, there you go. It's not nearly as complicated as it seems, however. I'll go through a couple of examples. First, let's consider the practical case that I would like to add a squad of 3-5 Stalkers, 1 Siren, and either 0 or 2 Crawlers to the KFO-Steamland map, and I would like them to only spawn during the Breaker wave (the one where you have to weld up the breaker boxes) and Escort wave (When that bastard says "Gooh, Bloody Knee!" a thousand times).
To do this, I'll start with a basic definition of the item that will go into the end of the ServerPerksX.ini file:
Code:
StoryNewSquads=( SquadInfo=( () , () ) )
[LIST]
[*]First, add the MapName. Since I'll be defining a specific wave for it to spawn in, it won't be relevant for any other maps:
StoryNewSquads=( Mapname="KFO-Steamland", SquadInfo=( () , () ) )
[*]Add the WaveTag to specify the Breaker wave, as defined in the KFO-Steamland map.
StoryNewSquads=( Mapname="KFO-Steamland", WaveTags=("BreakerSpawns","EscortSpawns") SquadInfo=( () , () ) )
[*]Add my Stalker definition, with 5 Stalkers, each having a 0.8 chance to spawn (80%).
StoryNewSquads=( Mapname="KFO-Steamland", WaveTags=("BreakerSpawns","EscortSpawns") SquadInfo=( (SpawnClass="KFChar.ZombieStalker",NumToSpawn=2,PerZedChance=0.8) , () ) )
[*]Add my Siren
StoryNewSquads=( Mapname="KFO-Steamland", WaveTags=("BreakerSpawns","EscortSpawns") SquadInfo=( (SpawnClass="KFChar.ZombieStalker",NumToSpawn=2,PerZedChance=0.8) , (SpawnClass="KFChar.ZombieSiren",NumToSpawn=1) ) )
[*]Add my Crawlers, giving them a number of 2, and a chance of 0.5 to show up. So we have a 50% chance to get 2 of them, or they aren't there at all.
StoryNewSquads=( Mapname="KFO-Steamland", WaveTags=("BreakerSpawns","EscortSpawns") SquadInfo=( (SpawnClass="KFChar.ZombieStalker",NumToSpawn=2,PerZedChance=0.8) , (SpawnClass="KFChar.ZombieSiren",NumToSpawn=1) , (SpawnClass="KFChar.ZombieCrawler",NumToSpawn=2,PercentChance=0.5) ) )
[/LIST]
Now copy that **** to the .ini
Next, let's consider that I want to add a squad of 5 Shivers to every Story Mode map, and I want them to always show up in every wave. This is quite simple!
Again, start with the simplest definition:
Code:
StoryNewSquads=( SquadInfo=( () ) )
[LIST]
[*]Since we want this to be on every map, all the time, in every wave, the
only thing we need to define here is the PercentChanceAddToAll variable, and
the SquadInfo. Start with the simple variable:
StoryNewSquads=( PercentChanceAddToAll=1.0, SquadInfo=( () ) )
[*]Now just tack on the Squad definition
StoryNewSquads=( PercentChanceAddToAll=1.0, SquadInfo=( (SpawnClass="MyPackage.ZombieShiver",NumToSpawn=5) ) )
[/LIST]
And that's it.
SRSimpleList
An extremely simple replacement system designed to outright replace all occurences of one zombie type with another. Still under development.
Feedback, comments, suggestions, ideas, remarks, etcetera are all very welcome![/QUOTE]
can this mutator uped LV to 254,why i ask,i used serverperks but it could not uped the LV while i uped to 71,i always set the max LV254
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
Now imagine Tripwire will make some radical changes in KFMod or KFStoryGame packages. And they like to do that. Take, for example, ScoredHeadshot() from the last patch. All modders will be supposed to make changes in their mods and do it TWICE, because they'll have 2 copies of practically the same class.