Fallout New Vegas GECK & Scripting Help 101

[prideslayer]

If your script name starts with an underscore, it's compiled with the NVSE compiler instead of the geck compiler. It can fix issues with scripts that won't compile, sometimes.

[nyaalich]

@tomm:  Topic 5.  If a block name starts with an underscore it bypasses the GECK's compiler.  Is that also the case with the script's name?  I did not see mention of that.

[prideslayer]

Oops that's right, block name, not script name.

[DoctaSax]

Slight addendum to the big post I once made about playidle and why it is so much better.

In the past I always specified the anim to play directly in the script because that's how my tests went & that's how had to implement it in sofo, the anims being part of specific scenes that involved other things that needed specific scripting. Now that we're looking into a playidle system for sexout the need arose to use it with a variable instead of pointing to the anim ID directly.

Playidle does not take a ref var as parameter. In fact it probably never took forms at all. What it does take as parameter is the EditorID string.

 

So if you go:

 

string_var sv_name

 

let sv_name := "DanceFemaleFidget02" ; or however you want to retrieve the string, like pull it out of an array

playidle $sv_name

 

you're all set.

[jaam]

 

- You can now save scripts without compiling them (useful if you want to save your script and finish it later).

The absolute horrors this is going to introduce, I'm almost certain.

 

 

That has been around since the very first version 3 or 4 years ago

 

I am more interested in the next to last change: Leaving loaded esp as masters when saving.

[Odessa]

On save w/o compiling: if you have never saved the script with compiling, it seems to disappear. Or at least I found that to much frustration.

--

 

@ prideslayer: compiler override also lets you do all manner of cool stuff like this:

array_var entry ; * I dont need any more vars because I enjoy a challenge in debugging *
 
foreach entry <- (ar_List ClothesFormList, HatsFormList, WeaponsFormList)
     Player.AddItemHealthPercent (ListGetNthForm entry["value"], (Rand 0, (ListGetCount entry["value"]))), 1, (Rand 0, 1)
loop

------------------------

 

 

 if eval ( (Call tsolIsActorInUse rTrickGirl) || (rTrickGirl.NX_GetEVFl "Sol:Busy") || (rTrickJohn != 0 && (Call tsolIsActorInUse rTrickJohn)) )

 

After over an hour of debugging, this above line causes my quest script to break and never run again, at all (first line is printc), even if I load game, although getquestrunning returns true. (it may have run a few times prior without reaching the line).
 

I'm starting to get the feeling UDFs need to be used gently. Incidentally, each one of those in turn calls the sexout is-actor-in-use UDF.

[prideslayer]

I'm really hesitant at the moment to pack such complicated expressions on a single line; I break them up into several lines, make sure it works, combine slowly if warranted -- usually I'll leave them as single lines for readability until I start running into script length issues or something.

[nyaalich]

I've never been able to save w/o compiling.  However, s/he doesn't update their release notes well.  I do believe that that feature has supposedly been there for a long time.

[prideslayer]

Speaking of powerup, is this error about "characters\_male\idleanims" normal when opening the idles with just the FONV ESM loaded? I may have just been blindly clicking "yes yes yes yes" to everything when opening the geck, or I may have boned my ESM somehow.

 

MODEL ERROR: Could not laod file 'Characters\_Male\IdleAnims'

 

Origin: 004C1A4A

"Yes to all" will .....

Don't remember seeing that before, but probably have and just went tone deaf to it.

[nyaalich]

I believe that I get that message whenever I try to use the render window.  Doesn't seem to like the body replacers.

[DoctaSax]

 if eval ( (Call tsolIsActorInUse rTrickGirl) || (rTrickGirl.NX_GetEVFl "Sol:Busy") || (rTrickJohn != 0 && (Call tsolIsActorInUse rTrickJohn)) )

 

After over an hour of debugging, this above line causes my quest script to break and never run again, at all (first line is printc), even if I load game, although getquestrunning returns true. (it may have run a few times prior without reaching the line).

 

I'm starting to get the feeling UDFs need to be used gently. Incidentally, each one of those in turn calls the sexout is-actor-in-use UDF.

 

 

I'm really hesitant at the moment to pack such complicated expressions on a single line; I break them up into several lines, make sure it works, combine slowly if warranted -- usually I'll leave them as single lines for readability until I start running into script length issues or something.

 

This seems to be mostly a problem with complex if eval lines, especially with logical operators. I can't quite put my finger on the cause - I don't think the line size limit should be kicking in by then, that's more of a concern with strings taking up a lot of space, not so much a factor with functions and udf calls.

Another concern is that some of those sub-expressions don't necessarily return a boolean; it might be worth trying them in the context of a comparison like:

if eval ( (1 == Call tsolIsActorInUse rTrickGirl) || (1 == rTrickGirl.NX_GetEVFl "Sol:Busy") || (rTrickJohn != 0 && (1 == Call tsolIsActorInUse rTrickJohn)) )

etc

No guarantees though. At all. Also if you're running this in a CO block, you want to add more parentheses, like ((rTrickJohn != 0) && etc), possibly even (rTrickGirl.NX_GetEVFl "Sol:Busy")

 

@pride: I think the anim warning is really just the top folder not having a specific kf file set, and PU being unable to tell that this is not a problem. Shouldn't affect or have affected your esm - I get it even with just the fallout esm.

[nyaalich]

@pride:  I checked.  Just for you.     Got other issues going through stuff with just NV loaded, but not that one.

[prideslayer]

@pride: I think the anim warning is really just the top folder not having a specific kf file set, and PU being unable to tell that this is not a problem. Shouldn't affect or have affected your esm - I get it even with just the fallout esm.

 

@pride:  I checked.  Just for you.     Got other issues going through stuff with just NV loaded, but not that one.

