Jump to content

Fallout New Vegas GECK & Scripting Help 101


Recommended Posts

I know you can restore some windows default settings erasing GECK inis inside My Documents - so in the same way, maybe there are specific lines to add to the inis so that the windows are bigger? I really don't know, I never had reasons to poke with that...

Link to comment

I know you can restore some windows default settings erasing GECK inis inside My Documents - so in the same way, maybe there are specific lines to add to the inis so that the windows are bigger?

Nah, it's hardcoded, the inis only store information to say last window size and position (which also works only for some of the windows).

 

 

I really don't know, I never had reasons to poke with that...

I usually prefer most of my open windows fullscreen :) It is very annoying to scroll through small lists with a large number of items instead of maximizing them to see more at once. Well, whatever...

 

And speaking of that MessageBox menus — made it with a pseudo-quest with pseudo-stages. Works fine on debug tests, haven't tested it in actual action although. Main disadvantage — you can only have one copy at a time (i.e. no nesting), otherwise the quest variables will be just overwritten. Could be probably implemented with nested arrays, but I think I've had enough of GECK-induced frustration for now :)

Link to comment

I think you could duplicate the quest with TempCloneForm. Things would get deep though ;).

Hmm, hadn't thought of this, thanks!

Didn't know you could do that to a quest and reference it, well, as a reference either :)

And if I do a TempCloneForm of a Quest inside a function call will it auto-destruct on function end?

Link to comment

TempCloneForms persist until you quit game, so you would need a GetGameRestarted block to handle save/loads. You would also need to use the 'Get|SetVariable' functions to access its variables externally (and store them elsewhere if they need to persist).

 

Its something I've been wanting an excuse to use for a while, but there are usually better suited alternatives.

Link to comment

TempCloneForms persist until you quit game, so you would need a GetGameRestarted block to handle save/loads. You would also need to use the 'Get|SetVariable' functions to access its variables externally (and store them elsewhere if they need to persist).

 

Its something I've been wanting an excuse to use for a while, but there are usually better suited alternatives.

Okay, GECK/NVSE really needs some well organized manual, otherwise you just tend to learn a useful function after you've already created a couple of ugly script crunches :)

 

About that TempCloneForm. What I meant to ask — if I do something like this:

scn SomeFunction
ref rQRef
begin Function {}
  let rQRef := TemCloneForm SomeQuest
  ;do stuff
end
what will happen to this cloned quest since it won't be accessible any more? I'm just thinking from a programmer's (which I'm actually not) point of view: memory leaks and all :)
Link to comment

 

Okay, GECK/NVSE really needs some well organized manual, otherwise you just tend to learn a useful function after you've already created a couple of ugly script crunches :)

A certain amount of NVSE documentation was written by a daemoness who gathers power more you struggle and bang your head against the monitor.

 

And another amount was written by Odessa, so careful to what you write or I'll shoot you on sight.

 

 

 

I'm kidding of course.

 

 

Link to comment

By default it will leak. If you are worried, just store the rQRef in a quest variable.

Ok, thanks :)

 

A certain amount of NVSE documentation was written by a daemoness who gathers power more you struggle and bang your head against the monitor. 

And another amount was written by Odessa, so careful to what you write or I'll shoot you on sight.

Ookay, shutting up :)

I think I've read most of the mentioned tutorials. Probably I'm just kinda spoiled by mainstream programming languages, in part of documentation department :D

Link to comment

All right, a little bit of frustration... again :)

 

This:

SetModLocalData "MyMod:Version" 1
int iMyModVersion
let iMyModVersion := GetModLocalData "MyMod:Version"
Works fine.

 

This:

SetModLocalData "MyMod:Name" "Some Name"
string_var strMyModName
let strMyModName := GetModLocalData "MyMod:Name"
Gives an in-game error on let.

What am I doing wrong?

Link to comment

You found a bug in NVSE. Guess I forgot to check string_var when I tested it before. I'll let jaam know.

 

There are two workarounds you can use:

 

set my_string_var to GetModLocalData "whatever key" ; # use set instead of let.

 

let My_Array := GetAllModLocalData

let my_str := My_Array["whatever key"]

Link to comment

You found a bug in NVSE. Guess I forgot to check string_var when I tested it before. I'll let jaam know.

 

There are two workarounds you can use:

 

set my_string_var to GetModLocalData "whatever key" ; # use set instead of let.

 

