I've seen the 72 hour bug referred to in these forums, usually regarding a companion. What exactly is it?

Thanks!

If a companion, or any NPC is left alone for 72 game hours their stats will revert to how they were when they were first spawned.

When you have been separated from a npc for more than 72 hours, everything with them re-sets to what it was before you met.

A quest npc mght have forgotten that you ever met.

Someone who was hostile to you have forgotten that he was angry.

A companion might have losed all his acquired skills.

*deleted* (sorry, doubled posting )

This post has been edited by Emma: Aug 5 2005, 07:39 PM

Morrowind keeps track of a *lot* of things you're not aware of. For instance, it remembers whether you've talked to an NPC or not, among many others. All that data can seriously slow down your game, to the point of CTDing it. Fortunately, there's a great way to clear all that information from Morrowind's data stores: since the game only tracks that data for the previous 72 hours, resting for three days clears the stores and can lead to a much smoother game.

This is the only 72 hour bug I know of -- I don't (yet) use companion mods, so I'm not entirely certain that this is the bug you were asking about.

Edit: Blast! Beaten to the punch not once, but twice by the same person!

This post has been edited by Grundulum: Aug 5 2005, 07:37 PM

Thanks, BTS!
I see why Emma's Laura mods have the telepathy ring! Shame to invest $$$ in advancing her skills to lose it all.

Oh no!!!
Of course you won't lose any of Laura's skill! There is a backup-script keeping track of it all. So you should never have to worry.
Same goes for my other companions, except for the oldest one, Witchgirl (who deserves an update). Their skills will always be restored the minute you meet them (or at least next time you check their skills)
But... Laura's telepathy ring won't work if you are separated for her for more than 72 hours. This is why she also gives you another ring, that will always bring her to Vivec Foreign Quarter plaza, regardless of any 72-hours bugs. (No worries - the moment you meet Laura, the telepathy ring will start to work again).


And as Grundulum says, "bug" is probably not a good word, as the 72-hours"bug" in many way can be very helpful.

This post has been edited by Emma: Aug 5 2005, 07:44 PM

The 72 hour "bug" is usually a reference to The Underground, where a very obscure glitch caused the game to crash for many users exactly 72 game hours after leaving a certain point in the quest. The crashes would increase in frequency until the mod was unplayable for some. People who didn't kill all the spiders in one particular building would be more susceptible to the bug than others.

Qarl's attempt to fix this bug kinda sorta suffered 'mission creep' and will emerge as The Underground 2, with no bug and lots of lovely goodies!

Uhm... people may refer to The Underground in connection with the 72 hour "bug", but... the 72-hourbug was generally known and refered to before I think Qarl had even joined the ES-boards .

I believe calling TU2 a case of "mission creep" may be the single most gargantuan understatement I have ever read on these forums. And I've been reading for a while. Just so you know.

In other words the 72-hour "bug" is really a feature built into the game to clean up "garbage" every 72 game hours.

Thanks Emma. Sounds like companion mod making is a sophisticated undetaking. Being aware of what is going on "behind the scenes" as it were makes me appreciate the finished product more.

By the way. I'm upgrading from Laura 2.1 to 2.2. I haven't gotten very far, so I'm tempted to do a clean from 2.1 (drop all Laura related items, leave any cells with her or the cottage, save, disable 2.1, save) and then add in 2.2. Other than start the mod from the start, will that cause any problems (ignoring mod order ones!)
Do I need to replace/upgrade the textures/sounds/meshes/etc, or can I simply replace the esp?

Thanks also ninefold, grundulum,pricess-stomper and BTS! (not looking to slight anyone)

Grundulum, I used the enchanted editor to clear cells/NPC's affected to help FPS. Sounds like your 3 day vacation trick would work too (and not blank out my map!)

The readme for Laura 2.2 has a section "5b - UPGRADING IMPORTANT!!! PLEASE READ!!!". That says it for upgrading from 2.0 and earlier, but it also applies to upgrading from 2.1 to 2.2.

