Fallout New Vegas GECK & Scripting Help 101

[Guest]

Thank you both for explanation. I didn't know "new-line character" was Return/Enter... I can easily drown in a glass of water, so I was completely misunderstanding the sense of that sentence... shame on me

[nyaalich]

I can easily drown in a glass of water

 

Before or after you've given a ton of good advice on here and possibly figured out the solution for facial expressions?

 

Don't be so hard on yourself. 

[Halstrom]

thank you. Yes i don't mind to be spammy because I use them only while I'm looking for mistakes. Is there a way to visualize automatically its text value instead of hex value? or should I GBO the hex value?

 

EDIT: nyaalich, %i gives the name of the ref as text or ... ffxxxxxx?

 

Just remember to provide a toggle or disable/remove it when you've finished debugging, as some of us modders do our testing with all mods active and, having the console cluttered with other mods debug messages and no way to turn them off gets annoying

You can always grab a SCR debug number if you don't have MCM in the mod

[Guest]

I just had a bad experience, just like everytime I use new things without really knowing what I'm doing.

 

I'm working on a ESM + ESP, the ESM contains UDF so there's no way to test it without the ESP. ESP calls ingame UDF and sees if everything is ok. But both files need to be tweaked in GECK. So what I was doing was loading them both in GECK and set Active the one I was going to modify in that session, then switch the flag and reload when need to modify the other file etc.

The result is I managed to stick the ESP as master of the ESM which crashes FNVEdit too... I never thought a ESP could become a ESM's master, really. I'll scratch my work and take back the backup, because I don't know if some ESP record remained in the ESM so I feel that erasing the relationship with TESSnip won't really solve, I don't want to risk.

 

Anyway, excluding the fact that I'll never load my ESP again when I flag the ESM as master, is there something I must be aware of modifying masters in GECK? some limitation? like this post from Zippy, I can't understand what it means but I feel is important.

 

And by the way, this is for those working on a core like sexout.esm: since it doesn't do a lot on its own, how to you test it? you install a random SO plugin and then everytime you go out and test in game? how can you manage mistakes on your esm if you don't load the esp together to double check that the wrong results are not related to the esp instead that your esm?

 

Thank you

[t3589]

@ A.J.  Open two gecks?  One with the esm, one with the esp.  If you make changes in the esm, close and reload the esp(in a new geck) before making any changes in it.  That's how I'd probably do it.  I'm guessing lots of debug info is the way to test. SCOF maybe?

[Odessa]

Since you were switching between active .esm and active .esp, you might have accidentally edited a record in the .esp whilst the .esm was set active (and the reverse) creating the 2-way mastering problem. If you can still open it with TESsnip deleting that record may fix it.

 

I believe that the GECK does not officially support editting .esm, it is only possible due to a hack in the PU, and its problematic. I never do it, I do all my edits to an .esp, then I convert that to a seperate .esm file every time I test it- a little more long winded but its been reliable. I think it is a bad idea to ever have an .esp open in the GECK if it is not active.

 

It sounds like your .esp and .esm are not very clearly seperated in scope, my 2 cents would be to rethink the design.

[Guest]

T, I can't open two GECKS, it doesn't allow me. Maybe I should replicate two entire NV folders and use two different icons for GECK, but well I'm not sure if it really deserves the effort...

 

Yes Odessa I think I did that, I modified a record in the ESP while ESM was active or viceversa, that's why I preferred taking back the backup instead that inspecting, I could have missed something and maybe notice the issues only after few more days of works. I also never used to modify ESMs in the past, but this time it's almost necessary... the ESM itself doesn't do anything but needs a lot of tweaking continuously. I'm having weird results so to double check them I often modify the ESP too adding redundancy to see where I did mistakes, if in the ESM or in the ESP... I know it could sound strange, but when the game gives me weird results, I tend to have doubts in every line I write to see if I really did some dumb mistake. Like in this case, the scripts tells me a variable should take a certain REF value, while instead in game it assumes the value of another variable. It seems one of these rare glitches I've seen in the past, but until I really prove that I prefer saying I did a dumb mistake and I don't see it...

[t3589]

Odessas way sounds easiest.

 

