Jump to content

[Skyrim] Information Baked Into Saves


Arthmoor

Recommended Posts

Ah, in that case you need to go back into the CK, open the offending object, click on the properties button for its script, and click OK on it. That will update the esp to remove the invalid property.

Link to comment
Share on other sites

Yeah, most of the time when I test stuff I do quit to desktop before testing something new - and in the case I was describing, I did quit to desktop everytime, and the same repeated on whichever save I was loading from desktop. That property name popped up every time in my log0, when it never was present neither in the script nor in that old save. Which gives me the unpleasant feeling that after the game has ran a new script once, it can't forget it no matter what save you load. Getting rid of the warning is easy, but my understanding is the fact that you get no warning doesn't mean that script is not baked in already.

It's not just scripts too: in the CK, I load Honeyside for instance and just disable the Vanilla NobleBed reference - or more precisely I set it as "opposite state" to its parent - then place the exact same form instead, which of course has a new reference ID, which I set to "Initially disabled". When I load that .esp, the Vanilla bed reference baked in my save is effectively disabled, but my modded reference is not - and I can't disable it through script either. That new reference of a Form baked in my saves behaves exactly as the Vanilla reference did. Weird.

@ Arthmoor: yeah, that's the first thing I double checked: the property tab was properly set. But thanks for reminding me - I'll double check that I don't have another reference using that script that I may forgotten to check in that test plugin. I'll let you know but if that's the case, my bad for taking up your time...

Link to comment
Share on other sites

Well here's hoping Bethesda haven't invented new challenges for the community in the form of Quantum bugs, they can be in two different places simultaneously :fear:, the space time continuuuuum holds no bounds for a Gamebryo engine :)

Link to comment
Share on other sites

Lol  :ninja: Quantum bugs, sure feels like that at times...

Hmm... Tried something about the bed reference placed in Honeyside which would load despite its "initially disabled" flag: it had a script attached to it with an "Auto State". If I remove the script, the bed is  properly disabled when I load the cell, if I attach a script to it, the flag seems to be ignored. That script's only purpose was to verify which update of the HousePurchase quest had been added, it was pointing at baked references.

As for that Property warning I'm getting from yet another script, it's still there - I was hoping I had overlooked another instance of the script as Arthmoor suggested, but no: only one instance and everything was properly referenced. I also checked the skse logs which clearly show that plugin was never registered in any of the saves I loaded. Still the error pops up no matter which save I load... :geek: 

Link to comment
Share on other sites

On 1/2/2018 at 6:05 PM, XJDHDR said:
On 7/17/2013 at 11:33 AM, Arthmoor said:

There is one method for mitigating this - to a point. Blank a script you want the system to clear. As long as it isn't carrying out OnUpdate() events, the game will strip all the properties, variables, and other things from it. That will leave behind just an empty stub on your save. That will still never go away, but it DOES clean up most of the problem in the process. It's as close to a "save cleaner" as one can safely get.

Sorry for the necro but I am wondering what would happen if someone uninstalls a mod without providing blank copies of the scripts used by the mod? Would the save game keep all the functions and events (that are not OnUpdate events) from the scripts that were removed? And if so, will the game try to send events to and run functions in those scripts? This is all assuming the scripts do NOT contain OnUpdate events.

 

Edit: Also

On 6/14/2013 at 9:01 PM, Arthmoor said:
  • Papyrus script properties. These become permanently baked in from the moment the game starts and/or when a new mod with scripts is added. Script properties can only be updated by forcing them to change via an update script, like what the USKP uses for retroactive fixes.
  • Objects pointed to by Papyrus properties. These can never be moved, even with scripted commands. This data is baked in from the moment the game starts and/or a new mod is added. Most attempts will simply fail silently, while others will log an error saying the objects can't be moved.

Does anyone know if these two problems apply to ALL script properties or can AutoReadOnly properties mitigate them.

Sorry to interrupt this discussion but would it be possible for someone to answer these questions I asked a while ago? Thank you

Link to comment
Share on other sites

@XJDHDR:

Quote

 if someone uninstalls a mod without providing blank copies of the scripts used by the mod?

You mean an uninstall version of a mod that set's the script overrides to null? There won't be any scripts to run, so no problem, as long as the mod is de-activated.

I'd say all, but if you have Oldrim, fire up Hadoram's script cleaner and search in one of your saves for these. Please post back the results. :)

