MShoap13

If your mod refers to a form that doesn't exist it could potentially cause CTDs and other weirdness beyond naked NPCs. You could always ask for permission to redistribute the armor(s) as part of your package to avoid sending users to umpteen different Nexus pages. Outside of making multiple versions of your .esp and a scripted install, or creating a wrye-bash/reproccer style program to compile your .esp on the fly, I'm not aware of any other solutions.

I'm still stumped on this one. I can't figure out why my second Magic Effect script isn't getting applied. If no one's willing to take a look, are there any solid examples for Perks conditionally adding scripted on-hit effects ?

Compression works the other way my friend. Compressed files take up less space on disk but require decompression overhead in order to be useable. Additionally, the game doesn't and can't decompress all .bsa files on start up. That would take upwards of 3 Gigs of RAM with all vanilla files. For minimum load stutter in-game you want to extract and ignore as many of the game's default .bsa files as possible. I believe there are a number of files in the meshes, sounds, and voices archives that do not function properly if you extract them. I can confirm that so long as you have a loose file replacement in your \data\ directory (or your virtual \data\ directory if you're using MO) for everything in your textures.bsa you can just omit it in the list of .bsa's to load in your Skyrim.ini file. As far as messing with mods that ship with .bsa files I would typically leave them alone. It's probably rare that they're substantial enough for you to see any significant performance gains. If say Vurts Flora Overhaul were in a .bsa I could see that being a candidate for extracting but it's rare to find a mod with that many commonly used textures that ships with them compressed.

