This post is both to provide information for modders, as well as to ask for some help with a few weird situations I've come across.
I'm working with a feature of Racemenu by expired6978 that's, to my knowledge, not been used by any other modders before. This feature doesn't really have a name that I'm aware of, but the gist of it is that you can use "Custom" headparts by assigning a headpart record a TYPE value that's out of range from what the CK normally allows. In other words, where normally TYPE would read something like "Eyes" or "Hair" or similar, you can use an external editor like zEdit to forcibly change the TYPE value to a number like "32". Racemenu then has the ability to read in some .ini files to create an extra slider in the character creation menu that will populate with any Headparts that are assigned the specified TYPE value. Suffice to say, there's a world of opportunity for turning things that would normally take up an equipment slot and inventory space into a character-creation slider. I have created and published 3 mods using this feature – most popular of which is Horns Aplenty – and I go into more detail on the mod pages' description about how I did it and how to use it. Please remember if you decide to make a mod using this feature, keep in mind that overlapping TYPE values should only be used for Addons to an existing slider. In other words, if you want to make a Horn model addon to my Horns Aplenty mod that just appends an extra Horn model to the end of the slider, you can assign them to TYPE value 32 and don't need to include any .ini files, but if you want to create a whole new slider, you should pick another number that nobody else uses and create the appropriate .ini files to go with it so that it becomes a separate slider.
Now, thus far the process has been fairly simple, if a bit manual/menial – I create a new Headpart record with this out-of-range TYPE value, take an existing model that I want to turn into a headpart such as a horn ArmorAddon record, copy the mesh's .nif path into my Headpart record, and fill in the appropriate Data and Race flags to make it a playable record. In conjunction with some .ini files with particular formatting/naming, I can load it up in-game and it works in a slider.
However, I've encountered a handful of oddities as I've attempted to apply this process to certain situations. It's possible that my issues may stem in part from using a feature that's essentially undocumented and barely-tested (it didn't even work properly until about a year ago when expired6978 and I were discussing a mod idea and he realized the feature was broken), but as I'm still a fairly inexperienced modder there's also a decent chance I'm just doing it wrong.
My issues are as follows, in no particular order.
Some .nif files have multiple mesh components to them with their own texture paths and so on. Looking at them in Nifskope I see multiple BSTriShape sections, and looking at them in Outfit Studio it shows multiple items in the Meshes tab. This is normal, and these function as expected for the ArmorAddon records in the source mod(s) that I'm trying to convert. However, when I create them as a Headpart record, in-game it only renders the first mesh in the list of meshes, rather than the entire set of meshes in the .nif file. Thus far I've resolved the issue by splitting them up into separate .nif files with one mesh item each, assigning the secondary .nifs as Headpart Extra records, and attaching them to a main Headpart record. This is inelegant, bloats file-size, causes permissions issues for mods where I'm not allowed to redistribute meshes, and creates a lot of menial work. Do any of you know if this is normal behavior for headparts in Skyrim to only utilize the first mesh portion of a .nif file? Is there a more elegant workaround other than manually splitting up the .nif?
Some ArmorAddon records make use of the Texture Sets feature to create several variants of a model with different textures using only one .nif file. For some reason, however, even if I mirror the Texture Sets assignments exactly in my headpart records, they do not seem to actually swap out the Cubemap properly. When viewed in-game, they just use whatever was assigned in the .nif. I suppose I could manually copy the mesh files and assign the cubemaps within the .nif file, but that's sort of the same issue as above and creates a lot of menial work, especially for models that utilize both multi-mesh .nif files and texture set cubemaps. Do any of you know of a way to make headparts properly utilize the Texture Sets feature to swap cubemaps, or is that perhaps an engine limitation?
I've tried making a .tri morph file for one of the models as an experiment to potentially create a morph slider that allows you to move the associated headpart mesh forward/backward/etc in order to resolve clipping issues with hair or Khajiit ears and the like. I've attached the .tri to the corresponding headpart record and I've followed guides to associate the .tri file with a Racemenu slider that shows up in-game with the appropriate values. But, for some reason, when I increment the slider in-game, the headpart mesh does not move. Do any of you know what pitfalls I may be falling into for creating such a morph slider?
I've tried using a Tail .nif file in the same fashion as I have done for my Horns and Ears mods to see if I could make a Tail slider for character creation, but invariably it either crashes the game immediately after I increment the slider to apply the tail, or the tail sticks out straight/stiff with the middle section stretching off into infinity (and then the game crashes after a minute or two). I know that stretching body parts is usually a symptom of broken animation/physics; do any of you know if headparts allow for animations in the meshes like a Tail would use? I know some folks have been able to make HDT-enabled hair before which is a headpart – do you know if the physics component is part of the Headpart record, or if it's just attached to the .nif somehow outside of the .esp? I can confirm that the tail attaches to the correct place and moves with the character properly if you move them around, so I know this can work as long as there's a way to resolve the animation/physics crashing issues.
I've attempted to create a Halo slider (using the Halos from Angelic Halos and Demonic Horns to start), but for some reason on that particular slider, whenever I increment the slider through the halos that have animated flames on them, the model from the previous item in the slider does not get removed. In other words, they all pile up and I see multiple Halos all in the same spot at the same time. I have no idea if this is an issue with Racemenu and/or this Custom/out-of-range Headparts feature I'm using, or if there's something else that would cause a slider to forget to unload the previous item(s) when you increment it.
In a similar vein to the above, for some strange reason Vampire characters experience the same "stacking" issue where the slider doesn't unload previous items, but this happens to all of the custom/out-of-range headpart sliders so you end up with, say, multiple horns all at once. I don't play vampires myself so I've never encountered the problem, but I've received multiple reports regarding it.
A big thank you to anyone who helps provide information about these issues, and I wish everyone that read my post a pleasant day.
- None Found
More about The Elder ScrollsPost: "Converting “Armor” items to Headparts for Character Creation" specifically for the game The Elder Scrolls. Other useful information about this game:
Top 20 NEW Medieval Games of 2021
Swords, dragons, knights, castles - if you love any of this stuff, you might like these games throughout 2021.
10 NEW Shooter Games of 2021 With Over The Top Action
We've been keeping our eye on these crazy action oriented first and third person shooter games releasing this year. What's on your personal list? Let us know!
Top 10 NEW Survival Games of 2021
Survival video games are still going strong in 2021. Here's everything to look forward to on PC, PS5, Xbox Series X, Nintendo Switch, and beyond.