Expired6978

I'm not sure whether your concern is with loading, or evaluating these lists as they are two different things. Leveled Lists are essentially trees. What happens when loot is evaluated (usually when the actor is spawned) is it has to traverse that tree and evaluate percentages for each item in the list. If you have leveled lists containing more leveled lists, or happen to add a large tree to the bottom of an existing tree, you've just made that tree much larger. This becomes very problematic if you have a leveled list that links to a previous leveled list in the chain, i.e. a cyclic reference. If the game has no cyclic reference protection it would just lock the game up indefinitely, but since leveled lists are percentage based you may just happen to encounter a probability evaluation that decides not to enter the cyclic reference and ends the cycle. By moving your changes from the script (or essentially the save game) to plugin you're trading load time for startup time. Loading from plugin is adding to these lists at startup, before you load a save game. If you had script-added lists, loading a save has to revert all previously added entries, then re-add all the ones from the new save. Loading leveled lists from a save is barely more expensive than loading from a plugin so this shouldn't really be an issue. The main difference to note here is the fact that loading another save has to unload and reload contents to the leveled lists, you pay this expense every time you load another save, rather than once at startup. This has absolutely nothing to do with Papyrus after you've called AddForm on the LeveledList. Once it's in the list the next time the game is saved, it's now baked into the save.

I always use GetFormFromFile to get your Quest and then CastAs to fetch your Main script without making Four-Play a masterfile, but that's just me and my attitude of avoiding hard dependencies if possible lol. Which is the correct way. Directly depending on scripts breaks when that script doesn't exist in the first place. They added all this functionality for indirectly accessing scripts for a reason.

ECE does not rely on only SKSE, it relies on some custom code in it's own plugin to apply secondary custom morphs. This isn't just change a few types to 64-bit and it's good to go, it needs to be re-written. Sure RaceMenu needs more than just SKSE and it's going to take time to fix quite a lot of the stuff that has internally changed, some features may even need to be dropped with how much has actually changed regarding meshes and textures. Most of this is going to be happening concurrently since I'm probably going to be focusing on the areas of SKSE that my plugins require i.e. Scaleform injection and communications, translations, NetImmerse manipulation etc.

I don't mean that in a general sense, I mean that particularly for Skyrim's Engine, there's a lot of caveats with some of the native functions you just have to know by reversing it as well as observing behavior, my code is commented, but not enough to explain entire native functions and how they deal with reference counting or certain moments where data is cached. By not compiling it I mean theres various files that are part of SKSE that are more up-to-date than what is currently released. You could compile it with what is available, but more than likely you're going to build an unstable version of my plugin. I would need to also upload the SKSE files alongside the plugin with the appropriate directory layout, not really a big deal I most likely will do this when I release it so that it is more or less compile-able straight from a fresh git clone.

It's closed source because nobody would ever be able to build it, nor understand half of what's going on. I'm releasing the source when FO4 is released. I'm occasionally getting crash on load from StorageUtil so I'm not sure if that's interfering with my test scenarios, but I believe I should have fixed the crash on cell load with a decapitated body in it: I've included the PDB which you can use to resolve the symbols if you load it through windbg. https://drive.google.com/file/d/0BxcCUXFKD04_NUhwOXV6RkxuODQ/view?usp=sharing

Yes you can return arrays. VMResultArray<BSFixedString> foo(StaticFunctionTag*){ VMResultArray<BSFixedString> list; list.resize(2, 0); list[0] = BSFixedString("hello"); list[1] = BSFixedString("world"); return list; } OMG thank you! So the wiki is outdated "Although it isn't possible to return an array from an SKSE function that's exported to Papyrus" It wasn't possible at the time, it's possible now after I decoded what the game does with the "new x[y]" instruction. There were some odd special cases I had to account for, I tried to maintain the templating schema, it isn't perfect. The VMResultArray is essentially just an STL vector wrapper, when the implementation of your function is run, the virtual function of the NativeFunction will call your implementation, return a list, then create a VM array and copy your contents over (Packing) The problem with this implementation is your array is probably going to be copied 3 times. Once to populate it, once to copy it to the parent function from the return value, then again to move the contents into the actual VM type. Though I think the benefit of convenience and maintaining the template specs outweighs the lost instructions from multiple copies, nobody should really be creating arrays large enough for it to be a serious issue.

