sfll

On the DDi/DDx crashing: Fixing DDi (probably not needed, hiding) Fixing DDx: EDIT: OK I finally narrowed it down to something mindblowingly ridiculous. Every item has its 3d art loaded into the game in a disabled state by the DDi registration system, meshes were fine, textures were formatted correctly according to nifscan, etc. however... In DDx, "textures\devious\xpduderino\cuffsPadded_silver_em.dds" is 513x512px instead of 512x512px which is not supported and not handled well in SE at all and so it just CTDs. cuffsPadded_silver_em.dds

The DDi/DDx crashing looks to be .esm related running check for errors on the esm: Removing all the entries with errors does allow DDi w/ DDx to load, access mcm, etc. but it is not a proper fix. Looking into a more proper fix.

I posted that but Fore posted directly after saying it was fixed in FNIS 7.1.1 so I would keep it where they are and run consistency check w/ 7.1.1 (post here).

RE: Creature Framework (reposting my PM to someone) "It doesn't always work, just more often with aroused disabled. There is still an issue with the strip feature that seems to be removing the body-switch item. You can see when this happens because the model will "flash" for a couple frames to the nude model then back again, if you target the npc and type showinventory you can see what was unequipped and type "equipitem xxxxxxxx" to switch the skin back. It seems to work better with a creature that has already been used once rather than a fresh one." RE: DDi/DDx Versions before 4.0 work fine for me on conversion, DDi 4.0 with DDx 4.0 always CTD sometime during initialization for me (even before you open MCM). A caveat on DDi though: With FNIS XXL at least, abc1_h2h_locomotionpose.hkx (3.3) abc2_h2h_locomotionpose.hkx (3.3) abc3_h2h_locomotionpose.hkx (3.3, 4.0) abc4_h2h_locomotionpose.hkx (3.3, 4.0) abc5_h2h_locomotionpose.hkx (3.3, 4.0) ...needed to be moved (not just copied) from \DD up to the main actors\character\animations directory or it would fail FNIS consistency check and CTD on load every time.