Follow those instructions: Emma is very good at making her mods upgradable safely.

I'm pretty sure it has been mentioned more in connection that one mod than I've seen it mentioned elsewhere, hence mentioning it because if someone's seen it referred to in that context and not in the other context (which I wouldn't refer to as a 'bug' - more a 'feature' or 'quirk') they might still be confused.



Just trying to help...



I try.

It's easier to upgrade to ver 2.2 (which generally works fine) than trying to disable one mod from an ongoing game and instead add another version.

I would definitely recommend that you follow the instructions on how to clean the npc-line ( available in readme, my site and my forum) and then just continue your gameplay. The upgrade should only take you a few minutes, shouldn't cause any problems. (But don't use Enchanted editor for cleaning... for some reason, that causes problems with the new animation files. Do as I say in the instruction!)

The disable/replace option means that you have to clean out journal entries etc, and you will STILL have to clean the npc line, else your new Laura will on top of everything else be headless!!


And I second Ninefold - the "infamous 72-hoursbug" is most likely more of a feature than a "bug" (although still very annoying for us companion modders )

The 72 hour garbage cleanup time is controlled by the GMST that controls how long it takes to clear corpses.
I have not found a value to disable the garbage cleanup process, but it can be extended well beyond 72 hours without bogging down gameplay.

Um, yep. I'm getting a little carried away... again.

Another useful thing about the 72 hour garbage cleanup is the removal of dead bodies which could potentially slow the game way down.

Edit: Doh! But you can do what Iudas suggested and you'd be OK too.

This post has been edited by qarl: Aug 5 2005, 09:03 PM

Hehe, think I'll have to back off here...
I claimed the 72-hourbug was known before qarl had joined these boards, but... MAY 2002!!! Wow!! You've been around longer than me, qarl!

For a question that was answered in the first four (three? ) posts, this thread is drawing some very important people. Kind of funny, that.

Heh, yeah, but I've only been modding for about a year and a half. You've got me beat there. But I think your initial statement was valid anyway.

For the record: I've been through quite a few discussions of the 72-hour issue over the last few years, and your post is the first time I remember Qarl's name or his Underground mod mentioned in connection with that particular issue.

This does come up fairly regularly with regard to companions and NPCs/creatures in general, since the clean up of their variables is most likely to be noticed and to break things in mods.

(And some of you are typing faster than I am, so I don't have to mention to Emma just how long Qarl's been here... )

----------------------------------------------------------------------------

As other posters have already said, this is more of a cleanup process than an actual bug: if a particular cell isn't active for 72 hours, some of the temporary data associated with the cell and objects in the cell is deleted. Presumably a way to save memory, to reduce the amount of data the game engine has to manage at one time, etc.

If a modder has problems because of data being lost to the cleanup process, the solution is to figure out what data is being lost and then figure out a more permanent way to preserve the information. For example, if you want an NPC's 'talked to PC' flag to survive for more than 72 hours, you can use a dialogue results box to set a local or global variable to retain the flag.

This post has been edited by DinkumThinkum: Aug 5 2005, 09:24 PM

The 72-hour feature can be used as a way to shrink down the savegame filesize and clean up a save. More accurately it can be used in addition to better methods of cleaning your save game.

Yes Grundulum, these are illustrious posters! I like rubbing elbows with the Master/Diviner legends! And me a simple adept...

Seriously, thanks for the advice all.

Emma, I get nervous playing with the CS, but after following the instructions for the Enchanted Editor, and trying to learn Wrye Mash, your upgrade instructions should be easy!
BTW, does upgrading 2.1 to 2.2 change anything beyond the esp? I've got dial up at home and fast onnection at work, so I can download the mod at work and take the esp home on a floppy.

Lots about Laura here, but as it is your thread, I guess it isn't "hi-jacking" if I reply to it ...

On top of the esp-file, you have to have three new animation files for the kiss/sleep/dance-animation by RX31. I don't think that a floppy will be sufficient for that.