let My_Array := GetAllModLocalData

let my_str := My_Array["whatever key"]

Oh, OK, good to know. I've spent about 20 minutes randomly changing stuff trying to figure out where I'm stupid. Thanks! :)

 

Btw, are you checking up on "The Sexoutng Api" thread? I've had a question there regarding some of the Sexout internals (managing NPSs orientations), an answer from the developer's point of view would be really appreciated :)

Link to comment

Another weird thing.

If I create a message in GECK, for example, MyMessage: "%n doesn't like you", and then try to bring it up with a script:

ref rActor
let rActor := SunnyRef
ShowMessage MyMessage rActor
leads to an instant crash to desktop.

I know I can use MessageEx instead, just wanted to know if this is a bug or a feature.

Link to comment

Out of curiosity, I did few more tries and it's not the only strange thing of ShowMessage. If you put the same in the lower box (the one to make a menu), it will want a "time" value as first parameter, which makes no sense. However it won't CTD since it seems to ignore the format notation. While on the upper part (the message one), %n is not the only one ignored. I just tried a carriage return and it doesn't work.

 

That thing on the wiki was written in the days of FOSE, it's relative to FO3, it would have been interesting to test it with it. I just tried but my FO3 decided to refuse to start and I've got not much will to reinstall it.

Link to comment

I'm wondering if there is a way to have GECK trace the complete inventory value of a given container. I'm tyring to make a caravan runner's mod here and for that it's crucial that the game figures out the total value of the transported goods. I could just go ahead, add all items to formlists and use those, but let's be honest, that takes way too much time (not to mention that only vanilla items can be included that way.)

Maybe someone has found the piece of code where the game shows the caps to be transferred during barter somewhere in GECK?

Link to comment

A.J., as far as I remember there was a note somewhere that formatting doesn't work on buttons for vanilla MessageBoxes. Well, whatever, it's just easier to switch to MessageEx and MessageBoxEx, which at least don't cause CTDs :)

 

pepertje, from a noticeable lag on opening a heavily populated container I'd say it evaluates its total value on every open. Can be easily done with a "foreach rItem <- rContainer" and maybe stored in some cache until the container is updated? If it's a custom made container you could probably assign some events to it, I'm not sure, speaking from a-sorta-programmer's point of view, the game most of the times has its own apprehension on how things should run, which is frustrating at least :)

Link to comment

Another unobvious issue.

 

Let's say I have a stringmap array:


scn SomeQuestScript

array_var arrActorsArray

begin GameMode
  let arrActorsArray := Ar_Map "refs"::(Ar_Construct "array") "values"::(Ar_Construct "array")
  let arrActorsArray["refs"] := Ar_List PlayerRef SunnyRef ButchRef
  let arrActorsArray["values"] := Ar_List 10 20 30
end
And then I have to access it from some function. This:


scn SomeFn

begin Function {}
  if eval (SomeQuest.arrActorsArray) ;Check 1
    if eval (SomeQuest.arrActorsArray["refs"]) ;Check 2
      ;do stuff
    endif
  endif
