nosis

vanishing has not been a problem since like 105 or older - so there won't really be a "when this mod is fixed" - any vanishing problems after then were caused by the glitch where non-fighting animals like deer would scale down to 0, thusly being impossible to see - which was fixed in the last release. you have the right idea - but dont use the FFxxxxxx version. use the actual base version, which for sabrecat is something like 00023aba or something along those lines. those ff ones are temporary ones that the game WILL reassign at some point in the future when it feels like it. Well, I mention it because it happened to me twice before I realized that it was because I was adding temporary NPCs to my pack. I have the latest version of untamed. I would have my pack wait... I'd go into a building or something, come out, and the temporary would be completely missing. Then I realized what was happening because I was working on a mod were you could essentially build an army in a similar manner and the same thing was happening in that mod. EDIT: One was a horse and the other a sabre cat... so it has nothing to do with deer or anything like that. Also, to reiterate, I was saying not to use FFxxxxxx NPCs because they're the ones that are bugged. I'm not quite sure what you're saying in your response.To be clear, I'm not adding NPCs via the console, I'm just identifying buggy ones.

I'm not sure if anyone mentioned this yet, but I've seen a couple of "My pack member vanished" posts. Here's the deal. Temporary random spawn NPCs (for example, the Sabre cat you might find the companions randomly fighting out in the world, or the random horse that you can just ride temporarily) are designed to auto-disable/delete themselves at the engine level essentially once they're out of view. These NPCs always have a ObjectReference ID in the form of FFxxxxxx (always starts with FF). The solution (until the mod is fixed) is to simply never add them to your pack. When in doubt you can open the console and check their ID. It appears however that getting impregnated by a temporary NPC, and then giving birth results in a pack member that is not a temporary NPC, so that's safe (in other words, have sex with the temporary, then dismiss them and later give birth).

Unless I find a major bug, or someone comes forward with a feature request, 0.3.0 will be the last release for a while. With the exception of automatic dead-lock detetion it does everything I personally want. I'm going back to working on fun mods (which will give me a chance to better real world test this anyhow). In a few weeks I'll come back to this. In the mean time, please keep me updated if you use it, find issues, have requests, etc. Thanks.

Cool. Getting skyrim back up to modding standards again and defiantly wanted to take a look at this. Great. Please let me know immediately if you find issues, have requests, insight, whatever. The time table on this is fast because I'd like it frozen permenantly as fast as possible. This is not a long-term maintenance-feature growing utility, simply a "git-er-done" but stable and optimized utility. Working on now: A couple minor bug fixes are done. I forgot ActiveMagicEffect wasn't a form so I've added ownership for that. Debug tools up the wazoo (thread dumping report with tons of details and dead-lock detection with easy console access to these things).

Opps... documentation issue in 0.2.1. The quick-start example was passing lockID to UpgradeLock(). It's fixed here, but I'm not going to upload a new zip just to change the readme. Ignore it in the zip please.

To anyone who cares, I now consider this an early beta rather than an early alpha. I encourage everyone to use it in projects that they aren't planning to release within the next few weeks (I expect to be able to claim it's "stable" at that point and freeze development sans-bug fixes). At this point I still haven't found a major bug, the core API is mostly locked down (likely just additional functionality will be added moving forward), and I've 100% confirmed that it: Doesn't dead-lock itself Prevents race conditions Fully supports truly concurrent readers Enjoy and don't forget to report back to me .

Okay jbezorg... how about this? What if with each AllocLock call the mod is required the provide the owning form. NosLocks tracks the form that allocated it. Then, on initialization or periodically it purges all locks where that reference has suddenly become None? A little hacky but that could work.

