ehtyeci

Not sure what you're trying to refute here. Perhaps reading would have helped.

Not entirely sure what you mean by "just" moving bones to new positions. The only type of animation that allows relative transforms is additive animations. The standard ones, however, use absolute transforms which are done locally in the parent coordsys. All this logic is defined in the skeleton.hkx and possibly behavior files set in the subgraph, and is set up to allow retargeting and blending if the animation requires it. Retargeting works by assigning a collection of bones and allow them to be proxy animated through a secondary hkx animation. This is how actors are able to run and reload at the same time, even as reloading and running are essentially two separate animations. But this is all unchartered to me, and would require knowledge with behavior files. The CK apparently does allow for XML-formatted hkt behavior files, so I wouldn't be surprised if someone were to be able to frankenstein new logic that allowed this. The nif version of skeleton is from what I understand only used for skinning and attachment logic and is a one-way interface to latch onto animations. Havok doesn't see the nif - only the hkx, which does share a lot of similarities to the nif. You will need to have both - a nif and an hkx version. You can create an hkx skeleton using only three filters: "Align Scene to Node", "Create Skeleton" and "Write to Platform". Out of curiosity, why are you trying to animate the human skeleton inside the power armor? It seems a bit redundant. Is it because you want to show the body inside the power armor? Or because you want actual human body animations on top of the power armor animations?

For custom skeletons to work you'll need a custom skeleton.hkx that holds a list of bone names as well as custom animations exported with said bone names as transform tracks. Vanilla animations only contain transform tracks for vanilla bones, which, as you rightfully deduced won't touch custom bones. To create a custom skeleton.hkx, you can read a guide of creating a skeleton here. It covers the process of generating a havok skeleton using HCT for vanilla races, but the procedure is similar for custom skeletons, except that you won't be extracting a bone definitions list from the existing skeleton.hkx, but instead creating one from scratch. The bone definitions list is just a text file containing one bone name per line starting with Root at the top. Since you are creating a completely new skeleton, the order of bones on the custom skeleton.hkx won't matter, but every animation you export must be exported with the same sequence as the custom skeleton was generated. You'll need to accidentally get your hands on havok content tools 2014.1.1 64 - it was once a free download through project anarchy, but has since ceased after the MS buyout, so it's against nexus TOS to post links. This would be a massive undertaking, since you'd probably only be able to convert 80% of all PA anims - the rest, mostly additive anims won't parse correctly with the unpackers so you'd have to create them from the ground up.

I don't remember what the workshop spotlight sounded like - is it identical to the machine gun turrets? Anyway, after locating the LPM descriptors for both machine gun and enemy camp spotlight turrets, their LPM descriptors didn't appear to be referenced, like at all, throughout the CK. Usually they'd be mapped through a KSSM then referenced using a keyword such as the s_40_TurretLowTech, but even the KSSMs only contain descriptors for weapon fire. The workshop spotlight belongs to the TurretWorkshopRace, which uses a general behavior graph in "Actors\Turret\TurretWorkshop.hkx". Unpacking this graph using hkxpack yields a reference to another graph in "Characters\Workshop\TurretWorkshopCharacter.hkx" which again references "Actors\Turret\Behaviors\TurretWorkshopRootBehavior.hkx", and here's the kicker: The TurretWorkshopRootBehavior file has an "eventToSend" payload with the string "NPCRobotTurretLowTechMotorLPM" - the idle motor sound used by machine gun turrets. Not sure how much help this is, but as far as I can see the idle sounds appear to be hardcoded in the behavior files. Another thing, is that most if not all non-workshop spotlights are simply activators and aren't even considered actors. I'm basing this off the SpotLightDetect01, which has a SearchMotorLPM that references OBJSpotlightMotorSearchLPM - the only reference I could find using the loop from spotlights at enemy camps.

The glow is generated using "Textures\Effects\Gradients\BloodGlow02Grad.dds" fed into the mesh "GlowCracks001:1" as greyscale texture. When set as greyscale, the color comes from "Emissive Color" in the shader node. Note that not all meshes use a material file - some meshes, like the "GlowCracks001:1" uses a texture directly in the BSLightingShaderProperty node, and does not reference to an external material file. You will know a material file is used when the shader node explicitly shows a material path in its name. Material files do not contain textures themselves, but point to other texture files. You can view a material file using Material Editor by ousnius. https://www.nexusmods.com/fallout4/mods/3635/ You can use Gimp, Photoshop, Paint.NET (with bc7 support), Compressonator, DirectXTex, NvTT, among others to convert to and from dds.

