Jump to content

"Proper" khajit and argonian bodyshapes/animations


MarkInMKUK

Recommended Posts

Very impressive work so far! This project is really looking very promising and I can't wait to watch it come along.

 

While I was aware of all this for quite a while already I just so happened to stumble into this thread today. I guess not much free time at all also means not much checking online forums and such, and checking my own comments sections and PMs already takes its time. My apologies for that. On weekends workload seems to subside a little though... at least during the nights.

 

I don't know if I can be of much help here, but I thought giving a short summary of things I did, why I did them this way and not that way and facts about the limitations we're fighting couldn't hurt. So people get an idea what this all is really about and what it means to do these things they're requesting.

 

Facts first, the limitations of the game engine:

  • While skeleton files can be assigned on a per-actor basis, the skeletons the player will be using can't be assigned even on a per-race basis. There are scripted ways to change them while ingame, especially nowadays with recent OBSE development, but there are still some limitations the OBSE devs still try to overcome, especially regarding changes to apply "on-the-fly".
  • There is only 1 single set of body meshes, male and female, for all races the same. So the only way to get one race use a different body or body meshes than all the others will be by scripting.
  • Replacing the default skeleton files is easily done, but there can only be 1 skeleton file each in their place. Due to the number of mods replacing your skeleton files already for features like bouncing boobs, high heels, clothing or hair bones, "skeletal variation" and the like, only 1 of these mods will survive, the one installed last.
  • In Oblivion your body comes with your clothing. It doesn't matter what body mods you installed, if you're not using the fitting Stock Clothing and Armor Replacers either (or even wearing an item done for a different body), you'll have a Vanilla body mesh again while wearing these items and it will use Vanilla textures (if present, purple/black/<insert-random-error-indicator> otherwise).
  • I'm not yet far enough into it myself, but it seems animations are skeleton-bound. By changing the skeleton file used you can change the animations used, given everything's in a different folder. This is a future approach I was investigating, getting away from skeleton "replacements", thus getting away from incompatibility and towards really "unique" skeletal structure/anatomy.
  • Before skeleton-swapping on-the-fly became possible there was no way to alter the skeleton/animations for one race without this also affecting all others, especially when aiming towards "playable" races.

 

Now, what's the basic idea of my scripting approach:

  • Abusing the fact that body comes with clothing I utilized the approach to "equip" custom bodyparts via scripting.
  • While you can alter the anatomy of those "equippable" bodyparts, you can only go so far until it becomes impracticable for a regular humanoid skeleton lying underneath, which is what I was still limited to. The degree of "digitigrade'ness" (horrible word, I know) the meshes in Scripted Argonian Feet/Argonian Beautification or even my Anthro-Dragon Race show is about as far as you can go until things start looking, and acting, weird.
  • Only equipping custom bodyparts while not wearing anything in the respective slot though is already done on a regular basis in other mods and by far not enough for me. I designed an automated way to swap an items' appearance with one fitting the custom bodyshape by switching the NIF files the equipped item uses, given there is such an alternative file present, and otherwise force-unequipping the item with offending appearance.
  • Later approaches also involve so-called Replacer Templates, that is rather generic appearances to be used instead for the time being until a real replacement file gets added into the folders. Which appearance gets used by which item is determined by factors like item value, class, armor type, or whatever else you can think of as factors. (This was so far only done for my Anthro-Dragons, because they are what it all started with and are my testing ground for new features which will later migrate into Scripted Argonian Feet or whatever one makes of this scripting resource, the Cloth Wraps there being the only appearance set so far.)
  • First I tried it with altering the NIF path of the item equipped directly. This however was bound to clash with many other things, as you can only alter "base" items' NIF files, as in every single instance of an item in the game "at once" (like every leather boot suddenly becomes an Argonian counterpart). Of course getting the changes to show required the items to be unequipped and reequipped (something the OBSE guys are still working on to overcome as far as I remember), making it very unlikely, almost impossible, for the changes to show on anything else than the affected actor, but still the possibility itself was enough to disqualify this as a valid approach for me. And coming to think of it, you could not have 2 mods of this kind affecting 2 different races at once when they end up trying to alter the appearance of one and the same item.
  • That's why my approach uses CloneForm to create copies of the base items it's going to alter the NIF files of, applies the changes to the copies, exchanges the items in the inventory of the affected actor and reequips them afterwards. A clever system of Pluggy arrays was keeping track of already adapted items, so there aren't just more and more Cloned Forms of the same base created each time an Argonian equips something. (This was back then when there was no array functionality in OBSE itself, yet. Nowadays Pluggy should not be required anymore, if just I could rewrite my scripts for this.)

 

