DuncanWasHere

I'm not convinced that Nexus staff actually believe in the efficacy of this redesign, nor am I hopeful that the overwhelmingly negative reception to it will result in a decent compromise for us. Because obviously it's outrageously bad to the point of being comical, and I'll give the staff the benefit of the doubt that they aren't genuinely all on a different wavelength from the rest of the population, it's just their job to defend the brand image. So based on the time spans surrounding this project, it reeks of corporate mismanagement and sunk-cost fallacy to me. So, I get it, it's being forced through to production because it *has* to be, even though no one is really happy about it, or maybe it actually is more economical for the company despite the visceral reaction it triggers in active users, because somehow all the BF Skinner magic works out. For the record, I feel bad for the staff for having to deal with this mess. I know it's soul-sucking either way.

I almost never post on the forums, but yeah this change is just shockingly terrible enough that I had to say something, and what frustrates me most is that I get the feeling that this is the kind of change that companies just steamroll through, never roll back, and the community just learns to accept that their input means nothing for anything of actual importance. It's especially sad to see because Nexus has been relatively good about respecting their users/creators and not enshittifying the platform, aside from when they came out with collections. I noticed when the forums were changed, and I thought it was terrible, but I didn't really care because I didn't use the forums. When user profiles were changed it was more concerning, but at least there wasn't a lot to screw up there. But jeez this is just awful now. Really bad. I don't know what options they realistically have here, but for whatever it means to them, this change is going to make me use the site less. I think it is obviously going to have that effect on a lot of people. I remember reading that the reason for the changes was because they had to update to a new site API for security reasons. Which is totally fair. But I don't know how that prevents them from fixing at least half of the issue, which is just the terrible, oppressively minimalist CSS.

