Tutorial: NVSE4+ part 3: String variables

[DoctaSax]

Ah, if you passed it as an actual string instead of a string var, don't bother.

[Guest tomm434]

Oh thanks! What a relief.

[Odessa]

 

The code from calling script is

 

call aaraiderFunctionSex Oral

And this string is only present in function.

 

!

 

Oral is a global int constant added by sexout.

 

call aaraiderFunctionSex Oral

 

== call aaraiderFunctionSex 3

 

!= call aaraiderFunctionSex "Oral"

[Guest tomm434]

Odessa, you mean that it's bad to type Oral without brackets?

[Odessa]

No, unquoted arguments are converted to a string by the compiler, but only if the text isn't a recognized term.

 

If you have Sexout as a master, then it adds the following global constants (unchangeable variables accessible from everywhere)

 

Vaginal == 1

Anal == 2

Oral == 3

 

so,

int iSexType

let iSexType := Oral

 

iSexType == 3

 

string_var sex_type

let sex_type := Oral

 

sex_type != "Oral"

 

---

You should always quote what you intend to be a string.

[Guest tomm434]

I still don't understand. I feel like I'm wasting your time.

 

I just looked at my code and I always put brackets

call aaraiderFunctionSex "Oral"

Without them code doesn't comply.

[Odessa]

You mean "" quotes? Yeah, thats fine. But, if you leave the quotes out then Oral is replaced with the int 3, if sexout is a master. In the days before string_vars were available it meant you could do:

int SexType

set SexType to Oral

if SexType == Oral

 

which is more readable than:

set SexType to 3

if SexType == 3

 

In the same way you might do:

int GetNextActor

set GetNextActor to 1

Label GetNextActor

 

instead of just:

Label 1

 

With NVSE4 and string_vars there isn't a need for this, but I noticed you skipped the quotes in an example you posted and thought it might catch you out.

[Guest tomm434]

I understand now, thanks.

[Guest]

I have a problem but not sure it's possible, maybe I'm asking too much from udf and strings

 

    let sv_TmpVar := "MRPVar.MRP" + sv_Part
    PrintC "My MRPVar is %z" sv_TmpVar

    let MRPTmpValue := sv_TmpVar

 

sv_TmpVar shows the exact name of a quest.var, but the value isn't passed to MRPTmpValue since I guess I can't do something like that... I tried with $sv_TmpVar too.

I can't use CO because it's a UDF, unless there's a way I don't know to override it. I tried _function and it doesn't work.

 

Is this possible?

[Odessa]

You can use CO in a UDF like any other script: Begin _Function { }

 

If it doesn't work, I think you have a syntax error somewhere. That code excerpt looks okay to me, assuming you have declared the 3 vars as string_var.

[DoctaSax]

What is MRPTmpValue meant to be? If it's anything other than a string, 'let' won't let you.

You may be able to use the GetVariable, GetRefVariable, SetVariable etc functions though.

 

let somefloat := GetVariable "variablenamestringorstringvar" QuestID

; change variablestring

SetVariable "variablenamestringorstringvar" somefloat QuestID

 

CO can be used in a UDF, same as any other non-result script.

 

 

EDIT: forgot 'somefloat' in the set-line

[Guest]

Thank you both, CO wasn't compiling because it's the same mistake:

let MRPTmpValue := $sv_TmpVar

this doesn't compile in both the cases because MRPTmpValue was Int

 

Solved with GetVariable, thank you both 

 

On a side note, it's incredible how you can reduce scripts so much with UDFs used in this way... I just pass part of the name to the UDF and it constructs the rest of the name and executes functions. Let's see how much I'll remember these shortcuts the day I'll have to modify the code

 

Oh and congratz to the one who updated Beth guide with these new stuff, pretty sure it's one of you two

[DoctaSax]

Kudos to Odessa for that.

[Guest]

I'm using an external quest.script to store some string variables (created by UDFs). These are one-shot variables, and I would use them like this:

 

Main script:

...

Call a UDF which creates the string and put the value in the quest.string

Call a Spell referring to that quest.string

Call another UDF referring to the same quest.script

 

Call the first UDF to construct another string and put the value in the same quest.string (overwriting it)

Call the spell referring to nthe new value of quest.string

