Jump to content

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


Recommended Posts

  • 3 weeks later...
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 =)))

 

Link to comment

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

Link to comment
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

 

post-187071-0-55154600-1429433371_thumb.jpg

 

 

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.

 

 

 

Link to comment

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. ;)

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. For more information, see our Privacy Policy & Terms of Use