Fallout New Vegas GECK & Scripting Help 101

[Guest tomm434]

I know you can't save a GECK file if you are silly enough to have it open in FNVEdit at the same time, you get all sorts of errors 

 

not that enough I'm not ^^

[Guest]

^^^ I do that everytime. It's hard to loose the bad habits...

 

EDIT: my bad... I mean... LOSE... thank you Astymma

[astymma]

Or lose them

[t3589]

OK I've spent 5 hours now trying to get saytodone to trigger.  I don't get it.

scn SOTestScript

ref rTarget
short doOnce

Begin OnAdd
    set rTarget to GetContainer
End

Begin GameMode
    if (0 == doOnce)
        rTarget.SayTo Player SOTest 0 1
        set doOnce to 1
    endif
End

Begin SayToDone SOTest
    RemoveMe
End

EDIT:  OK I think I've figured it out.  It's too bad too.  But I think that saytodone only works on the object script of the actor.  Poopy.

 

EDIT EDIT: So I went ahead and added my own saytodone using the dialog end results.  Now I don't need to meter audio files playing.  Sweet.

 

Edited May 3, 2014 by t3589

[Guest]

I'm modifying an old script of mine to make it a bit more reliable in most circumstances, this means I'm staging it in a lot of sub-blocks so that if the game is laggy it still SHOULD MOSTLY (...) work even if the script breaks for some reasons.

 

Essentially, this is the script:

 

if stage 1

   set to stage 2

   block1

   return

 

if stage 2

   set to stage 3

   block2

   return

 

etc.

 

Every block is not heavy to be handled and I assume that even the low delay I'm using can handle it. On the other side, I decided to put Return so that it can start every block on a new frame and not breaking the execution for example in the middle of a block

 

Is my thought about Return correct? it's a quest script, I assume it doesn't mess with variable values just because I Return, is it correct?

 

