sclerocephalus

First, I recommend reading through the random encounter thread at AFK mods (see link below). This will explain how the random encounters are supposed to work, why they did dry up after a while in a purely vanilla game, the results of these failures (this also had consequences for e.g. workshop attacks) and how the problems were fixed. Once you understand how the system works, you won't make wrong assumptions any longer. https://www.afkmods.com/index.php?/topic/4807-issues-with-random-encounters/ Second, the game will not start any random encounters if there are too many actors in an area because actor handling costs significant performance. Thus, once settlements have grown beyond a certain settler count, RE spots in their immediate vicinity will stop spawning quests. This behaviour is hard-coded, meaning that there's no workaround to spawn RE quests anyway. The RE triggers still send events to the story manager as they're supposed to, but the story manager simply says "no" and doesn't start anything. Note that this can ne easily tracked on your papyrus log because the game prints out a warning (saying "Failed to start a random encounter. Check number of quests currently running and number of actors in the area.") every time this happens.

Location references are special tags for items or actors within a location. They are used by quests to fill their aliases, but they are also used by the radiant quest system to select a target location. For example, if a quest places an item in a chest to be collected by the player, it has to make sure that there's a suitable chest somewhere in the location, preferentially in the boss room (so the task won't be overly simple). To make this work as fast as possible (there's always the alternative to let a script check all containers in a location, but this will make the target selection very slow), the chest is given a special LocRefType, so the quest selector only has to check the locations for that reference. Though, there is other stuff where they are used: for example, whether a location is clearable or not depends on whether it has a boss (and that's another LocRefType). If there are actors with that LocRefType in a location, the game marks it as cleared once all these actors have been killed. If the LocRefTypes are missing, it will never be marked as cleared (and then, it will also reset much faster). If there are too few locations available to be chosen as targets by specific quests (they ususally don't look for just one LocRefTyoe), the radiant quest system may lock up, and quest givers may stop to give you new quests for a while.

Yes. Working on this for months. When trying to place specific items on a rack (e.g. the ebony blade, etc. but also a number of mod-added weapons), removing it from the player's inventory returns a borked reference which behaves like a none, but logically isn't "none", and slips through all sanity checks (sounds totally weird, I know, but is - sadly - true). Technical details are here: http://forums.bethsoft.com/topic/1476556-no-native-object-or-object-is-of-incorrect-type/

These are warnings, not errors (they are prefixed as such in the logs for a clear distinction) and there's a big difference: (1) Warnings are never printed while you're actually playing. They are sent to the log during the loading process, i.e. while you're still on the loading screen. They usually stop to get logged once the "VM is thawing" message appears. At this point, you are entering the game. Thus, whatever it is that slows down your game has nothing to do with the warnings. (2) Errors are logged at all times, but mostly while you're actually playing. Logging alone costs performance. Otherwise, it depends on the specific error whether or not it results in a significant performance loss. Most of the errors in your log are from mods you're running. Since errors are always signs of malfunctioning, mod authors should not go live with any scripted mod that leaves messages on the log. The truth however is that many people don't really care about. Try to contact the authors of the mods that contribute most significantly to your log spam. They may bark at you or tell you that there's nothing wrong and you won't have to care about (which is, simply speaking, plain nonsense - and if you were still searching for a good reason to uninstall those mods, that should be it).

You're misinterpreting the logs. Taking the following message block as an example, I will try to explain it in more detail: [None].SilverSwordScript.Is3DLoaded() - "<native>" Line ? [ (03016ADB)].WeaponRackActivateScript.PlaceItem() - "WeaponRackActivateSCRIPT.psc" Line 268 [ (03016ADB)].WeaponRackActivateScript.HandlePlayerItem() - "<savegame>" Line ? [ (03016ADB)].WeaponRackActivateScript.RunPlayerActivation() - "WeaponRackActivateSCRIPT.psc" Line 188 [ (03016ADB)].WeaponRackActivateScript.OnActivate() - "WeaponRackActivateSCRIPT.psc" Line 84 In every line, the reference is that of the object that runs the script. Next is the name of the object. Since scripts extend object references, a scripted object and the script running on it are logically the same, so the logs will list the objects by their script name. Thus, "[(03016ADB)].WeaponRackActivateScript" is a weapon rack activator object (it runs WeaponRackActivateScript and its reference is 03016ADB, presumably a Hearthfires rack). What stands next is the command that was logged. The message blocks have to be read from the bottom up to trace the error chronologically: first, the script handled an OnActivate() event (lowest line). From within the event block, it called the RunPlayerActivation() function (second lowest line). From this function, it called the HandlePlayerItem() function (third line; note that this function was restored from the save, which might indicate that the mod which holds the scripts was temporarily disabled, but there also are other explanations). From the HandlePlayerItem() function, it called the PlaceItem() function (second line), and then the error occurred. The actual error is always logged in the top line, and this line is conspicuous, because there is no object listed that runs the script! What happened here is that the engine lost the reference of the object and is now unable to proceed (no surprise is that ...). Simply speaking, there is a loose script instance running that is not attached to anything. There only are two possible reasons for this phenomenon: (1) The engine is temporarily overcharged with scripting tasks. This may happen when a cell is loaded to the brim with scripted objects (especially weapon racks, because the scripts on them will all start running at the same time). (2) An invalid tweak in Skyrim.ini. Read this for example: http://www.creationkit.com/INI_Settings_%28Papyrus%29#iMaxAllocatedMemoryBytes

Log sizes in the order of 100 MB point to an invalid tweak in Skyrim.ini (this also explains the crashes): http://www.creationkit.com/INI_Settings_%28Papyrus%29#iMaxAllocatedMemoryBytes

First, USKP has indeed updated the weapon rack scripts. More on this can be found here (although in parts rather technical, this thread will explain what changes were made and why they had to be made): http://afkmods.iguanadons.net/index.php?/topic/3669-overhauling-the-weapon-rack-scripts/ Second, we did not miss to clear out unused properties. Clearing them out is one of the reasons why those warnings appear at all. Thus, unused properties from previous versions are usually kept when a script is modified. Third, what you refer to as "property errors" are warnings not errors. There's a big difference between warnings and errors, and they are prefixed in the logs with either "warning" or "error" to make a clear distinction: (1) Warnings are notifications sent by the engine.Warnings do not imply that anything isn't working; most of the time, they just inform you about script updates (keep in mind that the log was conceived as a developer's tool, and its main goal was to enable developers to keep track of changes critical to their own work when a group of people was working on the same project). After the official updates, your logs were full of similar messages as a result of various script updates. Those warnings are not lasting though (unlike errors) and will disappear over time when all affected instances have switched to the new scripts. Also, warnings are NEVER logged during gameplay (and therefore, have no impact on performance). When you scroll down in your log, you should find a "VM is thawing" message right after the warnings block. This is where you actually entered the game. (2) Errors do always imply a malfunction and have to be taken very serious. They are exclusively logged while playing and logging alone may have a considerable impact on performance. Fourth, as already suspected by IsharaMeradin, the messages are indicating that you have a mod running which overrides the USKP weapon rack scripts. Possible culprits are mods that claim to fix the ebony blade problem. If you have one of them installed, you should uninstall it, since those mods have stopped working properly after the 1.9 patch (which appears to have introduced a new sort of reference that cannot be properly handled by papyrus). Fifth, scripts are not the cause of whatever is crashing your game. All modifications that are potentially leading to crashes are completely out of reach for scripting applications.

The OnEffectStart event is supposed to fire when the active magic effect starts on the target. Thus, if you cast your spell without a target actor, I would expect that nothing happens. To make the event fire when the casting actor starts casting the spell, you must set up the spell's delivery type as "self" in the CK (technically, the event will still fire then when the effect starts on the target, but the traget is now the casting actor).

First of all, forget the papyrus log when you try to find the reason(s) for a CTD.: A CTD is an issue where the engine hooks up immediately. If this happens, there is no module active that could print anything on any log. Moreover, messages on the papyrus log are printed with some delay. That is, the last lines on the log refer to a time at which your game was still stable.The papyrus log is a script log, not an engine log. Thus, anything that goes wrong at the engine level wouldn't be recorded there anyway.The most common reasons for CTDs are missing master files (this results in a CTD on the loading screen), navmesh problems (usually due to inappropriate edits), deleted references (the so-called UDRs) and bad meshes. All this cannot be touched from within a script (in fact, anything that could potentially lead to a CTD is out of reach to script commands). Scripting is pretty safe and I don't know of any documented case where a script has been unambiguously identified as the culprit for a CTD.

Would be fine if they eventually had an idea on how to put wheels to a good use - other than as parts of dis-functional carts people use to decorate their gardens with.

I highly recommend to install BOSS and Wrye Bash before proceeding to step three.

I have already sent a message to the author. Meanwhile, upon a closer look, it turns out that the modified packages are not used by any NPC in the mod. This was just an assumption because I had an older version of the mod installed some time ago with which I never encountered any problems. This makes the bugfix very, very easy: - Open the construction set and load Oblivion.esm and the Jade Manor.esp. Set the latter as active file. - From the "Characters" menu, select packages. - Locate "aaaServicesEditorLoc8x12LockAtEnd" in the list and select it with a double-click. Tick the "Unlock doors at start" and "Lock doors at end" boxes. Also untick the "Unequip Weapons" box in order to revert all changes to vanilla Oblivion. Leave the window by clicking the "OK" button. - Do exactly the same with "aaaServicesEditorLocLockAt End". - Save. That's it. The only things left to do now are to re-establish the load order and to rebuilt the Bashed Patch (if you're using one). However, there are other changes to vanilla AI packages evident from the esp file, everyone of which might cause a conflict at some point in the game. The simple fix outlined above will not cure all potential problems. Thoroughly cleaning up the esp file is likely the best solution.

After a recent new installation of the game (along with a large number of mods), I noticed a strange bug consisting in most of the shops - both vanilla and mod-added shops - remaining closed at all times and NPC's crowding on the streets in front of them. A search in the forum reveals that this bug was previously reported by several users, but a convincing solution was never presented. When you start a new quest, the bug is particularly annoying because it prevents you from accessing most of the shops in the IC Market District, many of which are essential to the main quest. Meanwhile, I found out on my own that the culprit is "Jade Manor", versions 1.2 - 1.26: This mod removes the door flags (!) from the vanilla AI packages "aaaServicesEditorLoc8x12LockatEnd" and "aaaServicesEditorLocLockatEnd" resulting in all merchants with these packages assigned never unlocking their shops anymore. The modified packages are used on an NPC who'll leave the house to the player after finishing a small quest which was added in version 1.2. Hence, earlier versions probably do not cause this conflict.