The MCM pages have more documentation added including a "How Do I?" notes section.
The new SkyUI 5.0 crafting menu doesn't use the old category system and without the categories having the containers and furniture at the forge menu was just too ugly so now they get their own special crafting station menu.
You can access the new container and furniture crafting menu by by opening the Character Menu (Tab) then pressing Place (NumLock).
I have but one request if I may, would you please add a Smelter, Smith, Tanning, Enchanting, Alchemy station, and cooking stations?? Please, pretty please?
EDIT: Never mind on that, just learned how to place the items at me.
Upon replaying my oldrim save, I noticed a very poor framerate when I visited Solstheim, for some reason. Then I check my mod one by one (including memory optimizer and skse plugin ctd fixes etc), after tweaking the mod and retracing my way, I found that I had been abusing my ini file, in the papyrus section. I reverted it to the default values, and my framerate is much-much better now.
As I finally remember why I'd done that in the past, one of the reasons is because of the DELAY I'm experiencing WHEN ACTIVATING THE WEARABLE CONTAINER by LeftEquip. It's either not responsive or would take too long if it even gets activated at all (so you have to spam it). When I set the values of "fUpdateBudgetMS" and "fExtraTaskletBudgetMS" to 800 in skyrim.ini, then it'd get the responsiveness I'm expecting (that's the last setting in the past). Now, I never find the documentation about these .ini settings, but when I tweak it to a much lower value (50 and 1.6) my modded game with 718 active scripts is running correctly and all the mod functionalities are performing as expected, except for the same wearable container activation delay I just found out.
Because the evidence seems to point at some faulty script I decided to debug and tweak your source code, and the delay is gone! (but you do have to hold the LeftEquip for a few ms until the OnControlUp event catches up) Here's the new code and hope you can check the interaction of the new code with all the other scripts in your framework design.
It's a fantastic mod! and I've been using it with Campfire Placeable to fine-tune its positioning system.
CDC_StorageMonitor.psc: (no state, no utility wait)
;================================================================ ; Portable and Wearable token management - when LeftEquip pressed ;================================================================ ; .....
No, those changes are a bad idea. Your version appears more responsive because you're now measuring from when you release the control instead of when you press it and things are more reliable because you're able to compensate for script lag in your game by holding the button even longer than my built-in delays (which you can still do to some extent even with the original scripts if you think of opening a container as holding LeftEquip until the container opens). But you've broken some other features of the mod (which you may not be using and so may not have noticed).
The expected lag when activating a remote container is about 0.23 seconds at 30 FPS (and can be 0.13s at 60 FPS or even 0.08s at 120 FPS). Anything over 0.25 would be from an overloaded Papyrus scripting engine and universal script lag. Note, that the original game menus are capped at 30 FPS so check out mods that can give you a higher FPS in menus which should improve responsiveness for this this mod.
A very poor framerate in Solstheim with the BudgetMS values at the insane 800 level means you've got way too much script activity going on. And you've basically confirmed a script overload problem with your description of how this mod is behaving. This mod uses every trick I know to reduce the load it puts on the game's script engine but at the price of "responsiveness" and possible unreliability if your game is already overloaded.
So I recommend finding out which of your mods are actually very poorly optimized and causing your massive scripting load rather than trying to tweak this one to compensate.
Since you mention Papyrus settings, and had obviously been following one of the old guides that had horrible information on the topic, here's what I keep on hand based on information from one of the developers of Papyrus.
Skyrim Papyrus INI settings and Script Performance
The best thing you can do for Papyrus script and overall system performance is ensure you get the highest framerate possible on your system. If adding that extra HD texture pack lowers your framerate from 60 to 50 you may want to reconsider.
The original game maximum is 60 FPS (and 30 FPS in menus). But we now know how to achieve higher rates without breaking the game. Increasing menu framerates can be extremely helpful in general and for some types of mods in particular.
Many early INI tweaking guides made assumptions about the Papyrus settings that have been proven wrong. Updated versions of most of those guides have removed their old advice, but the old recommendations are still being passed around by well-intentioned users who haven't noticed the guide updates.
Using the old incorrect settings is at best a placebo and at worst simply sweeping small problems under the rug so they can become a rotting mass that destroys the floor later.
Papyrus performance is directly tied to game framerate. The only Papyrus setting that is likely having a positive effect is the UpdateTime setting.
fPostLoadUpdateTimeMS=2000 The purpose of that setting is to give scripts a chance to get everything initialized correctly when you load a new area. It can help with the wandering mannequins and other problems people see when changing locations. It also gives Papyrus a little extra slice of time to catch up if it has fallen behind. A value of 2000 adds an extra 2 second delay to every load screen. The default for the PC is 500 and you should start with 1000 and then try 1500 before jumping all the way to 2000 if you're going to try making changes.
The two BudgetMS settings might also have a positive effect, but not with values of 800 (which was the typical advice given by early guides).
The defaults for these two are both 1.2 and raising them will lower your FPS if the scripting system is overloaded which will in turn make the scripting system run slower not faster. If you really are experiencing script lag because Papyrus isn't getting enough time, then you could try changing the BudgetMS values to 1.4.
fUpdateBudgetMS=1.4 fExtraTaskletBudgetMS=1.4 If after switching from 1.2 to 1.4 you can't see a difference then raising the values more is not going to help either. If you see a difference but the problem hasn't gone away completely then try values of 1.6 or 1.8. But if you do change these values then you want to use the absolute smallest ones you can because the higher these numbers are the less time you allow for the engine to handle NPC AI, lighting, magic effects, and all of the other non-script things that need to be done.
The three memory settings should never be changed. If you find lines like these in your INI files simply delete them no matter what number appears after the equals sign.
Raising these values above their defaults is more likely to result in stuttering and game crashes than any performance increase. Early guides assumed those values were limiting the game's overall use of memory, but they are really only limiting the scripting system's use of memory. Those limits are vital for good system performance, because without them the Papyrus scripting engine can start claiming memory that is needed for the meshes, textures, and other game content. Game stuttering can result if Papyrus is claiming so much memory that meshes and textures need to be swapped out too often. Game crashes occur if Papyrus is using so much memory that there isn't enough room to load all of the meshes and textures needed to display the current location.
The remaining three Papyrus settings should generally be left at their default values.
bEnableLogging=0 bEnableTrace=0 bLoadDebugInformation=0 Turning on those settings will consume more memory and slow down the game. Papyrus logging is almost never useful in determining why the system is crashing or running slowly. Unless you are writing scripts or actively working with a modder to debug problems with a particular mod (and you know the problems are script related), there is no good reason to change those settings.
As for the specific script changes and why they are a bad idea...
First, the state changes are there to ensure minimal script overhead by default. You've made the script look shorter but actually take more time to run. In the original form the equip and unequip events don't get called in the vast majority of cases due to the way the game optimizes empty event definitions. Your version always results in an event call. Since you're only setting variables it is only one function call, but it's still more than the original and will decrease your overall game performance slightly.
Second, the script handles more than just remote activation of containers and your optimizations break those other features. The WaitMenuMode call of 0.02 seconds on the unequip event is important because unequip and equip events need to be processed in reverse order if an item is replacing a previously equipped item. If you're just trying to activate a remote container this isn't strictly needed, but the other features require it, so it's not really an optional feature. The 0.02 seconds is generally enough time to ensure that the equip has a chance to run first, but on an overloaded system the events could still trigger in the wrong sequence if you have massive script lag. So if I were to make a change it would be to increase that value for overloaded systems not to remove it.
Third, the 0.04 delay on the OnControlUp even is there to give the previous 0.02 delay a chance to happen. It's purpose is so that you don't have to worry about how long you hold the button. And this is all about script lag, but written with the assumption that your script lag is minimal. This won't contribute to your visible lag when opening a container, so on a highly loaded system it could be set even higher. The drawback is that the player might release the LeftEquip control then do a RightEquip action that still gets treated as a LeftEquip during the delay period.
So ironically increasing the wait delays should actually make it work more reliably, but nothing can really fix the apparent lag other than thinking of this as a "hold to activate" rather than "tap to activate" action.
No, there are defaults for things that won't be transferred, but you can't customize that set. The best you can do is chose particular categories of items and then sort your inventory so that the items you don't want to transfer are at the bottom then use the "From Top" P key action.
No, but if you bothered to look at the author's mods for Skyrim SE, you would find the same job done by a couple of them together. Portable Containers Decorator Helper See his other mods for SE for any other functions you might be missing.
Fresh install of Skyrim LE, and the appropriate version of SKSE, but, this mod doesn't show up in the MCM menu. I tried the command listed by another member to 'kick off' the menu, but, I get a 'command not found' message. I installed with vortex, the mod is activated/enabled, it shows up in my data folder, but, still doesn't appear to want to work.
If the mod itself is working, then it's just a standard MCM being quirky problem. Generally things not appearing in the MCM menu resolve themselves eventually.
The MCM system periodically sends out an invitation for mods to register themselves. But only one can be registering at a time and a single mod can hold up the registration system for all of the others. When you start a new game with new mod combinations it can take a while for every mod to get their turn, especially if one of the bigger and more poorly written mods gets to go first.
Actually, it was MY screw up. :D I installed the mods, but, missed a step actually activating them..... Which I thought Vortex was going to do on installation. (not like I make a habit of installing mods I am not going to use......) Nope.
I still pretty new to vortex. So, I am going to try and pass that off as my excuse. :D
I've been using this mod since I found it, years ago, but circumstances beyond my control required a reinstall of both FO4, and Skyrim.... Just another reason for me to hate steam. :D
I built a shelf for books. Works fine, until I put "Explorer's guide to Skyrim" in it. The book disappears, and the shelf can't be interacted with again. Maybe because of the special properties of that book?
As far as I can tell, I have successfully made myself a personal port of this to SE! By that, I mean that I have not yet encountered any problems with it (though I have not yet tested all of the features). I am very happy about this because this is one of my need-to-have mods when I'm playing Skyrim. I know that there's a very minimal version of it made by the original author of this mod for SE, but it is just too minimal for my tastes. If anyone would like to attempt the same thing (keeping in mind that there certainly is the potential for problems) this is what I did:
-Manually download this mod from the files tab -Unpack it -Unpack the .bsa file with BSAopt -Convert any meshes using the SSE Nif Optimizer -Recompress loose files -Load up into the mod manager of your choice(I used NMM) -Start up the creation kit -Load up the storage helpers plugin(set to active file) -Wait for it to load in the CC -Save and exit -Be happy with yourself and this absolutely lovely mod :)
Here is a link for a probably better articulated set of directions: https://www.nexusmods.com/skyrimspecialedition/mods/17990
EDIT: Made minor tweaks to written steps and added a link for a better guide
Unfortunately, the permissions on this mod don't allow for conversions to other games to be put up, so I can't help you there. You'll just have to do some trial and error on your own if you'd really like to use this mod in SSE- and perhaps avoid broken options if they're there (I really only use the convert items to containers function of this mod, so I don't know how well everything else works). If you try again, good luck!
Because SKSE64 was so late coming for SE I recreated most of this mod in stages as separate pieces for SE. In the end I liked how those mods work better than this one and so this hasn't been ported to SE.
There's Decorator Helper for the item positioning feature, Better Container Controls for SkyUI for quick transfer of items into and out of containers, and Portable Containers for the wearable containers feature. While you can't craft usable containers Decorator Helper makes it easy to create copies of existing containers. The only major feature missing is item renaming, but a version of that for anything you can pick up is part of my Enchantment Swapper mod.
No kidding. Saved my sanity with Better Container Controls and Portable Containers. I've been looking for something like BCC for a very long time, and even though I kinda hoped it would be able to move items faster than it does, it helps to get those things done without staggering my brain.
438 comments
The MCM pages have more documentation added including a "How Do I?" notes section.
The new SkyUI 5.0 crafting menu doesn't use the old category system and without the categories having the containers and furniture at the forge menu was just too ugly so now they get their own special crafting station menu.
You can access the new container and furniture crafting menu by by opening the Character Menu (Tab) then pressing Place (NumLock).
EDIT: Never mind on that, just learned how to place the items at me.
As I finally remember why I'd done that in the past, one of the reasons is because of the DELAY I'm experiencing WHEN ACTIVATING THE WEARABLE CONTAINER by LeftEquip. It's either not responsive or would take too long if it even gets activated at all (so you have to spam it). When I set the values of "fUpdateBudgetMS" and "fExtraTaskletBudgetMS" to 800 in skyrim.ini, then it'd get the responsiveness I'm expecting (that's the last setting in the past). Now, I never find the documentation about these .ini settings, but when I tweak it to a much lower value (50 and 1.6) my modded game with 718 active scripts is running correctly and all the mod functionalities are performing as expected, except for the same wearable container activation delay I just found out.
Because the evidence seems to point at some faulty script I decided to debug and tweak your source code, and the delay is gone! (but you do have to hold the LeftEquip for a few ms until the OnControlUp event catches up) Here's the new code and hope you can check the interaction of the new code with all the other scripts in your framework design.
It's a fantastic mod! and I've been using it with Campfire Placeable to fine-tune its positioning system.
CDC_StorageMonitor.psc: (no state, no utility wait)
;================================================================
; Portable and Wearable token management - when LeftEquip pressed
;================================================================
; .....
bool doReequip
Form base_
Event OnMenuOpen(string menuName)
RegisterForControl("LeftEquip")
EndEvent
Event OnMenuClose(string menuName)
UnregisterForControl("LeftEquip")
EndEvent
Event OnControlUp(string control, float holdtime)
if (control == "LeftEquip" && base_ as Armor)
(GetOwningQuest() as CDC_StorageHelper).ActivateRemoteContainer(base_, doReequip)
endif
EndEvent
Event OnObjectEquipped(Form base, ObjectReference ref)
doReequip = false
base_ = base
EndEvent
Event OnObjectUnequipped(Form base, ObjectReference ref)
doReequip = true
base_ = base
EndEvent
The expected lag when activating a remote container is about 0.23 seconds at 30 FPS (and can be 0.13s at 60 FPS or even 0.08s at 120 FPS). Anything over 0.25 would be from an overloaded Papyrus scripting engine and universal script lag. Note, that the original game menus are capped at 30 FPS so check out mods that can give you a higher FPS in menus which should improve responsiveness for this this mod.
A very poor framerate in Solstheim with the BudgetMS values at the insane 800 level means you've got way too much script activity going on. And you've basically confirmed a script overload problem with your description of how this mod is behaving. This mod uses every trick I know to reduce the load it puts on the game's script engine but at the price of "responsiveness" and possible unreliability if your game is already overloaded.
So I recommend finding out which of your mods are actually very poorly optimized and causing your massive scripting load rather than trying to tweak this one to compensate.
Since you mention Papyrus settings, and had obviously been following one of the old guides that had horrible information on the topic, here's what I keep on hand based on information from one of the developers of Papyrus.
As for the specific script changes and why they are a bad idea...
First, the state changes are there to ensure minimal script overhead by default. You've made the script look shorter but actually take more time to run. In the original form the equip and unequip events don't get called in the vast majority of cases due to the way the game optimizes empty event definitions. Your version always results in an event call. Since you're only setting variables it is only one function call, but it's still more than the original and will decrease your overall game performance slightly.
Second, the script handles more than just remote activation of containers and your optimizations break those other features. The WaitMenuMode call of 0.02 seconds on the unequip event is important because unequip and equip events need to be processed in reverse order if an item is replacing a previously equipped item. If you're just trying to activate a remote container this isn't strictly needed, but the other features require it, so it's not really an optional feature. The 0.02 seconds is generally enough time to ensure that the equip has a chance to run first, but on an overloaded system the events could still trigger in the wrong sequence if you have massive script lag. So if I were to make a change it would be to increase that value for overloaded systems not to remove it.
Third, the 0.04 delay on the OnControlUp even is there to give the previous 0.02 delay a chance to happen. It's purpose is so that you don't have to worry about how long you hold the button. And this is all about script lag, but written with the assumption that your script lag is minimal. This won't contribute to your visible lag when opening a container, so on a highly loaded system it could be set even higher. The drawback is that the player might release the LeftEquip control then do a RightEquip action that still gets treated as a LeftEquip during the delay period.
So ironically increasing the wait delays should actually make it work more reliably, but nothing can really fix the apparent lag other than thinking of this as a "hold to activate" rather than "tap to activate" action.
is there a way to prevent certain items from transfering like arrows, food and others like fate cards for LOTD etc.
Portable Containers
Decorator Helper
See his other mods for SE for any other functions you might be missing.
What am I missing here??
The MCM system periodically sends out an invitation for mods to register themselves. But only one can be registering at a time and a single mod can hold up the registration system for all of the others. When you start a new game with new mod combinations it can take a while for every mod to get their turn, especially if one of the bigger and more poorly written mods gets to go first.
I still pretty new to vortex. So, I am going to try and pass that off as my excuse. :D
I've been using this mod since I found it, years ago, but circumstances beyond my control required a reinstall of both FO4, and Skyrim.... Just another reason for me to hate steam. :D
Maybe because of the special properties of that book?
-Manually download this mod from the files tab
-Unpack it
-Unpack the .bsa file with BSAopt
-Convert any meshes using the SSE Nif Optimizer
-Recompress loose files
-Load up into the mod manager of your choice(I used NMM)
-Start up the creation kit
-Load up the storage helpers plugin(set to active file)
-Wait for it to load in the CC
-Save and exit
-Be happy with yourself and this absolutely lovely mod :)
Here is a link for a probably better articulated set of directions: https://www.nexusmods.com/skyrimspecialedition/mods/17990
EDIT: Made minor tweaks to written steps and added a link for a better guide
There's Decorator Helper for the item positioning feature, Better Container Controls for SkyUI for quick transfer of items into and out of containers, and Portable Containers for the wearable containers feature. While you can't craft usable containers Decorator Helper makes it easy to create copies of existing containers. The only major feature missing is item renaming, but a version of that for anything you can pick up is part of my Enchantment Swapper mod.