One playtester reported problems with the new animations when he used Enchanted Editor to clean out the npc-line for the upgrade, and therefore I suggest that you use the TESCS instead, following my instructions. That worked like a charm.

Thanks Emma!

It's my thread and I'll hi-jack if I want to...

Unless you read all 13 or so of the Underground release threads, in which case the phrase was uttered 238,475,492,374 times. Or thereabouts.



That's really useful information. Thank you

Well, I must admit that I haven't read every word of the Underground threads. I have looked in on them occasionally, but I haven't followed them regularly.

The reason I poked at you : not sure just how long Qarl's being working on the Underground, but I know Emma and I tracked down a bug caused by the 72-hour cleanup in one of her mods two years ago, and even then it was a known issue for modders. (I keep old E-mails, and that particular discussion was easy to find.)


But it might not be as 'easy' as I made it sound. First you have to notice the bug and then you have to figure out that it's a 72-hour cleanup issue. Once you've made it that far, then you have to figure out just which piece of information you need to save to fix the problem. And then you have to figure out how to save it.

When I was working on the PotionSaver code, one thing I'd do periodically was put my character in an interior cell and leave the test NPC in an exterior cell (or vice versa). I'd wait for 72 or more hours, and then go back to where the NPC was to make sure nothing had broken.

With my character in an interior and the NPC in an exterior (or vice versa), that would make sure the NPC was not in an active cell. Then waiting for 72 hours would run the cleanup code for that cell and the NPC, and trigger any 72 hour problems in my scripting, etc.

Doing something like that occasionally might be a good idea for any mod that makes much use of NPCs, quests, dialogue in general, companions, etc. Put your character into an empty interior cell, wait 72 hours, then go back out and see if anything breaks.

Saved that advice as a 'favorite'. Thank you.

The bug only affects NPCs, hey? (not activators or anything else)

This is one bug I haven't bothered investigating much.

Not quite what I said. This seems to be noticed most often with respect to NPCs.

For example, this issue also affects targeted global scripts, regardless of what their target is: if the target isn't in an active cell for 72 hours or more, then the the scripts lose their targeting.

I don't have a complete list of everything that's affected by the 72 hour cleanup. There were a lot of long discussions on this a while back, but no idea if any of those threads have been archived anywhere. I know there's a few mentions of this in SFD.

What's the name of this GMST?
Can it be updated within a running game?

From the Morrowind Scripting for Dummies:

Notes: According to my testing, the activate function can not be used by itself, without OnActivate in the same script. The OnActivate and Activate functions can be in different parts of the script, though. However, Activate will not work before OnActivate has not at least been called once. There have been reports that the object also must have been manually activated at least once within the last 72 hours, so apparently the game eventually forgets that OnActivate has been called previously.

-------------------------------------------------

It seems that Talked to PC will reset to 0 if the player has spent 72 game hours out of the NPC's cell. This time limit also applies to other NPC-related functions such as "forceGreeting": the NPC is available for a forceGreeting reference from a different cell only for 72 game hours. As a workaround, if you use PositionCell on the NPC once per day (even without changing their location), the 72 hour time limit no longer applies (Forum info /Time limit info from Cortex, thanks to Srikandi for bringing it to my attention). This trick to get around Actors breaking their connection to you after 72 hours seems to require the cell you send them to to not be the cell where you initially met them (Forum info / Cortex).

This either implies it must not be their editor starting cell or that it must be a cell that you have not visited. In my fix I have an interior I send them to for this purpose so either explanation could be why it works.
So basically after you have met them they get sent there each day even though they are already there after the first sending.


Edit: Speeling

This post has been edited by qarl: Aug 6 2005, 10:31 AM

Hmm... sounds like a fix. I might have to include that in any mods I do. Have them repositioned every 48 hours or so. Could break it up so a portion is done every hour, so as not to slow everything down too much...

