Jump to content

EiffelGTower

Members
  • Content Count

    9
  • Joined

  • Last visited

  1. 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?
  2. 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(...): 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?
  3. 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: Then a little further: And yet in another thread (Skyrim Levels of persistence), this time about references - Level 4 persistency here: 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!
  4. Oh, sorry, I missed your replies, guys - and thanks for it! Nope, not using any unofficial patch on this install, it's as ancient as Skyrim itself, only one DLC, heavily modded, still running smoothly and I was reluctant to patch it after several 1000 hours on it - I use it mostly as a crash test for my mods. (I do have another full install on another computer). It didn't look like an error but it sure bloats my logs when I use them for debugging my mods. Thanks for the tip anyway, I'll try that Imstearn, see what difference it makes in the log.
  5. Not sure this is actually an error but could someone help me understand what this means? While I let my game run on vanity camera in a cleared interior cell (Drelas Cottage) to let SKSE "ClearInvalidRegistrations" do its job, my Papyrus log filled up with this line some 2500 times in 4 hours - and with only that line, nothing else: [03/04/2018 - 07:50:43PM] [DLC2PillarBuilderActorScript < (020177DB)>]OnPackageStart() Reference of the actor varied - 20 different actors in fact - although (020177DB) is the most common one. I can't figure out what's going on, this points at the Dragonborn main quest which I completed ages ago (I only have Dragonborn installed on that machine). No stack above it, no error, just this line filling in every 2 or 3 seconds. I have absolutely no other mod referencing these actors, quest, packages or locations. I did a bit of digging in SKSE and the CK but it's a fairly complex quest and I'm not sure I get it all. Not sure either that the mentioned script "DLC2PillarBuilderActorScript" is the culprit - looks more like some other script is trying to force update the quest aliases. Has anybody else seen that before? Any idea what I should do to clean that mess up? Thanks a bunch!
  6. Lol 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...
  7. 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...
  8. Hey, thanks a lot for your answer, Arthmoor! These warnings occured before the game loaded, loading an ancient save which had never seen any version of this script (either with the original Property or with the modified one) and loading a script where that "missing" Property never appeared - so I was wondering if somehow that property change had not been stored in the plugin itself since it couldn't have been stored in that 6 month old save... Just couldn't figure out where that missing property's name and ID was coming from. But if I'm understanding you and what I read here correctly, these warnings should not "contaminate" the loading save? They can only be baked inside new saves (auto or manual), is that correct?
  9. I'm nowhere near as experienced as any of you guys, so this is a most enlighting read for me, thanks! I have a question about scripts if any of you is reading this. Started working on a scripted mod recently using custom keywords as properties - then experimented removing one keyword from a script property to point directly at the same linkedRef instead (skipping the keyword). Of course, log shows "Warning: Property _MarkerToCheckKW cannot be initialized because the script no longer contains that property" if I reload a save made when my test plugin was running. For the sake of experimenting, I disabled the plugin, loaded a complete Vanilla save from 6 months ago, made a new save, quit, enabled my plugin and reloaded that save. The crazy thing (for me) is that my log still shows exactly the same warning as if that old save had seen that plugin before. So my question is where and how is that information stored if not in the save?

Support us on Patreon!

Patreon
×
×
  • Create New...