ZScript VM issues (memory leak?)

[Major Cooke]

While working on developing D4D some more, I thought about moving the player overlay stuff into the player tick processing and gave it a try.

D4D Bad version
D4D Good version

Load up the bad version and start playing normally. After a few minutes, you'll notice the frame rate starting to chug, and it only keeps getting worse until it comes to an outright crawl. Memory also slowly increases.
The good version doesn't have this issue. So what's the difference?

Under ZD4D/Doom4Player.txt, lines 847-879:

Code: Select all

            //A_Overlay(Overlay_Cooldown1,"Overlay.Cooldown1",true);
            //A_Overlay(Overlay_Cooldown2,"Overlay.Cooldown2",true);
            //A_Overlay(Overlay_Cooldown3,"Overlay.Cooldown3",true);
            //A_Overlay(Overlay_MovementHealthArmor,"Overlay.MovementHealthArmor",true); // This one does not cause the lag-downs.
            
            // Don't change these.
            A_Overlay(Overlay_LedgeGrab,"Overlay.LedgeGrab",true);
            A_Overlay(99,"Overlay.Debug",true);
            //A_Overlay(Overlay_AnglePitch,"Overlay.AnglePitch",true);
        }
        Super.PostBeginPlay();
    }
    
    //--------------------------------------------------------------------------
    // Active Functions
    //--------------------------------------------------------------------------
    
    int CooldownTimer[3];
    override void Tick()
    {
        
        static const int CooldownCaps[] = { 3, 2, 10 };
        for (int i = 0; i < 3; i++)
        {
            CooldownTimer[i] = (CooldownTimer[i] + 1) % CooldownCaps[i];
        }
        
        if (!CooldownTimer[0])    ProcessCooldown1();
        if (!CooldownTimer[1])    ProcessCooldown2();
        if (!CooldownTimer[2])    ProcessCooldown3();
        UpdateHAM(); //This is the cause of the issues.
        Super.Tick();
    }

UpdateHAM is the exact same as Overlay.MovementHealthArmor -- same code and all. If you comment out
UpdateHam(); on line 877
and uncomment
A_Overlay(Overlay_MovementHealthArmor,"Overlay.MovementHealthArmor",true); on line 850,
said issue will not happen.

[Graf Zahl]

Please try to narrow it down a bit before letting me have a look. Trying to find the cause in there won't be easy with this much code, and you know better how to selectively disable parts of it.

[Major Cooke]

Found it. It's these three lines at the top of UpdateHAM:

Code: Select all

		A_SetInventory("SuperHealthToken",Clamp(health-100,0,100));
		A_SetInventory("HealthToken",Clamp(health,0,100));
		A_SetInventory("SuperArmorToken",Clamp(CountInv("BasicArmor")-100,0,100));

Any one of these three causes the drag-down.

[Graf Zahl]

Can you see anything strange once the slowdown occurs and you call 'printinv' at the console?

[Major Cooke]

Yep. It creates entire new entries of the health tokens for example.

---

These tokens are found inside ZD4D/MiscItems.txt.

Code: Select all

Class      HealthToken : Inventory { Default { Inventory.MaxAmount 100; }}
Class SuperHealthToken : Inventory { Default { Inventory.MaxAmount 100; }}
Class SuperArmorToken  : Inventory { Default { Inventory.MaxAmount 100; }}

[Graf Zahl]

Looks like an implementation error in A_SetInventory.

[Major Cooke]

Well, it works when it's performed in the states but I have no idea how it's not working for non-states.

[Graf Zahl]

I cannot reproduce this effect. Loading D4Dbad with the base mod I can play through entire maps without any item pile-up in the inventory.

(And just a quick note: This is the last open issue I want fixed for 2.3.1, so if I can't find a way to reproduce it, I'll release a version this evening without a fix.)

[Major Cooke]

Okay, perhaps it's related to build.

I'm using RelWithDebInfo 64-bit.

[Graf Zahl]