*wonders how long it would take to reposition 70 people*

That 72-Hour bug never happens too me although my game will crash bout every fours hours.

There's an extreme difficulty in the solution GBG talks about with regard to companions though... Say you leave a companion in some random cell you happen to be in and don't rejoin them for 72 hours... There's no way to do a PositionCell on the companion and return them to the position and cell you left them in because there's no way to know what the actual cell they are in IS.

Perhaps there is another function that has the same effect...

Well, you can always use intervention or recall to make them meet you instead of going to them...

Well, I was thinking in regards to non-companions too. PositionCell seems like it would take a while to do, compared to other functions

FCorpseClearDelay = 72
No GMST can be changed while the game is running.
Any GMST can be changed between game sessions.
The corpse clear timer is for 72 game hours ( 144 real world minutes of play ).
One of the appendices of Morrowind Scripting for Dummies 8th ed contains the complete list of GMSTs, their default values, and for some of them an explanation of what equations the specific GMST is part of.
F GMSTs are floating point values
I GMSTs are integer values

An easy way to see the 72-hour cleanup in action for yourself:

1. Open up the console and click on an NPC or creature so their ID shows up at the top of the console window. Then close the console.

2. Go to the opposite type of cell: from an interior, go to the exterior; from the exterior, go to an interior cell. Or, if you're in an exterior cell, just go to an exterior cell a long way away: once that's not adjacent to the cell the NPC or creature is in.

3. Open the console again, and the NPC/creature's ID will still be at the top.

4. Wait 24 hours and check the console: ID is still there.

5. Wait a couple more times (till the total is 72 or more hours), and check the console again: now the NPC/creature's ID is no longer shown.

As long as the NPC/creature's name is shown at the top of the console, they're 'targeted': if you type a script command in the console that requires a target, it will affect that NPC or creature. After the 72 hour cleanup runs, the targeting is lost.

----------------------------------------------------------------------------
----------------------------------------------------------------------------

Getting a bit more technical here:

Interestingly, I also tried this with a static object (part of a building) and the console did not lose it's target, even though I waited a few more times beyond 72 hours (in case I'd lost track).

So it could be that targeting is only lost during cleanup if the target has temporaty data associated with it. I.e., a static is just there: either it exists or it doesn't; no temporary data attached to it. But NPCs and creatures have various temporary bits and pieces of information: whether or not they've talked to the PC, for example.

Just tossing this in here because targeted scripts are also affected by the 72 hour cleanup the same as the console targeting. Haven't tested with a script, but it seems reasonable that this might mean that scripts targeted on a static might stay targeted even past 72 hours.

hey!

i did not know this!!

I never ever realized that this would be a good way to clear the game of "script creep"! have ten script mods running at once and hours later the game slow slows way way down!

I am afraid to install many script mods, as i have 300 already.

thanks.....
i think that i will post this over in the tech section!

freestone

It depends on what a script does or how clean the code is whether or not it will impact your fps. Also, keeping your savegame clean really helps. For instance, if you remove a mod that has scripts in it, chances are the scripts are still running in your savegame. To remove the mod completely from your savegame, use Wrye Mash.

!!! Qarl, I had no clue about that. Guess I'd better invest some time learning how to use Wrye Mash.

Grundulum, I am a bit clueless when it comes to computing, and I was able to install and get python going to run Wye Mash. The read me is very helpful- I couldn't make heads or tails of it just fiddling around (I still haven't figured out the construction set). I can't tell if I'm getting a FPS boost, but I can tell you it fixed my doubling.

BTW, I'm pleased/surprised to find this thread alive and well.

I'd be surprised if the 72 hour cleanup had much effect on slowdowns caused by having too many scripts running at the same time.

1. Global scripts run constantly: once they're started, they keep executing until a StopScript command is used to shut them down. 72 hour cleanup won't do anything about their impact on FPS.

2. Local scripts run constantly if they're in an active cell.

If the player is in an interior cell, the only local scripts running are the ones attached to objects in that interior cell.