Anyway you can open your geckcustom.ini and change bAllowMultipleEditors=0 to bAllowMultipleEditors=1 to open multiple editors.

[Guest]

very nice clue, I didn't know that, thank you very much

[nyaalich]

Stupid Question:  If you mark a quest as start game enabled but the conditions on the quest haven't been met yet, the quest script does run normally before the PC has technically started the quest, yes?  I want to trigger a quest 3 days after another quest has been competed, and I want to make sure that the new quests script will properly check the time until it enables the variable that indicates that 3 days have passed.

[nyaalich]

And while I'm here... the zoomed in dialogue in the box is only for the Topics tab of a quest, yes?  Any of the other tabs is basically what NPCs say to each other or to you without the dialogue menu, right?

[Halstrom]

Personally I've never experienced an issue editing esm's in GECK, I do it all the time with SCR, Pregnancy, Offspring & Drugging, sometimes I'll make edits in SCR from the Pregnancy esm in the GECK then use FNVEdit to copy over the changes to SCR.esm and then remove the edits from Pregnancy, only time that doesn't work is if I want to add new assets to SCR then I have to do it in SCR. Early versions of GECK/PU couldn't edit esm's at all so people had to work in esp's then convert them to esm.

[prideslayer]

I know I've asked this question before, but I can't find the answer and don't remember what it was.

 

Regarding UDFs, if I create one in the Sexout ESM, can mods that have sexout as a master call it?

 

Also, where'd Doc's "new fangled" NVSE tutorials go? I thought this was addressed in one of them.

[Odessa]

Doc's tutorial: http://www.loverslab.com/topic/26802-tutorial-nvse4-part-2-user-defined-functions-udfs/?do=findComment&comment=783228

[jaam]

Yes, your UDF will be available. I have been toying with the idea of converting SexoutNGSanitizeScriptNX into multiple calls to the same generic UDF, so ther mods could calculte and reuse the same NX vars in their conditions.

Did'nt start yet though.

 

[Guest]

Is it only my impression or NVSE makes some sort of "filter" ? I mean, I'm playing with UDFs and I call so many times null refs as parameters, but instead that some CTD I only find explicit errors in console "hey you, you're calling null refs!". If it's NVSE doing that, I love it, I love it very much

[Guest tomm434]

Stupid Question:  If you mark a quest as start game enabled but the conditions on the quest haven't been met yet, the quest script does run normally before the PC has technically started the quest, yes?  I want to trigger a quest 3 days after another quest has been competed, and I want to make sure that the new quests script will properly check the time until it enables the variable that indicates that 3 days have passed.

 

What do you mean by "Conditions of the quest?"

 

I have quest which is enabled from the start have a condition there.

 

if GetGameLoaded || GetGameRestarted
    set iIndex to GetModIndex "FalloutTTWquestoverhaul.esp"                                            
    PrintC "FalloutTTWQuestOverhaul loaded at index (hex): %x2 or (dec): %g" iIndex iIndex
endif

I don't start it manually and script works as it should every time I start the game.

[jaam]

Stupid Question:  If you mark a quest as start game enabled but the conditions on the quest haven't been met yet, the quest script does run normally before the PC has technically started the quest, yes?  I want to trigger a quest 3 days after another quest has been competed, and I want to make sure that the new quests script will properly check the time until it enables the variable that indicates that 3 days have passed.

 

Quests conditions applies to dialogues in the quest. Not wether or not the quest will run. It is a shortcut to specifying them on every topic.

[nyaalich]

Thanks, jaam.  I had no fucking clue.  That's where reading and assuming differ.  I guess that I don't have to keep putting an obnoxious amount of conditions on every line of dialogue. 

[jaam]

Can be magical with some and / or constructs

 

[Guest]

I guess that I don't have to keep putting an obnoxious amount of conditions on every line of dialogue. 

 

Quest condition saved my mod once, I'm so glad to have found it

[prideslayer]

Jaam, Odessa.. thanks!

 

I'm going to give everyone until the weekend to make sure the current Beta is ok and if so, promote to release, and then undertake some heavy UDF oriented refactoring. The main goal will be to split out the most commonly used stuff that is of use to other mods, so we can settle on an interface that will allow me to modify the guts and introduce fixes without everyone having to change their stuff.

 