UPDATE NOTE: The SOS Light bundled with Tempered Skins does not have the "SE" in it, while the one in the main SOS download does - corrected SLCumshotConfig.psc changes to check for both versions. All conversions need mesh (.nif) conversion (see OP) All conversions need .esp resaving (good idea to make a duplicate and use SSEdit "Compare to" with what comes out of the CK as well. All .esm need master flag removed then reapplied post conversion. All animations need conversion with HavokBehaviorPostProcess.exe A quick way to do recursive directory .hkx updating (in-place, keep backup): # PowerShell from directory that needs converting, make sure to copy HavokBehaviorPostProcess.exe or place in PATH $hkxToProcess = Get-ChildItem -Recurse -Path *.hkx ForEach ($hkx in $hkxToProcess) { HavokBehaviorPostProcess.exe --platformamd64 $hkx $hkx } My conversion work so far: ~SexLab Cumshot Needs new NiOverride (skee64 https://github.com/expired6978/SKSE64Plugins) Needs script change for NiOverride check Needs script change for SoS Light SE ~Creature Framework Needs new JContainers (https://github.com/ryobg/JContainers) Needs script change for JContainers check Has issues with (I believe) the SexLab strip routine, somewhat alleviated by turning off interactings with Aroused in MCM ~More Nasty Critters Needs new JContainers (https://github.com/ryobg/JContainers) Seems to work fine, issues caused by Creature Framework ~More Nasty Critters Seems to work fine, issues caused by Creature Framework ~I'll Take The Display Model Needs conversion but seems to work without issue. TODO

MNC works if you disable aroused features in the MCM - it looks like it is a conflict with the strip routine causing the "nude" model to be removed. EDIT: In the Creature Framework MCM

4,278,193,662 is less than uin32 max of 4,294,967,295. Converted to hex it is 0xFF000DFE which translates into the following: Unsigned Byte Byte Byte Byte Byte Byte Byte Byte F F 0 0 0 D F E 1111 1111 0000 0000 0000 1101 1111 1110 uint32 = 4,278,193,662 Signed Byte Byte Byte Byte Byte Byte Byte Byte F F F 2 0 2 0000 0000 1111 1111 1111 0010 0000 0010 int32 = -16,773,634 A signed integer in x86 (and most architectures) use a system called Two's Complement (easier explanation). Essentially if the number is negative (first bit is 1) then you would flip (negate) all the bits, add one, then convert to a decimal keeping the sign. EDIT: IPB mangles my wikipedia link, but there is a (very) long explanation there if you want to read it.

I thought the reason GetFormEx was added by the SKSE team was to handle form id's > 0x8000000. It should in theory work if you hand it the "negative" form id which can be directly obtained using Papyrus. From SKSE source (snippets): ; ... typedef TESForm * (* _LookupFormByID)(UInt32 id); extern const _LookupFormByID LookupFormByID; ; ... const _LookupFormByID LookupFormByID = (_LookupFormByID)0x00451A30; ; ... TESForm* GetFormEx(StaticFunctionTag * base, UInt32 formId) { return LookupFormByID(formId); } It looks like that should be calling the same function but bypassing Papyrus's limitation on signed/unsigned. This works for me, try testing it for your purposes? (I don't know how action script behaves) ; get information Actor akTest = Game.GetCurrentCrosshairRef() as Actor Int akInt = akTest.GetFormID() as Int ; forwards logic MiscUtil.PrintConsole("F: " + akTest + ", " + akInt) ; backwards logic MiscUtil.PrintConsole("B: " + akInt + ", " + Game.GetFormEx(akInt)) The negative integer must be preserved throughout if it travels to the UI etc, and it can only be used with GetFormEx as far as I know. (Technical note): The "UInt32 formId" argument in GetFormEx is essentially "casting" the signed integer given in Papyrus to an unsigned integer, then passing it along to the game's built in function for GetForm. A 32-bit signed integer has its highest order bit reserved for sign so you get [1 bit] + or - and [31 bits] of number. For a signed integer that is -2^31 to 2^31-1 or 2,147,483,648 to 2,147,483,647. An 32-bit unsigned integer is simply 0 to 2^32-1 or 0 to 4,294,967,295. As long as the signage is preserved when transferring the integer representing the form id, there isn't actually any conversion going on between the two numbers as they are both the same bits, just used differently. EDIT: I guess maybe a point of confusion may be why I wrote GetFormID_s in the first place if you don't need it here... basically you need it everywhere else except here (such as GetFormFromFile or GetModName). Though if you did decide to pass around and preserve ids as signed integers you should be able to do this directly: ; new function String function GetFormID_s_int(Int zInt) global String ModID = IntToHex(Math.RightShift(zInt, 24)) String SubID = IntToHex(Math.LogicalAnd(0x00FFFFFF, zInt)) ... or indirectly ; using old function String akString = GetFormID_s(Game.GetFormEx(akInt))

Maybe I am not understanding the issue, but if dispel / actor tracking is actually causing the issue possibly 1. Switch to dispelling by keyword (possibly safer). 2. Quest alias should be able to track involved actors through save-load. 3. If it is only about passing the information back to the UI on load, could that be done with an event? 4. If it is about the dispel / load issues, maybe gate any actions using OnCellLoad which waits until all 3d objects are loaded?

I think for your purposes you will be better served doing as much of the work in Papyrus as possible. SKSE plugins should really only be used when something is either not available (or not functional) or is practically impossible (due to speed - ex physics implementations) in Papyrus. That is just my opinion though. As for calling nioverride.dll functions directly, you would have to load their addresses in your own dll. That seems like a great headache and introduces possible failure points that wouldn't exist otherwise. Expired didn't include source (corrected, see here), and nioverride.dll doesn't export anything but SKSEPlugin_Load and SKSEPlugin_Query. To find the address of the individual functions you would have to resort to one of the following methods: hook/add to the SKSE plugin loading register functions to get loaded function addresses, or disassemble the dll and find the entry points, map manually or pattern search on load. After that you would need to guess the data types based on the nioverride.psc and similar functions in SKSE's NetImmerse. (Side note: if anyone knows a better way to do something like this please let me know.) I may have missed it but is there a reason to use nioverride instead of SKSE's Netimmerse functions? It is highly likely that where their functionality overlaps they are doing the same thing under the hood. EDIT: If you want some example code to look at Quick Loot is built using libSkyrim and could be instructive as it has a UI component. EDIT2: libSkyrim's dump_functions_plugin looks like it can be used to get SKSE plugin function entry points.

Drawing a clear distinction is probably the only way people are likely to make other mods using the framework. Without the ability to point to one thing and say "this is the framework" and point to another and say "and this is how you use it" it seems less likely people will use it to make additional mods. Documentation could solve this, but I am not sure that would be any less work.

You have 2,167 comments on Nexus with ~473 of them being your own with 58,704 unique downloads. Even if every comment is negative that would only be 2.89% negative. As for the framework issue, the reason SexLab is viewed by others as a "framework" when OSA isn't is probably due to the fact that, on its own, SexLab doesn't do anything. If SexLab came with an integrated and comprehensive animation mod built in, it would likely be viewed the same way as OSex. To be honest the best way to get OSA to catch on as a framework is probably to separate OSA and OSex into two different downloads, where people can use OSex as a concrete example of what a plugin for OSA looks like and how to build one. You'd have the following sort of configuration: OSA Framework scripts (everything that would be needed by any OSA mod) Framework UI files (loading, navigation, selection, etc) The OSA.esm A very small demo plugin, maybe with ~1-2 animations and transitions (opt) Reference material (opt). OSex Animation scripts (or other scripts needed by OSex but not OSA) Animation UI files (such as all the menu art for the OSex positions, OSex layout, etc) A seperate OSex.esp That would be the best advice I could give, though I realize it may represent a ton of work to separate out the two projects.

I believe that function is supposed to apply a scaling on a single axis (from the way it is worded). So key 0 = x, key 1 = y, key 2 = z. That would mean that you'd need 3 calls for each usage to scale the node universally.

I do not experience any CTD on load, I'll post my load order, specs, and other relevant information below. If anyone wants me to try changing something to test let me know. If someone has a small mod setup that they know crashes including ENB, SKSE, INI tweaks, etc. and they want me to recreate it for testing I will try to accommodate. Also, has anyone tried SKSE minidump / crash logging?

You could replace it with a check for keywords: if(actra.HasKeywordString("ActorTypeNPC") && !actra.HasKeywordString("ActorTypeCreature") && !actra.HasKeywordString("ActorTypeAnimal") ) That should be mostly as comprehensive.