If the player is in an exterior cell, then all the local scripts on objects in that exterior cell and all the adjacent exterior cells (nine cells total) are running.

The local scripts start or stop running immediately as the player moves in and out of different cells; there's no 72 hour cleanup delay.

So I really don't think the 72 hour garbage collection will help much if you're running too many scripts.

Someone else reported this, but my experiments indicate that it's not true. If your save game has a global script running and then the mod that it depends on is removed, then the script will be discarded from the savegame as part of normal Morrowind game load process. Of course, Mash does remove other debris that Morrowind does not.

Script FPS Hit:
* Script efficiency, *especially* how fast it returns. (I.e. is there a return running at the top of the script.)
* How many scripts are running. I once tried scripting creatures so that they died a natural death. Very efficient, returned almost immediately almost all the time, but I still noticed an FPS hit when there were a lot of creatures around.

I've been wondering about the 72 hour thing... That's got to be reflected in the game file somehow...

Hmmm, One time I removed Vampires Embrace from my game but had savegames with it in there. When I loaded up a savegame I would always get errors saying that some global scripts (which were from VE because the were prifixed with 'emb') couldn't find some global variables it needs...

You sure it wasn't the variables in the script it couldn't find? If you remove a global script that was running and had variables, then you'll get errors saying that script can't find the variables the first time you load (even though the script no longer exists)

Hmm... Could there have been another mod that replicated those same scripts? E.g., maybe an MCA patch or vampire hunger or something? Or does TesTool stick scripts in it's merged object mod?Also, does it still happen if you save and reload?

If you can replicate the process that causes a script to stick around like that, let me know how you do it. If I can replicate it, I'll add SCPTs to my list of debris types.

1. I think targeted scripts disconnect from objects/activators when you load the game instead of using the 72 hour mechanism, but my testing on that may have been clouded by my next point as i had used a placeatpc activator in my test.

2. Targeted scripts disconnect from anything (even npcs) created by placeatpc or placeatme when you load the game, even if they are in the same cell as you. Npcs created like this are also subject to the 72 hour bug.

It may be worth testing how corpse persists effects the placeatpc bug

This post has been edited by Cortex: Aug 9 2005, 01:58 PM

Interesting... Global scripts references are encoded just like frmr's. SCPT.RNAM: objIndex int (3 bytes); modIndex 1 unsigned byte. (If you have the latest Mash, it has an updated ESTemplate.ini.)

If Morrowind can't find the target on startup, it resets SCPT.RNAM to \255\255\255\255 (= 4 byte integer with value -1). I wonder if it's doing that in this case? Not that I see a way that such knowledge would help, but just curious...

1. Targeted scripts work fine through a save/reload if the target was placed in the game world in the Construction Set.

I specifically tested this with NPCs: the original version of the PotionSaver (I think I already posted this somewhere) was set up as a separate targeted script, targeted on the companion. That worked fine through save/quit/reload: tested that intensively, multiple times before I decided to just embed it in the companion's local script instead.

2. As you mention, targeted scripts will lose their targets on a save/reload if the target was not placed into the game in the Construction Set. For example, if the target was added to the game from a script or dialogue results box.

Interestingly, this applies to the player character too: if you check in the editor, you'll see that the 'player' has a count of zero. They're not in the world in the Construction Set, but are placed there after the game starts. And, as I recently confirmed, scripts targeted on the player will lose their target during a save/reload.

3. Scripts that target an NPC will lose their target after 72 hours, regardless of how the NPC is placed in the game. Works the same as my little demo with the console window a few posts earlier.

----------------------------------------------------------------------------

Depending on the situation, dealing with the loss of target may be trivial.

For the project I'm currently trying to finish, the main script is a targeted script on the player.