That's because multiplicative is the only way that makes sense. You cant invert an average. It's a one-way computation. I can add a toggle to do averaging for scales if you really want, but it'll be hacky. NetImmerse normally packs all the transforms into an NiTransform object, it includes scale, position, and rotation. All of the operations you do on this object have overloads for the operators, so I basically store all the modifications to the key as an NiTransform, then when it computes the result it just multiplies them all together. transform = t1 * t2 * t3 * ... I would need to special case this to assume 1.0 for scale, then manually compute the average. If you want an average you could actually manage that yourself if you wanted. NiOverride gives you access to all keys to a node, so you can get all the keys, make an average, then delete all the keys and make your merged average. This assumes the other mod isn't constantly setting the key value.

See the tab at the top right that says Camera? http://www.nexusmods.com/skyrim/mods/29624/? You can rotate the entire character there, as well as move the camera up and down, only thing you cannot change is the camera pitch, which is frankly not very useful anyhow.

Nice, works for quite a lot of morphs you didn't explicitly test, only one I noticed that clips terribly is pregnancy, but I would expect that for pretty much any outfit.

Regarding the floating wrists bug for BodyMorph this has been fixed for the next NiOverride version. The native function I used to clone the NiSkinInstance wasn't copying everything, it lost data when it made a new skin instance, particularly the pointers to the world transforms on a per-bone basis.

3.2.0+ also has BodyGen, but this feature isn't accessible until SKSE 1.7.3. It can guide body shape based on parameters: morphs.ini Skyrim.esm|F62F0=Sevenbase,Random,Waist,Breasts templates.ini Sevenbase=7B High@1.0 | 7B Bombshell High@1.0 | 7B Natural High@1.0 | 7B Cleavage High@1.0 | 7B Bcup High@1.0 Breasts=BreastSH@1.0 | BreastSSH@2.0, Breast@1.0, BreastCleavage@0.1:1.0, BreastGravity@0.1:1.0 Waist=Waist@-1.0:1.0 | ChubbyWaist@-1.0:1.0 | WideWaistLine@-1.0:1.0 Random=Breasts@-1.0, BreastsSmall@-1.0, BreastsSH@0:1.0, BreastSSH@0:1.0, BreastsFantasy@1.0, BigTorso@-1.0, Waist@-1.0:1.0, ChubbyWaist@-1.0:1.0, RoundAss@-1.0:1.0, SlimThighs@-1.0:1.0, Thighs@1.0, PregnancyBelly@0:1.0, NippleDistance@-1.0:0.0, Arms@-1.0:0.0, NippleSize@-1.0:0.0, ButtCrack@-1.0:0.0, Butt@-1.0:0.0, ButtShape2@-1.0:0.0, Legs@-1.0:0.0 The syntax allows for controlled randomization, or static shape. The morphs file outlines the templates to use on a per instance basis (Meaning the parameters get evaluated for each new instance of the Actor) The template file outlines an evaluation procedure defined by the syntax. bar represents OR operations (Where it will randomly pick one from the set) comma represents AND operations @ represents the separator between Morph name and value range colon represents the range of evaluation When no range is specified(a number with no colon) it will choose the specified value, this allows for static shapes, useful for altering a particular NPC. These guided files are per-mod, so you can have your own outline files for your own mod, or override other mods based on load order. I will probably make a TES5Edit script to apply to various vanilla NPCs and maybe come up with a decent template to start. I was hoping that this project would be further along and more people would be creating compatible outfits, I would like to see what people can come up with.