I've had some luck with creating skeletons and KFs using Blender 3.6 Niftools and NifSkope. I recently managed to rig and skin my singing fish from scratch and got KF animations working. Currently in the process of porting the Oblivion horse skeleton, meshes, and anims to New Vegas and I ran into the dreaded 90 degree issue. But I've heard it has to do with the Oblivion anims themselves... not sure at this point as I've dealt with so much bullshit between each iteration of my skeleton and anims. I'm by no means an expert but I can give a few pointers that I wish I had known to start out with: Whenever you import a skeleton into blender, you should select "Include > Process > Skeleton Only" in the import settings. Otherwise it will import as a bunch of empties. When exporting your skinned meshes from Blender, make sure the skeleton attached to the armature has all of its parenting cleared. Go into edit mode, select all bones, and select "Parent > Clear > Clear Parent" from the viewport header. Also, because of this animations won't work if you attach them directly to the skinned meshes. To get around this in Blender, you can delete the bones from the armature and then import the skeleton NIF with the armature selected (or you can import the skeleton first and then the skinned mesh with "Geometry Only.") Every bone in the skeleton must be prefixed with Bip01. Other than that, I'm pretty sure the names themselves can be whatever you want. The structure doesn't seem to matter either as long as Bip01 and Bip01 NonAccum are at the top of the hierarchy. Bip01 and Bip01 NonAccum should always have their transforms zeroed. In NifSkope you should see their local axes aligned with the global axes and in Blender the bones should lie on the +X axis in octrahedral view. Also, the whole of the skeleton itself should be facing +Y. This is considered forward orientation. Blender likes to export the skeleton with a NiNode as the scene root. This is easy to overlook since you'd expect it for skinned meshes. Make sure it's a BSFadeNode. BSBounds seems to be the main collision box for the creature. The collision spheres and capsules attached to the bones are likely for controlling the creature's collision with statics and whatnot. Not sure how bone LOD works but it seems to not be strictly needed. Blender will export KF anims in clamped mode and without the Accum Root set (in most cases they should be looped and the Accum Root should always be Bip01). If you try to export a skeleton from Blender with the exact name "Skeleton.nif," it seems to always give an error that goes something like: "AttributeError: 'TransformAnimation' object has no attribute 'transform_anim." It should work fine if you name the export anything other than "Skeleton.nif." In SNIFF, there's a tool to optimize KF anims which removes redundant keyframes. Very useful if you're baking anims in Blender and then need to adjust the transforms in NifSkope but don't want to copy the same values 100 times. For most creatures, BSXFlags in the skeleton NIF should always have Havok, Ragdoll, Dynamic, and Articulated checked. Havok enables collisions, Ragdoll (I assume) enables skeleton stuff, Dynamic enables gravity, and Articulated "chains" your collisions together (not 100% sure what that means). The "SkeletonID" extra data block you see in vanilla skeletons doesn't seem to be necessary. The root node of your skeleton and skinned meshes should always be named "Scene Root." The bhkBlendCollisionObjects should all have the flags ACTIVE | SET_LOCAL | USE_VEL and Heir Gain and Vel Gain should both be set to 1. If you export your skeleton with the idle animation baked in, remove the NiControllerManagers from under the Scene Root and any interpolators attached to Bip01 or Bip01 NonAccum. For some reason some of the vanilla skeletons have empty NiTransformControllers attached to them. Bone priority in the KF's controlled blocks seems to be on an anim-by-anim basis. I just copy them from the corresponding vanilla KFs. No idea how collision groups or ragdolls work. Also, the New Vegas GECK's ragdoll editor is broken so if you want to create custom body part data and stuff I think you have to either use xEdit or the Fallout 3 GECK. I haven't been able to get locomotion anims working in the GECK yet. I can see Bip01 being translated in Blender and NifSkope but they just run in place in the GECK, and the creature won't play the anims at all in-game presumably because of that. In the GECK console, I get a warning like "AnimGroup 'Forward' for 'Scene Root' was exported with 'Animate in Place' from MAX." I would think that such a flag, whatever it might be, would be reflected somewhere in NifSkope, but I haven't found a solution yet. After testing working vanilla anims on the custom skeleton, it's an issue with the skeleton itself rather than the KFs. To anyone who is more experienced with this stuff, please correct me if anything I said is wrong or missing info. Trying to fix orientation issues between Blender, Nifskope, and the GECK is a total pain in the ass and currently the source of all my woes. Just remember that Bip01 and Bip01 NonAccum should NEVER be rotated in the skeleton or the .KF animations. But if this problem does happen to you for one reason or another (in my case I think it was because the Oblivion skeletons used a Bip01 bone orientation of +Z for some reason) then there are some more quirks you have to keep in mind: In some cases, Blender, Nifskope, and the GECK will all show different orientations of the animation. Always check all three. The GECK orientation will always be the one seen in game. In Blender, if your skeleton's rest pose (easily visible in edit mode) is rotated 90 or 180 degrees from the animation's pose, then you have a big problem. I haven't found a good fix for this yet, but ideally you need to have the pose and rest pose in the same orientation, pointing forward along the +Y axis and with the Bip01 and Bip01 NonAccum bones having zero rotation. Rotating the scene root won't work because it rotates the rest pose with it. Rotating the rest pose won't work because it rotates the animated pose with it. Rotating one of the parent bones (under NonAccum) could work, but that needs to be baked into the animation. In my case, the bone I needed to rotate (Bip01 Spine0) was already keyframed, so simply propagating the transform wasn't an option without compromising the whole animation. If I could somehow apply that offset as an additive blend to every key in the animation (in the same way you'd use blend modes when drawing) then I think my problem would be solved, but I don't know how to do this. If there is a way, then apparently I cannot phrase the question properly to get the answer I need. Adding a new pivot adjustment bone underneath Bip01 NonAccum and parenting everything else to it seemed like the best solution to me, but it resulted in a weird offset for the rest of the pose that I had to fix manually for each animation, which became messier and messier until the anims started deforming. Perhaps there was something I was overlooking, because logically it seems like it should work if the bone has the same orientation as the original Bip01 NonAccum... I will continue experimenting and report back if I achieve a breakthrough. If anyone else has a suggestion for a workaround, I would love to hear it.