To deal with loss of targeting when the game is loaded, I just use a Start Script. It checks to see if the main script is running. If it is, it stops it and then restarts it using 'Player->StartScript DT_UC_Main'. That solves the targeting problem. (And if the main script isn't running, then it gets left alone.)

In my case, shutting down and immediately restarting the main script is completely harmless. For other scripts, it could be trickier.

I have not tested it, but the same approach might work for NPCs, etc. that are placed into the game with a script (instead of in the editor). However, if the NPC does not have a unique ID this would not be reliable, since there's no way (that I know of) to control which reference the script would pick as a target.

----------------------------------------------------------------------------

With the player, I don't have to worry about 72 hour cleanup, since the player by definition is always in an active cell.

For NPCs, it takes a tiny bit more code to deal with the 72 hour loss of targeting when they're not in an active cell.

The way I did it involved a little extra code in the targeted script and in the NPC's local script:

1. In the targeted script, I had a timer that constantly counted down. Whenever hit zero, the targeted script would automatically StopScript itself.

2. In the NPC's local script, I had a small block of keep-alive code that did two things:

a. It constantly reset the timer in the target script. That prevented the target script from shutting itself down as long as the NPC's local script was running.

b. The keep-alive code also checked to see if the targeted script was running. If it wasn't, then it would 'NPC_ID->StartScript <targeted script>' to restart the script and reset the targeting.

So it worked like this:

1. As long as the NPC was in an active cell, its local script would be running and its keep-alive code would keep resetting the timer in the targeted script. That made sure the timer never counted down to zero, so the targeted script would never stop running as long as the NPC was in an active cell.

2. If the NPC was not in an active cell (i.e., the player left them behind), then the NPC's local script would stop running and stop resetting the timer in the targeted script.

So then the targeted script would stop once the time delay ran out. I think I had it set to five seconds (something small, anyway).

3. When the player moved so the NPC was once again in an active cell, the local script would start running again. It would detect that the targeted script was no longer running, and restart it with its target again.

Worked like a charm.

Just like the fix for loss of targeting when you save and reload, this only works if your targeted script can be stopped and restarted without causing problems.

Ya know, I've been doing this for some time. I had no idea this was as much of a problem as it seems to be.
I learned of this from Thepal, who is working on LtM.

Now, for those who have average-decent computers, changing the "Hours" for LtM (or other mods) may be a good thing. (Closer to real time-or real one on one time)

This in itself is not a fix...but with the fact a Player is doing more in 72 hours, the likelihood of the reset is a little less. You can then couple this with "extending" the 72 hour clean-up time as well...I dunno...to 210 hours. (It can be done-Yes?)

Then, as DinkumThinkum pointed out, a Script with a timer to maybe check if "clean-up hour" is getting close at hand and save what needs to be saved.

I don't know that much about this, but if you can change the game time, why can't you just alter this 72 hour bug-cleanup-glitch-thing like you can with time?
Should not affect game speed unless you have a 486DX with a VGA card.

I'll shut up now.

One problem with trying to beat the 72 hour cleanup by doing some kind of save: if the 72 hour value is changed, there's no way for a script to see it.

The 72 hours is set in a GMST: a game setting. And GMST's are only accessible in the Construction Set; there's no way to read or change them in the game.

Another problem is that some of the temporary data variables aren't directly accessible from a script.

The classic example: 'Talked to PC'. This is a temporary NPC variable that keeps track of whether or not the NPC has talked to the player, but it will be reset when the player is away from the NPC's cell for more than 72 hours.

The only time that variable can be accessed is in dialogue. So to save the value past the 72 hour cleanup, you'd need to include a dialogue greeting or response for that NPC that would set a script variable to save the value of the temporay 'Talked to PC' variable. So the only time you'd be able to save that would be while the PC was actually talking to the NPC; there's no way to do it later.

So the best way to avoid the 72 hour bug with Talked to PC is to set a local variable to 1 when you talked to an NPC for the first time and then then check for this variable to be 1 instead of checking if Talked to PC is 1. The local varible isn't affected by the 72 hour bug if I got it right.

it seems that the fCorpseClearDelay GMST is really not only responsible for the corpses but for all the cleanup work. I tested it with the "Talked to PC" variable and it works.

So why not simply setting this GMST really high (eg to 30240 which is 1008 real time hours) so the problem doesn't exist anymore (who plays the game more than 1000 hours). To me it sounds like a solution since I agree that this "cleanup" isn't that important for performance.

edit: maybe you'll have to set it even higher, because the player will sleep alot of hours too... but that doesn't change the general "idea".

This post has been edited by Corv: Oct 21 2005, 03:07 AM

Most players use many, many mods. If we start touching this setting, all of us, won't it be that the settings in the newest mod in the setup will overwrite the settings in the other mods? So that if I set this GMST to 30240 and someone has set it to a lower number in a newer mod, then it will be the lower number ingame.

The local variable works as you say. But if you need to clean away the npc-line for that npc, the variable will be set to 0. That sometimes causes new problems, for instance if we are talking about a companion npc. Journal entries are a very safe way to go of course

The other issue with setting FCorpseClearDelay to a very high value, is that nothing gets cleaned up, dead critters just keep on rotting, dead enemies just lay there clogging the landscape, your save games balloon in size.

Emma, yes the last loaded mod that changes a thing is the dominant mod for that thing. The easiest way around that specific issue is to make a very simple 1 change mod and either give it a creation date far into the future, or use TesTool to arrange for that mod to be the last loaded.
Mod:
change ONLY FCorpseClearDelay from its default value of 72 to some other value. ( Options might be 168 ( a week ) 720 ( a month ) 2160 ( a quarter ) 8736 ( a game year ) )
save mod
While this will not solve the problem, it will push the problem beyond most normal play sessions. The 72 hour default is the equvialent of 2 hours and 24 minutes of game play.
I use for my own games a setting of 336 ( two weeks ) which gives me about 10 hours of gameplay before the bug recurs.

Yes it is more interesting for TCs that's true. It's just a bit annoying that Beth made ALL the cleanup depend on that one variable. Making one for corpses and another for all the variables would have made sense.

What do you mean with "if you need to clean away the npc-line"?

A npc-line is created in the save-games when the settings for a npc is changed during the game. The most typical example is a companion, where you often change the flee-setting in the script, but also for instance skills settings or attributes.

If a npc has a npc-line, a 'backup' of this npc is created in the saved game.
If you want to upgrade the mod where this npc belong, you have to clean away th npc-line, else you will have problems. Else the "backup" will ensure that the npc will remain like he was before the upgrade; new scripts won't work, new animations won't work, etc.

The even worse example is if you have disabled a companion mod from your game and then try to enable it again. The companion will show up... but without head and without script!! Because a "ghost" of him, based on the npc-line, will keep head and script.

It's not very hard to clean away the npc-line... you can read more about how to do that here.

But, when you clean the npc-line, short variables will naturally be set to 0, and if you are using a short variable as a dialog filter, the dialog will obviously be affected.

So, if you want a 'safe' way to deal with initial greetings, journal entries should be the best option.

As for TalkedToPC, there's another thing to consider as well: mods like for instance Vampire's Embrace. (Not sure if this has already been mentioned in this thread - if so pardon me for bringing it up again).

Vampire Embrace adds a 'pre-greeting' (in greetings section 0) that will take effect before the initial greeting. This means that when the mod-original greeting execute, you HAVE always already talked to the npc (in the 'pre-greeting') So TalkedToPC will be 1!

So, for anyone using VE, the filterfunction TalkedToPC will potentially kill the whole dialog...

I find it critical for performance. Every "interesting" object (creatures, NPC, objects with scripts, movable items, containers you have accessed, etc.) in every cell you have visited in the last 72 game hours is both kept in memory and stored in the save game file. On reason people notice the game getting slower and more unstable the longer they play is because of all of that extra data being tracked. The machine simply gets overwhelmed. I find that if a character doesn't travel around too much there isn't a problem but if I have a character that uses Recall, Interventions, and other fast travel services to visit multiple cities in a short period of time the game is almost unplayable until after a nice 72 hour rest. The 72 hour cleanup doesn't clean out everything, but it cleans enough.

As an experiment travel to Balmora and save the game. Then reload and notice the FPS/performance. Walk around the city so you get all of those cells loaded. Use the Guide to teleport to Caldera, then walk/run north out of Caldera to Ald-ruhn. Take the Strider to Gnisis, walk up to Khuul and take a Boat.... You get the idea, just travel around from location to location as quickly as possible. Before the magic 72 hours expires, return to Balmora and compare the FPS/performance to what you had when you loaded the game. If your game is anything like mine you'll see a drastic decrease in performance. If you sleep for 72 hours you'll get a better performance again. Of course, saving and restarting is the only way to get full performance back.

Does this 72 hour bug affect NPC inventories as well? How about spell effects/added abilities? (not racial abilities)

Inventory and spells are not affected. I don't know that anyone has made an actual list of which things are and are not affected. The basic skills and attributes are while inventory, spells and AI settings aren't.

What you say is true... but I think there might be exceptions (depending on what situation you have).

Initially this thread was about companions, and many companions have spells and even attributes added by dialog or script. I.e. the spells and abilities arent' added in the npc-information box in the construction set. If spells/abilities are added by dialog, I would highly suspect (without really, really knowing, as I haven't tested) that they will be removed with the 72 hours bug.

