Sign in to follow this  
Followers 0
DeadHerring

Modifying existing persistent references and scripts

This is a bit of a hypothetical question, since I haven't tried to do it myself. Just trying to understand the logic so I don't make the mistakes in the first place. I ran across a post that I tried to help out with since it appeared to be a scripting logic problem on the surface of it. And hey, two mystified scripting newbies trying to figure things out is still better than one. We call it a learning experience where I come from. It came up in the course of the discussion that it may actually be a problem with modifying persistent references and scripts that were being added by the mod that this person was making a patch for. Nothing to do with script logic at all.

Here's where I don't follow. I've been under the impression that modifying an asset from the vanilla game or another mod creates records in your esp that raise conflicts with the original content and win out, so your changes (being the latest) are integrated and supposedly made seamless with the original version if you've done things right. That's the whole point of a compatability patch, right? Meshing two mods together by merging records into a third esp to resolve clashes and manually tweaking things in the CS when there's no hard and fast rule for how conflicts should be handled? Unless I'm missing something, the unofficial patches use this mechanism to override buggy original content. The conflict resolution part of it anyway. Not the merging.

So my question is this. Under what circumstances can you not modify existing assets? Does the story change when you start getting into persistent references with scripts attached, like activators? Or maybe a better question would be, what are the wrong ways to do it that should be avoided at all costs? And what about modifying assets that have already been modified from the vanilla version by another mod that you're patching? Assuming that the last esp loaded in always wins out, and the CS always generates complete record sets for anything that you've touched, RefID's intact and unchanged and all that, then how is this even an issue? I must be missing something...

Hope I got the right forum for this question, seemed to be the best match. Thanks in advance, I appreciate any and all input! :)

Edited by DeadHerring
0

Share this post


Link to post
Share on other sites

:D I know which post you're referring to. It's very hard to describe in a general sense what can be done and what shouldn't be done with persistent references. You certainly don't want to delete them. Or to be more accurate, you can delete them and then have TES4Edit Undelete and Disable References for you. It will put them in the proper state and get them out of your way.

The problem is that you never know what another mod is going to do. You might have another mod come along and try to reference the object you've deleted. If that happens, then the game will crash.

Here's a situation I ran into recently. In the Dark Brotherhood Chronicles, we wanted to modify some vanilla NPC's. Now I've been told it's safe to add dialogue and AI packages to them. If our mod is removed, the extra dialogue and AI packages will simply disappear. However in one case, the NPC wound up in the Tiber Septim hotel. This is what the game does if the NPC is placed in a cell that disappears when the mod is removed. Normally that wouldn't be a problem. The NPC will resume its normal schedule and return to where it's supposed to be. However in this case, the NPC had an AI package that made him stay in his current location. So our mod would require an uninstall script to move this NPC back to where he belongs before the mod is removed. We've taken steps to fix this issue.

So those are the points to consider. If you are modifying something that might be referenced by another mod, you can't just delete it in yours. In the particular case you are referring to, the modder simply replaced a door mesh with a different mesh - but the new mesh has a different name, which was required in this particular case. So it's not clear to me why he is running into the problem he's having, but I feel that moving the existing door out of the way and replacing it with a new door is the best way to proceed in this case.

Lastly, if your mod wants to do something drastic with an NPC, like killing him, then you need to clone the original NPC and use the clone in your mod. You will need to move the original NPC to an inaccessible cell. Once again, when your mod is removed, the NPC will be placed in the Tiber Septim Hotel and his normal AI packages should kick in so he returns to his normal schedule. If he doesn't have an AI package that will have him return, then you need to provide an uninstall script so that you can move him before your mod is removed.

0

Share this post


Link to post
Share on other sites

Thanks for the reply :). Sounds like persistent references are going to be a source of frustration and teeth-grinding no matter how long I work with the CS :lol:. But this at least gives me an idea of a few things watch out for. Curious that the NPC didn't go back to his old schedule when the records (esp) putting him there are gone. Hmm...AI state is stored in the save files, isn't it? All the state data would go in there. Otherwise the game couldn't resume on loading.

Bear with me, fledgling programmer here, so I always try to figure everything out if it involves code somebody else's written, even Bethesda :lol: I've been told I tend to over-analyze too :D

Edited by DeadHerring
0

Share this post


Link to post
Share on other sites

Normally an NPC would. This particular NPC had aaaDefaultStayAtCurrentLocation as the only package that was applicable once he was plopped down in the Tiber Septim. So he very obediently stood in the middle of the Tiber Septim with a stupid grin on his face. If he had other packages defined, he would have returned to his normal schedule, which would have him return to the city he should be in and continue from there.

And if you want to know how to do something, Bethesda's scripts are the first place to look, imo. Not always the most efficient, but they do provide a clue to how the game was designed and how Beth intended some things to work. I find it really interesting to note the lines that have been commented out - those are also a clue to what works and what doesn't.

0

Share this post


Link to post
Share on other sites

A short tutorial/info on the subject.

It's always best to avoid touching them if you can though. Even the vanilla ones. If it's persistent there's a 99.99% chance something is using it and will not appreciate it being messed with.

0

Share this post


Link to post
Share on other sites

@ Arthmoor: Bookmarked. Great article! Good to know about the level engine bug too, that could've have made for some serious headaches. Thanks for the link, it answers a lot of questions I hadn't even thought to ask yet :). I can also see how modifying persistent references can cause serious problems with save game files after the mod making changes is removed. Regardless of whether the mod breaks or the game CTDs because of the changes being made in the first place. Sounds like a good way to get your mod un-endorsed on tesnexus.

Thanks, everyone, for taking the time to answer my questions :). I think I know enough now to avoid these pitfalls at least. Hopefully there aren't too many more out there to find.

Edited by DeadHerring
0

Share this post


Link to post
Share on other sites

Thanks Arthmoor - I'll paste that link in to the post on Beth that started all this :D

0

Share this post


Link to post
Share on other sites

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
Sign in to follow this  
Followers 0