Using CloneForm and force-equipping/-unequipping comes with its limitations as well, of course. Which is what I was working on last time I could work on anything not job-related.

  • A Cloned Form might have all attributes, scripts and the like from the original item, but it won't be recognized "as" the original by its FormID, obviously. So any scripts checking for ItemCount of QuestItemXYZ will fail as there is no longer QuestItemXYZ in the inventory but CloneOfFormXYZ instead. The same goes for GetEquippedObject or GetEquipmentSlotMask and the like, of course. I was talking to scruggsywuggsy the ferret about this back then and he said it could be possible to implement some kind of "alias"-based approach making Cloned Forms recognized as the originals where intended, but I don't know what was done in this regard, yet, as my laptop died and I more or less "left the scene" involuntarily.
  • Not quite long ago equipping an item via EquipItem or EquipItemNS did "not" trigger any "OnEquip" blocks of attached scripts, while unequipping via UnequipItem or UnequipItemNS very well "did" trigger the "OnUnequip" blocks. In Vanilla Oblivion many toggle-type checks work by setting some flag to true when the item is equipped and setting it to false when it's unequipped, as is the case for the Arena Raiments for example. This mechanism will break, because equipping the Arena Raiment will set the flag to true, it getting unequipped by my scripts will set it to false, my scripts equipping the adapted one then will "not" set it back to true, and the whole check is useless. Luckily this was changed by the latest OBSE release with the clever alternatives to EquipItem and UneqipItem which "will" trigger those "On..." blocks when wanted. I only need to incorporate these into my scripts next.
  • Adding an item to your inventory means you end up with a perfectly clean and polished instance at 100% health and 100% charge (where applicable). This means just by unequipping and reequipping an item Argonians could "fully repair" it with no cost. The functions for getting and setting an item's health or charge back then were only working on "equipped" items, so I could very well store the health of the item about to be unequipped and then set the health of the adapted item once equipped, but the other way round I was in a little trouble as items could also have been exchanged between actors at the same time the unequip took place and the new owner couldn't possibly know the stored health value. Plus it was impossible to define which of the 5 or so Iron Boots in the inventory should be replaced, equipped or whatever, as most functions could only affect "base" items, yet again. It could even happen that the equipped item was 1 of 5 Iron Boots but the swapped one was "not" the equipped one (really bad thing!). I think I took precautions for this case and just can't remember them anymore... but still EquipItem or RemoveItem was acting quite unpredictable with multiple instances of the same item in the inventory. As far as I'm informed (which is close to not at all anymore) there was some development for OBSE into this direction as well, like addressing even non-equipped items in inventories and the like... but I don't know.

 

Getting rid of these last limitations was what I was working on mainly before my laptop died and I was forced out of business. The new scripts used by my Anthro-Dragons were meant to replace the old and very much out-dated approach used in SAF... but the latest version has never seen the light of the day then up to now. I still need to iron out some flaws.

 

