Help for stability in a mod

[A.J.]

Since there are many experienced modders around here, I hope someone could help me to fill some doubts concerning stability on my mod.

 

1 - I use scripts, they are simple but they are present in many places. As mod user, I always heard (without understanding what this means) that a mod with scripts is more dangerous than a plain one, and it could cause savegame issues. I'd like to understand this better, where are the real issues. Maybe it is related to the next point?

 

2 - If a mod introduces an item and then I disable the mod, I simply see the item disappearing from my inventory. But what happens with new npcs with scripts attached? or items with scripts? And, mainly, what happens with running scripts? i.e. I have some gamemode running scripts to check the time passing, and I don't mean checking seconds, I mean checking days, so that some events can happen after some time. What happens to them? Are they dangerous?

 

3 - If all these above are dangerous, I'd like to introduce some "cleaning" procedure, so that the user tired of playing with this mod could simply clean his game before unchecking my esp. Is this possible? What should I do, conceptually speaking? Resetting variables values to 0? (ok ok maybe this is stupid, but I really am wondering how can I clean the user's game)

 

4 - Ok sorry I hope this isn't too stupid. This is about GetIsID. I understood the sense behind it for the GREETINGS topic, and I applied it to other new topics I did, so I can make the same question to different npc obtaining different answers. Reading Bethesda guide, I understood they wanted me to place that condition in every topic condition (if I understood well). I don't do it, never. Because I realized that since my topics are all linked with a certain criteria, npc X won't have the topic of npc Y. This is what logic told me. But... after a long time I noticed that if I go inside the last tab "Scripts" inside a npc, it shows me all the topics where I didn't put GetIsID as condition, like if it's a potential user of that topic. Is this important for mod stability? Does it potentially create issues? or it's just a matter of praticity?

 

5 - Everytime I start GECK with PU now, many warns about navmeshing appear, like this one:

http://www.mediafire.com/view/srb418w61yschkm/pu2.jpg#

 

Did I change vanilla exterior navmesh? yes.

Did I finalize it? Nope.

Did I have problems with npc not moving correctly because of it? No.

Why didn't I finalize? Since I've seen there was no difference, and since amazing modders in wonderful mods didn't finalize their  navmesh, I took them as example.

 

So... are these warns really important?

 

---------

 

I hope someone can share some experience, especially on the first points, the ones concerning scripts and mod stability. Thank you very much.

[DoctaSax]

1,2,3: In FNV, & any other pre-skyrim game, that should be fine although it really depends on what the script does - if it temporarily modifies actor or item stats etc., moves something, or attaches an nx variable to an actor then those modifications will stay in the game when the mod's removed, for instance.

 

4: Mostly that's just about keeping things tidy. I like to make sure topics are only listed as available for the NPCs that use them, just in case. GetIsID ones really help reduce the possibility of you using a different one like something faction related & another mod adding an npc to a faction making that line available to an npc that shouldn't have it. This is only really a problem for topics that are flagged as "top-level" or added to the list of known topics with the "addtopic" function (never use the addtopic box), ie something that shows up by itself at the top level of the dialog menu in-game. Note that if entering the same conditions to every topic line is a drag, you can also enter conditions to the quest itself as a primary filter. Me, if I have a lot of conditions to add - checkmeout being a good example - I settle on a basic set of conditions that I copy across & adjust as needed.

[A.J.]

Thank you very much, DoctaSax. These scripts do or modify things or make things happen after some time, but nothing concerning vanilla content. They all are related to npc / events / items inside the mod itself. So I understand there are no dangers in them, because they would disappear with the things they affect. I hope I understood well

 

For 4, I don't think I got it. The "keeping things tidy" is what I though too, it confirms then. But the "top-level" thing and the "addtopic", I didn't get it. Probably it is because I don't use it, so no worries. Me too sometimes I use a lot of conditions, and since the columns are narrow and the box is little, mistakes come out because I read bad many times, that's the main reason why I didn't want to put also a GetIsId. Glad to see it doesn't cause other issues

