Fallout New Vegas GECK & Scripting Help 101

[Odessa]

 

I've heard of that. I might look it into it with future mods. I expected more people telling me to not use AddToLeveledList to be honest, I've heard a lot of people say its bad to use it. 

 

 

There is a workaround- there is no command to undo AddToLeveledList, but on a clean save any forms that are mod dependent are removed from vanilla lists if their parent is not loaded.

 

Therefore, its only bad to use AddToLeveledList if you add vanilla forms to vanilla lists. You can work around this by creating a new leveled list with any items you want in it, and adding that (mod contained) leveled list to the vanilla leveled list. (so, vanilla LLs contain nested mod-dependent LLs, themselves containing anything)

 

I do this in my dlc/ammo integration mod.

[jaam]

Here's a good one for you coding gurus:

 

I'm trying to output the list of hairs available to a race to the log in an NVSE plugin function. I've walked tLists plenty of times before, but not tLists of pointers.

TESRace* race = NULL;
ExtractArgsEx(EXTRACT_ARGS_EX, &race);
if(race)
    for(tList<TESHair*>::Iterator iter = race->hairs.Begin(); !iter.End(); ++iter)
    {
        TESHair* hair = *iter.Get();
        _MESSAGE("%04.0f :: [%08X]", hair->hairFlags, hair->refID);
    }
}

What I end up with is garbage values being output to the log, as my 'hair' pointer is obviously not pointing to the right data.

The 'iter.Get()' call returns a TESHair**, and I'm definitely not handling it right. Oh, pointers...

 

1) that's not really a GECK question

2) I hate iters. 

3) this should work I think , but I would trace it with a debugger if it did not print what I expected.

 

[Halstrom]

 

I've heard of that. I might look it into it with future mods. I expected more people telling me to not use AddToLeveledList to be honest, I've heard a lot of people say its bad to use it.

 

There is a workaround- there is no command to undo AddToLeveledList, but on a clean save any forms that are mod dependent are removed from vanilla lists if their parent is not loaded.

 

Therefore, its only bad to use AddToLeveledList if you add vanilla forms to vanilla lists. You can work around this by creating a new leveled list with any items you want in it, and adding that (mod contained) leveled list to the vanilla leveled list. (so, vanilla LLs contain nested mod-dependent LLs, themselves containing anything)

 

I do this in my dlc/ammo integration mod.

 

Hmm cool idea will do that instead

[Guest]

 

Therefore, its only bad to use AddToLeveledList if you add vanilla forms to vanilla lists. You can work around this by creating a new leveled list with any items you want in it, and adding that (mod contained) leveled list to the vanilla leveled list. (so, vanilla LLs contain nested mod-dependent LLs, themselves containing anything)

 

That's wonderful, thank you

[jaam]

Here's a good one for you coding gurus:

 

I'm trying to output the list of hairs available to a race to the log in an NVSE plugin function. I've walked tLists plenty of times before, but not tLists of pointers.

TESRace* race = NULL;
ExtractArgsEx(EXTRACT_ARGS_EX, &race);
if(race)
    for(tList<TESHair*>::Iterator iter = race->hairs.Begin(); !iter.End(); ++iter)
    {
        TESHair* hair = *iter.Get();
        _MESSAGE("%04.0f :: [%08X]", hair->hairFlags, hair->refID);
    }
}

What I end up with is garbage values being output to the log, as my 'hair' pointer is obviously not pointing to the right data.

The 'iter.Get()' call returns a TESHair**, and I'm definitely not handling it right. Oh, pointers...

 

The race definition in NVSE is incorrect, so use this syntax:

			TESHair* hair = (TESHair*)(iter.Get());

It should be corrected in the next iteration of NVSE.

 

EDIT : and hairFlags is a byte, so use %d rather than %f

 

[Xilandro]

Is there some kind of a list of unsafe functions? I heard a lot about "save bloats" people are talking about, and I have no idea what exactly those bloats are and what functions "bloat the savegame".

[prideslayer]

None of the functions are inherently unsafe, it's just that some of them require you to clean up afterwards -- and you can't guarantee you'll be able to do the cleanup because your mod might be disabled/uninstalled before you get the chance. Honestly I haven't personally had any bloat problems, but I don't max out my modlist (or even come close) like many people do.

[Xilandro]

