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.

IsRaining is only a condition/console function. To check the current weather with Papyrus functions you would this to see if its either raining or snowing: Weather.GetCurrentWeather().GetClassification() > 1 Snow is 3, Rain is 2, Cloudy is 1, Clear is 0, and -1 is used for odd cases that aren't any of those. FindWeather is used to get a valid weather code of the appropriate type for the player's current location. Most regions of the game have their own versions of the 4 basic weather types and some simply aren't possible (it's not supposed to ever rain in the city of Winterhold, it should never snow in Riften, etc.). Typically you would use FindWeather to find an appropriate choice to use with SetActive or ForceActive.

Interaction with the UI is done in the core game logic. We have no access to that level of the game's code.

And it's more than just updating a number. Some people have had the "bright idea" of just changing that number in SSEEdit but can cause more problems than just trying to run the mod without porting it. The only way to properly port the mod is to load and then save the ESP file using the SSE Creation Kit.

If you don't run the ESP file through the Special Edition Creation Kit then you have not really ported it. Technically there are some mods that will work without porting, but it's completely irresponsible to claim to have ported a mod (even for your own use) without running it through the new CK. Even if you don't run things through the new CK some record forms will be fine, some will cause obvious problems immediately, and others will seem to work but silently cause problems that only become noticeable later. It's that last case that's so dangerous. If you have to ask whether a conversion is needed then yes it is. If a mod only uses the form types that don't technically need to be converted then you'll be OK, but unless you're an expert on the ESP file format then there's no way to be sure which ones are safe and which aren't.

You could also just use the official archive creator that comes with the CK. It's horrible for BSA file extraction since it can't cope with a missing .bsl (which oddly isn't needed by the game itself or other BSA tools), but it is guaranteed to create a valid archive.

The SE port of Jaxonz Positioner (at least versions 1 and 2 that I've tested) worked. There are certain features that don't work exactly like the original and there are various warnings and error messages that can appear, but they aren't game breaking in any way. Jaxonz wrote her own DLL to support the orginal mod and also used some unwise programming techniques (that are fine in general programming, but terrible for Skyrim scripting for mods). The person who ported her mod has worked around those issues but the Positioner is very complex and simply working around problems can be difficult. As for options I only know two of 2 mods that allow moving items around in the game. There were more for the original game but the others didn't get ported over. Your choices are the port of Jaxonz Positioner or my Decorator Helper https://www.nexusmods.com/skyrimspecialedition/mods/11708. Decorator Helper serves the same basic purpose of moving items, but works using special spells because I wrote it specifically for the Special Edition before SKSE64 was available. If you've used Jaxonz Positioner (or my Storage Helpers mod for the original game) the the controls in Decorator Helper will seem strange at first, but I've actually come to prefer the new Decorator Helper way of moving things myself.

I forgot there is one problem. If used for a spell or lesser power that can be re-cast then it will stack the fortify effect allowing you to be come insanely fast. I've only used that method on a greater power where I didn't have to worry about that. If it's for something that can be re-cast you'll need to use one of the other mechanisms (keywords and no recast flags) to prevent multiple castings. Alternately you should be able to use the Peak Value Modifier effect but add a second magic effect that changes the inventory weight to the fortify speed spell or lesser power.

I would do a line of sight check and a distance check on each location change until the player is far enough away and not looking in the direction of the building. It won't take too many checks before it meets success. If the building is in a location with other nearby buildings you might need to make sure the player isn't in one of those unless you are willing to have it collapse while the player was inside. (And OnLocationChange doesn't fire "continuously" it's actually fairly rare and a reasonable event to use for this purpose.)

I forgot about the quirk of speed not automatically changing with SpeedMult updates in my first post. There is a simple non-script way to solve that problem too. Use the Dual Value Modifier magic effect Archtype instead of the Peak Value Modifier. You use SpeedMult as the main actor value and InventoryWeight as the secondary AV. Assign a second AV weight factor of -0.001 which will give the player a very minor decrease in carry capacity while speed is boosted. With a factor of -0.001 the change won't make any practical difference but will be enough to make the change in speed register correctly.

Yes, it's a special form of programming and it really is a unique language that also requires a distinct way of thinking about solving problems. It's definitely not for everyone. Of course there are other aspects of modding that are completely beyond my abilities (and interest) too.