DrakeTheDragon

As for the more Morrowind-like Argonians there are several mods (my own included) covering this topic already as well. For the heads I'd go with Jjiinx's mod: http://tesnexus.com/downloads/file.php?id=13444 It gives them a more Morrowind-like base shape in FaceGen settings to start off from. And for the feet I currently only know of my own work towards this, using beasty feet meshes and slightly-bent legs created by jdayT quite a while ago. I have to deny the impossibility of the features requested and the limitation to only 1 body for all races. Solutions so far come with their own restrictions of course, mostly the need to create an insane amount of new meshes first (it's as incompatible to existing things as a new body mod), but it "can" be done already. edit: And keep in mind my current solution is far out-dated already and I can do way more than that today, like having a unique set of skeleton and animations on a per-race basis or more (my dragon race is going into that direction now, then Scripted Argonian Feet will follow, for yet more Morrowind-like traits to Oblivion's Argonians). All thanks to OBSE and the whole world of new possibilities it opens up.

Huh? It's weird I can't find any myself anymore either. However, I found some CM partner vampires from Divine Avenger stating they include custom vampire teeth in the download and some custom vampire races with similar features. Could be worth checking out.

These are no files you could find in your BSA. The fangs for vampires are a shape modifier from the TRI file for the human teeth NIF. There's a shape key like "vampire" especially for this purpose which makes the canines extend significantly. There are, however, some really nice vampire teeth for use in a race, outside of the hardcoded vampirism mechanics of Oblivion, you can find here on the Nexus. I think searching for "vampire" and/or "teeth"/"fangs" should yield proper results already.

You're lucky. This is AlienSlof's Giger Armor in most parts, and Lady Slof is almost exclusively modding for the male body. I don't know if it is allowed to link to sites with adult content here, but if you go to her webpage "www.slofslair.co.uk", you will find it among her Oblivion mods quite quickly. I have no idea whatsoever where this helmet's coming from though.

In Oblivion certain file types have to be just in exactly the right folder for their purpose. For example if you try using a NIF from outside "meshes", no way. A DDS from outside "textures" is not gonna work either. Then there are further file types which are even restricted to certain sub-folders, birthsigns obviously being one of them. Make sure your birthsign image is inside the same folder all other birthsigns are in. There might be sub-folders per mod or author "inside" this but none will be "outside" of it.

Invisible Vanilla clothing is a commonly known issue when using Robert's Male bodies. I couldn't yet gather any information as for why it is invisible, but the cause is rather simple and easy to fix. As a matter of fact in Oblivion your body comes with your clothes. It doesn't matter the slightest which body mod you're using, when you're wearing Vanilla items you will have a Vanilla body mesh underneath. The skin texture however is assigned per race, no matter what mesh is currently trying to use it. Of course Robert's mod makes it so its own textures with their unique layout are used for the races. However, those will not work properly on Vanilla body meshes. Apart from the texture layout not matching and weird skin sections being at off places on the body due to this, this becoming invisible thing also seems to be quite common, although yet still unexplained. Anyways, the easy fix is to make sure you're not using any Vanilla body meshes anymore, by always using the proper Stock Clothing and Armor Replacers for your respective body mods. Strangely it was always missed in the documentation of body mods, but those are actually far away from "optional". Just consider a custom race with no texture support for Vanilla... it will be completely purple or pitch black or invisible (the game engine seems to decide this very unreliably) when wearing items from the original game. As for the invisible underwear I can "see" in this screenshot, make sure the textures it's pointing to are actually at their proper place. There were some changes between Robert's V3, V4 and V5 and mixing up their meshes and textures can lead to this result. And here you see an example of the unreliability of the game engine's choice of error indicators mentioned above. Usually "missing textures", indicated by purple meshes, has priority over "missing normalmaps" (".._n.dds"), indicated by either pitch black meshes or completely invisible ones (somehow depending on the slot the item is worn in and some other factors yet unknown to me in detail), but as you can see this is not "always" the case.