Using "Update Bounds" in nifskope should recalculate the sphere based on a generated bounding box instead of a mesh's origin. When you introduce a mesh into nifskope, you should always load it from the origin point, with the center of the mesh starting at the nifskope origin, then use transform to procedurally move it to its intended position. The reason for this is that meshes are half-precision unless flagged as full (you shouldn't really use full precision) and geometry gets distorted the further away from center it is loaded into nifskope. If it starts at origin (with no distortions), then procedurally moved to its intended space, it keeps its shape.

All right, it's out. Took me a while to nail some hierarchical issues, and because of how convoluted it is switching out constraints I had to learn maxscript to facilitate my troubleshooting.

It might be a lot easier if you made a recipe to create caps as ammo, using caps as the components. This way, the ammo would have the entire ammo framework of the game. You won't need to use RegisterForRemoteEvent and subtract a cap for every "weaponFire" annotation that gets triggered.

I just finished setting up the cat rig templates for power armor and exported animations are working in-game. There's a few things I want to iron out in terms of ease of access on the template, but the rig itself is complete and ready to use. Send me a PM for the templates if you don't want to wait for the nexus release ;)

Nobody has still figured out how to parse certain hkx files in order to create 32 bit versions and fbx so we can open in max, skeletons being one of them. You can, however make your own rig. The process involves converting to tagfile xml, fetching the sequence of bone names and feeding this into a max scene with a skeleton.nif and havok content tools. You'll also have to create dummy bones to fill in the blanks left by the nif, but the end result is a working skeleton, although not rigged by means of conventional biped/CAT. I'm working on creating a PA CAT rig myself. I've got it in max and it imports and plays converted fbx PA anims just fine. The only thing I need to do is turning it into a CAT rig. As far as I know, noone has yet made 3rd person anims for power armor. Well not for much longer, hopefully. Here's a site to get you started. https://www.sfmnauts.com/fallout-4/animations.html This should get you half-way, at least. The only step it doesn't cover is converting an existing rig to CAT.

Thanks man. One of the reasons I haven't updated fo4 yet was because of autoload. Now I can. And thanks to reg for setting this up.

Have you tried loading only a bare minimum plugins? If you load a large chain of plugins, many which are dependant of others, the ck will break on the first unstable plugin while it does a live ref lookup every time you open an editor. Xedit doesnt do that because it seems to keep all records offline. If you have Everything Search on your computer, you can keep it open and see if the ck dumps any messages to the EditorWarnings.txt. Though mostly a last resort, you can try renaming the ck ini files located in the root of fo4 directory, then have ck generate some fresh ones. I first thought you maybe did some edits to the nif, since a broken nif is the first thing that may cause the ck to crash. In which case, there's a quick way of checking a nif by opening ck, and without loading any plugins go to View > Preview Window and drag & drop a nif file into it. But since you're only editing properties of a formid, this doesn't really help.

Environment maps are defined in the shader node or in a material file linked to the nif. A cubemap is an array of textures in one file that forms a cube or sphere with a continuous image in order to create surface reflection or image-based lighting. In fo4 cubemaps have a very specific size of 513kB, because they are not mipmapped, are 128px and uncompressed argb_8888. Fo4 is very picky about cubemaps, and most definitely won't take a non-cubemap without producing weird results. As for ck crashing, could be a number of reasons. What edits are you doing? A screenshot of the gameboy effect would help.

Your character turning bald means that the headgear technically works, only that the mesh is either not showing at all or is displaced. I'd check the latter first, because it's the most common issue everyone has with headwear. Just tcl up un the air and look for the hat beneath the character. If you see it, then it's a skinning issue at least. Edit: While maybe not directly related to the missing mesh issue - looking at your screenshots, you have some discrepancies regarding the ap keywords. I don't know how armor aps differ from weapons, but besides the ap_ prefix they need to match in name. Your mesh ap is HatPin, while the logical ap in ck is PinHat. They need to be the same afaik.

You'll need this guide. It contains a PDF with information about importing animations. It also comes with max scenes for various max versions with CAT and biped rigs for both 1st and 3rd person, as well as a set of tools to convert vanilla animations to fbx so you can import into max. It needs to be between max 13 and 15, because only those support the tool for exporting the correct version of havok anims, so 14 is just fine. If by export you mean importing fo4 assets for animating in max, you just need a nif plugin for max to load the models. You'll find the models inside "Fallout4 - Meshes.ba2". You can use something like this for extracting.