To begin with, from my limited experience, most of the scripts you're likely to be dealing with while modding are likely to attach to one of three items: a Quest, an Actor, or a Magic Effect. If you attach a script to a Quest, it generally needs to extend "Quest" in order for the game to initialize it. If you create a script through the CK where you're attaching it, and then immediately close the dialogue window for the item you attached a script to by hitting 'OK' it will save a blank script to your \Scripts\Sources\ folder that already has the proper extension. Properties are like Global variables only you're importing a specific reference as a new variable that you wouldn't necessarily have access to based on what class structure your script extends. A really good example of this is Perks. Say you've attached a script to an Actor that needs to check whether or not you have a specific Perk. You'd need to set up a property for that perk before just declaring it willy-nilly underneath the Actor class. To actually implement the Property correctly is more complicated than it should have to be because the Form (generic umbrella term that includes all of TES's records [Actor/Spell/Item/Quest]) you've attached your script to actually has to have a filled out Property reference that points to said Property's Form ID. To add a Property via the CK, Click your script, open the Properties tab, Add a Property, Select it's type then type it's Editor ID into the "name" box, hit OK, then back out in the Properties tab choose "Auto-Fill" and the CK will automatically find the correct Form ID to associate with your Property. You cannot have a variable anywhere in your script that already has your Property's Editor ID as it's text when you're doing this so you may have to comment lines out temporarily while populating your Properties. Back to your particular topic, there are at least two different Mark and Recall mods floating around and I would personally go delve into what they've done to figure out how to best approach your implementation. If you can learn to browse plugins in TES5Edit it does make sorting what's what within a plugin quite a bit easier as xEdit by nature filters out superfluous items. If you can then cross-reference what you learn in xEdit back to the CK you're set as the CK is the best place to actually alter or make Forms. Also, you can compile your scripts and save your plugin in the CK then immediately go test in game without closing the CK assuming you have enough System RAM to do so.

That NavMesh error is not what's causing your problem. It literally happens every time you open any plugin in the CK.

I'm having an odd issue where the script I've written for leveling One Handed is applying but the script I've written for my 30/60/90 is not getting activated though the setups (perk --> Spell --> Magic Effect) are essentially identical. No clue what's causing the issue. There's nothing wrong with having multiple scripts running on the same event is there? Link to the file with source: http://s000.tinyupload.com/index.php?file_id=93050818463833644664

I'd go dig into how Ebony Mail functions. It sounds like it has a script adding a Spell to the player which then applies a Magical Effect. You need to know where in the chain the Sneaking conditional is in order to properly replicate it.

Did you have another version of ENB installed before Phinix? If so, left over files that aren't compatible with Phinix could be the issue.

Both of those logs appear to be during a game save (usually a cell transition) and both of them show the VM Thawing... message as the last event. You may not be allowing Papyrus enough time for it to reload the snapshot. You papyrus settings are mostly pretty good: [Papyrus]fUpdateBudgetMS=1.6 <--------- Increasing this setting and the one below it may help to work out some of the CTDs during combat. The default setting is 1.2ms but with more OnActor scripts running, it may need to be increased. 12ms is the upper limit I'd recommend but I wouldn't imagine anything much over 3-4 would be necessary in the most extreme circumstances.fExtraTaskletBudgetMS=1.6fPostLoadUpdateTimeMS=1000.0 <--- try bumping this up to help prevent the CTDs on save/transition. It's also in milliseconds and it will very slightly increase loading times (by however many milliseconds you add) but I'd try out 1800-2000 and values higher than that may even be needed.bEnableLogging=1bEnableTrace=1bLoadDebugInformation=1 <-- remember to turn all three of these back off for optimal gameplay and stabilitiy testing. You've seen the message that mattered, so you don't really need them on right now. Only have them on if you're trying to reproduce an issue and store a log of it.iMaxMemoryPageSize=8192 <-- A little high but probably not hurting anything. It would take some insane stack calls to fill this as Papyrus is a very light script and large stacks aren't that common. 1024 to 2048 should be more than enough.iMinMemoryPageSize=256iMaxAllocatedMemoryBytes=8388608 <-- 8MB is getting up there for this setting as SKSE can have problems if this is set too high. These problems can cause CTDs or even corrupt your saves (broken quests, NPCs acting strangely etc.). The default is 75kB and the only time Papyrus uses a lot of memory at once is when it's snap-shotting and then recalling the script VM's state (during saves and transitions). Try cutting this down to 1 to 2 MB (1048576 to 2097152) Also, abut your experience in Helgen; a modded Skyrim being unstable in Helgen is very, very common as it's one of the most script-heavy portions of the game. It's generally recommended to disable as many mods as possible until you've completed the entire tutorial dungeon and have exited the cave. There are some mods that you may need to have on beforehand (during character creation or whatever) but anything that doesn't state it's absolutely required should probably be avoided.

Post your Skyrim.ini and a Papyrus Log of a CTD please. You've probably overloaded the Papyrus system if you're getting CTDs during transitions. There are some tweaks you can mess with that may (read should) improve stability, but there are no guarantees with Skyrim.

That would be a missing mesh. Probably an armor.

It's a 32-bit application, so, it' can't exceed 3.2GB. If you had the source code and the means to compile it as a 64-bit application (not to mention the time and experience to fix all of the bugs that this would bring out of the woodworks), that would be a different story. You don't need to do anything to get Skyrim to see more RAM as (since patch 1.3 or something) it's already got the LAA flag.

No These are bad settings. Bad, baaaad, settings. http://www.creationkit.com/INI_Settings_%28Papyrus%29

Try a forced cell reset. Grab No Boring Sleep-Wait Menu, travel to a small interior cell (like a player home) and use this mod to wait 31 days.

Get some fresh air blowing underneath that thing. Make sure your case is blowing more air out than it's pulling in. Use an FPS limiter to help reduce load in the less stressful areas of the game.

Outside of VFO's trees and shrubs having altered meshes that require VFOs textures, and WATER's specific alterations to shorelines to reduce the sharpness of the line where water bodies begin, it's entirely personal preference. There is no right or wrong answer to give you other than experiment for yourself and see what you like best. :dry:

The game freezes or it CTDs? Is there a sound loop (where the game repeats the same split-second of sound a number of times) when this occurs?

These are way, waaaaay to high. As I suggested in my previous post, start around 12 (the default for both of these is 1.2). I haven't done too much testing with these so I can't really suggest a reasonable max value, but 12 is already ten times the amount of time, for Papyrus to do it's thing, than default. 800 is just plain silly. This could probably come down a bit, but it's not really hurting anything. This is a delay used when the game reloads the last state of your Papyrus VM (at loading screens and saves). It's only downside is slightly increased loading times (2000 = a 2 second pause). This is a little on the high side, (That's 2400KB) but it shouldn't be high enough to cause any problems. I typically suggest 1MB (1048576) as it's more than enough, but low enough to not run into problems. This setting determines the maximum amount of System RAM the Papyrus VM can use. When the Papyrus VM screenshots itself and then reloads the screenshot (during saves and loading screens), it's memory usage spikes. If it runs out of System RAM during this spike, your game will CTD. The default of 75KB (76800) has been shown to not be enough for some setups. Ridiculously large values (100MBs or more) have been shown to cause stack count issues among other things. Bumping this up to 768 or 1024 may increase stability for your mod setup. It should definitely reduce stutter though as you have Footprints and Crimson Tide running and they both have large stacks that need lots of memory (comparatively, "lots of memory" at least) All of the following mods have at least one script that runs constantly. Some of them run solely on the player, some of them determine when a bird is going to pop up, and others even have scripts that run on all Actors that are currently loaded (Crimson Tide, WetandCold, Footprints): Chesko_Frostfall.espBirds.espskyBirds - Airborne Perching Birds.espConvenient Horses.espFootprints.espFootprints - Ash.espWetandCold.espSkyUI.espiHUD.espCloaks.espPumpingIron.espHeadtracking.espThe Dance of Death - Ultimate Edition.espCrimson Tide - Blood.espUFO - Ultimate Follower Overhaul.espgetSnowy.espMany mods require no Papyrus scripting at all, just .esp alterations. FasterHorses_Sprint_x1_5.esp for example. Others require .esp additions along with custom resources (meshes and textures), Immersive Armors falls under this category. Some mods don't even require a plugin, just a custom resource (HD2K falls here). If the Papyrus Tweaks, and removing Moonpath don't help, try disabling CoT - Sounds. If that fixes it for you, you could try re-enabling it and lowering your sound sampling rate in the Windows Control Panel. I believe 16 bit 41000Hz is what I've seen suggested when running sound replacers.