Basically a package with male meshes and a package with female ones should not be able to conflict at all. It's different sets of files affected by each after all. I know for certain you can use Stock and Overhaul Clothing and Armor Replacers for Robert's Male and for Exnem's, HGEC or any other derivative thereof at the same time just fine. Maybe it'll help looking at what files actually are reported as conflicting in BAIN before even becoming concerned by this. I got BAIN reporting conflicts between any two of my AB packages myself already, but only because any AB package has the same readmes. Most times it's as simple and meaningless as this.

Your idea of gender distinction this way is of course also possible now. There can always be only 1 player in the game and this one can only be of 1 gender. So assigning a different skeleton by gender actually is amongst the easiest things in the world. For NPCs one can determine the gender and then assign the proper skeleton as well. The thing with retractable claws was already done in my Anthro-Dragons, just without animations to retract them it was not used yet. Additional bones in skeletons was something which could always be done, but of course, in its current state my mod is very conflict-prone as there can only be 1 mod replacing the default skeleton ever. I'm so relieved I can get away from this restriction now with the new approach! The only drawback I see would be animation replacers not affecting the custom races with their own skeletons and isolated sets of animations. But then, at least for my dragons, such custom animations won't look right on their unique anatomy anyways, so I'd have to adapt them first for compatibility by all means. I can imagine the same will be true for custom-anatomy Argonians or Khajiit likewise then. Ah, come on. Look at it from my side... people like You always give me new ideas when I am running out of them. Without ideas I couldn't make "anything" happen. Never underestimate your own value!

Hmm, it's been a little quiet around here lately. I made some progress investigating the approach with different skeletons + animations on a per-race basis and wanted to let you know, so far everything was working as expected. This really seems to be an approach going to work out. I was able to get my dragon race working without mesh distortions flying all over and its very own custom set of animations just by using 'SetPlayerSkeletonPath "characters\DrakeDragon\_male\skeletonbeast.nif"' shortly after loading the game. I never replaced the skeletons in "characters\_male" with mine on this install so it should be 100% conflict-free so far. "characters\DrakeDragon\_male" is the folder I put all animations into and replaced certain ones with custom ones. Now after the skeleton switch on the fly only I was using those animations and only those. I think this is a very promising approach and will now fully switch my dragon race mod to using it. I can even use several different sets of animations without restricting them to 1 per race. Think about a different set when walking on all fours, or when flying, or... and I'll just switch to them via this command at every time. There's a similar method to change an NPC's skeleton (and animations then) as far as I know. So I think fully customized motion for beasts isn't that far away from becoming reality anymore now. Just a heads up.

Just don't forget that body meshes (underwear actually are body meshes) are the same for "all" races by design of the game engine. For different bodies (underwear or nude for example) for different races you will need complex scripting approaches to work around. The individual race folders are only used for heads, and in case of beast races also tails. It is not a matter of just textures, nor can the creators of body mods do anything about it. And even if it was possible to have different bodies for different races, the body would still be replaced by the one inside each item you equip. Equip an item with a tackle in it and there will be a tackle, no matter what body the individual race has as default.

Just make sure you don't miss this 1st person skeleton for 3rd person animations, "meshes/characters/_1stperson/skeleton.nif", if I'm not mistaken. Any "real" 1st person animation playing on this one is what's causing this dislocation. edit: Getting rid of any 3rd person animations in the 1st person folder (or also "special anims" for this matter) will also be advisable. Though they're not known to cause this issue. They just won't work/look right on a proper 1st person skeleton anymore.

With an OMOD this won't work. Deactivating an OMOD will not 100% remove its files. When there's another OMOD in your list containing a PC/NPC skeleton like the mods with the fake first person, OBMM will "not" remove the skeleton or replace it with the previous one or anything. You using one of those special 1st person skeletons with any regular Vanilla 1st person animation not done for such a special skeleton will cause exactly this camera dislocation. Make sure the special 1st person skeleton is really gone when you're no longer using mods with this fake first person view.