First up in that goal will be some simple but useful things. A few off the top of my head should be pretty easy and let me get a new beta out quickly for other modders to test with.

 

fnSOValidActor(ref) -- Umbrella sanity check that an actor is a living adult in the same cell.

fnSOAvailableActor(ref) -- Higher level wrapper for fnValidActor that will also check that the actor is not already in use.

 

Internally I'll also start coding and using these for a bunch of things that are currently spells:

- dressing/undressing

- locking/unlocking (set/clear inuse)

etc.

 

For anyone that's tested, I'm curious about script behavior involving UDFs at frame-end as well. A script that doesn't complete/return in the current frame gets restarted from the top on the next frame. If this happens inside a UDF does it restart the UDF from the top the next frame, or the entire calling script?

[Guest tomm434]

Jaam, Odessa.. thanks!

 

I'm going to give everyone until the weekend to make sure the current Beta is ok and if so, promote to release, and then undertake some heavy UDF oriented refactoring. The main goal will be to split out the most commonly used stuff that is of use to other mods, so we can settle on an interface that will allow me to modify the guts and introduce fixes without everyone having to change their stuff.

 

First up in that goal will be some simple but useful things. A few off the top of my head should be pretty easy and let me get a new beta out quickly for other modders to test with.

 

fnSOValidActor(ref) -- Umbrella sanity check that an actor is a living adult in the same cell.

fnSOAvailableActor(ref) -- Higher level wrapper for fnValidActor that will also check that the actor is not already in use.

 

Internally I'll also start coding and using these for a bunch of things that are currently spells:

- dressing/undressing

- locking/unlocking (set/clear inuse)

etc.

 

For anyone that's tested, I'm curious about script behavior involving UDFs at frame-end as well. A script that doesn't complete/return in the current frame gets restarted from the top on the next frame. If this happens inside a UDF does it restart the UDF from the top the next frame, or the entire calling script?

 

In theory if you want to use completely new system, you can make a script for FNVedit which transforms old esp scripts on new ones. Just saying...

[prideslayer]

 

Jaam, Odessa.. thanks!

 

I'm going to give everyone until the weekend to make sure the current Beta is ok and if so, promote to release, and then undertake some heavy UDF oriented refactoring. The main goal will be to split out the most commonly used stuff that is of use to other mods, so we can settle on an interface that will allow me to modify the guts and introduce fixes without everyone having to change their stuff.

 

First up in that goal will be some simple but useful things. A few off the top of my head should be pretty easy and let me get a new beta out quickly for other modders to test with.

 

fnSOValidActor(ref) -- Umbrella sanity check that an actor is a living adult in the same cell.

fnSOAvailableActor(ref) -- Higher level wrapper for fnValidActor that will also check that the actor is not already in use.

 

Internally I'll also start coding and using these for a bunch of things that are currently spells:

- dressing/undressing

- locking/unlocking (set/clear inuse)

etc.

 

For anyone that's tested, I'm curious about script behavior involving UDFs at frame-end as well. A script that doesn't complete/return in the current frame gets restarted from the top on the next frame. If this happens inside a UDF does it restart the UDF from the top the next frame, or the entire calling script?

 

In theory if you want to use completely new system, you can make a script for FNVedit which transforms old esp scripts on new ones. Just saying...

 

Yeah... maybe one day. Right now, this junk is fragile enough without me trying some stunt like that and having it do exactly what I incorrectly told it to do.

[DoctaSax]

 

For anyone that's tested, I'm curious about script behavior involving UDFs at frame-end as well. A script that doesn't complete/return in the current frame gets restarted from the top on the next frame. If this happens inside a UDF does it restart the UDF from the top the next frame, or the entire calling script?

 

In the early stages of Spunk I did a few stupid things that stretched the damn system, like running everything off nested UDFs in loops etc, but never saw a UDF not finish. Instead, there was just some lag until everything got done.

I'm assuming, if a UDF didn't get to finish, it wouldn't start itself over again, being one-frame only, but as said, I never saw it happen quite like that.