To answer your question literrally (you said "lockid"), no. At that point the lock id (not the locker itself) is in fully reentrant space and is truely a temporary variable only held in the Papyrus VM (but still saved in the save file during it's lifetime). I think you might be actually asking(totally correct me if I'm wrong) if an associated locker (NosLock as returned by AllocLock()) would be saved by a mod, and then, god-forbid that mod disappears, the lock is automatically unlocked and deallocated? Sadly, no... not possible right now. I'm not sure how to make that happen. Papyrus is pretty much the most simplistic language in the world, so there's no destructor calls or anything on dereferencing. As it stands right now, YOU MUST manually unlock/deallocate the locker(s) that you have. If anyone has any ideas on how to get around that I'm well beyond all ears. EDIT: This is no longer the case. Every two minutes a garbage collection process runs cleaning up orphaned locks (only in they were created "owned" by something in your mod).

View File Nosis' Locks: Arbitrary Read/Write Locks "Protects your code against CTDs better than Trojan protects against STDs" v0.3.0 Description NosLocks gives you an generic read/write locking mechanism to use as you see fit. It abstracts out the GotoState() paradigm of Papyrus effectively allowing a single script to have multiple states at the same time (via semaphore barriers). This library provides classic read/write locking capabilities: many readers and zero writers, or one writer and zero readers. WARNING Semaphore barriers are dangerous if you aren't careful with them. Only you can prevent dead-locks by avoiding modding while intoxicated! BETA Notice (No Longer a Warning) v0.3.0 is a mid-beta release. It's barely been tested under real world conditions but has been heavily self-tested at this point. The API will likely change a bit as well. I'm putting it out there mostly so that other modders can try it out and give feedback/make requests before I move it to a more late beta/stable state and lock the API. It's core has been proven enough at this point that I encourage you to start using it for any projects that you don't plan on releasing in the next few weeks (I expect to declare it late beta/stable by then). My plan is simple. Once it's stable the API gets locked and, other than an unexpected bug fix or two, freeze development of it entirely. So now's the time to make requests, suggestions, etc. Why Would I Need This? If you're a modder then it will help you elegantly protect your code from race conditions, particularly with complex multi-state code that "yields the floor" at inopportune moments. If you're not a modder it might be because another mod is using this (doubtful right now). You can stop reading here unless your curiosity is just boiling over. Dependencies v0.3.0: Maybe SKSE? If you want great debug information then it's a must have. Otherwise I believe nothing should be broken if you don't have it. If someone could test WITHOUT SKSE (try running the debug dump and see what's in your logs) and get back to me, I'd greatly appriciate it. v0.2.x: None. Zip. Zilch. Not even Skyrim.esm. Nothing. Upgrading From 0.2.x If you had any allocated locks in your save file then a clean save is required due to a bug that's now been fixed. Upgrading From 0.1 Clean save. Start over. Your code will be broken anyhow due to API changes. What's New (from 0.2.x to 0.3.0) Bug fixes (two major), support for ActiveMagicEffect as owner, and a bunch of debugging methods/capabilities. In detail, the following was done... What's New (from 0.1 to 0.2.x) A lot. Heavy API refactoring. No bug fixes because I didn't find any . Two major API usage changes: Locks are now "owned" so that they may be garbage collected when deadbeef. You no longer have to manually get the manager. Everything you need is scoped globally. In detail the following has changed... Reference Guide NosLocks: NosLock: Console Commands: Quick-Start Example The below demonstrates NosLocks in a nutshell... NosLock MyLockEvent OnInit() MyLock = NosLocks.AllocLockForForm(Self)EndEventInt Function GetSomething(Actor whatever, Int lockID=0) MyLock.ReadLock(lockID) Int res = gottenFromSomeProtectedData MyLock.Unlock() Return resEndFunctionFunction SetSomething(Actor whatever, Int lockID=0) MyLock.ReadLock(lockID) If (!GetSomething(whatever, lockID)) lockID = MyLock.UpgradeLock() If (!GetSomething(whatever, lockID)) ; check again manipulateSomeProtectedData EndIf EndIf MyLock.Unlock()EndFunction . In-Depth Example Owned vs. Unowned Locks In 0.1 all locks were unowned. Starting with 0.2 it's now strongly preferred that you allocate owned locks. If the script using the lock is a Form use AllocLockForForm(). If it's an Alias use AllocLockForAlias(). If it's an ActiveMagicEffect use AllocLockForAME(). Explict lock freeing is still preferred of course, but now the locks can be garbage collected when someone uninstalls your mod. A Note About Lock Upgrades If you are unfamiliar with read/write locks (but understand the concept of mutexing), keep something in mind: you can not make assumptions about the state of your data after the upgrade. The upgrade is not an atomic operation. During the upgrade another writer might have come along and changed your protected data. Basically... Write Lock IDs Two things... First, 0 is the only invalid write lock ID, so don't expect 0. Second, they should be passed around in a fully reentrant manner. Don't globalize them (it's tempting... I know) or you might find yourself scratching your head about why you're dead-locking when it looks like you shouldn't be. Lock Leaking Release those locks back to the manager if they have a limited life time! Be kind. There's 128 of them but that runs out quickly if they aren't released but new ones keep getting acquired. Examples: If you're using a lock in a magic effect, NosLocks.FreeLock(MyLock) on the effect finish event! If you have a lock for a quest that only is used when the quest is running, release it when the quest stops! If you have "permanent" locks and start an "uninstall" procedure, give them back or they will walk in limbo for eternity! If you don't remember to release then owned locks will be garbage collected periodically (not optimum of course), but unowned locks will be lost forever! Leaking unowned locks may eventually result in the player's save game being 100% deadbeef. Pre-emptive FAQ Please read before asking questions/asserting positions as they might already be addressed. Please try it out (not on a stable branch of your project) and let me know what you think. Particularly if there's issues or feature/API request changes. ~ nosis Submitter nosis Submitted 08/19/2014 Category Modders Resources Requires Special Edition Compatible