Fair. Very fair.

 

some of them require you to clean up afterwards

For example?

[jaam]

Placeatme is discouraged by the wiki, but I think you would have to create a lot of reference before noticing an effect.

 

It is different in Skyrim where the script virtual machine takes up most of the save size and can easily diverge if any script starts going insane.

[Xilandro]

So, in most cases bloat is caused by references without markfordelete and string_vars (and those are gone after mod uninstallation anyway). Then why people are complaining about bloating the savegame if there's only few things that will do such bloat =) were working on corpse decay feature and people start throwing rocks at me "Bloats! You will break my stable mod built! Savegames will be corrupted!"

 

Haven't work with Skyrim scripts yet. Heard something about scripts are baked into the savegame directly o_O

[prideslayer]

Fair. Very fair.

 

some of them require you to clean up afterwards

For example?

 

You already mentioned the two big ones, "temporary" references you don't delete, and string vars(*) you don't destroy. Any spells you put on things is another -- if you don't ensure they get removed, they can potentially stick around forever. For normal spells it's not a problem because they have a reasonable duration, but it's a problem for those that have an effectively infinite duration (like the sexout ones). You need to make sure you dispel them when they're done.

 

Formlists are the only other one I can think of off the top of my head. If you have your own list and keep adding things to it, but never removing stuff, it'll just grow forever.

 

Most of these only become a noticeable problem when dozens of mods are doing the same sort of thing. One mod would have to have hundreds or thousands of formlists for example; but when you have 100 mods active, they only need 10 each.

 

(*) String vars don't technically bloat the savefile, just like NX vars don't, they bloat their respective sideload files; the .nvse files for strings, and the .csv for NX. This is a bit better for players at least because if those files get bloated, the player can make a clean save and then delete them if they didn't shrink, and so not lose their game progress. ACTUAL savegame bloat is more problematic because in a some cases, a clean save can't fix it, and the only recourse is to go to an earlier save and lose progress.

[Guest]

I also think it's a problem when a spawned npc has a script running on it (i.e. spawned enemies who heal themselves when health < a certain value, or they buff with psycho / spells / etc. I did some in the past), since the script doesn't stop running after the death. For corpse degrading this should be interesting to point out, especially when people like me play with a low timescale, I guess the corpses will remain a long time in game even if not marked as Quests, so a lot of istances of the same scripts will remain on the savegame. I guess.

[DoctaSax]

You already mentioned the two big ones, "temporary" references you don't delete, and string vars(*) you don't destroy. Any spells you put on things is another -- if you don't ensure they get removed, they can potentially stick around forever. For normal spells it's not a problem because they have a reasonable duration, but it's a problem for those that have an effectively infinite duration (like the sexout ones). You need to make sure you dispel them when they're done.

 

Formlists are the only other one I can think of off the top of my head. If you have your own list and keep adding things to it, but never removing stuff, it'll just grow forever.

 

Most of these only become a noticeable problem when dozens of mods are doing the same sort of thing. One mod would have to have hundreds or thousands of formlists for example; but when you have 100 mods active, they only need 10 each.

 

(*) String vars don't technically bloat the savefile, just like NX vars don't, they bloat their respective sideload files; the .nvse files for strings, and the .csv for NX. This is a bit better for players at least because if those files get bloated, the player can make a clean save and then delete them if they didn't shrink, and so not lose their game progress. ACTUAL savegame bloat is more problematic because in a some cases, a clean save can't fix it, and the only recourse is to go to an earlier save and lose progress.

If you look inside a save file, none of it compares to the massive bloat that ensues from the game keeping track of every damn tin can your character tripped over along the way.

[Guest tomm434]

If you look inside a save file, none of it compares to the massive bloat that ensues from the game keeping track of every damn tin can your character tripped over along the way.

Does Fallout has any save editor to delete bloat savegames (like Skyrim does?)

[nyaalich]

There's a New Vegas REFR Deleter program that I have used.  I haven't looked at before/after sizes of my save, but I do think that it's had slight impact on load time.  I haven't had it corrupt my saves, but then I've used it maybe 3 times?

[Guest tomm434]

thanks. I remember that in Skyrim this kind of program shortened load tiime a lot.

[prideslayer]

 