[Halstrom]

One thing to note is scripts on tokens on NPC's do run when the player is out of the cell, though effects and their scripts self delete even when passing through doorways or wait / fast travel. Another thing is I've noticed many GetSelfs & GetContainers don't always return the Actors REF on the first scan/run or maybe 2nd run of the script it may return NULL  so it's good to use "If rZActor" as a condition to run.

Also use a disable like iRemoving because even after dispelling or disabling a script or removing an object it may run once or twice more.

 

I also add an iCount to reduce the frequency of large scripts or scripts I don't want to run immediately as I've found if 10-20 actors have the same script running it can cause some lag for some users.

 

I've never done much with actor or dialogue scripts so no idea whether/how the above applies to them.

 

So most of my scripts look like this:

Set rZActor to GetContainer

Set iCount to iCount + 1
if rZActor && iCount > 299 && iRemoving < 1
	Set iCount to 0


; *** Do Stuff

    if iScriptFinished
	Set iRemoving to 1
	RemoveMe
    endif


endif

[DoctaSax]

Thank you very much, DoctaSax. These scripts do or modify things or make things happen after some time, but nothing concerning vanilla content. They all are related to npc / events / items inside the mod itself. So I understand there are no dangers in them, because they would disappear with the things they affect. I hope I understood well

 

For 4, I don't think I got it. The "keeping things tidy" is what I though too, it confirms then. But the "top-level" thing and the "addtopic", I didn't get it. Probably it is because I don't use it, so no worries. Me too sometimes I use a lot of conditions, and since the columns are narrow and the box is little, mistakes come out because I read bad many times, that's the main reason why I didn't want to put also a GetIsId. Glad to see it doesn't cause other issues

Yes, there's only a need for pre-uninstall script clean-up if you leave things behind that need cleaning up, really.

 

About the addtopic thing:

 

Flagging a topic as "top-level" makes it appear in the list of topics you see in-game once you're past the greeting part of a dialog, ie the 'general list' of things you can talk to the npc about. Using the addtopic function in a script ("addtopic TopicID") does the same thing. You probably use the "choices" box from a greeting line to directly go deeper into further conversation instead, which is fine. Once you're a level down on a non-top-level topic, linked through "choices" from a line that has the necessary conditions, there is no conflict.

 

Using the "addtopic box", right above the choices box, as an alternative to the "top-level" flag or the addtopic function, can trigger a nasty bug in the game engine if it's used on a line under the GREETING topic. This bug can be difficult to track down because it will happen for some but not others depending on load order, and can cause harmless mods to be accused of breaking other ones, including the one that's actually at fault. This can cause a lot of drama, and frankly it's an easy mistake to make. This was something that people kept warning others about when I learned about dialog in Oblivion a few years back - it's less of a problem now because we have the top-level flag, but that doesn't mean the bug itself got fixed and new generations of fallout modders without Oblivion background tend not to know about it. Which is why I keep warning people about it, whether it has much to do with the discussion or not.

[A.J.]

Thank you both of you!

 

Doctasax

Since the first time I've read about it on the Bethesda guide, I never found a reason to use the Topic box, I always used Choices. I suppose I was lucky then, or it is sixth sense...  But it's nice knowing there's a bug linked to it, a good trick to remember when someone else will need help with it.

 

Halstrom

I admit I feel definetely ignorant. I think it's a standard and clean way to write a script, and since I have my own dirty way to write scripts, I have some difficulties. But it seems a good control, I really would love to understand it better.

 

Is it a OnAdd block, on a token added to a pc/npc? Or I simply misunderstood everything?

 

Also when does rZActor && iCount > 299 return true? I mean, ok I see the counter but... what about that reference? Does it means "try to get the reference that contains you, do it for 300 times so I'm sure you'll get it, after that do the DoStuff block, then I set iRemoving so this won't happen anymore"?

