cdcooley

ReDragon's script is designed for making sure things happen only when the player is present. The item gets disabled when the player leaves the cell and the re-enable if the player enters at the right time. When entering the cell during the "on" time there will be a slight delay before the state change (which is meant to lighten the script load when a cell loads, but might be distracting if the player leaves while things are on and then returns almost immediately to find them off and just turning on). More importantly the use of a standard 1 hour re-check interval instead of calculating a new check for the appropriate time means it will both use more resources and not guarantee the switch at the right time if the player remains in the cell for multiple hours. (So basically it's a fine script, but the wrong one for this task.)

Try this. I haven't tested it but it should work.

You'll need both a Spell (the lesser power) and a Magic Effect (the effect that actually produces the change). Start with the Altmer Highborn power, PowerHighElfMagickaRegen, and effect, RaceHighElfFortifyMagickaRate, as a model. Instead of the actor value in the magic effect being MagickaRate you'll need SpeedMult and UnarmedDamage. If you wanted passive abilities it's basically the same but use the Altmer Highborn ability, AbHighElfMagicka, and effect, AbFortifyMagickaHighElf.

The only way to fix it would be to change the how the path is typed on the object. Literally go find where you typed "AmuletsandRings" and change it to all lowercase.

Note that the really critical part is where you would choose to return. In your original code you indicated you wanted to return after the first if-endif statement. That would have meant that the second one would never even be checked. IsharaMeradin's code uses the if-elseif-endif structure and corrects the potential problem by including the return inside that first if section. In that example the return isn't actually needed since the elseif will also effectively tell the game that the function has nothing more to do when the first if condition is met.

That's just the CK using the path from the item to give you a filtered and "organized" view. The filtering in the CK is case sensitive but the game and filesystem aren't. It's not a problem just slightly annoying when you're looking for something and have to check both sections in that CK list.

The CK will automatically separate textures into their own BSA. That file will have the compression flag turned on while the main file won't. (It's a bad idea to use compression for the sound and script folders and possibly a few others.) The " - Textures" variation is the only special BSA name recognized automatically by Skyrim. (Oblivion would load any BSA that started with the name of a matching mod.)

SSEEdit/TES5Edit has built-in features to compare two mods. And just looking at a mod will show you the changes it makes in a fairly compact way.

I'm not sure what would happen if you have a script self activate when the object isn't in a loaded cell and so I decided to play it safe. There could be both animation and persistence issues. But yes, in theory having OnUpdate() call OnActivate(self) instead of FlipTheSwitch() might work.

OK, here's an updated version that should make the system activate automatically when the batteries are fully charged. It also has the option for having a limit on how long the batteries work before being drained down and need to be recharged. (Note that keeping the new HoursUntilDrained value at 0 means they never drain down.) Depending on what is happening Notification messages don't always appear on screen, so it's possible that message was sent but you couldn't see it. With this version the lever position isn't always going to match the battery charging state. That can be fixed but unless the visual position of the lever is critical I wouldn't bother. Since you're making changes both when the player flips the switch and at a specific time it's fairly complicated to keep everything synced up using the proper animations.

Here's a script (with two different implementations of the OnActivate logic) that should accomplish your Plan A. The important part is the use of the "Busy" state to prevent double activation of the lever. Technically the best version of this would use a lever that doesn't have the NorLever01SCRIPT or other default lever scripts and implements their logic to make sure the lever always appears in the correct push or pull state. My version of the OnActivate event ignores the lever's position and keeps track of the what action to take based on the amount of charge already completed and whether there's a current charging start time. With it the activator could just as easily be a simple button with no memory of on and off.

There is no auto-save AFTER anything. Auto-saves always happen before some event. But they can be turned off somewhere in the settings menu if you're feeling lucky/foolish. (The developers put in auto-saves just before the points where the game is most likely to crash. That's why there's one just before any fast-travel and at most cell changes.)

SKSE implements a version of custom events. Even without them you can follow the SkyUI example and have a master quest in your base mod and let the plugin mods register themselves with it.

I would use DispelAllSpells to cancel any current effects, then drain about 1000% of magicka. That should be enough to overcome any bonuses the player might have. :)