When cleaning a file in TES5Edit, you should only load the file your cleaning and it's explicit dependencies (which IIRC, are automatically loaded if they're available). The big thing that needs cleaning there is the UDRs as they can cause major issues if a mod loading further down in your list tries to alter a reference that was deleted in a plugin loaded before it. The ITMs can also cause issues but rarely are they as troublesome as the UDRs can be. If you get an error for a particular file while trying to load it into Edit, feel free to post a PrintScreen image of it here and someone should be able to point you in the right direction. Onto the next issue, you need to get Wrye Bash and make a Bashed Patch. You have a lot of mods that alter leveled lists and without a bashed patch, only the last version of a list will take precedent. Bash will combine them for you. And that deleted NavMesh warning could be a big problem if any other mod in your load order relies on that particular NavMesh.

Is this with Autosave on? If so, you could be seeing issues from savegame bloat. How large is your most recent save file? It could also be the Papyrus VM running out of RAM, but this is a theoretical crash source. The game pauses all scripts during saves and stores the VM in memory, reloading all of these causes a huge spike in the Papyrus VM's memory usage. It's pretty much impossible to say this is definitively the cause of crashing during saves. Increasing the following line under the [Papyrus] section of Skyrim.ini may or may not clear it up: iMaxAllocatedMemoryBytes=76800 That's the default value (about 75KB). It's pretty safe to bump it up to 1MB (1048576). Anything past that is probably pretty senseless and ridiculous numbers (like the oh-so-often used/recommended 2GB) is probably going to cause problems. This number is just how much System RAM Papyrus can claim at any given time, not how much RAM Skyrim itself uses.