I know many new modders have made the mistake of adding items directly to a merchant's inventory, and these items have of course not shown up in an ongoing game, where the player has already met the merchant. It would be interesting to check once what actually happens if you don't meet this merchant for +72 hours. Would modded items added to the inventory then show up like it does on a npc you meet for the first time? Or not? I don't know the answer, but would be interested to know in case someone has an answer.

(I'm BTW storing this thread in the tutorials section of my site, and am updating it as new questions show up)

I am by no means an expert on this, but I don't think any information added to an NPC in the CS would be susceptible to the 72 hours "bug" - rather, those would be the values the NPC would be reset to when the "bug" takes effect.

And from some recent testing of my mage companion, I'm reasonably certain that spells added to an NPC via a script are not affected - the NPC will still use them even when all stats have been reset to their intitial values.

For sure - what is added in the npc-infobox will always be there, if it's a new npc. But, if you in a mod add items to for instance the inventory of a merchant that belongs in original MW, people who have already met this merchant ingame won't be able to buy these items from him. This is because the facts about him, including his inventory, are already stored in their saves. But, when thinking of it, I actually wouldn't believe that the items added by a mod will show up even if you don't visit him for +72 hours. Most likely, there is a npc-line created for him as soon as you start to trade with him, and then this npc-line will keep track of what 'should' be in his inventory. Which means that you will only find the new, 'modd-added' items if you start a new game.
So, the solution to that is to add the items to his shop and assign ownership to him, rather than putting the items in his inventory.



That's good to know!

If I understand correctly, this means that if you activated a mod such as Dark Orcish Armor after previously visiting the Armorer in Balmora, the armor would not appear in his inventory.

sieboldii

If a mod adds the items by adding a new container with the items in the same cell as the merchant the items will appear. If the items are added to an existing container or the merchant directly then no.

It's that entry stored in the save game file that holds the changes made to inventory and spells you might make to the NPC. That part survives the 72 hour bug. I haven't spent much time looking at how the data gets stored in the save files but in-game the changes to skills and attributes are stored in different areas than the information about inventory and spells.

The information about a particular NPC is actually stored in many little pieces. Some things get reset every 72 hours, some pieces are never written into the save game files so they are reset when you reload the game. Scale is an interesting example because it survives the 72 hour bug and as long as the value is between 0.5 and 2 it will also survive game reloads. But if you use a script to set a scale larger than 2 or smaller than 0.5 it will be stored in the save game file as either 2 or 0.5!