Ep1cL3w7z

Hi, friends! Long time, no chat. Good to see the continued work on all of this degeneracy! Happened to be lazily slapping together a functional SSE/AE installation together and came across your posts here. I might be able to provide a little bit of insight, though it's probably to matters that are irrelevant by now. GDAName probably stood for GetDetailedActorName, a function I made for logging purposes, which I'll again bring up below. I'm glad somebody else is aware of the internal workings of Papyrus, as it's something that I ultimately ended up delving into far more than I should have. I did not, however, optimize CF as much as possible (biggest one being moving functions around between scripts, as has since been done it seems), because the goal was always a balance of modularity and performance. As an example, a big point for me was to ensure that the behavior/functionality of the CFEffect could always be replicated fully by a user of the framework and could be essentially drop-in replaced if somebody desired, without relying on private APIs. I therefore always (mostly?) adhered to a logical separation of concerns and tried to split things out where it made sense. I've always been stubborn here as well, because the equivalent method using Quest Aliases was never as fast or reliable for me, and cloaks never really failed either. As long as your CPU wasn't a total potato (or Papyrus' performance settings were configured well for your potato status), cloaks were 100% reliable and consistent. Additionally, I honestly still don't fully understand how the quest aliases work - it seems like it's relying on a lot of under-the-hood "magic" that you don't get to see or have control over, and I have no idea what effect it has on the game ultimately. There's also little room for adjustment (vs. how CF provided options to tweak the cloak's performance). Hopefully Bethesda properly addresses this need (dynamically applying effects/running scripts for all new actors encountered) in future games so that we don't have so many mods relying on cloak spells or other weird methods and duplicating effort. Ah, who am I kidding - that will probably never happen. IIRC, the numeric SexLab state (0/1/2/3) came straight from SexLab at the time, and CF was just working off of that input. Just concatenating the actor reference onto the string definitely doesn't (or didn't) provide as much info, but hell if I know what the big difference is at this point, years later.

You would need to go through and disable each creature race/skin combination in the MCM.

Not without manually replacing files with the versions of the creatures you want, no. CF isn't very performance-heavy in the first place.

That's due to MNC doing things improperly (it was originally made long before CF existed). It modifies the vanilla meshes directly rather than supplying a separate "unaroused/normal" state in addition to the aroused state.

Then disable the SLA integration.

I'm fully aware of how script instances work - which is why, as I already explained in my previous post, the cloak cooldown exists. The apply effect is only instantiated and applied at most once per minute with the default settings. You can increase the cloak cooldown to even further restrict it. The log messages are not errors, they're debug messages - and you can turn them off. The reason is I want it to (assuming there is no measurable benefit to excluding it, which I am not at all convinced there is).

I don't want to add an arbitrary restriction preventing the use of human races, as I don't believe there will be any noticeable performance benefit. I can all but guarantee that checking with SexLab beforehand whether or not the NPC is a creature won't improve performance, as it's not really any different from CF checking if its race/skin are registered. Something that you all seem to be overlooking is that CF already doesn't re-check the same actors every time the cloak is applied - the apply effect/spell has a much longer duration than the cloak rate (by default, at least), meaning the effect that does the check doesn't even get reapplied until the previous instance of it has expired. With the default settings, the cloak may be applied every 5 seconds, but a single NPC won't receive the apply effect (and henceforth will not add any Papyrus load) more than once every minute. This makes it even less likely that making the cloak spell itself not target human NPCs will make any noteworthy performance improvement. I feel that you may be experiencing the placebo effect for the reasons stated above. Additionally, unless there is something wrong with your configuration (too high fExtraTaskletBudgetMS, for example), Papyrus should not be able to cause stuttering in the first place.

Creature Framework is designed to work with any NPC intentionally. The misnomer is entirely my fault, as I couldn't think of anything to fit better at the time. Originally, it did have an arbitrary restriction preventing it from working on the non-creature races. When I was working on the framework before I released it publicly and getting feedback from lordescobar666 and dentarr, that was one of the first changes they suggested - removing that entirely arbitrary restriction. I did remove it, and I 100% agree with them. I'm not going to re-add this restriction, because it already bails out very early on NPCs that don't have registered race/skin combinations (that's what those log messages indicate), so you would hardly see any difference anyways.