You can't remove Flames and Healing because they are assigned to the player in the CK directly. There are some mods change that, but you shouldn't count on it and if you add that feature to your mod it will introduce incompatibilities. Depending on what other mods are involved there might also be racial powers and spells that you can't block either. A fairly effective strategy is simply to apply a perk or spell effect drains the player of magicka and/or increases the cost of spell casting so much that it's not possible. (And remember to drain or increase costs enough to compensate for any bonuses the player might have. 100% drain won't do much good if the player has an effect that doubles base magicka. But then there are the spells/powers that don't cost any magicka and spells or effects provided by abilities or perks. Basically there's no way to guarantee the player doesn't have access to some powerful effects. So I would go with draining magicka and upping spell costs as part of a special perk, use "DispelAllSpells()" and just not worry too much about whatever is leftover.

It will decrease your game performance and require significantly more disk space. So it's not a great idea, but shouldn't be game breaking unless you're already pushing your computer's limits.

There is absolutely no difference between Function and Event once the script is compiled so technically you can use Function everywhere without any problems. The use of Event is purely a cosmetic feature to make the bits of code called by the game engine itself stand out. The Champollion script decompiler is used by many people to get source code for mods that only included the compiled scripts. That program generates scripts that use Function everywhere instead of Event. My guess is that this trend started when people used that tool and copied its results into their own mods.

It should be taking 4 frames total but could potentially take longer. A minor improvement would be to use the PlayerREF property instead of the Game.GetPlayer() call because that function is 1/4 of the script's running time, but that still doesn't explain a long delay. The only reason I can think of that this would be slow is that you've already got too much other script activity going on in your game. Each of the functions will require one frame to run, but even at 30 fps that should still be just over 0.1 seconds for the message (with the explosion and health both happening during that time).

Yes, other mods that provide their own DLLs will also have to be updated just like SKSE64. So if you use any mods like that you'll need to track their update status.

LE mods can be converted for use with SE but the reverse isn't true except in special cases. If you're planning to support both versions you need to develop for LE then convert to SE.

Don't register the Player for the event, register the script. Event OnInit() RegisterForMenu("StatsMenu") EndEvent

Are they entering on their own or are they simply following you because you entered while they were talking to you? The second issue is a standard game "feature" and they should leave again as soon as they finish talking (unless the door is locked). The only other thing I can think of would be that your house doesn't have it's own unique location. If you're simply reusing a public or shared location NPCs might be coming in to look for usable furniture and idle markers.

That's accomplished by attaching an ash pile (although technically from script you can attach any object you want which is how ice wraiths and ghosts have their custom remains). You could leave behind an ice shard or a small puddle. And the best part is that the game will clear out the "ash pile" in the same way it cleans up dead bodies.

Loading a save after dying is usually safe because you're loading something that was saved recently and no major changes that could cause problems generally happen in that case (assuming you haven't disabled the default autosaving behaviors). Yes, loading other characters should be disallowed, but it's one of those things Bethesda didn't think about and there's nothing we can do other than know it's a bad idea. You're probably right that it could have been related to the survival mode. In fact the most likely problem is that you were switching between saves that did and didn't have that mode enabled and the mis-match was one of those problem cases where the featured became partially on and partially off. I know some of the SKSE team are fairly active on Reddit, but other than sending an email to the team I don't think there's a formal feedback channel. But this wouldn't be something SKSE would address.

By "switching savegame profiles" do you mean that you've been playing a game then loaded another savegame? If so, that's a potential problem. If you switched to a savegame of a different character or back to one that hadn't had that mod installed before then I would definitely expect problems and even possibly a crash. Any time you load a saved game from anywhere except the opening game menu you run a very serious risk of game corruption and if the save you're loading isn't a very recent save for the same character it will almost certainly cause significant corruption. When you do that sort of load the game doesn't completely reset memory and so part of the state from the game you were playing is merged into the state loaded from the savegame file. In some cases the merged information is just a giant mess and all sorts of bad things can happen. I would consider a crash to be a blessing because it means you don't have time to then save that corrupted mess into an other savegame file.