That shouldn't matter. I played through MAP15 both in release and debug and nothing bad happened. Can you post the EXACT main resource file you use, maybe something in there is causing it.

[Major Cooke]

...Waaaaiiiit a minute!

It's happening with Going Down!

[_mental_]

Sorry but how to load those good and bad .pk3's?

I tried them with Doom 2 WAD only and got bunch of missing patch warnings and finally

Code: Select all

Script error, "D4Dbad.pk3:animdefs.aed" line 3: Unknown texture UAC_ROT0

OK, loaded it after D4D 2.0.3 and got

Code: Select all

Script error, "D4Dgood.pk3:cvarinfo.txt" line 1: cvar 'user_TracerFX' already exists

OK, cloned https://github.com/MajorCooke/Doom4DoomResources to load with those files and got assertion failure at src/scripting/vm/vmbuilder.cpp:504

Code: Select all

assert((Used[firstword] & mask) == mask);

---

Code: Select all

VMFunctionBuilder::RegAvailability::Return(int, int) at src/scripting/vm/vmbuilder.cpp:504
FxLocalVariableDeclaration::Release(VMFunctionBuilder*) at src/scripting/codegeneration/codegen.cpp:10182
FxCompoundStatement::Emit(VMFunctionBuilder*) at src/scripting/codegeneration/codegen.cpp:8659
FxExpression::EmitStatement(VMFunctionBuilder*) at src/scripting/codegeneration/codegen.cpp:304
FxIfStatement::Emit(VMFunctionBuilder*) at src/scripting/codegeneration/codegen.cpp:9074
FxExpression::EmitStatement(VMFunctionBuilder*) at src/scripting/codegeneration/codegen.cpp:304
FxSequence::Emit(VMFunctionBuilder*) at src/scripting/codegeneration/codegen.cpp:8611
FxCompoundStatement::Emit(VMFunctionBuilder*) at src/scripting/codegeneration/codegen.cpp:8655
FxExpression::EmitStatement(VMFunctionBuilder*) at src/scripting/codegeneration/codegen.cpp:304
FxIfStatement::Emit(VMFunctionBuilder*) at src/scripting/codegeneration/codegen.cpp:9074
FxExpression::EmitStatement(VMFunctionBuilder*) at src/scripting/codegeneration/codegen.cpp:304
FxSequence::Emit(VMFunctionBuilder*) at src/scripting/codegeneration/codegen.cpp:8611
FxCompoundStatement::Emit(VMFunctionBuilder*) at src/scripting/codegeneration/codegen.cpp:8655
FxExpression::EmitStatement(VMFunctionBuilder*) at src/scripting/codegeneration/codegen.cpp:304
FxSequence::Emit(VMFunctionBuilder*) at src/scripting/codegeneration/codegen.cpp:8611
FxCompoundStatement::Emit(VMFunctionBuilder*) at src/scripting/codegeneration/codegen.cpp:8655
FFunctionBuildList::Build() at src/scripting/vm/vmbuilder.cpp:913
LoadActors() at src/scripting/thingdef.cpp:381
PClassActor::StaticInit() at src/info.cpp:215
D_DoomMain() at src/d_main.cpp:2471

I'm just trying to help

[Graf Zahl]

Yeah, with that mod it happens right from the start. Looks like bad Dehacked interaction.

[Major Cooke]

@Mental: You need D4DResources.pk3. Load that before D4D's code package.

@Graf: I figured as much. Should I rename things on my side or do you plan on doing something for it?

The weirdest part is, if it's called from an overlay, it doesn't do that. But from the tick function, that issue happens.

[Graf Zahl]

Actually, no,it's not Dehacked, it's voodoo dolls. You absolutely have to add a voodoo doll check to your tick() function, or very bad things can happen.

To do that add

Code: Select all

if (player.mo != this)
{
    Super.tick();
    return;
}

at the top. I cannot fix the engine-side issue without risking breakage of the entire voodoo doll inventory transfer feature.
I think this needs to be stated in the Wiki as well when trying to override tick() for players.