Scripted Argonian Feet was always intended to be just "1 of many" mods of this kind. I purposely kept, and keep, my scripting approach as universally applicable as possible. Just look at my dragons' scripting. There's a big config array in the main quest script defining which race gets which bodyparts for which controlled slots and which replacer templates etc. and even in which way fitting clothing is enforced for a specific slot and if at all and if combined-slot items (items occupying more than 1 slot at once) are an exception or not etc. etc. etc. This was even intended to become externalised into an ".ini" file at some time in the future. Neither SAF nor my dragons or any other of the mods I do will ever conflict with each other, this I'm taking special care of. Altering Scripted Argonian Feet so it becomes Scripted "Khajiit" Feet should just be a matter of seconds to me. I invent a new "tag" for the filenames of adapted NIFs ("ABfeet" from "Argonian Beautification feet" likely will not serve for Khajiit, but as it's just a matter of changing some strings in the scripts it could be anything else basically) and alter my scripts accordingly, and all it then needs would be custom bodyparts and adapted NIFs for some items, just like I added to SAF for proof of concept.

 

The only cause for me not having done this, yet, apart from the obvious being unable to do any modding or at least not much at the moment, is that as I said the SAF scripts are far out-dated already and far inferior to my dragons'. But the latter need some tweaking as well first before I can release them for anything else than test-releases... and SAF was far beyond the point of a test-release already.

 

Oh, and in answer to some questions/comments which came up regarding my mods:

Argonian Beautification is only a "compilation" of mods from others made compatible and support for many different bodies added.

Even the original Slof's Better Beasts only supported Robert's Male, Female and TFF mesh-wise, so I had to adapt the spiked tails and the fingerclaws to fit all the others myself.

jdayT's mod was also only intended as a proof-of-concept rather. He's given you the Argonian Feet so many other mods took up to create their own beast feet from. His plugin was just a simple way to put them into the game. He created a few nice clothing items with those feet in and hand-placed them into all Vanilla Argonian NPCs' inventories, removing their regular shoes/boots in the process.

This only affecting Vanilla NPCs and none from mods or even the player or companions was one of the main causes for "Scripted" Argonian Feet's creation. I wanted something which does the same for just about "all" Argonians, no matter if coming from the original game or a mod. As long as they're either of RaceID "Argonian" or affected by the Argonian Racial Ability "Poison Immunity" my scripts will be running on them and do their magic.