Link to comment
Share on other sites

On 2/28/2018 at 5:38 PM, lmstearn said:

@XJDHDR:

You mean an uninstall version of a mod that set's the script overrides to null? There won't be any scripts to run, so no problem, as long as the mod is de-activated.

I'd say all, but if you have Oldrim, fire up Hadoram's script cleaner and search in one of your saves for these. Please post back the results. :)

I was thinking along the lines of replacing the scripts provided by a mod with scripts that contain only a scriptname declaration: No variables, properties, functions, events or anything else.

Unfortunately, I don't currently have a save that I can test my hypothesis on.

Link to comment
Share on other sites

  • 1 year later...

Not sure anybody is still reading this thread but if so, I'd appreciate if someone could enlighten me about alias reference persistency.

OP states:

Quote

"Objects pointed to in forced reference aliases for quests. These are not supposed to become permanently persistent, but more often than not that's exactly what happens."

Then a little further:

Quote

"Everything in the OP refers to stuff placed by hand via the CK. Using scripts and PlaceAtMe() is not treated the same by the game so it's not going to be clear whether or not the same rules apply."

And yet in another thread (Skyrim Levels of persistence), this time about references - Level 4 persistency here:

Quote

"When a reference is assigned in a quest alias, that reference becomes globally persistent for as long as that quest is running. While the CK Wiki makes a distinction between "Forced Reference" and other types of aliases, experience has shown that all reference aliases are treated the same way. While the quest is off, you can relocate positions on these references at will."

 

Using PlaceAtMe and quest aliases is just what I'm doing in an attempt to - hopefully - avoid persistency:

- I'm working on a mod which places custom Furniture objects at runtime through a perk script, all instances flagged as initially disabled in the hope that I can delete them once I'm done with them.

- I then keep track of these placed objects' refs by Forcing them to Alias refs in a quest which only runs when needed. Attached scripts therefore extend ReferenceAliases rather than created objects. No reference is used as property and variables are filled at runtime, then assigned a "none" value before scripts go to an empty "Done" state.

- That quest is later stopped via an external modEvent intended to clear() all aliases and try to delete all placed references to avoid baking them in saves.

But now after reading several threads about persistency, I'm wondering if forcing my placed objects to alias refs is the proper move to avoid persistency issues. Wouldn't I be better off avoiding a quest altogether and having my scripts extend placed refs' instead?

Any idea? Many thanks in advance!

Link to comment
Share on other sites

As long as the quest containing the alias is active, the reference will be persistent. There's nothing that can be done to avoid that, and there's no inconsistency in what each thread is talking about.

Link to comment
Share on other sites

 Thanks a lot for your answer, Arthmoor, much appreciated! :)

No inconsistencies for sure, but some questionning (at least for me) about references added at run-time with PlaceAtMe(...):

Quote

"Everything in the OP refers to stuff placed by hand via the CK. Using scripts and PlaceAtMe() is not treated the same by the game so it's not going to be clear whether or not the same rules apply."

By alias being "active", you mean quest running and alias not cleared, right? Meaning, once I've stopped the quest and cleared alias, persistence flags are lifted?

Like I said, I was considering avoiding the quest altogether. If I get a better chance to avoid persistency by attaching my scripts to refs placed at run-time - that's what I'll do. Would you say it's a safer solution? 

Link to comment
Share on other sites

There's also another bit of information to keep in mind which isn't covered by those topics. If Papyrus assigns the reference you generate with PlaceAtMe to a variable within a script, that also causes that reference to be persistent until it's either set to "None" or the placed reference is deleted. You can't really avoid it because it's necessary for a lot of things to work correctly. I'd recommend not trying to avoid it as much as you seem to be trying to. Just don't be excessive in the use of persistent actors/objects and you'll be fine.

Link to comment
Share on other sites

Hey thanks again, Arthmoor :)

Yeah, I'm aware refs are persistent until set to none - and you're right, I tend to be overcautious about errors, unwanted persistency or save-bloating but in the long run, it's probably helped me keep my mods somewhat clean. Users have such a "creative" way to induce bugs that I'd rather be safe than sorry...

Thanks for keeping this site alive after all these years!.. When in doubt, who better to ask than the "Destroyer of Bugs", right? ;)

 

Link to comment
Share on other sites

  • 3 months later...

Very useful thread!

