|
|
|
[AcediaFixes.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
|
|
|
|
|
|
|
|
|
|
|
|
[AcediaFixes.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
|
|
|
|
|
|
|
|
|
|
|
|
[AcediaFixes.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')
|
|
|
|
|
|
|
|
|
|
|
|
[AcediaFixes.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,
|
|
|
|
; so if you wish to prevent it, keep this flag set to `false`.
|
|
|
|
ignoreTossFlags=true
|
|
|
|
|
|
|
|
|
|
|
|
[AcediaFixes.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
|
|
|
|
; We immediately reduce the rate dosh can be spawned at when players throw
|
|
|
|
; new wads of cash. But, for performance reasons, we only periodically turn it
|
|
|
|
; back up. This interval determines how often we check for whether it's okay
|
|
|
|
; to raise the limit on the spawned dosh.
|
|
|
|
; You should not set this value too high, it is recommended not to exceed
|
|
|
|
; 1 second.
|
|
|
|
checkInterval=0.25
|
|
|
|
|
|
|
|
|
|
|
|
[AcediaFixes.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
|
|
|
|
|
|
|
|
|
|
|
|
[AcediaFixes.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.???'
|
|
|
|
|
|
|
|
[AcediaFixes.FixPipes]
|
|
|
|
; This feature addresses several bugs related to pipe bombs:
|
|
|
|
; 1. Gaining extra explosive damage by shooting pipes with
|
|
|
|
; a high fire rate weapon;
|
|
|
|
; 2. Other players exploding one's pipes;
|
|
|
|
; 3. Corpses and story NPCs exploding nearby pipes;
|
|
|
|
; 4. Pipes being stuck in places where they cannot detect nearby
|
|
|
|
; enemies and, therefore, not exploding.
|
|
|
|
autoEnable=true
|
|
|
|
; NOTE #1: setting either of `preventMassiveDamage` or
|
|
|
|
; `preventSuspiciousDamage` might change how and where pipes might fall on
|
|
|
|
; the ground (for example, pipe hats shoul not work anymore). In most cases,
|
|
|
|
; however, there should be no difference from vanilla gameplay.
|
|
|
|
; Setting this to `true` fixes a mechanic that allows pipes to deal extra
|
|
|
|
; damage when detonated with a high fire rate weapons: pipes will now always
|
|
|
|
; deal the same amount of damage.
|
|
|
|
preventMassiveDamage=true
|
|
|
|
; It's possible for teammates to explode one's pipe under certain
|
|
|
|
; circumstances. Setting this setting to `true` will prevent that
|
|
|
|
; from happening.
|
|
|
|
preventSuspiciousDamage=true
|
|
|
|
; Setting this to `true` will prevent pipe bombs from being detonated by
|
|
|
|
; the nearby corpses on other player.
|
|
|
|
preventCorpseDetonation=true
|
|
|
|
; Setting this to `true` will prevents pipe bombs from being detonated by
|
|
|
|
; nearby KFO NPCs (Ringmaster Lockheart).
|
|
|
|
preventNPCDetonation=true
|
|
|
|
; Certain spots prevent pipe bombs from having a line of sight to the
|
|
|
|
; nearby zeds, preventing them from ever exploding. This issue can be resolves
|
|
|
|
; by checking zed's proximity not to the pipe itself, but to a point directly
|
|
|
|
; above it (20 units above by default).
|
|
|
|
; If you wish to disable this part of the feature - set it to zero or
|
|
|
|
; negative value. Otherwise it is suggested to keep it at `20`.
|
|
|
|
proximityCheckElevation=20
|
|
|
|
|
|
|
|
|
|
|
|
[AcediaFixes.FixProjectileFF]
|
|
|
|
; This feature addresses the bug that allows teammates to explode some of
|
|
|
|
; the player's projectiles by damaging them even when friendly fire is
|
|
|
|
; turned off, therefore killing the player (whether by accident or not).
|
|
|
|
autoEnable=true
|
|
|
|
; By default (`ignoreFriendlyFire == false`), when friendly fire is enabled
|
|
|
|
; (at any level), this fix allows other players to explode one's projectiles.
|
|
|
|
; By setting this to `true` you will force this fix to prevent it no matter
|
|
|
|
; what, even when server has full friendly fire enabled.
|
|
|
|
ignoreFriendlyFire=false
|
|
|
|
|
|
|
|
[AcediaFixes.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
|