jdayT even went so far and gave you a set of equippable feet, rather digitigrade bent legs and some fitting clothing for your own use in the Ayleid Cask I mentioned in my AB readme (because it was hard to find this information in jdayT's original mod) so you could try his new meshes out all the way you wanted. So, yes, he was serious.

I just went and made it so his feet didn't require their own textures anymore but used the ones of the race they're equipped on and adapted in skin tint and color to the settings you did during CharGen. Then I adapted them to any body AB is supporting, as jdayT originally only did them for Robert's Male and TFF.

What I did "not" do, however, was anything regarding Argonian heads. I was using these mods myself so I added them into the "recommended" section of my readme, but I did not include them or anything. Credit to whom credit is due.

The range of adapted items in SAF as well as the range of supported bodies by SAF is only due to me back then not having had much experience in modeling, yet. Those were among my first creations and far from perfect. I was the scripter mainly but needed something to show-off for a proof of concept. I wasn't always talking of future additions to the range of adapted items and the fact that any adapted NIF file you add will automatically be taken up by my scripts and used, without the need to alter any scripts or plugins, for nothing.

 

On a sidenote: I'm intending to rid SAF of the Pluggy dependance, add in the combined-slot exception so those DB Armors and the like I haven't adapted yet won't be forced off, perhaps remove the whole enforced unequipping deal altogether, and maybe even try to migrate the Replacer Template approach into SAF, even if only with the cloth wraps for Argonian Feet I've done ages ago, just like my dragons. I just can't tell when this will happen or how long it will take. But when it's done it'll still be only a matter of seconds for me to turn it into a Scripted Khajiit Feet for you here, if you'll make use of it or not.

 

On a yet less related sidenote: The next release of my Anthro-Dragons, whenever this will be, will use its very own custom skeleton with its very own custom set of animations, isolated from the rest of the world (ahem, races). If this turns out a feasible approach I intend to make use of it for a new approach to Argonian Feet, of course with "real" digitigrade anatomy/skeletal structure and movement animations. I'll let you know when this yields promising results... hopefully it'll not take me too long to get some time for this.

 

Anyways, I'm watching this thread now with anticipation. I might be mistaken as a lizard guy, given my tendency towards Argonian mods, but it's only my favourite race of the two beasts so I started with it. I'm a beast race fan in general! The poor 'jiit were only left behind by my mods due to the lack of time for attending to two similar projects at once... and because I felt them already nicely dealt with by Slof's mods and others back then. Nevertheless, the catfolk was always intended to follow up once I'm done. :thumbsup:

Edited by DrakeTheDragon
Link to comment
Share on other sites

  • Replies 311
  • Created
  • Last Reply

Top Posters In This Topic

Drake-

 

Thanks for taking the time to weigh in on this. As my scripting ability pales in comparison to your own I'll defer to your expertise in this area. I've looked at the script for the scripted feet mod and honestly couldn't make heads or tails... or feet- of it. :blink: Here's where things stand so far:

 

-I've modified Semtex's 'Paws as Ability' mod to replace the default body parts when unclothed. I've checked this in game and it works well on the PC and NPCs, they now get my legs, feet, and hands when unclothed.

 

-I'm handling the armor by attaching scripts directly to the boots and graves. It does a race check, and if the wearer is Khajiit then it substitutes the Khajiit .nif in place of the vanilla .nif. I plan on adding this bit of scripting to the existing script of Jakben's boots also. This way they can have an alternate appearance without breaking quests. I've tested this in-game on the PC only. I've been operating under the assumption that the onequip block would trigger for NPCs as well even if this means you need to wait for the NPC to change clothes first. Is this incorrect?

 

-I'm trying to stay away from any skeleton modifications as this is beyond my ability and I'm trying to minimize conflicts.

 

Once I finish enough armor sets to do some thorough testing I'll likely be picking your brain some more. It may be better to use your scripts instead to keep the beast mods consistent.

 

Any idea when you'll be getting back into the modding game full-time?

 

-Razorpony

Link to comment
Share on other sites

 

 

Abusing the fact that body comes with clothing I utilized the approach to "equip" custom bodyparts via scripting.

 

 

this scripts already exist: Scripts for custom race and you can see some races using it in my profile ( they're adult content )

it was made by Ronyn, but i have fixed some bugs to avoid crash. i have made a tutorial too.

 

but i'm interested by all ideas for animations linked to a race. it's easy to do for idle anims, because it's possible to add conditions in the CS, but i'm looking for something to give combat animations to a specific race ( i'm working on a race with claws and i want it to use them instead of punch for hand to hand combat )

Link to comment
Share on other sites

It's nice to see so many people working on this while I'm internet-deprived. Allegedly I'll be online again on Thursday and can catch up properly instead of squinting at a mobile phone screen. Razorpony - I *REALLY* like the new footwear. Drake - glad you have joined the thread as you inspired me to believe it was all possible.
Link to comment
Share on other sites

razorpony, the OnEquip blocks do work on NPCs the same as they do on the PC, as far as I know. It might take them some more time to react as there are several factors determining script processing periods and times on actors, but this won't affect their functioning in a noticable way.

As for when I will be able to go on modding full-scale again, I still can't really tell. I might now be working from a MacBook, which is an improvement over the NetBook I was previously stuck on, as I can now use a rom drive and have a hardware setup able to handle Oblivion so I could install the CS, OBMM and the tools again. But my free time is still as limited as before due to the massive workload from my part-time job. Nevertheless, now that I technically "can" make progress again there's a bigger chance I "will" make progress, whenever I find some free time for it.

 

I was tracking this scripting resource for custom races since the first upload by Ronyn. There's a similarity in what my approach does and what this one does, in that they both use the "equippable bodyparts" idea. I first found it in jdayT's mods though, don't know where he got it from. Anyways, this scripting resource does not work the same way my scripting approach does at all.

For my own solution it was "unacceptable" having to add scripts to every item I want to equip (isn't this even reverting attributes and stats back to Vanilla during the process?). Neither was having to manually add a custom counterpart for every non-fitting item in the CS and hardcoded item IDs in swapping scripts. I wanted a dynamic and automatic solution which did not touch any existing item records nor incorporate new ones for every adapted item (CloneForm is somehow doing this, of course, but it's not the same as requiring a new plugin for each set of adapted armor I release, in that it does not require any action by myself, only NIF files).

The use of the "GetEquippedObject" function instead of "GetEquipmentSlotMask" is also a show-stopper for me. With GetEquippedObject you're limited to only the few pre-defined slot-combinations (I think the readme of the linked resource is also mentioning this even) and you have to meet the combination of the item worn exactly or it will not work. Check the lowerbody slot with GetEquippedObject and wear the Arena Raiment, it will "not" return the Raiment's ID. Last time I checked it even returned "nonsense" instead of "0" as expected. GetEquipmentSlotMask on the other hand can check for any arbitrary combination of slots, through the bit-sum of their slotmasks. And when you check the lowerbody slot only and wear the Arena Raiment this one actually returns the Raiment's ID. GetEquipmentSlotMask is my personal preference over GetEquippedObject at all times due to this.

 

As for complete sets of custom animations on a per-race basis, I'm still investigating this myself, but last time I checked it was something along the lines of putting my custom skeleton into a different folder than "meshes/characters/_male", let's say "meshes/characters/DrakeDragon" for example, then the race will use animations found in "DrakeDragon" instead of the ones in "_male". Don't know if it will even use any animations from "_male" at all anymore. Assigning different skeletons to NPCs is a simple task in the CS. Doing this for the player requires some in-development OBSE functions and tricks to make the changes show right away. I have to investigate this further myself first though before I can tell any technical details. I'm away from the modding scene far too long already.

Link to comment
Share on other sites

As we'd be doing custom animations / skeletons on a per-race basis, would it make sense to put any custom racial stuff into "meshes/characters/_maleKhajiit" or "meshes/characters/_femaleArgonian" or whatever? Then it's nice and logical, and other people can use the same directories for add-on resources without needing to do additional esp files, as the script should check these default directories for any override stuff first. I always find working with a subject in a file name easier to remember than a modder's name - of course if said modder prefers to have their name engraved in the file structure for posterity then obviously that's a consideration.
Link to comment
Share on other sites

its good that the modders here are getting your insight drake

 

and the boots look good razorpony also i like how everything is going along more and more ppl are getting interested in this :crazy laughter:

 

if only i had the ability to help but i am a amateur at modding i can think of ideas and can do research tho lol

 

oh and good luck everyone and good luck with finding some free time drake

 

if i have a gaming comp by the time this is out its gonna be first day dl lol

Edited by hellchosen
Link to comment
Share on other sites

Introducing even gender-distinction into the "unique skeletons and animations per race"-approach is an interesting idea. What you name the folders however is something you can freely decide on.

But please keep in mind, only because I was writing about it here doesn't mean the new approach with skeletons and animations in a race-specific folder is something you should fully concentrate on already. As I said the required technicals in the background need not even be completely usable, yet. I just "heard" about these things while I was inactive and thought they'll be the new way to go for me. I don't know enough of the details, yet, to know if it will work at all even.

 

Of course a generic foldername is easier to remember and handle than one with a modder's name in it. But I disagree about it being "engraving" one's name into the folder structure "for posterity".

Look at it from my side for example:

On my drives there's a race sub-folder named "dragon" where all my dragon files and stuff are in. Quite a generic name lacking any reference to myself.

Then people started asking for a release of the stuff I had done so far. My laptop was going to die and my files about to get lost permanently, and I can't say "no", so I agreed and prepared an unfinished, incomplete test-release for upload. Missing resource files needed to be created, dummy files got proper replacements, and files I didn't have permission to inclusion for got fitting substitutes.

Then there was the folder name. "dragon" might be totally in order for my own use, but I could impossibly release it with this in public! I even "know" of other custom races which are using this folder name already and I will never go and "reserve" such a generic folder name for my mods. I needed a proper folder name, still making the race be recognizeable as dragons, but most unlikely to clash with other existing dragon races. And what's a better prefix than the name a modder is known under in the community? Who's going to use another modder's name in his folders? I already prefix all EditorIDs in my mods with it, again for compatibility's sake, and a clean structuring not only I can manage.

 

If I wouldn't share, I wouldn't care. But as I do share when asked for it I have to do it in a clean and easy-to-handle folder structure. Is there anyone who disagrees?

So please refrain from calling this what I thought to be common habit even a thing "for posterity". I myself couldn't care less, but there are others who very well might.

Edited by DrakeTheDragon
Link to comment
Share on other sites

Actually Drake the only items I had to add to the CS were the unclothed body parts to use as 'clothing'. I made 2 scripts so far,one I attach to boots/shoes and one I attach to greaves/pants. They contain a simple ModMaleBipedPath command that works like this:

 

ModMaleBipedPath "armor|khajiit"

 

This substitutes the word Khajiit for the word armor in the nifpath, so instead of the steel boot mesh loading from data\meshes\armor\steel\m\boots.nif it loads from data\meshes\Khajiit\steel\m\boots.nif. So, all the .nif paths are changed on the fly and objects don't have to be added in the CS. THis should also work with the raiment as it doesn't matter what slot it occupies, the onequip block will run when it's worn. My plan was to put the scripting in an .esm so that any armor conversions that are made later could simply include a khajiit mesh and have the script attached.

 

I've tested this system in game and it works so far. The only change I need to make is the addition of an unequip block to revert back to the vanilla mesh when the boots/greaves are removed. Didn't realize the path change stuck.

 

And don't worry Drake, no one thinks you're vain for including your name in the file structure. It's common practice. Lots of people do it to keep things seperate.

 

-Razorpony

Link to comment
Share on other sites

That's the same thing I'm doing to the Cloned Forms in my approach, in a way, as I'm not changing the folder but adding a certain "tag" into the filename.

I was refering to the linked scripting resource by Ronyn and Rebel O Conner.

 

Out of curiosity, how are you getting the change to show on worn items? My initial trouble came from the need to unequip-reequip the item in question for the changes to take effect, as until the latest OBSE the EquipItem function I used for this was not triggering the OnEquip event handlers of scripted items. But luckily this is a thing of the past as well since the last OBSE release.

 

I know I'm very picky in evading the highly unlikely chance of 2 NPCs, a beast and a human, equipping the same item type and both ending up with the beast version due to ModXXXBipedPath affecting all instances of the base object in the game at once. I think it's even impossible for this to happen, as scripts likely aren't running in parallel anyways. But two such custom races using the same script approach and both trying to alter the NIF path of one and the same base item was a troubling thought to me. But as long as you don't wait for the next frame between the change and the equipping, thus don't give control back to different scripts, this should not cause issues either. Perhaps I'm just being overly careful with this here.

 

Maybe technology even changed since I last checked and the changes are only affecting the referenced object instance now. In this case it'd be very valuable to know this, as I could scratch my whole CloneForm-based solution with all its inherited troubles and rewrite my token scripts.

 

I wasn't really worrying for myself. I couldn't care less, like I said. Knowing the common reactions to misunderstandable statements like this across the web though I just thought this last sentence could cause bad feelings and wanted to rectify this. It'd be a shame to see this thread derailing.

Link to comment
Share on other sites

  • Recently Browsing   0 members

    • No registered users viewing this page.

×
×
  • Create New...