It depends on what type of array it is. If it is of type "Array", i.e. has a numerical index, you access elements like "myArray[1]" or "myArray[indexVar]" just like in C. If it is of type "StringMap", i.e. has a literal index, it's like "myArray["oneIndex"]". To access or modify an array's contents you will have to use the "let" and "eval" commands though, for so-called "OBSE expressions", as the traditional commands like "set" don't know the new OBSE datatypes in all cases or just act differently for them. To iterate through an array without knowing its specific indices you can use "ForEach" like array_var itemArray array_var item ... ForEach item <- itemArray ... Loop Inside this loop then "item["key"]" holds the index and "item["value"]" the contents of the current index of the array the iteration is at. Directly accessing the content the way you did it in your example above I'd not advise to do though. It's safer to use a temporary variable for the reference like "let myRef := myArray[myIndex]" and then use it in a condition or whatever like you did "... myRef.getDistance ...". I hope this helps. edit: Seems I was typing too slowly again.

Nah, I don't think so. Your idea to also introduce gender-distinction "when" going the route of different skeletons and animations per race was really valuable. I was just warning not to immediately jump on this specific bandwagon before we even know if it's possible. This last sentence was just making me worry how it will come across and I tried to take the wind out of its sails by explaining why I for one am doing my foldernames this way intentionally. One has to be overly careful with wording and how sentences come across in online discussions. No hard feelings and no cause for any.

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.

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.

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.

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:

Didn't Dark0ne write it was an exploit performed by the adserving company ("blacktreegaming" I guess) itself? Well, whatever it was, the ad provider is responsible for not distributing infected, harmful or otherwise malicious ads. Let me add that many of their ads already were "harmful" in my eyes even without any viruses or trojans in them. The little netbook I'm currently stuck with almost broke when there was again one of those videos playing, without asking me if it may. Getting these insanely loud sound effects all of a sudden in the middle of the night wasn't much better. But those ads which weren't actually much animated or anything else suspicious but still managed to prevent scrolling down, clicking links or even closing windows really put me off. And now they even managed to get the functionality of this site damaged to a point where there are no searches possible and one has to click on "ignore" for every link you click and can only pray that you get through to the location you were aiming at and won't just end up somewhere else entirely due to the redirect killing yet other url parameters! If you ask me, this is a good opportunity to reconsider sticking to this in-my-eyes-"untrustworthy" ad provider altogether now. There must be many far superior ones out there. ...oh, well,... for the time being until this Google-issue gets settled and the site gets operational again in Firefox browsers I'll just fall back to using Internet Explorer for browsing the Nexus. All hail to Microsoft for not relying on Google that insanely much! (God, I can't believe I hailed MS! But Google managed to become yet more unbearable for the moment.)

For me it always displayed the "attacking site" warning message and killed all additional parameters from the url due to the redirect, so I never got any search results either. I don't know if it's a feasible solution for you, but I'm not using Firefox for browsing the Nexus anymore until Google gets this issue settled. Microsoft's IE is, for the first time in its life, working like a charm in this case.

Ignore my writing about the "Mozilla Gatekeeper". Further investigations revealed that part of the URL for the XUL-definition is only an intended pun, a reference to the film "ghostbusters". But still the warning page in Firefox seems to be originating from Mozilla itself, so the last point of my post is still valid.

I'm getting redirected to such a page with FireFox as well. According to the source code (which is hard to get as it redirects loading the source to the error site as well, but with FireBug I got around this) it's something called "Mozilla Gatekeeper" where this page is coming from. I don't know if it's connected to Google or anything, but if it doesn't fix on its own, it might be possible Mozilla is maintaining such a list of its own and it needs to be removed from there as well.