Tutorial: NVSE4+ Part 2: User Defined Functions (UDFs)

[Halstrom]

GECK did that to me using vanilla functions once, no idea why, it was only one script, and it was a copy replace paste of another that saved fine. I ended up creating a new script and saved ok, then deleted the old one.

[Guest]

Should I destruct a string, when I pass it as parameter for a UDF, at the end of the UDF itself? (I mean this for bloats)

[Guest tomm434]

Should I destruct a string, when I pass it as parameter for a UDF, at the end of the UDF itself? (I mean this for bloats)

 

Once someone (I don't remember who but he was green) said that it's not neccesary.

But I always do that =)))

 

[prideslayer]

I do also, and arrays get set to ar_null as well.

[Odessa]

No, you don't need to.

 

UDF string arguments are automatically cleaned up, according to the OBSE documentation, and I have confirmed this is accurate via testing. I never do so in my mods, and use them a lot.

 

Test details:

 

 

Quest script running once per frame:

scn BloatQuestScript

; once per frame!
int i

Begin GameMode

    call fnStringBloat "qwertyuiopasdfghjklzxcvbnmmsdfsadgdtgasdgaasdgasdttsd", "anotherverylongstringisher in my string var sfagsdgdfsdfhdfssfgs"
    let i += 1
    if eval (0 == i % 1000)
        Print "BLOAT called "+$i+ "times"
        MessageEx "Bloat called %g times" i
    endif

End

fnStringBloat Version 1:

scn fnStringBloat

string_var one
string_var two
string_var three

Begin Function { one, two }

  PrintD " StringBloat: " + one + two

End

Savegame after ~1000 calls, .nvse = 286 bytes.

Savegame after ~2000 calls, .nvse = 286 bytes.

 

No bloat .

 

fnStringBloat Version 2, Now the string_var args are rebound:

scn fnStringBloat

string_var one
string_var two
string_var three

Begin Function { one, two }

  PrintD " StringBloat: " + one + two

  let one := "a new string var gggggggggsdagadsghafgasdhadyhdfhfdshsahfdfda"
  let two := "a new stringa vars two two fsdgsgafsghedjghrgujdrdfhsdrrahgdasrhadrayhr"

End

Savegame after ~1000 calls, .nvse = 286 bytes.

Savegame after ~2000 calls, .nvse = 286 bytes.

 

Still no bloat

 

fnStringBloat Version 3- now I use the non-argument string_var three, but don't clean it up!

scn fnStringBloat

string_var one
string_var two
string_var three

Begin Function { one, two }

  PrintD " StringBloat: " + one + two

  let one := "a new string var gggggggggsdagadsghafgasdhadyhdfhfdshsahfdfda"
  let two := "a new stringa vars two two fsdgsgafsghedjghrgujdrdfhsdrrahgdasrhadrayhr"

  let three := "I am not a UDF argument!!! So I should bloat, but lets check to be sure"

End

Savegame after ~1000 calls, .nvse = 95,776 bytes.

Savegame after ~2000 calls, .nvse = 186,406 bytes.

 

Bloat as was expected, because three is not a UDF argument .

----

 

Conclusion:

 

- You do not need to sv_destruct string_var arguments of a UDF

- You do need to sv_destruct string_var non-arguments

 

 

 

See also my previous test for some other info: http://www.loverslab.com/topic/4320-fallout-new-vegas-geck-scripting-help-101/?p=830740

[Guest tomm434]

That's strange because I have this case where bloat happens

string_var MYSTRING

begin function {}


            let MYSTRING := "ololo"
            SetFunctionValue MYSTRING

end

This is the bottom of that quicksave

 

 

 

EDIT:

 

In this case even if you sv_destruct string after SetFunctionValue line it will be present in NVSE file. I had to use string in quest and let functions edit it.

 

 

 

[Odessa]

No, that's exactly what is expected to happen. MYSTRING is not a UDF argument, so it bloats.

 

Change your script to this:

...

Begin Function { MYSTRING }   <-- Arguments go in here

...

 

and it will not bloat any more.

[Guest tomm434]

You're right it doesn't thanks!

 

[prideslayer]

Odessa's testing seems pretty thorough, but I still just sv_destruct or ar_null the arguments anyway; the engine seems to make copies for the arguments rather than passing the original values in, so I haven't seen it do any harm, and it's easy to just copy/paste the list of vars from the top of the script to the bottom to catch them all.