You already mentioned the two big ones, "temporary" references you don't delete, and string vars(*) you don't destroy. Any spells you put on things is another -- if you don't ensure they get removed, they can potentially stick around forever. For normal spells it's not a problem because they have a reasonable duration, but it's a problem for those that have an effectively infinite duration (like the sexout ones). You need to make sure you dispel them when they're done.

 

Formlists are the only other one I can think of off the top of my head. If you have your own list and keep adding things to it, but never removing stuff, it'll just grow forever.

 

Most of these only become a noticeable problem when dozens of mods are doing the same sort of thing. One mod would have to have hundreds or thousands of formlists for example; but when you have 100 mods active, they only need 10 each.

 

(*) String vars don't technically bloat the savefile, just like NX vars don't, they bloat their respective sideload files; the .nvse files for strings, and the .csv for NX. This is a bit better for players at least because if those files get bloated, the player can make a clean save and then delete them if they didn't shrink, and so not lose their game progress. ACTUAL savegame bloat is more problematic because in a some cases, a clean save can't fix it, and the only recourse is to go to an earlier save and lose progress.

If you look inside a save file, none of it compares to the massive bloat that ensues from the game keeping track of every damn tin can your character tripped over along the way.

 

Right, but I think mods have an impact on that too. I don't think that bloat stores even destroyed references, though I have noticed other odd things WRT the temp IDs (0xFF......) not being reused or something like that.

 

There's plenty of bloat in savegames in vanilla, that much is true. We shouldn't be trying to make it worse though.

[Guest]

Bloat shouldn't store destroyed references, that's the reason why Beth suggests to MarkForDelete a spawn.

 

I could be 10000% wrong with it, but I really feel that bloats come when scripts break and things don't work as intended. Some things (like var values, results) are stored in savegame, what happens when these results are not what they are supposed to be? am I sure that a clean save will clean something which is already wrong? I think there are too many unexpected things when a script breaks that even the game could foresee what will happen

[prideslayer]

A clean save will remove all the references added by any mods you 'clean'. Spells, scripts, whatever. Doesn't matter what state the scripts are in.

[Xilandro]

Wow, thanks a lot for detailed and useful answers =)

All this info is unique and very useful for people who heard about bloats, but, like me, was unsure what causes them. Somebody should gather all this info and make a small but awesome tutorial =)
 

I also think it's a problem when a spawned npc has a script running on it (i.e. spawned enemies who heal themselves when health < a certain value, or they buff with psycho / spells / etc. I did some in the past), since the script doesn't stop running after the death.

I always thought those scripts will stop after the death. That's interesting.

how about something like this?

If bDoOnce == 0
Set rSelf to GetSelf
set bDoOnce to 1
endif

if rSelf.GetDead != 1
 ;do all the fancy stuff
else
return
endif

end

For corpse degrading this should be interesting to point out, especially when people like me play with a low timescale, I guess the corpses will remain a long time in game even if not marked as Quests, so a lot of istances of the same scripts will remain on the savegame. I guess.

 

Non quest corpses are removed from the game after 3 days. Not a huge number actually. I'm also playing with a low timescale, and that's why I've added mcm with settings like max corpse number, decay stages time, and max corpse life.

[prideslayer]

You should not just return there, as that doesn't solve the problem. Do a dispel instead.

[jaam]

For those interested to see what is inside the saves : https://code.google.com/p/skyrim-plugin-decoding-project/source/browse/TES5Edit/releases/TES5Dump%203.0.32/FNVSaves-3.0.33-r1686-20140711.zip

 

That's a lot of (useless ) info though.

 

 

[prideslayer]

AFAIK they're basically in esp format but with a different header, right? It's a shame fnvedit won't open them for editing.

[jaam]

A ) Absolutely not

 

B ) That's on the (long term) plan.

 

[Guest]

For those interested to see what is inside the saves : https://code.google.com/p/skyrim-plugin-decoding-project/source/browse/TES5Edit/releases/TES5Dump%203.0.32/FNVSaves-3.0.33-r1686-20140711.zip

 

That's a lot of (useless ) info though.

 

I dumped a savegame to take a look. I fast took a look at those 55 Mb and it seems it mainly contains positions of references like npcs in world. But I can't find any FG records, but still I'm pretty sure they should be in the savegame, since Scanti's software injects the FG datas inside the savegame. Any clue? should I pass some specific parameter when I dump the savegame?