end
will fail the second check (or maybe crash on it internally, I'm not sure, no errors are given).

 

And this:


scn SomeFn

array_var arrActors

begin Function {}
  if eval (SomeQuest.arrActorsArray) ;Check 1
    let arrActors := SomeQuest.arrActorsArray["refs"]
    if eval (arrActors) ;Check 2
      ;do stuff
    endif
  endif
end
will evaluate as expected (i.e. passes both checks).

 

Is it a bug or a supposed behavior? Because this, for example:

foreach arrEntry <- SomeQuest.arrActorsArray["refs"]
works just fine...
Link to comment

When you use:

 

Array["key"]

 

NVSE expects "key" to exists, I am surprised you don't get a runtime error in the console, you usually do.

 

You should use either:

 

if Ar_HasKey Array, "key"

 

or

 

if TestExpr Array["key"] ; sort of like Try/Catch

 

if you are unsure whether "key" exists.

 

----

 

In your first function, you pointlessly initialize the nested arrays, then overwrite them with Ar_List- which creates a new initialized array.

Link to comment

When you use:

 

Array["key"]

 

NVSE expects "key" to exists, I am surprised you don't get a runtime error in the console, you usually do.

 

You should use either:

 

if Ar_HasKey Array, "key"

 

or

 

if TestExpr Array["key"] ; sort of like Try/Catch

 

if you are unsure whether "key" exists.

Thanks for the tip on checking for keys, although what I meant was checking whether an array SomeQuest.SomeArray["key"] was initialized or not (the keys are auto created on Quest first run, but the enclosed array may be null under certain conditions). So the question was why eval doesn't work correctly for "SomeQuest.SomeArray["key"]" but works for "SomeArray2" when the second just references the first?

The arrays are supposed to exist and be filled with data at the point of execution (unless they're not, hence the check) and I've noticed this inconsistent behavior when a cleanup function never fired. But after introducing a "shortcut" variable everything started to work fine. I don't know, maybe eval just doesn't support the "long" syntax, but it's not mentioned anywhere...

 

 

In your first function, you pointlessly initialize the nested arrays, then overwrite them with Ar_List- which creates a new initialized array.

Hmm, I'm still not quite sure about the correct syntax on how to create an empty stringmap array with specific keys which should be filled with data later on. Which way will be the most correct?

 

let arrMapArray := Ar_Map "key1" "key2" ;will this even work?

let arrMapArray := Ar_Map "key1"::Ar_Null "key2"::Ar_Null

let arrMapArray := Ar_Map "key1"::(Ar_Construct "array") "key2"::(Ar_Construct "array")

Link to comment

Hmm, I think I've found a bug. Running:

ref rQuest
float fVal

if HasVariable "SomeVar" rQuest
  let fVal := GetVariable "SomeVar" rQuest
  DebugPrint "SomeVar = %.5f" fVal
endif
on a null reference (i.e. rQuest hasn't been initialized yet) will always return true for HasVariable.
Link to comment

Would the quest containing the script have a "SomeVar" variable?

if rQuest is null, the calling script is checked for the variable, just like if you called SomeQuest.HasVariable "SomeVar"

 

I saw the issue in the source code, you were right.

 

 

Link to comment

I was checking random stuff, so the calling quest did contain only some of the variables. Even when randomly typing something like "if HasVariable "hguryw3kuh" rQuest" and "let fVal := GetVariable "jb435g3jk7" rQuest" it did return true and 0 in case rQuest was a null reference.

The reason I've noticed it was that I forgot to call rQuest initializing function first and then was trying to debug why did I always get zero instead of an actual value? :)

Link to comment

There's some weird thing with the way packages work I can't understand.

 

What I'm trying to do is quite simple: if a quest variable is in particular range the NPCs should play an idle defined in the package. The package includes those conditions. "Must complete", "Must reach location", "Continue if PC near" are unchecked, package type is Wander, location is "Near current location" with a small radius.

 

To add a package I use:

rActor.AddPackageAt MyPackage 0
rActor.EVP
and that works fine (most of the time, any way).

To remove I use a function (just to be safe in case something went wrong and there is more than one copy):

 

 

scn FnRemoveScriptPackage

; Args
ref rPackage

; Local vars
ref rMyself
int iPackagesCout
int iPackageIndex
ref rCurrentPackage


begin Function {rPackage}
  let rMyself := GetSelf
  let iPackagesCout := rMyself.GetPackageCount
  let iPackageIndex := iPackagesCout - 1
  while iPackageIndex >= 0
    let rCurrentPackage := GetNthPackage iPackageIndex
    if rCurrentPackage == rPackage
      rMyself.RemovePackageAt iPackageIndex
    endif
    let iPackageIndex -= 1
  loop
end

 

and call it:

rActor.call FnRemoveScriptPackage MyPackage
rActor.EVP
And for some actors it works fine, but for others (especially companions) the animation from the added/removed package keeps playing even after the package has been removed (GetCurrentPackage returns a correct vanilla/companion's appropriate package in console output). EVP and ResetAI don't help in any way, but if you talk to them or initiate a combat nearby — the correct package immediately kicks in.

 

 

******

 

Another animation-related question.

If certain conditions are not met, the PC is supposed to sit and wait. I restrain him with "DisablePlayerControls 1 1 1 0 0 0 0" and add a new idle with conditions "GetIsId NPC:Player == 1" AND "GetQuestVariable MyQuest.iStage > 50" AND "GetQuestVariable MyQuest.iStage < 200". It works mostly fine, but is not completely reliable, i.e. it sometimes takes a while for the animation to kick in, and the PC keeps to interrupt animation and stand up for a couple of seconds from time to time.

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