A whole bunch of minor bugs

[Insert Name Here]

(Note: all of these are on v1075 SDK)

Category: Code

Reproducibility: Always

Summary: You cannot pick up a second pistol if ammo is full on your single pistol and instead get a "Your ammo is full" message.

Description: The offending code is in KFGame.KFWeapon function DenyPickupQuery() (about line 1579). This function checks for pickups with which to give ammo. However, it does not account for dual weapons and as such it prevents picking up the second pistol if your single pistol ammo is full. It should allow the pistol to be picked up regardless of ammo.

Online/Offline: Both

---

Category: Code

Reproducibility: Always

Summary: You cannot pick up Crossbow bolts or Eviscerator sawblades if your spare ammo is full but the magazine is not.

Description: Again, the problem code is in KFGame.KFWeapon function DenyPickupQuery() (about line 1579). The offending lines are the two that check for full ammo (about lines 1590 and 1594):

if( CanRefillSecondaryAmmo() && !Pickup.IsA('Projectile') )
{
    bDenyPickUp =((SpareAmmoCount[0] + MagazineCapacity[0]) >= GetMaxAmmoAmount(0) && AmmoCount[1] >= MagazineCapacity[1]);
}
else
{
    bDenyPickUp = ((SpareAmmoCount[0] + MagazineCapacity[0]) >= GetMaxAmmoAmount(0));
}

The issue is that these lines check for MagazineCapacity[0]. They should instead check for AmmoCount[0], like so:

if( CanRefillSecondaryAmmo() && !Pickup.IsA('Projectile') )
{
    bDenyPickUp =((SpareAmmoCount[0] + AmmoCount[0]) >= GetMaxAmmoAmount(0) && AmmoCount[1] >= MagazineCapacity[1]);
}
else
{
    bDenyPickUp = ((SpareAmmoCount[0] + AmmoCount[0]) >= GetMaxAmmoAmount(0));
}

Online/Offline: Both

---

Category: Code

Reproducibility: Always

Summary: Using the KillBots cheat command also kills the cart in Santa's Workshop.

Description: The issue is in KFGame.KFAIController_ScriptedPawn. Its superclass KFAIController has bIsPlayer set to true, but unlike KFAIController_Monster, KFAIController_ScriptedPawn does not set bIsPlayer to false in its defaultproperties block, which it should.

Online/Offline: Both

---

Category: Code

Reproducibility: Always

Summary: Bloat mines from AI Bloats are not properly cleaned up from their gameplay pool upon destruction.

Description: The offending code is in KFGameContent.KFProj_BloatPukeMine function Destroyed() (about line 478). This function is supposed to remove the Bloat mines from the gameplay pool manager. The issue is at about line 482, with this check:

if( InstigatorController != none )

This is different from the conditions required to put an AI Bloat mine into the pool, which is at about line 99 in PostBeginPlay():

if( InstigatorController != none || IsAIProjectile() )

To fix this, add the IsAIProjectile() check to the removal code in Destroyed().

Online/Offline: Both

---

Category: Editor

Reproducibility: Always

