DrakeTheDragon
-
Posts
6448 -
Joined
-
Last visited
Posts posted by DrakeTheDragon
-
-
I have everything downloaded that I need- I think. Two questions:
I don't understand about the skeleton files you mentioned with Tiffa's mods. I searched the files using the term Anthros and found the race, but I don't know how to get just a skeleton. The Wolven Anthros mod doesn't use the same skeleton? Sorry- I'm lost here.
Also, I downloaded V5 of Roberts Male. I know it's beta- do you think I should go with V4 instead?
One more... now that I am actually adding the files the question came up- does it matter which version of the body replacers I use? I can't find anythng that says it matters. Can I just do whichever I like best? (which is Roberts Muscular and HGEC Fighter).
Thanks again so much
suzy
No no, sorry about the confusion, I was talking of the equipment mods "for" the Wolven Anthros. In some of them Tiffawolf used my dragon claws with armblades, and those blades, being sheathable/unsheathable through animations by their own bones, will require my skeleton files to be used for the player or whoever wears the stuff. To get them you can either download and install my whole 0.0.7 pre-beta release, or, as it's only the skeletons really, put my files somewhere outside of your Oblivion folder, in a temporary place or something, then inside my folder structure (which is mirroring the games' one) search for "meshes/characters/_male/skeleton.nif" and ".../skeletonbeast.nif" and just copy&paste them into your "meshes/characters/_male". Then you have my custom skeletons and the items requiring my custom bones will not stretch into infinity anymore. Or open the offending files with NifSkope and right-click->"remove branch" the armblades and spikes. Replacing your existing skeletons with mine might actually cause more harm than it is useful. There can only be 1 skeleton file used for all races at once and whichever mod replaced this one last wins. If you're for example using a custom race based on Chingari's and Ismelda's Demon Race or Breeze's Seducers skeletons, then it's fine as those bones are included in mine, but if it's for example some skeletons for BBB, real high heels or Corronera's Maximum Compatibility Skeleton, then you're out of luck, as those bones weren't included in my skeletons, yet. Replacing these with mine will make my stuff work, but break all the others. Nevertheless, this becomes only valid when you intend to use any of those equipment mods Tiffa adapted to her Wolven Anthros and only when it contains such items with some bodyparts of my dragons in them. It was just a warning for the chance that.
Robert's V5 beta is totally fine. I'm using it myself. If anything, then you might realize a little difference in shape between your body and the body inside the items you're wearing. There aren't many Stock Replacers for the V5 beta, if any at all, even the ones included in the package are actually the V4 ones from Sen-chan, and the V4's shape is obviously a little different. The same is true for the body types. For Robert's as well as HGEC the textures will always fit all body types, but the meshes do show slight differences from type to type, some more noticable some less. There could even be some seams or gaps at where the different bodyparts connect, but again they shouldn't be too noticable. It's all a matter of preference really.
I can't remember which types the custom bodyparts in the Wolven Anthro mod were modelled for, but the differences shouldn't make that an obvious flaw.
I hope this helps.
-
Most likely it's Archive Invalidation to blame here. Which method for this did you use? I've had Steam users getting issues with even meshes (something which normally doesn't require Invalidation to begin with), only because they were using the wrong approach. BSA Redirection is all you'll ever need. Fire once, never bother with AI anymore. Get rid of any left-over ArchiveInvalidation.txt files as those will cause random issues such as this trying to invalidate files which aren't inside the newly placed dummy BSA (that's what BSA Redirection does) to begin with. BSA Redirection can be triggered through either OBMM's Utilities for Archive Invalidation (leave all settings on default and just make sure it's BSA Redirection selected), Wrye Bash's pendant from the Replacer tab, or the famous mod ArchiveInvalidationInvalidated!. They all do the same.
It could be also the file dates of your BSA files being far too recent for any mod-added resources to ever be used over them. In this case you can rectify this by using a tool to redate them to a proper year sufficiently far in the past. But somehow this is a confusing topic as it's still not sure this is even responsible for causing those issues to begin with. It'd be best to read up about this particular topic on Steam's own modding forums for Oblivion. As I'm not using Steam myself I've got only limited knowledge about the topic and am mostly just repeating what I heard of or read somewhere some time ago.
Oh, just in case, make sure that's happening when you're not wearing any clothing or armor items, as Vanilla items "will" give you back a Vanilla body while you wear them, unless their files got replaced by ones fitting the respective bodies/body mods as well, so-called Stock or Overhaul Clothing And Armor Replacers. The Wolven Anthros, and many others I know of, my own included, don't have texture support for Vanilla body meshes and as such Vanilla bodies will fall back to Imperial textures. Thus it's imperative not to be using any Vanilla body meshes anymore in any clothing or armor items.
-
Having a backup of the data folder should be all that's needed to revert back to a previously working state. There are mods who can mess with your Oblivion.ini (found outside of the data folder in some system folders inside "My Games/Oblivion") though, but I guess from those none will be among the list of your intended mods anyways.
Actually that's why I'm providing scripted installs through OBMM in my downloads. My users can go into OBMM, click "create", then "Add Archive", select my 7z file, will get a nice message informing them there's conversion data included in my 7z and asking if they want to use it to fill in all fields in the dialog, they press "yes", wait for the file to be read completely, then they see any data filled in already for them and only need to click "Create OMOD", wait for it to be done, can activate it from the right list, the list of OMODs, navigate from dialog to dialog answering questions about their preferences and wishes, and eviola, they're done, my scripts will handle the rest and take care all files, and only the right files, will go exactly where they should go. If anything went wrong then, it'd be me to blame for writing nonsense in my installation scripts or providing an invalid folder structure in my downloads.
Coming to think of it, that's pretty close to being "spoon-fed" by the tool, isn't it?
-
From what I read it's likely OBMM wasn't the culprit to begin with. It was Archive Invalidation done wrong, no matter via which tool, which was causing the crashing it appears.
Archive Invalidation is inevitable, if you want the game to use different textures than the ones inside its BSA. Only textures require Invalidation though, meshes and everything else so far will be used over the internal ones right away.
Now Archive Invalidation was long ago done through manually adding entries of files to invalidate into an ArchiveInvalidation.txt file in your folders. Later this got covered by tools to automatically fill in those files it finds in your folders which should be used over the internal ones from inside the BSA. But this ArchiveInvalidation.txt file was never working reliably to begin with. There were situations where it suddenly stopped doing any invalidation after a certain number of entries, then after adding a few more all of a sudden it was working again, and worse things, all pretty random or at least it could not be any rule deciphered so far.
A while after this a method called "BSA Alteration" got pretty prominent. Basically altering the contents of the BSA, so the new textures replace the internal textures right inside there directly, no way back ever apart from a backup of the BSA or a complete reinstall, this was also not the ideal solution, especially as like you experienced it's pretty easy to mess up Archive Invalidation horribly and with game-breaking results, and having done this in a "permanent" change to one of the game's core files is a really bad thing.
The up-to-date most common solution is what's called "BSA Redirection". It simply exploits the fact that actually only the one BSA at a certain place in the "SArchiveList" variable in the Oblivion.ini ever requires Invalidation. So it installs an empty dummy BSA into your data folder and inserts it at exact this position in the "SArchiveList" variable in the ini. So from then on only textures from inside this dummy BSA need ArchiveInvalidation, and as there are none, this means no textures ever again will require Invalidation. It's a one-time-only fire-and-forget solution, and you only have to repeat it should your Oblivion.ini somehow get altered and this entry in "SArchiveList" be removed or undone. OBMM's Utilities, Wrye Bash's Replacer tab and the famous mod ArchiveInvalidationInvalidated! all provide this new way for Archive Invalidation and are doing exactly the same. Just leave everything on defaults, "never" include meshes, and only use BSA Redirection, and should only need to do it once and never again worry about Archive Invalidation anymore.
There's one more important thing to keep in mind though. When using BSA Redirection it is pretty fatal when there's a left-over ArchiveInvalidation.txt file telling the game to invalidate a texture file which isn't in the dummy BSA to begin with (as it's an "empty" BSA "any" entry will cause this)! So find "all" of those ArchiveInvalidation.txt files, as there can actually be more than one in different folders, depends on which tools you used to automatically write them and where they placed their files, and get rid of them.
OBMM's strength over other managers clearly is the OMOD way of "scripted" installation. If there are any optional features in a mod package you need to decide about, it gives you a step-by-step wizard-like walk-through through each decision where you can make your choices and the script compiles your selections and in the end installs only the files your choices require. That's the power of OMODs and "OMOD-ready" archives, zip-files including special data for automatic conversion to OMODs so you only have to state "Add Archive" when inside the OMOD creator and every information, scripts, additional files will be filled in automatically for you, so you only need to click "Create OMOD" and be done. Usually those scripts are written in their own simple language, but there is also the possibility to write them in C# or Delphi (I think) and this was what gave you the error for one of your packages, as its author might have made a mistake in such a script there or you're missing some interpreter the script the author wrote requires. I don't know.
ESP files in sub-directories means the mod will likely require an installation script or you will have to move the proper ESPs according to your feature choices out of the subfolder into the data folder manually yourself afterwards. That's what manual installation instructions in readmes are made for then. You can of course always create an OMOD even from archives with such a structure, but the OMOD will only give you the same state as when you would simply extract the whole contents of the archive into your data folder, which is not necessarily a working mod install already, with non-used ESPs still in sub-directories and such.
OBMM's file conflict detector isn't really a "conflict" detector as it will only tell you when one OMOD is going to overwrite files from another OMOD, which in case of the one being the main mod and the other for example being an update or bugfix package is a totally valid situation and just what is intended. Still OBMM will report this situation as a file conflict between the two intended-to-be cumulative OMODs. Plus as was already mentioned, OBMM only keeps in mind which file is part of which OMOD, so if you deactivate an OMOD all its files will be removed, BUT if there's another OMOD containing the same files OBMM can't tell which one was installed last and will NOT remove the duplicate files altogether.
That's where BAIN, Wrye Bash's latest addition, comes in handy. BAIN (I think it's short for BAsh INstaller) also maintains an installation order, so if you uninstall a BAIN package the next package in this order will use its files to replace the ones removed, if there are files in common between different BAIN packages, or so I've understood it at least. However, Wrye Bash, and as such also BAIN, has a steeper learning curve and thus OBMM with its windows-like UI, automatic archive folder structure sanitizing on OMOD creation and the very comfortable OMOD installation scripts is better suited for a beginner.
Still it always stays a matter of choice and personal preference. I for one have switched to BAIN now, as it gives me more control over installation order (which after "load" order is the second most vital aspect of using mods properly), but I'm still providing OMOD conversion data in all my mod packages for users' convenience.
Oh, and there is no Oblivion.exe shipping with OBSE. That'd be illegal. The only thing required to get OBSE working is to place the DLLs and the obse_loader.exe into your Oblivion folder and from then on only start your game via obse_loader.exe instead of the Oblivion loader, or use start functions from OBMM or Wrye Bash, as both will either recognize OBSE in your folder and start the obse_loader.exe instead automatically (OBMM) or provide a means to start the obse_loader.exe instead through a checkbox (Wrye Bash). Nowadays there are also completely custom launcher apps available which again will provide means to start your game through obse_loader.exe or do this automatically, if you have OBSE installed. All the loader does is injecting code for additional script functions into the Oblivion.exe and then launch it, so if it's not started beforehand, those new functions will not be present and OBSE-dependent mods will not function properly. That's also why OBSE doesn't work with Oblivion from Direct2Drive, as they encrypted their Oblivion.exe and breaking it for the code injection is against the law. Steam however has long since realized the importance of OBSE and added functionality to start your game with OBSE support from its own launcher environment.
I hope this little information helps avoiding some confusion in future endeavours. Oh, and please refrain from claiming OBMM was messing up your install. The situation at hand was slightly different.
-
Well, I for one created OMODs from the three Wolven Anthros packages, because trying this out was the purpose here. The other mods, the requirements, I had already installed, this time I did this through BAIN though, but I was maintaining a strict OMOD collection in my last installation, so I know both will do fine. Just keep in mind you have to fix this one filename in all 3 packages or the OMODs you create won't be able to extract. And as for creating OMODs, once the filenames were fixed and the files repackaged into an archive I just told the OMOD creation dialog a fitting name, version and author (not all even necessary), clicked "Add Archive" and selected the newly created archive. Then, once it finished loading and listed the ESP in the small plugin list, I clicked "Create OMOD" and was done. No fancy configuration or anything necessary. That's what I like about OMODs and why I still include them in my mods although not using them myself anymore. They're so easy to handle.
But I wouldn't go for the V3 in Robert's Male. That's a pretty dated one. For a long time I was using V4, then I switched to the new V5 beta, now that it got some serious mod support. The feet meshes should be fitting any version, as will the body textures (that's great about Robert's bodies), so whatever you prefer should be fine.
If you have the install working, you should take a look at Tiffa's clothing and armor mods for the Wolven Anthros. There is some pretty nice equipment to accompany the race. Keep in mind though that some of those sets will require you to use the skeleton files from my Anthro-Dragons, as Tiffa used some features from them in those items which require a skeleton with special custom bones or things will start stretching into infinity. But its only the skeleton files it requires and it shouldn't be much trouble to get this working.
Oh, and don't forget about the Stock Replacers for those body mods I was talking about. You will get texture issues when attempting to wear a Vanilla item on a custom race without texture support for Vanilla, if said items didn't get their meshes replaced beforehand. For HGEC the EVE project should provide a massive collection of Stock Replacers for any body type you prefer, and for Robert's Male I recommend the work of Sen-chan to be found here on the Nexus.
-
Conversions, as in using the original files and making them work in Oblivion, is forbidden by the EULA (not only the release, the use).
Creating these meshes and textures from scratch (or other mods' assets) though is totally fine.
-
I didn't encounter any issues so far. Every feature was working flawlessly. Of course I met the requirements prior to install already, been using Robert's Male for ages and without OBSE my own projects won't even be possible. The Stock Replacers are considered mandatory by me, although body mods' sites keep telling differently, they simply ignore the fact that custom races done specifically with only textures for those bodies and no textures for Vanilla will not work at all without these.
The difference between body mods and Vanilla is just different body meshes and textures with vastly improved quality while not having that noticable an impact on performance. It's a purely aesthetical thing but I personally wouldn't play the game with Vanilla bodies ever again. Most of them also fix a few flaws in the Oblivion.esm, so they can only be considered an improvement. Your savegames couldn't care less about what bodies/body mods you're using and will be fully compatible back and forth. You load a game from years back and will just have the better bodies in this one also from then on. Body mods are outside-of-game changes and will effect all your savegames once you load them. The changes will not save into them either so going back is always just a matter of uninstalling the mod (uninstalling, not deactivating, as replaced files will not be restored by only deactivating a plugin, a thing often mistaken also).
The meshes and textures used in the Wolven Anthros should not be able to throw your pc over the edge. I'm playing on an old Mac Book in a Win 7 virtual machine and I don't notice any slowdowns. The OBSE scripting it uses is pretty unobtrusive also and shouldn't cause an issue with performance either. The requirements have to work or the mod will not work, but there's no way I would play without those requirements anyways, so it's not causing any trouble for me.
Oh, and I'm not using HGEC but TFF (personal preference) so the females will not work, but I'm not playing a female anyways and it's not causign any issues. I'm also not using Ren's Beautypack mentioned in the requirements but Race Balancing Project and it seems to be doing the trick also, but even if it wasn't, I'd just be missing certain hairstyles, nothing the world's going to end about.
If you do use the Wolven Anthros, just make sure you really install them in this order: V3 full package first, V4 update package afterwards and the Invisible Wolf Fix at last. They will each replace almost all files of their predecessors, so just permit them to overwrite, if they ask.
-
So, I'm now offered two choices, continue modding just as usual, knowing what I'm aiming at can be achieved with the toolset I have and how, or stop modding altogether now for 3 years until Skyrim will be modded to a point at which I can take up my projects again, not knowing if it will even be possible ever... hmm, I guess that's not really a question, now is it?
-
Well, in Argonian Beautification for one I didn't include painted nipples at least. IABT didn't have any, I myself wasn't interested in any, so I didn't add them in myself either. However, there are still "modeled" nipples underneath the texture, so it's like a flat scale "painted" over a nipple.
One can tell my SAF scripts (through a simple "set ABraceQuest.enableUpper to 1" console command) to control the upperbody also and make it use AA- or A-cup meshes, either only when nude or, through the means of renamed AA-/A-cup Stock Replacer upperbody item files, also when wearing something, but again AA- or A-cup items still include body meshes with modeled nipples, of course. One would need a Stock Replacer "without" such features done first, then it would work fine. And of course it will already be fine as long as the items aren't showing the skin underneath (who's gonna tell there's a nipple underneath this leather-plated breast armor or not? X-ray vision anybody?), but there are some items which are, and those need adaptations mesh-wise first. For males it's the same, of course.
My scripts can make it so your Argonians are using different upperbody meshes, when nude or when clothed, than any of your other races, but it still needs proper meshes first for this to work as we intend it.
(On a side note, the female Argonians in my game "are" flat-chested already since I started with this, using files from a GGC Blind TFF Stock Replacer for this myself, but I haven't touched the nipples, yet.)
I like this idea with the padding, Semtex. Sounds pretty feasible to me for Argonian ladies not wanting to stick out of the masses too obviously when on social events or something. After all, being part of a society includes the need to "adapt" to it.
(Good catch with the salads there, Mark. I'm not sure about me, but Drake's got a weakness for apples, roasted in his own fire, of course!)
-
Update: Turned out this OBSE check is none at all. It's just a message popping up to remind one of the requirement of OBSE to use this race. It will pop up every time one changes his race to a Wolven Anthro, be it the first time or after using "showracemenu" at any time in a running game again. It will only pop up once and this do-once condition will only reset when you change your race to something else. There is no actual check going on or anything. It's just this one-time-only message popup. So it's nothing to worry about when one gets this, as it's without any meaning. It's the regular functioning of the scripts.
-
Maybe we need to kidnap DrakeTheDragon and feed him sacrificial virgins at regular intervals to help with the coding :)
My dragons would never accept virgins as sacrifice. They actually won't know what to do with them. The entire race has sworn to protect every living being weaker than them millenia ago at the end of what their scholars called the Feral Age, as a means to make up for the countless victims killed during their feral times sort of, which due to them being the superior race on Earth means every single living being on the planet. Due to this they became vegetarians and because this was millenia ago the current dragon population can't even eat meat anymore without getting sick and throwing up as their stomachs aren't used to it anymore. Let alone the smell of blood makes them sick already. So better not try to feed me virgins or I might do the same. :yucky:
However, such virgins could actually find their use as distractions for my brother / boss so he won't bother me that regularly with more work and I could get more free time...
But for what it's worth I'm already sticking my head into my scripts again for the big script overhaul I started half a year ago and since then totally revised already. I can basically rewrite all my scripts now as there were so many changes while I was away and so many new ideas I got that the whole approach, even the latest not-yet-implemented state, pretty much is very outdated as of now. It's not much but it's making progress. :yes:
-
I'm on a Mac, too, right now, but using Oblivion inside a Win 7 Pro virtual machine I require for some work tasks. It's not the fastest this thing could give me, but I'm not allowed to put any parallel OS installation on it so it's the best I can get, and every 3rd party tool or anything is working totally fine for me.
-
From a technical point of view the distance at which no nuke effect can be seen anymore is pretty short in Oblivion. One could make the nuke visible when distant through LOD meshes, but those won't move or change or anything, so it's again no feasible solution. Maybe one could use "morphing" meshes for this effect, but I don't know if those even can be used for LOD. Coming to think of it, you're that far away anyways, perhaps a billboard with just a nice animation of a nuke as texture could be the LOD mesh... but again I don't know if it's even possible for LOD to do this.
On a related note:
A while ago I was trying to make life detect somehow range over a whhole valley full of lifeforms. I was using trigonometrical math formulae to place adequately resized representative glowing dots at the correct projected position at max. near-view distance away from the player, but it did only work when the actors were close enough so I could see themselves anyways without any representative glowing dot projections. Turned out actors and other things outside of the near-view distance weren't even processed and technically "didn't exist" anymore at this time.
-
Alright, I think I figured out what was wrong with OMOD'ing it. Inside the archive (all of them have this, V3, V4 and invisible wolf fix) inside "textures/characters/canis lupis/eyes/wild eyes" there's a file called "wild eye Ty D.ddsi". Obviously the "i" at the end is a typo. What is really annoying is that this seems to make OBMM's unpacker crash with an "invalid block type" cryptic error making it sound as if the program itself was broken every time you try to "activate" such an OMOD. I really thought OBMM would be more fail-safe. Once I removed the erroneous "i" from the suffix and repackaged the archive as .7z it could successfully be activated after I turned it into an OMOD again.
I'm currently play-testing the mod to see if really everything did work out well this time, and then I will pay this OBSE detection code section a visit and try to figure out why it doesn't stop complaining for some although OBSE is clearly present and working and instead needs a work-around as described in the description to become silent.
-
Never be afraid to try a mod. If you take some precautions, no potential damage done will be persistent.
I was always intrigued to know why it is said installation won't work with mod managers or similar. Nowadays OBMM is pretty fail-safe in this regard and forgiving even the weirdest folder structures authors could come up with.
I'll give it a go once I can access the download page again (only SQL-errors currently) to make sure I've got the latest files.
I'm actually using BAIN now, but creating an OMOD from it and installing this way, to see what it could be that's said to go wrong then, will cause no trouble.
Plus I'll take a look at the part with this OBSE check, because quite frankly the messages I've read of it popping up until now don't make much sense.
Tiffa's work is of such outstanding quality, it'd be a shame, if these things were holding back potential downloaders.
-
Hmm, you're talking about Beautiful People but it's not in your mod list. Did you leave it out?
From what I see you were using MaleBodyReplacerV4.esp (Plugin8) together with BeautifulV22 - MaleBodyReplacerV4.esp (Plugin24), the latter being in charge as it is loading last and also incorporated into the bashed patch last. But the latter is only a compatibility add-on for using Robert's Male "together with" Beautiful People. What it does as it is right there without also having Beautiful People is it points or redirects some cosmetic assets or settings to files from Beautiful People, which aren't there, such as telling the game to use eye meshes which aren't there.
If you are using Beautiful People and I just can't see it, because it told you to use only the Robert's compatibility ESP instead, make sure you're using only this one and get rid of Plugin8.
However, using Beautiful People is accompanied with an Attention! sticker. The eye meshes it uses are conflicting with other eyes or eye mods but "replacing" the Vanilla files. If not handled with care and special precautions so only the fitting eye textures are used on the right meshes and no conflicting race or cosmetic settings will mix in, this is what causes the Googly Eyes sympton (wrong textures used for different eye meshes), among other things. Wrye Bash can fix a lot of this, but it can mean "omitting" several eye-related features (eye textures mainly) from other cosmetic mods.
-
For Fantasy Figures just search for "teamff" in the downloads. Might not be the most intuitive search term, but it leads to all necessary results.
-
Actually it's the apply mode setting of the NiTexturing property for the first one. The Silverlight parts all have this set to HIGHLIGHT, which is what makes this shiny surface. Change it to the normal MODULATE and the shine is gone. It will still be a slightly reflective metal, but the smooth shiny surface looking like plastic wrap is gone. Due to the massive number of parts per file for the Silverlight Armor I advise using the spell "optimize -> combine properties" first, so you will only have to do this once for each texture record, which will affect multiple armor parts at once, if you're lucky.
-
are ther any lizard mods out ther and is it posabble to do a kamodo dragons
i like them and would like to have them in oblivion after all they would exsest in this time
Well, I couldn't find any komodos, yet, but maybe these creatures might be of interest:
-
Anyone know where i can find a mod with a Simple SOLDIER armor :) i wanna make my own EX-soldier :D
thanks
PS-with purple/darkblue pants
Did you have a look at the mod linked on the last page already? http://tesnexus.com/downloads/file.php?id=26312
Maybe it's of some interest to you. It's the closest look-alike I found so far.
http://www.mediafire.com/?64smu4og48shhu9 Password: dopethrone
This was originally posted on hongfire but the link is dead, so i took it upon myself to track it down. Features all the female characters, excluding Fang, and even includes Lightnings blazefire saber (sword only). The 'races' for the characters are fairly spot on. *update* It appears the file is corrupt but i have included the password (which i had forgotten to post) if anyone has any luck with it
Out of curiosity I gave it a try and it's not the file which is corrupt. It's the passwort. Luckily it was only a small difference and easily found out. The real passwort is "Dopethrone", with a capital "D". If the difference was any bigger, I'd never found it out.
-
And there is no "entkleinden" in the German I know, and grew up with, so it must be a typo.
But what's so unfitting about the "victim" part here? At least in German "victim of a spell" makes a valid expression. Maybe "target" would be more suiting here?
I think the spell is just not working or you're missing a requirement, such as OBSE or an OBSE plugin for example. Is there any cause for not giving a link or telling a name to search for the mod in question?
-
You're talking of normalmaps here, that's the "..._n.dds" files. Interpolated Alpha is just 1 of 3 DXT compression types DDS files can be stored in, though the most used for normalmaps.
Anyways, the Alpha Channel, i.e. transparency of the normalmaps defines how much light the object reflects and where. Completely opaque (should be bright white in the alpha channel) means it will reflect massively, like a mirror, just without actually mirroring anything, while completely transparent (pitch black in alpha channel) doesn't reflect any light at all and the mesh stays pitch black ingame, just as if it was "missing" a normalmap. If you keep your alpha channel really very dark, so it's hard to see anything of the normalmap due to its extreme transparency, then you usually have a nice, not-so-shiny appearance ingame.
Also mind the render types for the NiTexture property in the NIF. Settings like "highlight" will make it extremely reflective and shiny, although even here the normalmap's alpha channel has the last word in the matter "how much".
A material like "EnvMap" (environment mapping) obviously will also cause certain shinyness and reflectivity, but again, the alpha channel of the normalmap defines how much.
Storing normalmaps in DXT1 or any format without alpha channel might work and give you no shine at all, but it could also go wrong and give you extremely shiny or pitch black meshes. Which of these happens is bound to factors I'm not aware of as of yet, so it seems to be pretty random still. Thus it's best not to store normalmaps in formats without alpha channel to begin with. Just playing safe.
-
You were talking of purple arms and FCOM items causing some mismatch with the bodies. This is because FCOM by default ships with models made for Vanilla bodies. You are using Robert's Male, if I got that right. That's the source of the mismatch between the bodies and the FCOM items for one. Purple arms to me doesn't sound like something happening when nude (then it'd surely be purple upperbody or purple everything), so again the items are to blame. It is a common issue with Robert's mod and items for Vanilla bodies. Sometimes the body and the clothing disappear entirely, sometimes bodies become purple. Especially when it's on a custom race which was created for Robert's Male only and has no texture support for Vanilla bodies. Vanilla bodies need 4 different textures, 1 for each body part, while Robert's bodies only need 1 for all. Those custom races now only have this 1 texture file (for the foot slot, as this is the slot used for full-body coverage in the body mod) and accordingly miss textures for the 3 other body parts, thus they'll be purple.
I myself am not always supporting other bodies than the ones I'm primarily modding for with textures, so I know my custom races won't work on Vanilla. But I'm listing those bodies as a requirement for a reason. And for the same reason I also list Stock Clothing And Armor Replacers for said bodies as a requirement, because you always get the body from inside the items you wear and should not wear any items made for the wrong body accordingly.
If you mean me with the profile picture, that's my own race, the Anthro-Dragons. I'm still working on them, so there's no real finished-up release anywhere to be found, yet. But I was forced to get my files somewhere safe or loose everything half a year ago when my laptop was on the verge of dying, and people already kept asking for me to release "what I have so far" so they could figure out themselves how to make use of it, so I uploaded everything here to the Nexus, creating the semi-official v0.0.7 pre-beta test-release. It's a fully working mod, a complete race, just lacking quite a lot of content still and my scripts need some serious fixing/improvements. Nevertheless the feedback I received so far was very positive, people seemed satisfied and enjoying it, as incomplete as it is, and the information I got from them helps a lot in ruling out the last flaws and overall improving it now that I can do at least "some" modding again, finally.
As for the head issues you're mentioning I've got no idea what could be the cause. Usually body mods are not affecting heads or faces, so it shouldn't be related to Robert's Male. Well, apart from the eye issue discussed here already, of course.
-
Using FCOM and Robert's Male Body Replacer makes it necessary for you to also download and install the Armor and Clothing Replacers for FCOM, as FCOM by itself includes new items made for vanilla bodies, which will not work right with Robert's bodies. If there are none to be found for FCOM itself, you'll need the ones for OOO (if any), MMM, Fran's, etc., whatever's part of FCOM basically. This is the case for "all" body replacers.
roberts male body and beautyful people v22 eye problem
in Classic Discussion
Posted
Just don't use both, the MaleBodyReplacerV4.esp "and" the BeautifulPeopleV22 - MaleBodyReplacerV4.esp as this will cause exactly this issue. Use only the one fitting your installation, that is the BP one, only if you're having BP, and the regular one otherwise. Installing from an OMOD they will "both" be activated by default.
The V5 beta doesn't include both, only the regular one, so that was the fix.