Also, I presume iScriptFinished  is setted to 1 inside the "Do stuff" part. But why? If I already did the DoStuff block, why checking if I did it?

Or, easier: if there's a guide explaining this kind of things, could you tell me where or what I should look for?

[Halstrom]

Thank you both of you!

 

Doctasax

Since the first time I've read about it on the Bethesda guide, I never found a reason to use the Topic box, I always used Choices. I suppose I was lucky then, or it is sixth sense...   But it's nice knowing there's a bug linked to it, a good trick to remember when someone else will need help with it.

 

Halstrom

I admit I feel definetely ignorant. I think it's a standard and clean way to write a script, and since I have my own dirty way to write scripts, I have some difficulties. But it seems a good control, I really would love to understand it better.

 

Is it a OnAdd block, on a token added to a pc/npc? Or I simply misunderstood everything?

 

Also when does rZActor && iCount > 299 return true? I mean, ok I see the counter but... what about that reference? Does it means "try to get the reference that contains you, do it for 300 times so I'm sure you'll get it, after that do the DoStuff block, then I set iRemoving so this won't happen anymore"?

Also, I presume iScriptFinished  is setted to 1 inside the "Do stuff" part. But why? If I already did the DoStuff block, why checking if I did it?

Or, easier: if there's a guide explaining this kind of things, could you tell me where or what I should look for?

 

The if rZActor just checks rZActor equals something, anything except "NULL" as I've found with some functions you might end up trying to remove or add items to an object or actor called "NULL" and that can cause a script to freeze or crash. You may get away without it 99.9% of the time, maybe on some script types more than others, but I've seen it fail at least a few times. The counter just reduces the frequency that the "Do stuff" happens to every 200th scan or run of the script. Some scripts where I want a fast response I skip it completely or set it to 99. That is 200 script scans not seconds, dependant on the script type that may be .1 of a second delay or 10 seconds.

 

I wouldn't do that inside an OnAdd or ScriptEffectStart as they only run once (supposedly anyway) you may not reliably get an Actors REF in an OnAdd so I Prefer to use a GameMode or ScriptEffectUpdate myself.

 

The iScriptFinished I might use if the script is done and I don't want it to run again or I detect the actor is dead because scripts keep running on corpses.

On that subject I also may need to check that the token is actually on an Actor too by:

 

if rZActor.GetIsSex Male || rZActor.GetIsSex Female

 

This stops scripts running inside crates or when left on the floor or carried by a Creature.

 

Check out the scripting thread in my sig, there's a lot of handy stuff in that thread from a lot of guys with more scripting knowledge than me.

 

[A.J.]

 

The if rZActor just checks rZActor equals something, anything except "NULL" as I've found with some functions you might end up trying to remove or add items to an object or actor called "NULL" and that can cause a script to freeze or crash. You may get away without it 99.9% of the time, maybe on some script types more than others, but I've seen it fail at least a few times. The counter just reduces the frequency that the "Do stuff" happens to every 200th scan or run of the script. Some scripts where I want a fast response I skip it completely or set it to 99. That is 200 script scans not seconds, dependant on the script type that may be .1 of a second delay or 10 seconds.

 

I wouldn't do that inside an OnAdd or ScriptEffectStart as they only run once (supposedly anyway) you may not reliably get an Actors REF in an OnAdd so I Prefer to use a GameMode or ScriptEffectUpdate myself.

 

The iScriptFinished I might use if the script is done and I don't want it to run again or I detect the actor is dead because scripts keep running on corpses.

On that subject I also may need to check that the token is actually on an Actor too by:

 

if rZActor.GetIsSex Male || rZActor.GetIsSex Female

 

This stops scripts running inside crates or when left on the floor or carried by a Creature.

 

Check out the scripting thread in my sig, there's a lot of handy stuff in that thread from a lot of guys with more scripting knowledge than me.

 

 

More scraps of wisdom. I really thank you and I don't want to seem boring but I really think it would be very useful if some of them would be pinned on the top of your scripting thread.