Summary: The BrewContent commandlet has not worked properly for the last few versions. It instead exits out right away (at least when trying to brew code packages; I haven't checked maps).

Description: Looking through the logs from a recent attempt to brew code, I found several error lines like this:

[0011.76] Error: Error reading attributes for 'C:\Users\<Username>\SteamLibrary\steamapps\common\killingfloor2\Binaries\Win64\..\..\KFGame\Unpublished\BrewedPC\Script\UnofficialMod.u'

I suspect that something changed in the BrewContent commandlet a few versions ago such that it no longer checks in the My Documents\My Games\KillingFloor2 folder and now checks the game folder instead. Extra Note: I have KF2 and the My Documents folder on different drives, but it always worked before so I don't think that's the problem. I'm just mentioning it in case it is.

Online/Offline: Offline

---

Category: Code

Reproducibility: Always

Summary: Many weapons have unusual or unexpected group priorities, which may cause unintended ordering in the inventory.

Description: The variable in question is KFGame.KFWeapon variable GroupPriority. These need to be looked at as many of them are set far from what one would expect if this value was based on weapon tier alone, usually:

• < 25 for 9mm/Dual 9mm, Perk Knife, Syringe, Welder
• 25 for Tier 1
• 50 for Tier 2
• 75 for Tier 3
• 100 for Tier 4
• ??? for Tier 5 (no expected value that I could find, but likely at least 100)

The following weapons are at least 15 GroupPriority away from the expected value (in parentheses):

• Berserker
  • Road Redeemer - 100 (50)
  • Fire Axe - 100 (50)
  • Katana - 100 (50)
  • Battle Axe - 85 (???)
• Field Medic
  • HM-501 Assault Rifle/Grenade Launcher - 50 (???)
• Demolitionist
  • M79 - 75 (50)
  • M16/M203 - 50 (75)
  • M32 - 75 (???)
• Firebug
  • Spitfires - 15 Single/35 Dual (???/50) (See P.S. below)
  • MAC-10 - 60 (75)
  • Husk Cannon - 75 (100)
• Gunslinger
  • Single pistols - Varies (15 for 1858 to 30 for .500 Magnum) (??? to ???) (See P.S. below)
  • Dual pistols - Varies (35 for Dual 1858s to 50 for Dual .500 Magnums) (25 for 1858s, 50 for 1911s, 75 for Desert Eagles, 100 for .500 Magnums and AF-2011A1s)
• SWAT
  • MP7 - 50 (25)
  • UMP - 90 (75)

There are also some weapons that are 10 or less GroupPriority away from the expected value (or are Tier 5 but probably aren't a problem). These ones are likely intentional, but I mention them here for completeness:

• HZ-12 - 55 (50)
• MP5 - 60 (50)
• P90 - 80 (75)
• Zweihander - 85 (75)
• M99 - 100 (???)
• Doomstick - 110 (100)
• Bone Crusher - 110 (100)
• Static Strikers - 110 (100)

P.S. The HM-101 Medic Pistol has 25 GroupPriority as expected, but this means that it has a higher GroupPriority than most single pistols. The exceptions are the Desert Eagle (25), AF2011-A1 (25), and .500 Magnum (30). It's also higher than the Dual 9mm Pistols (20), but that's probably intentional. Also, the single 9mm Pistol and the Perk Knife have the same priority (10), but this has never caused any issues AFAIK.

Online/Offline: Both

 

[s5yn3t]

That explains some very old bugs now, like bolt/saws pickup, bloat mines not being cleared (if i understood correctly, is what causing those phantom bloat mines, where you take acid dmg even if there's no mine to step on)

and now it also explains as to why med pistol has higher priority than slinger's 1911.

great find lad.

 

[®omano]

Pay these men who dig into code for you TWI at least some beers or something. It is embarrassing.

 

[infntnub]

A+ stuff man - good finds.

 

[Insert Name Here]

That explains some very old bugs now, like bolt/saws pickup, bloat mines not being cleared (if i understood correctly, is what causing those phantom bloat mines, where you take acid dmg even if there's no mine to step on)

and now it also explains as to why med pistol has higher priority than slinger's 1911.

great find lad.

Admittedly, I'm not sure if this is the cause of phantom bloat mines. If so, then great. I'm just not convinced. If it isn't, I do have a theory that makes more sense (to me, anyways), but I'll have to test it.

In any case, thanks.

 

[s5yn3t]

Admittedly, I'm not sure if this is the cause of phantom bloat mines. If so, then great. I'm just not convinced. If it isn't, I do have a theory that makes more sense (to me, anyways), but I'll have to test it.

In any case, thanks.

not cleaned from gameplay pool.

how does that work. If the bloat mine gets destroyed when transitioning to the trade time, but its hitbox and dmg are still intact?
But the game fails to fully remove and just keeps it in memory?

or im getting it all wrong?

 

[Insert Name Here]

not cleaned from gameplay pool.

how does that work. If the bloat mine gets destroyed when transitioning to the trade time, but its hitbox and dmg are still intact?
But the game fails to fully remove and just keeps it in memory?

or im getting it all wrong?

Basically, KF2 keeps a pool of currently active Bloat mines, preventing too many from existing in the world at one time (I assume for performance reasons; it also does this for C4). The reason I'm so unsure is that I don't know if the Bloat mine is really getting deleted from the game. When I was doing a quick test of it, one "getall" console command (for the Bloat mines themselves) was not turning up anything, but the "getall" for the gameplay pool was showing the proper references (logically, it should have been showing them as None, the UnrealScript value for "there's nothing here").

Foster Parent I'll test this later (if not this weekend, then sometime over the holidays), but if you want to hear my alternate theory on why I think the phantom Bloat mine bug exists: I think the Bloat mines may be getting torn off (bTearOff is set to true) via other means than the FadeOut() function. I found nothing relevant to confirm this in the SDK, so it might be something native-side (both Projectile and KFProjectile are native, and KFProjectile has native replication).

If bTearOff is set to true in KFProj_BloatPukeMine before it's set in FadeOut(), the client will do its normal fade out, but the mine does not get destroyed on the server, even at the end of the wave, because FadeOut() exits early on the dedicated server if bTearOff is true. The only way it will be destroyed is if a player runs into it (from the server's perspective) or if the auto-detonate timer runs out (5 minutes).

Basically: could you please ask one of the KF2 engine programmers to check if Projectile or KFProjectile (maybe even Actor?) are setting bTearOff to true at any point in the native code? If so, we might have our culprit here. Thanks.

 

[Foster Parent]

Insert Name Here - I am happy to ask, but there may not be any reply until after the holidays. The office is getting pretty empty. BTW, QA is testing directly from the text in the first post in this thread, so thanks again for such good notes. If only the Steam forums could make a bug report of more than 5 words...

 

[simplecat]

About phantom mines, i've been thinking this being a replication issue too.
Here are some thoughts about it, but ignore it. It appears to be not the case.

Spoiler!

Puke mine does not fade out on server, it simply gets destroyed after 0.2s. Puke mine does fade out on clients via tick event.
Wave ends and game runs DoTraderTimeCleanup() server side. There it tells puke mines to FadeOut().

Spoiler!

simulated function FadeOut()
{
    if( Physics == PHYS_Falling )
    {
        Destroy();
        return;
    }
    if( bFadingOut || bDeleteMe || (WorldInfo.NetMode == NM_DedicatedServer && bTearOff))
[COLOR=#00FF00]// this runs on the server firsly, statement after 3rd OR
operator shall yet be ignored because bTearOff has yet not been set to TRUE.[/COLOR]
    {
        return; [COLOR=#00FF00]// hence no early exit[/COLOR]
    }
    SetOwner( none );
    SetCollision( false, false );
    if( WorldInfo.NetMode != NM_DedicatedServer )[COLOR=#00FF00] // ignore this, we're not yet on client[/COLOR]
    {
        bFadingOut = true;
        FadeOutTime = WorldInfo.TimeSeconds + default.FadeOutTime;        
    }
    else
    {
        SetTimer( 0.2f, false, nameOf(Destroy) ); [COLOR=#00FF00]// we destroy it on server[/COLOR]
    }
    if( WorldInfo.NetMode != NM_Client ) [COLOR=#00FF00]// we update network[/COLOR]
    {
        bTearOff = true;
        bNetDirty = true;
        bForceNetUpdate = true;
    }
}

Now, when bTearOff recieved on the clients, the event TornOff() starts (and it starts on our server too, i think), which pushes FadeOut() again.

Spoiler!

simulated function FadeOut()
{
    if( Physics == PHYS_Falling )
    {
        Destroy();
        return;
    }
    if( bFadingOut || bDeleteMe || (WorldInfo.NetMode == NM_DedicatedServer && bTearOff))
[COLOR=#00FF00]// this is where the 3rd OR kicks in (only for server though)
so server won't have to execute this function once again.[/COLOR]
    {
        return; [COLOR=#00FF00]// early exit for server (we've been there before) but not for clients.[/COLOR]
    }
    SetOwner( none );
    SetCollision( false, false );
    if( WorldInfo.NetMode != NM_DedicatedServer )[COLOR=#00FF00] // there we tell our client's puke mines to start fading via Tick event.[/COLOR]
    {
        bFadingOut = true;
        FadeOutTime = WorldInfo.TimeSeconds + default.FadeOutTime;        
    }
    else
    {
        SetTimer( 0.2f, false, nameOf(Destroy) );[COLOR=#00FF00] // we do not destroy it on client there, for out clients it will happen later in Tick[/COLOR]
    }
    if( WorldInfo.NetMode != NM_Client ) [COLOR=#00FF00]// we do nothing here as a client[/COLOR]
    {
        bTearOff = true;
        bNetDirty = true;
        bForceNetUpdate = true;
    }
}

And everything there looks fine...

What seem to be the case is way more trivial: it is a self-detonation which mine sets in PostBeginPlay()

https://youtu.be/fmZkg3glLLk

SetTimer(FuseDuration, false, 'Timer_Explode');

Logically when object gets destroyed it should also cease all the currently active timers (whether they meant to run from itself or from other object). Why this does not happen to mine is yet unknown to me.

 

[Insert Name Here]

What seem to be the case is way more trivial: it is a self-detonation which mine sets in PostBeginPlay()

https://youtu.be/fmZkg3glLLk

SetTimer(FuseDuration, false, 'Timer_Explode');

Logically when object gets destroyed it should also cease all the currently active timers (whether they meant to run from itself or from other object). Why this does not happen to mine is yet unknown to me.

That's really weird, the timers should be cleared. I have to wonder if this might give my theory a bit more weight (namely, that the mines aren't actually being destroyed server-side for whatever reason). Have you tried running into where the mines were to see if they detonated?

 

[simplecat]

I have. Nothing really happens if i walk over the place where mine used to sit before getting whiped. But if i wait till its timer expires it will explode and i'll take damage.

Foster Parent

shameless plug, if you're on an engine optimization mission, could you please pass this along the subject?
https://forums.tripwireinteractive....8-game-desperately-needs-memory-optimizations

Namely to ask tech guys if having explosion templates always loaded in the memory and never getting cleared upon actor destruction is works as intended? I'm sure it is not.

 

[Foster Parent]

Today is the last day for most most people until after the holidays, but QA has some time today for testing from forum reports and we will keep eyes on this thread today and in the new year.

 

[Insert Name Here]

I have. Nothing really happens if i walk over the place where mine used to sit before getting whiped. But if i wait till its timer expires it will explode and i'll take damage.

Even weirder. That probably rules out the theory I posted above. Something else is going on here. The mine might be getting its collision, etc., removed, but it's not actually being deleted server-side. That makes no sense given the SDK code, though.

Thanks for your input on this. It looks like I'll have to create a test bench mutator to test this out because there might be something we're missing here.

EDIT:

Foster Parent simplecat

I coded up a mutator to test out various scenarios and made a huge discovery: It turns out that the Bloat mines are getting their FadeOut() function called properly, getting their collision turned off, etc., but the mines aren't being deleted server-side (which is why the timer is still active). Attempts to delete them by replicating what FadeOut() does (by setting a timer for Destroy()) were not working, but calling Destroy() directly did work.

With this in mind, I created a custom Bloat mine that, instead of creating a Destroy() timer in FadeOut(), created a timer for a separate function that called Destroy(). As far as I can tell, this actually worked to properly delete the Bloat mine on the server. For some reason, setting a timer that directly calls Destroy() doesn't trigger it, but doing it indirectly works fine.

If this is the culprit (and I believe it is), this is one hell of an engine quirk.

P.S. If I had to guess as to why a direct Destroy() timer doesn't work, it might have to do with one of these two possibilities:

• Destroy() is a latent function (according to its comment in Engine.Actor, about line 2014)
• Destroy() returns a value (timers might not work properly on functions that return a value despite the fact that it compiles fine)

 

[Foster Parent]

Wow, thanks Insert Name Here . I just sent that to QA to repro. They will be awfully happy.

 

[s5yn3t]

Active bloat mines are still an issue.
The trader god mode doesn't do much other than keeping it from popping up during that time.... but now those phantom bloat mines exploding occurrences increased since the god mode implementation.
Now you get poisoned at the start of a new wave....