That's too bad (I avoided touching slot 52) but pretty understandable (it's a custom mod that heavily works on the unused upper slots). Does SOS still work when naked in general? Regardless, I don't think this is patchable. The problem is simple: SOS is a complex beast, armor mods that rely on it rely on it being what it is, and my mod is just a super-duper-unimaginably-simple creature of a thing. EDIT: Actually--I presume--if the nifs could be properly modded then it's probably patchable, but that's waaaay out of my league at this stage in modding.

Slavetats has a really high chance of conflicting due to it's undouted usage of the unassigned slots. If you're still missing your body when DD-HC-ArmorBlock is 100% uninstalled/disabled, then it's not the source of the conflict. Armor details (including the models, slots, and textures) aren't saved with your save game (with the exception of any attached scripts, which my mod doesn't have), so it sounds like another armor mod has borked up your install. By backing up to vanilla I presume you mean 100% mod free (including loose files in Data) correct? If so, I have absolutely no idea how that's possible. Try a clean save (maybe there's a script attached to the armor borking this up in your save??? My mod doesn't do that, but maybe another mod did?). The symptoms make it sound like you have a broken/missing model for that armor.

Okay, I just did a bunch of tests on a "fresh" (as in a base skyrim install with only the dependancies added) and I couldn't reproduce the issue for the life of me. I tried emulating your experience by starting out with both Nightingale Armor and an Ebony Harness equiped, then installed the mod, and nothing (although I had to unequip the armor for the desired blocking effects to be seen). I tried all three variations of the nightingale armor, and nothing. I tried both the iron chastity belt and padded belt, and nothing. Questions... - Do you have a DLC installed and, if so, which? - If you move the remodeled armor mod to be after or before this one, does it make a difference? - What happens when you disable remodeled armor? - Anything else you might have noticed that might help clue me in on what the issue could be? Thanks.

Well that would be a bug. Thanks for the report . I'll check it out and get back to you.

I like "Armor Restrictions" as a starting point . Realistic implies different things for different people (as does "Immersive"). That's actually something I'm struggling with in terms of what should block what. Simple example: Dresses/robes cause clipping when I run wearing leg cuffs, so it severly breaks immersion for me, but the idea that I couldn't be wearing leg cuffs with a robe severly boggles my realism mind (a conflict I haven't decided on how to resolve... see the TODOs). Maybe, "Integrated Armor Restrictions"? idk. I definitely like the "Armor Restrictions" aspect.