*shifty eyes*

 

I get it with just FalloutNV as well. Nyaa, you don't? Doc and I both boned our vanilla ESMs the same way somehow?

[DoctaSax]

 if eval ( (Call tsolIsActorInUse rTrickGirl) || (rTrickGirl.NX_GetEVFl "Sol:Busy") || (rTrickJohn != 0 && (Call tsolIsActorInUse rTrickJohn)) )

 

After over an hour of debugging, this above line causes my quest script to break and never run again, at all (first line is printc), even if I load game, although getquestrunning returns true. (it may have run a few times prior without reaching the line).

 

I'm starting to get the feeling UDFs need to be used gently. Incidentally, each one of those in turn calls the sexout is-actor-in-use UDF.

 

As an alternative to breaking up the whole line in elseifs to avoid possible trouble with complex if evals, you may also try 'letting' it to a boolean and then checking that:

 

let bInt := ( my <= ((complicated > (call whateverUDF somestringmapelementparameter["for giggles"]) * expression)) || something != Idunno)

if bInt

  ; party

endif

 

[nyaalich]

I have boned other things about my game.  Not that one.

 

Considering that you both have been at this much longer than I have, you have had more time to bone your ESM. 

[Odessa]

Another concern is that some of those sub-expressions don't necessarily return a boolean;

 

I may be incorrect, by my assumption is that all types in fallout script are booleans, and there is no distinct boolean type- so you can use anything that returns something in an 'if eval' function, so:

 

if eval (Player.GetEquippedItem 2) ; *  or

 

if eval (NX_GetRandom 0, 3) ; * is fine, but not:

 

if eval (MessageEx "I assume this returns nothing")

[prideslayer]

That's true, but you're not evaling all that in the code you pasted..

 

if eval ( (Call tsolIsActorInUse rTrickGirl) || (rTrickGirl.NX_GetEVFl "Sol:Busy") || (rTrickJohn != 0 && (Call tsolIsActorInUse rTrickJohn)) )

e.g. in that first ||, they aren't being eval'd before being or'd, so if they're not boolean results, it may not work as expected. To be absolutely safe you'd have to do

 

if eval (eval(Call tsolIsActorInUse rTrickGirl) || eval(rTrickGirl.NX_GetEVFl "Sol:Busy") || (rTrickJohn != 0 && (eval Call tsolIsActorInUse rTrickJohn)) )

or

if eval ((0 != Call tsolIsActorInUse rTrickGirl) || (1 == rTrickGirl.NX_GetEVFl "Sol:Busy") || (rTrickJohn != 0 && (Call tsolIsActorInUse rTrickJohn)) )

It gets so cumbersome and guessworky that it's just easier to split them up, into local vars if you don't want to do a nested if.

[Halstrom]

Hmm I was under the impression for some reason in an if function you couldn't mix && and || even with bracketing, so have used variables to avoid doing so and it makes things more readable for me too not having an if that's 50% not shown off the edge of the page unless I scroll horizontally.

[prideslayer]

horizontal scrolling is the worst, but as far as I can tell, you can mix them just fine with the right parens.

[Guest tomm434]

 

Slight addendum to the big post I once made about playidle and why it is so much better.

In the past I always specified the anim to play directly in the script because that's how my tests went & that's how had to implement it in sofo, the anims being part of specific scenes that involved other things that needed specific scripting. Now that we're looking into a playidle system for sexout the need arose to use it with a variable instead of pointing to the anim ID directly.

Playidle does not take a ref var as parameter. In fact it probably never took forms at all. What it does take as parameter is the EditorID string.

 

So if you go:

 

string_var sv_name

 

let sv_name := "DanceFemaleFidget02" ; or however you want to retrieve the string, like pull it out of an array

playidle $sv_name

 

you're all set.

Do you mean that reffering to something first and using reference later is better?(more optimized)

[DoctaSax]

No, I mean that the playidle function doesn't take a form as parameter, it takes the actual editorID string. So you can't park the idle to play in a ref var, but need to stick it in a string var. This was new to me.

 

I used to write things like

playidle DanceFemaleFidget02

and it worked because I wrote the editorID string, I just thought the game would translate that to a formID, just like practically every other editorID you use in scripts. It doesn't. (And actually, for sexout that's a good thing.)

[Guest tomm434]

No, I mean that the playidle function doesn't take a form as parameter, it takes the actual editorID string. So you can't park the idle to play in a ref var, but need to stick it in a string var. This was new to me.

 

I used to write things like

playidle DanceFemaleFidget02

and it worked because I wrote the editorID string, I just thought the game would translate that to a formID, just like practically every other editorID you use in scripts. It doesn't. (And actually, for sexout that's a good thing.)

 

oh, ok. I asked because now I'm doing script like this

If player.getinworldspace WorldSpace1 ==1 && getquestrunning Quest1 ==0
startquest Quest1
endif

If player.getinworldspace WorldSpace2 ==1 && getquestrunning Quest2 ==0
startquest Quest2
endif

If player.getinworldspace WorldSpace3 ==1 && getquestrunning Quest3 ==0
startquest Quest3
endif

If player.getinworldspace WorldSpaceN ==1 && getquestrunning QuestN ==0
startquest QuestN
endif

The quest will always run and check for these variables. I don't know how many N's there will be yet.

 

Do you think it would be better to use arrays for this? (in terms of optimization)

[DoctaSax]

I don't really see a specific benefit with using arrays there. Besides you'd need dual ones because you can't use forms as keys.

[Guest tomm434]

I don't really see a specific benefit with using arrays there. Besides you'd need dual ones because you can't use forms as keys.

 

=(. Ok.

[nyaalich]

If you haven't already, you should check out Doc's tuts.  They're in his sig.  He's got GREAT tuts.  *obnoxious over-the-top wink*