cdcooley

Scripts in Papyrus are basically just class definitions from the perspective of most languages. It doesn't really matter how they get attached to a particular item. They can be attached to a base object or attached to a specific object reference. If you fill a property on the base object that property will take on that value for all references unless that same property gets reassigned by filling it again on a specific object reference. The Papyrus equivalent of object instances are the activated scripts attached to object references placed into the game world (and special singleton objects like Quests).

As long as you don't try to use a single quest to both store information (i.e. quest stages, script properties, etc.) and to find nearby items then using quest aliases is definitely the right way to find things that interest you. It's both much faster than trying to locate things with Papyrus calls and gives you more flexibility in what you can locate. I use it in a few of my mods.

The basic skills have simple matching games (in most cases) so Destruction skill is Destruction, Light Armor is LightArmor, Alchemy is Alchemy, etc. but Archery is Marksman and Speech is Speechcraft. Level isn't stored in an actor value. There are GetLevel and SetLevel functions for that one.

Also try Debug.Trace and then check the log file. I haven't checked, but it is possible that Notification doesn't work while you're in the book reading menu. So the keys may be getting processed and it is just the notifications that are failing.

I make my personal mods dependent on the unofficial patch, but not any mod I would release. I don't like forcing dependencies unless there's absolute no way around it. But yes, I always check to see if I'm overriding anything from the patch because if at all possible I want to "forward" their changes into my mod if at all possible.

That's a sub-component and I think it's accessible through QuestUpdateBaseInstance whose properties are defined in the QuestNotification class. I haven't looked at those specifically though.

OK, just brainstorming a little more. Could they be running something that's making a patch automatically for them? Or if your power is using an existing magic effect maybe some other mod is changing that effect which is causing the change in behavior?

Did you create that mod and publish it for SEwithout loading and saving it in the Special Edition CK? If so it's a failed conversion problem. There are still little internal (and generally invisible in xEdit) features of the file formats that are different between the LE and SE versions. And those differences can only be processed correctly by the official SE CK. If it isn't that I don't have a clue what could be going wrong.

If people foolishly use mods (or the console) to create clones of the player then the Unique Actor condition may not work correctly because the Player isn't actually unique (and the condition can select the clone instead of the real player). In theory your method should be fine because Unique Actors are supposed to be UNIQUE but when players and mod authors get "creative" it can cause problems. That's why they suggest selecting the player by reference. Interestingly in general you should avoid the Specific Reference option where possible, but this is one case where it is the better choice.

You really should be using the CK for making mods then cleaning them up with xEdit. There are plenty of things that xEdit can't do if you try to build an entire mod without ever loading it in the CK you are very likely generating something that has massive game destroying problems.

There are only two sources of script information. The .pex files and the savegame file. The version of the script first accessed when you start the game is the one that will be used until you close the game (with priority given for a loose .pex file if there is one and one from a .bsa using the same load order logic as the .esp files otherwise). Any function (not the entire script, just the function) actively running when you make a save will be stored in the savegame file. When the game reloads that function will continue to run until it is complete using the original function definition, but any new calls to that function will use the version from whichever .pex file gets loaded.

You can have textures in the main BSA file. I haven't tried having textures in the main file and also a separate textures bsa, but it should work.

You simply need an empty ESP (or ESL for special edition) file with a name to match the BSA.

I'm not sure about the size limit, but it's probably still true. The second part about naming is definitely false. That doesn't work with any version of Skyrim. The only two BSA names that the game recognizes are "mymod.bsa" and "mymod - Textures.bsa". You should be packing everything except textures (including scripts) into the main bsa file and it should not be compressed. The textures are separate because they can and should be compressed. And yes, with with SSE you could create a series of empty ESL mods so they don't take up a critical slot in your load order.

Yes, FindWeather might return None if the region really doesn't handle a particular weather type.