You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
255 lines
13 KiB
255 lines
13 KiB
[Acedia.FixDualiesCost] |
|
; This feature fixes several issues, related to the selling price of both |
|
; single and dual pistols, all originating from the existence of dual weapons. |
|
; Most notable issue is the ability to "print" money by buying and |
|
; selling pistols in a certain way. |
|
; |
|
; Fix only works with vanilla pistols, as it's unpredictable what |
|
; custom ones can do and they can handle these issues on their own |
|
; in a better way. |
|
autoEnable=true |
|
; Some issues involve possible decrease in pistols' price and |
|
; don't lead to the exploit, but are still bugs and require fixing. |
|
; If you have a Deagle in your inventory and then get another one |
|
; (by either buying or picking it off the ground) - the price of resulting |
|
; dual pistols will be set to the price of the last deagle, |
|
; like the first one wasn't worth anything at all. |
|
; In particular this means that (prices are off-perk for more clarity): |
|
; 1. If you buy dual deagles (-1000 do$h) and then sell them at 75% of |
|
; the cost (+750 do$h), you lose 250 do$h; |
|
; 2. If you first buy a deagle (-500 do$h), then buy |
|
; the second one (-500 do$h) and then sell them, you'll only get |
|
; 75% of the cost of 1 deagle (+375 do$h), now losing 625 do$h; |
|
; 3. So if you already have bought a deagle (-500 do$h), |
|
; you can get a more expensive weapon by doing a stupid thing |
|
; and first selling your Deagle (+375 do$h), |
|
; then buying dual deagles (-1000 do$h). |
|
; If you sell them after that, you'll gain 75% of the cost of |
|
; dual deagles (+750 do$h), leaving you with losing only 375 do$h. |
|
; Of course, situations described above are only relevant if you're planning |
|
; to sell your weapons at some point and most players won't even |
|
; notice these issues. |
|
; But such an oversight still shouldn't exist in a game and we fix it by |
|
; setting sell value of dualies as a sum of values of each pistol. |
|
; Yet, fixing this issue leads to players having more expensive |
|
; (while fairly priced) weapons than on vanilla, technically making |
|
; the game easier. And some people might object to having that in |
|
; a whitelisted bug-fixing feature. |
|
; These people are, without a question, complete degenerates. |
|
; But making mods for only non-mentally challenged isn't inclusive. |
|
; So we add this option. |
|
; Set it to 'false' if you only want to fix ammo printing |
|
; and leave the rest of the bullshit as-is. |
|
allowSellValueIncrease=true |
|
|
|
|
|
[Acedia.FixAmmoSelling] |
|
; This feature addressed an oversight in vanilla code that |
|
; allows clients to sell weapon's ammunition. |
|
; Due to the implementation of ammo selling, this allows cheaters to |
|
; "print money" by buying and selling ammo over and over again. |
|
autoEnable=true |
|
; Due to how this fix works, players with level below 6 get charged less |
|
; than necessary by the shop and this fix must take the rest of |
|
; the cost by itself. |
|
; The problem is, due to how ammo purchase is coded, low-level (<6 lvl) |
|
; players can actually buy more ammo for "fixed" weapons than they can afford |
|
; by filling ammo for one or all weapons. |
|
; Setting this flag to 'true' will allow us to still take full cost |
|
; from them, putting them in "debt" (having negative dosh amount). |
|
; If you don't want to have players with negative dosh values on your server |
|
; as a side-effect of this fix, then leave this flag as 'false', |
|
; letting low level players buy ammo cheaper |
|
; (but not cheaper than lvl6 could). |
|
; NOTE: this issue doesn't affect level 6 players. |
|
; NOTE #2: this fix does give players below level 6 some |
|
; technical advantage compared to vanilla game, but this advantage |
|
; cannot exceed benefits of having level 6. |
|
allowNegativeDosh=false |
|
|
|
|
|
[Acedia.FixInventoryAbuse] |
|
; This feature addressed two issues with the inventory: |
|
; 1. Players carrying amount of weapons that shouldn't be allowed by the |
|
; weight limit. |
|
; 2. Players carrying two variants of the same gun. |
|
; For example carrying both M32 and camo M32. |
|
; Single and dual version of the same weapon are also considered |
|
; the same type of gun, so you shouldn't be able to carry |
|
; both MK23 and dual MK23 or dual handcannons and golden handcannon. |
|
; But cheaters do. But not with this fix. |
|
autoEnable=true |
|
; How often (in seconds) should we do inventory validation checks? |
|
; You shouldn't really worry about performance, but there's also no need to |
|
; do this check too often. |
|
checkInterval=0.25 |
|
; For this fix to properly work, this array must contain an entry for |
|
; every dual weapon in the game (like pistols, with single and dual versions). |
|
; It's made configurable in case of custom dual weapons. |
|
dualiesClasses=(single=class'KFMod.SinglePickup',dual=class'KFMod.DualiesPickup') |
|
dualiesClasses=(single=class'KFMod.Magnum44Pickup',dual=class'KFMod.Dual44MagnumPickup') |
|
dualiesClasses=(single=class'KFMod.MK23Pickup',dual=class'KFMod.DualMK23Pickup') |
|
dualiesClasses=(single=class'KFMod.DeaglePickup',dual=class'KFMod.DualDeaglePickup') |
|
dualiesClasses=(single=class'KFMod.GoldenDeaglePickup',dual=class'KFMod.GoldenDualDeaglePickup') |
|
dualiesClasses=(single=class'KFMod.FlareRevolverPickup',dual=class'KFMod.DualFlareRevolverPickup') |
|
|
|
|
|
[Acedia.FixInfiniteNades] |
|
; This feature fixes a vulnerability in a code of 'Frag' that can allow |
|
; player to throw grenades even when he no longer has any. |
|
; There's also no cooldowns on the throw, which can lead to a server crash. |
|
autoEnable=true |
|
; Setting this flag to 'true' will allow to throw grenades by calling |
|
; 'ServerThrow' directly, as long as player has necessary ammo. |
|
; This can allow some players to throw grenades much quicker than intended, |
|
; therefore it's suggested to keep this flag set to 'false'. |
|
ignoreTossFlags=false |
|
|
|
|
|
[Acedia.FixDoshSpam] |
|
; This feature addressed two dosh-related issues: |
|
; 1. Crashing servers by spamming 'CashPickup' actors with 'TossCash'; |
|
; 2. Breaking collision detection logic by stacking large amount of |
|
; 'CashPickup' actors in one place, which allows one to either |
|
; reach unintended locations or even instantly kill zeds. |
|
; |
|
; It fixes them by limiting speed, with which dosh can spawn, and |
|
; allowing this limit to decrease when there's already too much dosh |
|
; present on the map. |
|
autoEnable=true |
|
; Highest and lowest speed with which players can throw dosh wads. |
|
; It'll be evenly spread between all players. |
|
; For example, if speed is set to 6 and only one player will be spamming dosh, |
|
; - he'll be able to throw 6 wads of dosh per second; |
|
; but if all 6 players are spamming it, - each will throw only 1 per second. |
|
; NOTE: these speed values can be exceeded, since a player is guaranteed |
|
; to be able to throw at least one wad of dosh, if he didn't do so in awhile. |
|
; NOTE #2: if maximum value is less than minimum one, |
|
; the lowest (maximum one) will be used. |
|
doshPerSecondLimitMax=50 |
|
doshPerSecondLimitMin=5 |
|
; Amount of dosh pickups on the map at which we must set dosh per second |
|
; to 'doshPerSecondLimitMin'. |
|
; We use 'doshPerSecondLimitMax' when there's no dosh on the map and |
|
; scale linearly between them as it's amount grows. |
|
criticalDoshAmount=25 |
|
|
|
|
|
[Acedia.FixSpectatorCrash] |
|
; This feature attempts to prevent server crashes caused by someone |
|
; quickly switching between being spectator and an active player. |
|
autoEnable=true |
|
; This fix will try to kick any player that switches between active player |
|
; and cooldown faster than time (in seconds) in this value. |
|
; NOTE: raising this value past default value of '0.25' |
|
; won't actually improve crash prevention, but might cause regular players to |
|
; get accidentally kicked. |
|
spectatorChangeTimeout=0.25 |
|
; [ADVANCED] Don't change this setting unless you know what you're doing. |
|
; Allows you to turn off server blocking. |
|
; Players that don't respect timeout will still be kicked. |
|
; This might be needed if this fix conflicts with another mutator |
|
; that also changes 'numPlayers'. |
|
; This option is necessary to block aggressive enough server crash |
|
; attempts, but can cause compatibility issues with some mutators. |
|
; It's highly recommended to rewrite such a mutator to be compatible instead. |
|
; NOTE: fix should be compatible with most faked players-type mutators, |
|
; since this it remembers the difference between amount of |
|
; real players and 'numPlayers'. |
|
; After unblocking, it sets 'numPlayers' to |
|
; the current amount of real players + that difference. |
|
; So 4 players + 3 (=7 numPlayers) after kicking 1 player becomes |
|
; 3 players + 3 (=6 numPlayers). |
|
allowServerBlock=true |
|
|
|
|
|
[Acedia.FixFFHack] |
|
; This feature fixes a bug that can allow players to bypass server's |
|
; friendly fire limitations and teamkill. |
|
; Usual fixes apply friendly fire scale to suspicious damage themselves, which |
|
; also disables some of the environmental damage. |
|
; In oder to avoid that, this fix allows server owner to define precisely |
|
; to what damage types to apply the friendly fire scaling. |
|
; It should be all damage types related to projectiles. |
|
autoEnable=true |
|
; Defines a general rule for chosing whether or not to apply |
|
; friendly fire scaling. |
|
; This can be overwritten by exceptions ('alwaysScale' or 'neverScale'). |
|
; Enabling scaling by default without any exceptions in 'neverScale' will |
|
; make this fix behave almost identically to Mutant's 'Explosives Fix Mutator'. |
|
scaleByDefault=false |
|
; Damage types, for which we should always reaaply friendly fire scaling. |
|
alwaysScale=Class'KFMod.DamTypeCrossbuzzsawHeadShot' |
|
alwaysScale=Class'KFMod.DamTypeCrossbuzzsaw' |
|
alwaysScale=Class'KFMod.DamTypeFrag' |
|
alwaysScale=Class'KFMod.DamTypePipeBomb' |
|
alwaysScale=Class'KFMod.DamTypeM203Grenade' |
|
alwaysScale=Class'KFMod.DamTypeM79Grenade' |
|
alwaysScale=Class'KFMod.DamTypeM79GrenadeImpact' |
|
alwaysScale=Class'KFMod.DamTypeM32Grenade' |
|
alwaysScale=Class'KFMod.DamTypeLAW' |
|
alwaysScale=Class'KFMod.DamTypeLawRocketImpact' |
|
alwaysScale=Class'KFMod.DamTypeFlameNade' |
|
alwaysScale=Class'KFMod.DamTypeFlareRevolver' |
|
alwaysScale=Class'KFMod.DamTypeFlareProjectileImpact' |
|
alwaysScale=Class'KFMod.DamTypeBurned' |
|
alwaysScale=Class'KFMod.DamTypeTrenchgun' |
|
alwaysScale=Class'KFMod.DamTypeHuskGun' |
|
alwaysScale=Class'KFMod.DamTypeCrossbow' |
|
alwaysScale=Class'KFMod.DamTypeCrossbowHeadShot' |
|
alwaysScale=Class'KFMod.DamTypeM99SniperRifle' |
|
alwaysScale=Class'KFMod.DamTypeM99HeadShot' |
|
alwaysScale=Class'KFMod.DamTypeShotgun' |
|
alwaysScale=Class'KFMod.DamTypeNailGun' |
|
alwaysScale=Class'KFMod.DamTypeDBShotgun' |
|
alwaysScale=Class'KFMod.DamTypeKSGShotgun' |
|
alwaysScale=Class'KFMod.DamTypeBenelli' |
|
alwaysScale=Class'KFMod.DamTypeSPGrenade' |
|
alwaysScale=Class'KFMod.DamTypeSPGrenadeImpact' |
|
alwaysScale=Class'KFMod.DamTypeSeekerSixRocket' |
|
alwaysScale=Class'KFMod.DamTypeSeekerRocketImpact' |
|
alwaysScale=Class'KFMod.DamTypeSealSquealExplosion' |
|
alwaysScale=Class'KFMod.DamTypeRocketImpact' |
|
alwaysScale=Class'KFMod.DamTypeBlowerThrower' |
|
alwaysScale=Class'KFMod.DamTypeSPShotgun' |
|
alwaysScale=Class'KFMod.DamTypeZEDGun' |
|
alwaysScale=Class'KFMod.DamTypeZEDGunMKII' |
|
alwaysScale=Class'KFMod.DamTypeZEDGunMKII' |
|
; Damage types, for which we should never reaply friendly fire scaling. |
|
;neverScale=Class'KFMod.???' |
|
|
|
|
|
[Acedia.FixZedTimeLags] |
|
; When zed time activates, game speed is immediately set to |
|
; 'zedTimeSlomoScale' (0.2 by default), defined, like all other variables, |
|
; in 'KFGameType'. Zed time lasts 'zedTimeDuration' seconds (3.0 by default), |
|
; but during last 'zedTimeDuration * 0.166' seconds (by default 0.498) |
|
; it starts to speed back up, causing game speed to update every tick. |
|
; This makes animations look more smooth when exiting zed-time. |
|
; However, updating speed every tick for that purpose seems like |
|
; an overkill and, combined with things like |
|
; increased tick rate, certain open maps and increased zed limit, |
|
; it can lead to noticable lags at the end of the zed time. |
|
; This fix limits amount of actual game speed updates, alleviating the issue. |
|
; |
|
; As a side effect it also fixes an issue where during zed time speed up |
|
; 'zedTimeSlomoScale' was assumed to be default value of '0.2'. |
|
; Now zed time will behave correctly with mods that change 'zedTimeSlomoScale'. |
|
autoEnable=true |
|
; Maximum amount of game speed updates upon leaving zed time. |
|
; 2 or 3 seem to provide a good enough result that, |
|
; i.e. it should be hard to notice difference with vanilla game behavior. |
|
; 1 is a smallest possible value, resulting in effectively removing any |
|
; smooting via speed up, simply changing speed from |
|
; the slowest (0.2) to the highest. |
|
; For the reference: on servers with default 30 tick rate there's usually |
|
; about 13 updates total (without this fix). |
|
maxGameSpeedUpdatesAmount=3 |
|
; [ADVANCED] Don't change this setting unless you know what you're doing. |
|
; Compatibility setting that allows to keep 'GameInfo' 's 'Tick' event |
|
; from being disabled. |
|
; Useful when running Acedia along with custom 'GameInfo' |
|
; (that isn't 'KFGameType') that relies on 'Tick' event. |
|
; Note, however, that in order to keep this fix working properly, |
|
; it's on you to make sure 'KFGameType.Tick()' logic isn't executed. |
|
disableTick=true |