While this is a good suggestion, you're still going to need 8 million packages. These override values wouldn't be per instance, they would be per-base form, unless you hooked the package Evaluation code and overwrote there. Though more packages is certainly easier than more Aliases with also more packages. The If/Else is a terrible idea to begin with, I've solved these major issues by having all the ReferenceAliases in an indexed array and store the index in an unused Actor Value. Looking up the follower is very fast, only insertion is slow. Even in worst case traversal of the whole list there's a tracked Maximum value so that you never need to traverse all 100, only up to the last index, which is still bad, since it's not re-sorted, you can get the case where you recruit 10 followers, and dismiss the first 9, it will still need to traverse to 10. I wouldn't really recommend altering these parameters, but then again I didn't really recommend overriding packages either since you ignore the original package stack concept. I never decoded these values though so I would either need to do this, or someone else would: If I had to guess, the structure would be in that linked list, and the linked list would be structures of variant types.

Yup, if you open up the jslot files you will see all the Sculpt data: "sculpt" : [ { "data" : [ [ 64, -696, -255, -2260 ], [ 0, 1183, -248, -2112 ], [ 8, 825, -998, -2531 ], [ 1, 705, -347, -2351 ], [ 2, 1218, -998, -2531 ], [ 3, -1175, -998, -2531 ], [ 4, -825, -998, -2531 ], ....... ... I wrote some stuff explaining the Sculpt data here and the preset itself but the forum decided to just delete all my text after the code block. Anyway, I'll summarize what I wrote: Sculpt data is all floats multiplied by the "divisor" (so dividing by the divisor gives you back the float offset) Shouldn't need the nif, but it's nice to have Presets should normally be enough to fully describe everything you did in RaceMenu Mods shown in the preset are only relevant to the Head Parts you used (i.e. doesn't include textures)

FYI all of these functions: Are going to cause major fragmentation issues, the arrays are really not meant to be manipulated this way. They are only meant to be used as "I need a big list of objects and I shouldn't have to iterate 0-N to get them all" The fundamental type isn't meant to be dynamically sized at all, it has no additional data to prevent frequent reallocation. I would recommend avoiding doing this and instead opting for a growth on request method (allocating more than you need, then filling the empty entries). The fragmentation here is going to be unreal. The method of creating an array already allocates at least twice per array due to the vector wrapper (more since you are likely pushing into the vector, which will have to reallocate to grow itself eventually). Now it's going to reallocate it twice per call and if you replace the previous array it also has to destroy that. Also not a good idea to flag any of these functions as NoWait (I haven't looked to see if this was done). Flagging a function as NoWait implies that the operation you are about to do is threadsafe and will not be queued to the callstack (this is why NoWait functions are faster, they are not queued and are ran immediately instead). There is also a bug with the VMResultArray wrapper in the current release, the bug is relevant to any VMResultArrays that Pack objects rather than primitives. Elements that are initialized as NULL will be broken at runtime and can't be assigned The fix is already in the next SKSE version, but you will need to rebuild your plugins, since this is a template wrapper and the code is actually compiled into your plugin. PapyrusArgs.h There are some new functions in the next SKSE version that might be of use. These functions involve batch operations on Arrays of References that can move and/or rotate all the objects in a single frame (Custom Latent functions)

http://pastebin.com/ki33eqw6 http://pastebin.com/iULYiGUp Replacing the PapyrusArgs in your SKSE plugin project will let you make use of the VM's CreateArray function, you don't need SKSE 1.7.2 to make new native functions that return arrays since the CreateArray function itself is part of the VM and the PapyrusArgs functions just safely wrap it, which would get compiled with your plugin. Arrays returned from native functions are not bound by the 128 limit. Here's some sample usage for returning arrays http://pastebin.com/WqvRdXEK VMResultArray is essentially an STL vector that acts as a proxy to transfer data into the VM result of the native function.