Does somebody know if music mods are baking something into your mod? I'm asking because I split my music mod .esp into multiple .esp's for each music type. The mod only alters music types and adds new tracks, nothing else.

If it saves some data into the savegame, is it gonna be harmful in anyway? 

Link to comment
Share on other sites

  • 1 year later...

A rather belated reply to this topic, mainly as I'm having a rather belated play-through of Skyrim for the first time in about a decade.  I've discovered I like it a lot more with better skin textures so the locals don't all look unwashed and moody.  Maybe I'm just a bit shallow like that.  "Skyrim: the province where soap is afraid to tread."

Ahem.  Er anyway, I was just looking up this general topic after discovering that The New Way Of Doing Things™ is for mods to change stuff like levelled lists using scripts rather than overrides and what-not, and I wondered "what sort of monster would do that?" but I now realise I didn't know the half of it.  Seeing the OP describe the way Papyrus indelibly changes stuff in a save file whose format Bethsoft have remained unhelpfully tight-lipped about and doesn't clean up after itself is horrifying, and it made for rather uncomfortable reading.  As much as Oblivion's script has its own horrors (e.g. trying to check a reference was valid and the contents of a field in the same IF statement would CTD if it was null... meh) at least it's nice and straightforward about what it's doing and is cleaned up if the mod is deactivated, so this came as a nasty surprise.

I suppose I shouldn't be that surprised having seen some examples of what's been found to cause other CTDs, e.g. not bothering to do what I just mentioned only in the original C code according to someone who disassembled bits of it, but it's still astonishing enough that I felt compelled to create an account here just to write "!!!" about it.  Actually I thought I'd already created an account here but I guess I must've done all my pestering of Arthmoor for information over on Nexus.

I'm kinda hoping that I haven't messed up my game too much playing mod carousel; it seems to be mostly okay, though as I implied earlier, it seems that further additions to levelled lists via the usual method (at least back in Oblivion) of rebuilding Bashed Patch doesn't appear to be working.  And I'm not desperately keen to add to the tangle of scripting with some of my own.  Plus I hate CK and take the attitude, "if it can't be done in Xedit, it's not worth doing."

Meanwhile, over in Markarth's general locale, it's raining goats.  Might be a messed-up save but I suspect that's probably just Skyrim being Skyrim.

Link to comment
Share on other sites

I thought I could outwit Skyrim's habit of writing immutable data to the save file by creating a new reference to supersede the old one but of course it has that covered too because the refID numbers are also permanently saved and apparently unchangeable.

I have to wonder who thought this was a good idea.  For a company whose games' ongoing popularity is significantly thanks to the modding scene and who've capitalised from it, they make some oddly contrary decisions.  Okay, I know in the grand scheme of things Skyrim's overall sales figures probably have little to do with modding, but would it kill them to be a bit less obtuse?  They could at least publish the file formats but sometimes they're worse than EA for "muh innerlecshal propartee" and refusing to divulge anything.

Apologies for all the grr, just spent the past hour trying to fix Realistic Room Rental for the Old Hroldan Inn where the bed was welded in the original position in spite of the mod being active before I ever entered.  I guess something somewhere must've referenced it before the mod was even installed and made its initial position permanent.

I dunno, it's easy to blame mods and players for expecting stuff to just work but I think after Oblivion mostly cleaned up after itself (well, except for permanent references) it wasn't an unreasonable expectation.  For a game that can go on for hundreds of hours, effectively having a static and unchanging load order from beginning to end is expecting a bit much IMHO.  The blame for these problems lies entirely with Bethsoft.

I guess the one thing modders can learn from it (or at least that I should learn) is to use scripting as little as possible and to always use new references rather than attempting to supersede old ones, though that's probably unworkable as it might also mean the creation of new and duplicate quests and the dependencies could be endless.

At least with this quest I was able to manually setstage my way through it until it got to a point I could complete it.  I would say it's a bit immersion-breaking, but so is having to F5 all the time...

I'm also wondering if any of this is still relevant outside of Skyrim anyway.  Though FO4 was still recognisably the same engine, it seemed to fix a huge amount of stuff I'd considered to be problematic about Skyrim, though my own modding habits remain mostly limited to adding new wearables to the game so my experience is limited.  At least they got rid of the NPCs' apparent soap-dodging habits, the only vestige of Skyrim's character rendering is that my PC looks like she hasn't slept in a week.  But so do I, so who am I to comment?

Link to comment
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
×
×
  • Create New...