etc.

...

And again, and again, everytime I need it. As you can see, the string is some sort of temporary value used by my spell, and it will be over-written everytime I invoke it in the main quest. So, potentially, it always has only a value a time. Do I still need to destruct them everytime I do that?

[Odessa]

I added NVSE to the wiki, but DoctaSax is the primary source for a lot of the info .

[DoctaSax]

I'm using an external quest.script to store some string variables (created by UDFs). These are one-shot variables, and I would use them like this:

...

Do I still need to destruct them everytime I do that?

 

Better safe than sorry.

 

[Guest]

Thank you

[prideslayer]

Doc (or anyone who knows),

 

Does the need to sv_destruct apply to strings passed in as params to a UDF, that you did not assign or construct yourself?

 

I have a few like this that are not being destroyed that might be the cause of some .nvse bloat.

 

Ex.

scn fnSexoutSetRVal

; args
ref rTarget
string_var svName
ref rVal

; internal
string_var nxKey

Begin Function{rTarget svName rVal}
  if (1 == IsReference rTarget)
    let nxKey  := "Sexout:Values:" + svName
    rTarget.NX_SetEVFo $nxKey rVal
    sv_destruct nxKey
  endif

  sv_destruct nxKey
  
  SetFunctionValue 0
End

Should I also be destroying svName?

[Guest tomm434]

Since it's a parameter to your UDF, you shouldn't have to. But it has to be destroyed in the calling script when you're done with it.

 

[Odessa]

According to the documentation you don't have a to sv_destruct udf arguments. This might be worth checking though.

 

Incidentally, I did a bit of testing with args a while back and discovered that all modification of arguments within a UDF are local to the UDF only. If you do sv_destruct an arg its harmless and won't affect the calling script's string_var.

[prideslayer]

Thanks.. as it's harmless, I think I'll "just do it" anyway. I wasn't sure if that was the case, or if destroying it would affect the caller.

[prideslayer]

According to the documentation you don't have a to sv_destruct udf arguments. This might be worth checking though.

 

Incidentally, I did a bit of testing with args a while back and discovered that all modification of arguments within a UDF are local to the UDF only. If you do sv_destruct an arg its harmless and won't affect the calling script's string_var.

Well, this doesn't seem to be completely true. I went through all my UDFs and added sv_destructs at the end for every string var, now it's CTD city when sexout tries to run. Going to do some more testing.

 

edit: eh could be unrelated, will sv_destruct twice in a row on the same var blow up? I'd rather not have to check for assignment on all of them before calling it, but might have no choice.

 

edit2: ok false alarm it seems, looks like something is wrong with whatever version of sexoutsex or scr, both of which aren't exactly up to date. console sex worked fine.

[Guest]

Curious to notice that this:

Player.Playidle $MyString

works, it's a while I use it. But this is new for me:

Player.AddItem $MyString 1

and it doesn't work.

I'm trying to use CO but it's getting stuck on GetType (if GetType MyRef == somenumber, it doesn't compile).

It's not the first time I have issues like this with CO and everytime I get stuck because it makes little sense for me. It wouldn't be bad to make some sort of "dictionary" with few examples on how to translate a function in the syntax that CO likes.

[Odessa]

That's not the CO, you've made a syntax mistake:

 

Most functions in FNV require a form (Editor ID) argument. A string is not a form, and the compiler can not make sense of it.

 

Since string variables were added, it has been discovered that some vanilla functions in FNV actually take string arguments, not forms- PlayIdle and GetAV are examples of this, AddItem is not.

--

 

On the second part, if the CO is being awkward, try using brackets to seperate your expressions, hence replace:

 

if GetType MyRef == SomeNumber ; ambiguous

 

with

 

if (GetType MyRef) == SomeNumber ; Find Type, then compare to some number

 

In the first example, the CO might be interpretting it the wrong way around, as "GetType (MyRef == SomeNumber)"

[Guest]

So do you think there's no absolutely way to create dynamically the item to add, like I was doing? it would reduce my script of many hundreds lines

 

---

 

On the second part, brackets don't work, it tells I'm using brackets improperly. It's a common issue between GetType and CO I always had, I would love to understand how to solve it, I'm avoiding CO because of things like this