Creature Framework isn't that script heavy, relatively speaking. I'm guessing you have loads of mods installed, though, and they all add up. SexLab and its related mods are all fairly script heavy, and those are basically standard installs on this site. Tweaking CF's performance settings may help a bit, but there are bigger changes you can make to improve things across the board. Increasing fUpdateBudgetMS and fExtraTaskletBudgetMS slightly can definitely help stabilize things in script-heavy setups, as long as you have a decent computer. If I recall correctly, I had fUpdateBudgetMS set to 1.8 and fExtraTaskletBudgetMS 2.2, or something along those lines. Contrary to what meany people believe, increasing these too much will be highly detrimental to your game's overall performance. Here's the way it works: fUpdateBudgetMS is the amount of time allocated to the Papyrus script engine per frame, in milliseconds. The default value of 1.6ms is around one-tenth of the target maximum frame time (16.6ms, the maximum amount of time to spend on a single frame in order to reach 60fps). If the script engine doesn't get to do everything it needs to do in that time, it then goes ahead and allocates additional time for it for that frame, which is what fExtraTaskletBudgetMS corresponds to. Increasing these too much when you don't have a good enough CPU means you'll likely begin experiencing high amounts of stuttering or framerate drops. There's no silver bullet to fixing Skyrim's performance, but these will definitely help with script lag/instability significantly. Unfortunately, Skyrim's engine is basically a big, unstable pile of dogshit, so there's really only so much it can handle (especially if your computer isn't up to snuff).

I spy with my little eye a stray @CPU modifying my mod description... Is the GitLab instance permanently gone? As it so happens, I do have a full local copy of the repository and its wiki, so nothing is lost forever. Just needs a place to make its home.

Sounds like your FPS is uncapped. Skyrim's game engine is absolutely awful, and many aspects of it (physics, primarily) are tied to framerate. This is why the game caps the framerate at 60 by default, as going beyond it breaks the game in all sorts of fun ways. Turn on vsync or set a framerate cap in its ini file. If you use an ENB, it likely has its own FPS capping functionality that you can use.

I misunderstood. I thought you were talking about skeletons as in the underlying thingy that animations/rigging work with, not an actual fucking skeleton.

CF has nothing to do with skeletons.

No clue what's going on with Odahviing, but I haven't looked at it in-depth. As for the issue that @vpoteryaev (quite the name) brings up, he appears to be correct. It looks like SSL's behaviour changed at some point, as this is what the GetGender function used to be in v1.60's SexLabFramework.psc: ;/** * Gets an actors "SexLab gender" which may differ from their vanilla ActorBase.GetSex() if their gender has been overridden. * * @param Actor ActorRef - The actor to get the SexLab gender for. * @return int - 0 for male, 1 for female, 3 for creature, 4 for female creature if creature genders are enabled and they are female - otherwise female creatures will default to 3 along with males. **/; int function GetGender(Actor ActorRef) return ActorLib.GetGender(ActorRef) endFunction This is what it is now, in v1.62: ;/* GetGender * * SexLab can mark an actor to be male or female without relying on the Sex specified in the Creation Kit for the actor. * * The "SexLab gender" may differ from their vanilla ActorBase.GetSex() if their gender has been overridden, or they are creatures. * * This function gives you the sex of the actor considering all SexLab modifications and also enabling sex for creatures. * * * * @param: ActorRef, the actual actor you what to understand the gender * * @return: an int with these possible values ("Human" is used as "Not a Creature"): * * 0 - Human Male (also the default values if the actor is not existing) * * 1 - Human Female * * 2 - Male Creature (this is the default value for any creature in case Creature Genders are disabled) * * 3 - Female Creature (this value is possible only if Creature Genders are enabled) */; int function GetGender(Actor ActorRef) return ActorLib.GetGender(ActorRef) endFunction So yes, the gender implementation in CF needs to be updated. I'll make sure to take care of this before the final release.

No, the cloak is a core part of how CF works. It simply wouldn't function without a cloak, as each creature race/skin would have to be modified the old-fashioned way - the API would not be possible. Each of the various creature mods would be back to conflicting with each other as before. On an unrelated note, I am interested in getting CF running on Special Edition once SexLab has been ported over.