Resaving through Nifskope or through your modeling software? Nifskope definitely should not be changing normals even with auto-sanitize turned on. Your modeling software might if you're exporting to nif. I know the max nif plugins are inconsistent across versions. I.e the one for max 18 doesn't add tangent space by default.

Have you done any edits to the mesh itself? If not, the simplest fix is to copy over the original mesh through Nifskope. Then add your bipod as a separate mesh in the nif. If yes, you can maybe recalculate normals in your 3D program, but most probably you either need to transfer normals from the original mesh or painstakingly recreate smoothing groups (max) or mark sharp edges (blender). The other options in Nifskope you can try is recalculate based on unweighted face normals (Right click mesh > Mesh > Face Normals). Then there's Smooth Normals which lets you set a max smoothing angle. I doubt these work, since it's standard practice to manually assign smoothing groups / sharp edges.

The mesh normals are wrong. It could happen for a number of reasons. The easiest is to try updating your mesh's tangent space in Nifskope.

Ctd on workbenches is almost always related to faulty nifs. Try swapping your modded nif with a vanilla or something you know works. Parent slots are only logical slots. They either work, or don't. You can't really crash the game even with custom parent slots unless you create some sort of a dependency loop, in which case Ck will warn you and auto-remove them.

For Photoshop, you should be using the fairly recently developed Intel texture works plugin which handles block compression iterations up to bc7. I've never had any issues opening any dds files in Photoshop using this as well as having the old Nvidia dds plugin as a backup. When you open dds files, make sure you use "Open As" from File and select the appropriate format. If you simply drag and drop or use "Open", Photoshop will make an assumption on what plugin to use for reading dds. You need to specify that you want the image to be opened by Intel texture works. Optionally you can use Compressonator and drop dds files into that - it eats almost anything except for some non-square dds files. It should at least give you the fourcc information as to what kind of compression was used, and let you export it to a more workable format for editing.

Hkt files are xml formatted multi-platform havok animation files which cannot be read by fo4 - it needs to be 64 bit (binary packed) hkx files, specifically the versions made with hct 2014.1 r1 64 bit, which is a plugin for 3ds max 13-15. Fbx is only used as a means to transfer animations to 3ds max for editing since max cannot open hkx files directly. It can, however, export animations to the correct hkx version provided you have said plugin. It can also convert 64 bit hkx files to 32 bit, which can then be converted to fbx using something like hkxpack, which in turn may be opened in 3ds max. The process is convoluted and you need very specific tools and versions of them, which is one of the reasons why mod animators for fo4 are far and apart. You don't really import animations into the ck. You instead either create completely new subgraph templates or create additive subgraphs and override the animation search paths in order to make fo4 play custom animations instead of the default ones. Fo4 uses a decentralized system where it reads a library of game events tied to animation files. These libraries are referred to as behavior files and share the same extension (hkx) as animation files (also hkx). Behavior files are found in the subgraph entries in the ck. An example of such entry is "HumanRaceSubGraphData" which holds subgraph entries for humanoids in fo4. When the game reads a behavior file, it gets a list of all the animations it needs to look for, and then proceeds to look for them in predetermined paths. You can influence where fo4 should look for these animations by setting up new paths or changing the existing ones in a custom subgraph.

Fallout 4 doesn't even have rounds showing during reloads with the drum magazines, which always annoyed me because the reload animation feels like player only reseats an empty magazine. I think there can be some compromise where we can see a few rounds hanging out as the player puts in a full mag, and for the detatch stage just cull the child bones to hide the rounds.

It would solve the fire animation, but if the belt is exposed during the detatch stage of the reload, we'd still need a script to determine how many rounds were left when the reload was initiated because we would be able to see them. The assault rifle wouldn't have this issue since the feed is on the side and relatively concealed (and we could just say that whatever rounds are left in the magazine just drop back into it so we can't see them), but for an open feed like the M60 it would still pose a problem.

Have you tried reducing target conditions to a maximum of two, where one race has it and the other does not? Just to debug and see if it's the length of conditions that causes it to fail. Also, can you give an example of the flavor text you mentioned? Not sure if I've seen it myself.

That still doesn't invalidate my previous post. Your additive graph has redundant entries. See if it helps by reducing the number of entries to the ones mentioned in my post or in the video. Or, you might have a gun behavior file overriding your melee weapons either by your esp or as a loose file. Did you place any loose files into your Data\meshes\Actors\Character\Behaviors directory? Did you at any point rename any melee behavior files into gun behavior or vice versa? I'll gladly take a look at your esp, if you'd like.