Try using "sexchange" in the console twice to reset your spell effects. Chick third person, scroll into first, and then check third again to make sure it doesn't return. If that doesn't work, you're going to have to do some homework and then remove the spell effect in the same manner as the Draugr eye fix. I believe this effect is related to the hell hounds.

Highly, highly doubt it. If you were on an i3-410 or something it might be an issue, but still an unlikely source of freezing IMO. Next time it freezes, open the task manager and check how much RAM Skyrim is using.

The workaround for this has been known since Fallout 3 (at least). Load your save, alt+tab out and open your Skyrim.ini, set uGrids back to the default of 5, save the .ini, alt+tab back into the game, open the console and run "refini", make a new save. It's advised to backup your old save (or at least not overwrite it). It's also advised to immediately exit to the menu and then load the new save you just made to make sure the uGrids change took.

The .bsa's are packed for easier internal working and streamlined distribution. They're packed with ultra-light compression and unpacking the OHRTP .bsa's only real negatives are increased clutter in your loose files and about 20MB's of disk space. The positives are reduced CPU overhead (decompression), reduced load stutter, and reduced System RAM usage. The reduction in RAM use is primarily triggered if you're running a large texture pack like 2K HD, Book of Silence, or multiple replacers. There are a number of issues you can run into with messing with the .bsa's. You usually see these types of issues from repacking the .bsa's without extreme care. There may or may not be issues from unpacking the root/DLC .bsa's but I can say for certain that unpacking the OHRTP is a safe and effective way to reduce the performance and stability impact it has on a heavily modded game.

Can you monitor your System RAM usage in the background? Freezes usually occur from maxing out the 32-bit engine's limit (around 3.2 GB). If Skyrim is getting close to this limit, CleanMem may be able to at least prolong your playtime before experiencing a freeze. A guide with some possibly useful information on CleanMem and Skyrim can be found here. Your crashes may be due to Papyrus overload. You've got quite a number of mods that run scripts in the background plus WarZONES which gets really Papyrus heavy when it spawns 10 actors at once. Adding/altering the following lines under the [Papyrus] section of your Skyrim.ini (located at \My Documents\My Games\Skyrim\) may increase stability: fUpdateBudgetMS=1.2 fExtraTaskletBudgetMS=1.2These are delays where the game literally pauses for x milliseconds, every-so-often, in order for the Papyrus VM to do it's thing. Increasing these may increase stability. The values shown (1.2) are the default values. I'd start between 10 and 12 for both settings and then, if that helps, bump it down from there. Setting these too high will cause massive microstutter, too low can be a source of crashes. So far two people I've helped (who had similarly Papyrus heavy load orders) have seen improvements in stability through increasing these. Please post back if these tweaks help; details (regarding whether or not they helped you, how low you were able to tweak them, etc.) would be appreciated. Regarding the Official High Res Texture Pack comment from earlier, an alternative solution would be to unpack the .bsa's (with BSAOpt or a similar program), copy them as loose files to your \Skyrim\Data\Textures\ directory, and then setting the game up to not load the .bsa archives (either via .esp or the .ini resource list) may be an effective alternative. Obviously, choosing not to overwrite any files belonging to other texture replacers would be recommended. You can even pack the OHRTP into a .7zip and use NMM/MO to install it for easy install/uninstall/overwrite history. If three different versions of a texture exist (one in the normal textures.bsa, one in the HRTP.bsa and one in loose files, the game loads all three into memory. This tip cuts out the redundantly loaded textures without losing the high res textures that aren't covered by other mods. I believe this can even be done with the normal textures.bsa though the impact on memory would be much smaller as it's textures are, on average, about four times smaller than the OHRTP.