Also, the whole thing is starting to be long (around 500 lines and it's half of what I need to do), is there some limit on the mere lenght which I'm not aware?

 

Thank you

 

EDIT: I have a lot of printC messages, is there a function that saves them on a file so I can inspect them better if something doesn't work? console can't show them all and it would be a good debug mode for users sending to me this sort of "log"

[Guest tomm434]

EDIT: I have a lot of printC messages, is there a function that saves them on a file so I can inspect them better if something doesn't work? console can't show them all and it would be a good debug mode for users sending to me this sort of "log"

"type scof "somefilename.txt" in the console; this will create an output file in your root folder by that name". *C Odessa.

[Odessa]

@AJ: You're correct on return, variables are persistant within an instance of a script (by which I mean, if you have multiple quest/object/spell instances using the same script, the variables of each one are seperate, but they are self-persistant within their runs)

 

There is a script length limit- in my experience, the GECK PU throws an error when you reach it, so you know. I'm not sure what the exact limit is, it varies, I think this is because comments/whitespace don't count, or perhaps its more complex than the actual line total. I've had an MCM script throw the length error at ~480 lines, but others compile fine at ~600.

[Guest]

 

"type scof "somefilename.txt" in the console; this will create an output file in your root folder by that name". *C Odessa.

 

 

and its equivalent con_SCOF, I just found it, thank you very much.

Downside is it doesn't store more than the console itself stores (those few pages of commands), I guess I'll have to invoke it more times

[Guest tomm434]

@AJ: You're correct on return, variables are persistant within an instance of a script (by which I mean, if you have multiple quest/object/spell instances using the same script, the variables of each one are seperate, but they are self-persistant within their runs)

 

There is a script length limit- in my experience, the GECK PU throws an error when you reach it, so you know. I'm not sure what the exact limit is, it varies, I think this is because comments/whitespace don't count, or perhaps its more complex than the actual line total. I've had an MCM script throw the length error at ~480 lines, but others compile fine at ~600.

 

I've got 1036 lines in my script. I'm not proud of it and it complies just fine.

[Guest]

now that's sad. I mean 600, or even 0100 isn't that long. And not really in this specific case, but generally speaking. I could of course split it in 2 quests and activate with startquest, but that's a solution I want to avoid when I can, in the past I found some issues in that (sometimes not starting the quest) and putting redundancy would mean... ok, I'll see that...

[Odessa]

Instead of splitting into 2 quests, you could also use UDFs to reduce script length. NVSE 4 is the stable version now, so I'd say theres no reason not to.

[jaam]

The limits are the number of character, including whitespace, in the source and the size of the compiled script.

I would not be surprised if the number of lines count also ( )

There was also a limit on a given line maximum length, but NVSE should have practically removed it.

[Guest tomm434]

if we're talking about optimizing the script;

 

By default every 5 seconds game checks conditions on quest script.

If MyVariable1 ==1
 do stuff

    if MyVariable2 ==1
      do stuff
    endif
   
    if MyVariable3 ==1
     dostuff 
    endif

     if MyVariable4 ==1
      dostuff
     endif

endif

 And if myVariable1 ==0, will game bother to check myVariable2, myVariable3 and myVariable4 or not?

[nyaalich]

No.  It'll skip it.

[DoctaSax]

The skipping itself also takes up some cpu power though. Depending on what type of script you're in, the overall structure and the probability of conditions being met, you could reverse the first check and add a return:

 

if myvariable1 != 1

   return

elseif ...

endif

 

or use some UDFS to export big chunks of code that only need to run occasionally

 

[Guest tomm434]

No.  It'll skip it.

 

Thanks. Now I'm not worried. It's still a matter of question if some big quest script should be separated in two.

 

For example, I have one big quest with scenes which unclude fade in black effects and I need to use timer for them. Leaving timer in quest is not good for perfomance but what's the diference between separaring this in 2 quests? if they run at the same time, the game checks all conditions anyway.

 

I see only one reason to do that - starting and stopping the quest wjen you need your scenes to play. From my expirience there is always a delay before script starts running. You need to start the quest  before you need a scene to happen and then test it, test it, test it.

it's a shame that UDF scripts only run for 1 frame.

[DoctaSax]

I'd use a spell for that.

Also, timers aren't particularly bad for performance. I know some oblivion guides had people stick that in quests with a ridiculously low fquestdelaytime, but that's not an issue in FNV.

[Guest tomm434]

The skipping itself also takes up some cpu power though. Depending on what type of script you're in, the overall structure and the probability of conditions being met, you could reverse the first check and add a return:

 

if myvariable1 != 1

   return

elseif ...

endif

 

or use some UDFS to export big chunks of code that only need to run occasionally

 

So you say it is better to create additional TOP LEVEL condition so script checks it additionaly than  ..ehm..  not to create it?

I have a lot of scenes in my quest.

If wakeupscene ==1

   If wakeupstage ==0
    do stuff
    set wakeupstage to 1
   endif


   If wakeupstage ==1
    do stuff
    set wakeupstage to 3
   endif

   If wakeupstage ==3
    do stuff
    set wakeupscene to 0
   endif
endif

if dancescene ==1

   if dancestage ==0
    dostuff
    set dancestage to 1
   endif


   if dancestage ==1
    dostuff
    set dancescene to 0
   endif

endif

And I have about 12-15 scenes like that(not always with stages). I always set 1 variable on top level so script only checks for it.

 

Should I create these additional conditions?

If dancescene ==0
return
endif


If wakeupscene ==0
return
endif

Edit. Oh, I didn't see your post. You mean placing spell for  some amount of time, then terminate it when the effect script is done?

[Guest]

The limits are the number of character, including whitespace, in the source and the size of the compiled script.

 

Now this makes me reminding of a weird case I had in the past, oh god... I had like a 350 lines, and other 350 who were skipped by ;

I had a loooot of issues, until I removed all the 350 with the ;

It was one of these cases where explicit errors like obviously bad syntax inside the script started to be compiled...

 

 

@Odessa

I've read Doctasax tutorial, and I've also dreamt about UDF, they charmed me a lot.

But I still can't even use properly the new nvse 4 syntax...

One day, one day I'll be able to use them... just a couple more years and I'll properly learn...

I think I need some sort of hamster on my desk which writes my code in a smarter way, but I doubt I can find them at the mall.

[Guest]

 

For example, I have one big quest with scenes which unclude fade in black effects and I need to use timer for them. Leaving timer in quest is not good for perfomance but what's the diference between separaring this in 2 quests? if they run at the same time, the game checks all conditions anyway.

 

Essentially you should stage your quests with startquest, and not running them both. Something like this:

 

quest 1

   start the scene

   move the actors

   fadetoblack

   stopquest quest 1

   startquest quest 2

 

quest 2

   remove fadetoblack

   continue the scene

   etc.

 

I much or less am using this in this script, also tweaking the quest delay based on how the script block is responsive or visually heavy (like when I create a clone and dress it I increase the delay and I stage it more, when I use IsKeyPressed I lower the delay)

 

now I do that when the scene is pure machinima and the player controls are disabled, because ... the player can still create irrational issues in that kind of timing and script breaks

 

On a side note, I just re-wrote the clone script, if you want to take a look, it "seems" more reliable to my eyes.

[DoctaSax]

Edit. Oh, I didn't see your post. You mean placing spell for  some amount of time, then terminate it when the effect script is done?

Yeah, you handle a specific scene in a spell, dispel when done. That way your quest script only handles the casting of spells if a particular stage condition is met. Don't be afraid to split things up a bit. And while UDFs are incredibly handy, sometimes a good old spell gives you just that right level of control in a repeating script.

Top-level checks adding a few returns: it's never a bad idea.

[Guest tomm434]

DoctaSax, ok, thanks. This seems like a nice idea. Can you tell me what delay is used in spell scripts? Sometimes I need player camera fixed on something and running that script every frame. And for some other scenes timing is priceless.

 

A.J. Interesting. Does it work stable?I'm getting used to checking everything I do in quest script, especcialy in machinima scenes.

[DoctaSax]

spells scripts run every frame

if you don't need the bulk of your code to run that fast, you can slow it down with a top-level timer check, or count

 

if eval ((ftimer += ScriptEffectElapsedSeconds) < somevalue)

   return

else

   let fTimer := 0

endif

 

or something similar with a simple count:

let iCount += 1

if iCount < somevalue

   return

else

  let iCount := 0

endif

[Guest tomm434]

spells scripts run every frame

if you don't need the bulk of your code to run that fast, you can slow it down with a top-level timer check, or count

 

if eval ((ftimer += ScriptEffectElapsedSeconds) < somevalue)

   return

else

   let fTimer := 0

endif

 

or something similar with a simple count:

let iCount += 1

if iCount < somevalue

   return

else

  let iCount := 0

endif

 

There is no such things for Effect script as Delay time for Quest script?

[DoctaSax]

There is no such things for Effect script as Delay time for Quest script?

Nope.