MongkeQaan Posted August 2, 2014 Posted August 2, 2014 Hmm. So I used to be able to use this mod no problem, but now it CTDs everytime I try and apply a tattoo to my character. It varies when it does it, whether it is before or after I select which tattoo, but it does. I thought I did all the requirments no problem, but for whatever reason I can't get it to work correctly.
murfk Posted August 2, 2014 Author Posted August 2, 2014 Most people who have problems find that they're fixed by making sure all of the requirements are at their most recent version. If that doesn't work for you, send me a Papyrus log.
Uriel Posted August 2, 2014 Posted August 2, 2014 I modified a script a little so it will ignore the texture check if tattoo record contains a "pack" field, and "Data\Slavetats-%pack%.bsa" exists in Skyrim's folder. It seems to be working, but the only way to load a custom .bsa without a .esp/.esm file is to include it's name into Skyrim.ini's "sResourceArchiveList#" parameter. Not very user friendly unfortunately.
murfk Posted August 2, 2014 Author Posted August 2, 2014 Yeah. That's a good thought, but I don't think it's simple enough to make part of the normal process. Edit: Besides, the json files still can't be packed up, and there's not that much benefit to compressing already-compressed textures.
RustyXXL Posted August 2, 2014 Posted August 2, 2014 but the only way to load a custom .bsa without a .esp/.esm file is to include it's name into Skyrim.ini's "sResourceArchiveList#" parameter. Not very user friendly unfortunately. Users of Mod Organizer would only have to check the bsa in their Archives list. Much better than manually having to add it, but still no real option, imho...maybe at max usable as optional extra. I won't offer that, though...whoever knows enough about that topic to set that checkmark, probably knows enough to pack the textures as a bsa themself.
Uriel Posted August 2, 2014 Posted August 2, 2014 Yeah. That's a good thought, but I don't think it's simple enough to make part of the normal process. Edit: Besides, the json files still can't be packed up, and there's not that much benefit to compressing already-compressed textures. Tat textures are filled by zeros, and DDS format can't compress those zeros at all. Dunno why. BSA packing works really well: from 100mb to 10mb for example(stockings). In theory, it works better this way because only 10mb's are being read from a hard drive.
RustyXXL Posted August 2, 2014 Posted August 2, 2014 In theory, it works better this way because only 10mb's are being read from a hard drive. The faster loading brings you exactly 0 advantage, when you don't have enough Video Memory for 4k Textures.
murfk Posted August 2, 2014 Author Posted August 2, 2014 Yeah. That's a good thought, but I don't think it's simple enough to make part of the normal process. Edit: Besides, the json files still can't be packed up, and there's not that much benefit to compressing already-compressed textures. Tat textures are filled by zeros, and DDS format can't compress those zeros at all. Dunno why. BSA packing works really well: from 100mb to 10mb for example(stockings). In theory, it works better this way because only 10mb's are being read from a hard drive. That's... horrible. Shame on whoever invented that compression. Anyway, I stand corrected. If it ever becomes possible for tattoo packs to add BSAs without user interaction, I'll add support to SlaveTats.
Uriel Posted August 2, 2014 Posted August 2, 2014 Yeah, ofc. Just saying it's a good thing. In theory, it works better this way because only 10mb's are being read from a hard drive. The faster loading brings you exactly 0 advantage, when you don't have enough Video Memory for 4k Textures. Stutters. Less things to read from a HDD, less stutters.
RustyXXL Posted August 2, 2014 Posted August 2, 2014 Yeah. That's a good thought, but I don't think it's simple enough to make part of the normal process. Edit: Besides, the json files still can't be packed up, and there's not that much benefit to compressing already-compressed textures. Tat textures are filled by zeros, and DDS format can't compress those zeros at all. Dunno why. BSA packing works really well: from 100mb to 10mb for example(stockings).In theory, it works better this way because only 10mb's are being read from a hard drive. That's... horrible. Shame on whoever invented that compression. As far as I understand that format, that's by design. The compression works differently than for example jpg, and is optimized for fast loading and fast decompression. As far as I understand the Format, they compress 2x2 fields of pixels into the same space that 1 pixel would take. That's why dds files of the same dimension are always the same size, and always are at a 4:1 size ratio to the original (except dxt1, which is always 6:1, because....there's a difference somewhere ;P). You might get better results with different algorythms, but you'd sacrifice decompression speed. Stutters. Less things to read from a HDD, less stutters. Well, my hdd would be fast enough. I benchmarked, monitored etc. When I use 4k Textures I get a 95% CTD guarantee with 4k textures. wether they are compressed or not makes no difference. My Graphics Memory is at 100%, my hdd is at 50-60% max. With downconverted to 2k CTDs are not more than usual with Skyrim...every now and then one, but I can play perfectly fine in the same areas even with uncompressed Textures. My Graphic Cards Memory is at 60-80% in that setup, my HDD stays at about 50%. Well, all I'm saying is that you can't generalize it. Everyone had to fit textures to their individual systems.
Uriel Posted August 2, 2014 Posted August 2, 2014 I can't generalize what? You say there's no difference if you read for ex 500mb and 5000mb from a hdd?
RustyXXL Posted August 2, 2014 Posted August 2, 2014 I can't generalize what? You say there's no difference if you read for ex 500mb and 5000mb from a hdd? No, I'm saying that wether or not bsa compression makes a difference for the framerate or stability depends on the users systems. On systems where the HDD is the weak point you are certainly right, that bsa compression can make a difference. On systems where the issue is the Video memory bsa compression makes no difference at all. On system where the CPU Power is the issue, while the HDD can deliver the data fast enough bsa compression might actually worsen the situation.
DarkpPatinumMOD Posted August 2, 2014 Posted August 2, 2014 I cant get the new version of this mod to work, i get external option on the tattoo option, wont let met choose any body option, were do i learn to use this mod, i installed it via NexusModManager, the only working version i have is version 0.9.12.1., 1.0.0 say failed to initialize target, and 1.0.03 just set all option to external and wont let me interact with them. can any body help me?
murfk Posted August 3, 2014 Author Posted August 3, 2014 As far as I understand that format, that's by design. The compression works differently than for example jpg, and is optimized for fast loading and fast decompression. As far as I understand the Format, they compress 2x2 fields of pixels into the same space that 1 pixel would take. That's why dds files of the same dimension are always the same size, and always are at a 4:1 size ratio to the original (except dxt1, which is always 6:1, because....there's a difference somewhere ;P). You might get better results with different algorythms, but you'd sacrifice decompression speed. Sure, except they could have added a run length encoding pass afterward. That would have taken care of the problem we were talking about, and most likely actually sped up decompression. Not that there's any point arguing about this here. The format is a done deal. Oh well.
murfk Posted August 3, 2014 Author Posted August 3, 2014 I cant get the new version of this mod to work, i get external option on the tattoo option, wont let met choose any body option, were do i learn to use this mod, i installed it via NexusModManager, the only working version i have is version 0.9.12.1., 1.0.0 say failed to initialize target, and 1.0.03 just set all option to external and wont let me interact with them. can any body help me? First, make sure you have the newest versions of JContainers, RaceMenu, and SKSE. Seriously. I've had five actual bugs reported since 1.0; every other problem was an outdated or missing one of those.
NYINEGY Posted August 3, 2014 Posted August 3, 2014 I vote for bsa because it is a skyrim native mechanism ... even if all you get is saving hd space it is worth it ....the way this overlay this works makes it irrelevant once the tatto is saved and applied to character for as long as you play it does not matter where it came from bsa or dx compressed or raw dds!you can make a small tutorial on packing the tat packs into bsa format and let those who are welling to do it read it!
RustyXXL Posted August 3, 2014 Posted August 3, 2014 Sorry, I totally failed to make my Point last night, and might have sounded a bit trolly. That wasn't my intention. I simply think that bsas, as long as they can't be automatically loaded, are only fighting the symptoms of an overburdened System, and only help some of the people. So it's okay to have the option, but to really solve the Problem for the user, giving them the Option of a lower resolution might be the way closer to their real problem. Basically there are 4 major limiting factors for the fps (when looking at textures alone), if we simplify the topic a bit: Video Memory: bsa packed - no effect, as bsas are unpacked when loading the data into the ram, bsas shouldn't have any effect on the Video Memory. Offering a lower resolution - If you got down 1 "step" (for example 4096x4096 -> 2048x2048) you reduce the Video Memory used for that texture by 3/4. Thus offering a massive improvement on the Video Memory usage. RAM: A part of the RAM usually also holds some of the textures, that currently are not directly needed but might be needed later in the area. Basically the same as above, only that Access to the RAM is usually slower. HDD: bsa packed - Improvement, if Ram and Video Memory are already Overburdened and can't hold all the Textures needed. Also big improvement if textures need to be loaded on the fly, because the preloading didn't know about the texture for whatever reasons. Offering a lower resolution - If you go down 1 "step" (for example 4096x4096 -> 2048x2048) you reduce the texture usage for that texture by 3/4. More Textures can be kept in the Video Memory and Ram, and less textures need to be loaded from the hdd, possibly removing the loading stutters while playing completly. Also reduces the amount of data that needs to be read by 3/4, further improving the situation. CPU: bsa packed - Having to decompress the bsa might have a negative effect on the CPU. I have no actual data on the actual effects of bsa compression, so this is highly theoretical on my side. actual effects might vary from not noticable, to big impact, depending on the cpu used etc. Offering a lower Resolution: Shouldn't have any real effect on the CPU usage at all. There might be a theoretical advantage to smaller file sizes, depending on the users filesystem, but I highly doubt there is any noticable advantage. So to summarize: when talking about the fps bsas only have an advantage when either a) the users system is already overburdened or stuff hasn't been correctly preloaded during the loading screen. Their main uses are reducing hdd usage and reducing Loading screen times. Especially when talking about problem a) reducing the texture size where possible might actually completly solve the situation. To add to that: I usually don't think you should save to much on texture resolutions on noticable Character features like textures in our case. This of course highly depends on the motive. Tattoos that don't have a lot of small details or diagonal lines might actually not need a to high resolution. Tattoos like the coenaculi, really profit from the higher resolution, as they have a lot of fine, curved lines and small details, that get lost/jagged when you reduce the resolution. That's why I was advocating earlier that the used resolution is the choice of the artist, not the repcker/redistributer like I am in that case. But I'm straying of course again: To really solve the issue, especially on lower end systems use "low" resolution textures for landscape/walls etc, "mid" res for furniture etc. and "high" res for character textures. Note that I don't actually mean any actual values in this case, low, mid and high are just used to compare to each other. What actual sizes are to be used depends on the individual system. This has 2 main reasons: An average user will spent a lot of attention on the characters, be it human or not human. He'll spent a bit more attention on humans or "high thread" targets, but all actors are more or less comparable in that regard. He'll spend less attention on the furniture, as they are "only" important for loot etc. Lastly he'll be spending as less attention as neccessary on the actual landscape. Usually the most used textures are for Landscapes, walls etc. There are usually less Furniture Texture than landscape and even less Actor textures. So to summarize: Saving system ressources on the most used textures, which the user notices the least allows us more ressources to be used where it really matters. I hope this makes more understandable where I'm coming from... As far as I understand that format, that's by design. The compression works differently than for example jpg, and is optimized for fast loading and fast decompression. As far as I understand the Format, they compress 2x2 fields of pixels into the same space that 1 pixel would take. That's why dds files of the same dimension are always the same size, and always are at a 4:1 size ratio to the original (except dxt1, which is always 6:1, because....there's a difference somewhere ;P). You might get better results with different algorythms, but you'd sacrifice decompression speed. Sure, except they could have added a run length encoding pass afterward. That would have taken care of the problem we were talking about, and most likely actually sped up decompression.Not that there's any point arguing about this here. The format is a done deal. Oh well. Well, at least this made me read up a bit on the dds format(s), so it was at least educative...^^
Uriel Posted August 3, 2014 Posted August 3, 2014 My thought here is: with all those mods around, preloading lost it's effectiveness a long time ago. BTW, CTD's from overly highres textures are cured by ENB. You will still run slow, but not CTD.
WizzyD Posted August 3, 2014 Posted August 3, 2014 would love to see a all in one pack. or a pick and choose fomod version.
RustyXXL Posted August 3, 2014 Posted August 3, 2014 My thought here is: with all those mods around, preloading lost it's effectiveness a long time ago. BTW, CTD's from overly highres textures are cured by ENB. You will still run slow, but not CTD. Still the Tattoo Overlays won't be loaded constantly from the hdd. They'd be at max max loaded once per tat and area, and thus can't be a direct cause for a constant microstutter. A constant microstutter in regard to textures loaded from hdd is caused by an overload of your total Video buffer (in onboard Ram and Graphic Card Ram), causing textures to be dropped, and is best cured by reducing overall texture quality, starting where you notice it the least.
judge0 Posted August 3, 2014 Posted August 3, 2014 Anyone here not using RaceMenu? I have an issue where all slots on all body parts are marked External and greyed out. I did make sure to select my character first. This is on all save files as well. {even those that never had Qayl or Slavetats installed} I have not had Race Menu installed until today, and only installed to try to clear the overlays as suggested in other threads. No warpaints, some tints around the eyes, were the only things I used for character creation with ECE. Latest ECE, NiOverride 2.8.0 Tattoos were applied by Dibellan Defender mod & Qayl Version of Slavetats used for application 1.02 Doing test runs of Qayl, with version 1.2, I would do the run. Then uninstall Qayl, Slavetats & Dibellan Defender. Follow with Save Cleaner and reinstall mods. This would remove doc's "locked" tattoo. With version 1.03 of Slavetats installed, Qayl's "locked" tattoo would persist, and now all saves show "External" on all slots. Tried installing RaceMenu and setting all Overlays to "Default" {they were at "default" to start with, no idea why the case change}. Tried changing cells, to no avail. Thanks.
murfk Posted August 3, 2014 Author Posted August 3, 2014 @judge0, please send me a papyrus log that covers opening the SlaveTats menu and selecting your character. The case change is just the Skyrim engine being unable to recognize cases. As far as it's concerned "default" and "Default" are the same word.
judge0 Posted August 3, 2014 Posted August 3, 2014 @judge0, please send me a papyrus log that covers opening the SlaveTats menu and selecting your character. The case change is just the Skyrim engine being unable to recognize cases. As far as it's concerned "default" and "Default" are the same word. I solved it murfk. To clear the "External" all mods & textures that were in save have to be present, as well as . . . While all those are active (i had to install it first) run showracemenu from console and use RaceMenu to set all Overlays to "Default" save game remove mods which applied tattoos (slavetats, all texture packs, Dibellan Defender) load game with Racemenu still active, and make a new save clean scripts load cleaned save save new game uninstall RaceMenu (so my character wouldn't look like a Cabbage Patch Kid) load game, save, clean scripts from new save add mods back "setstage ski_configmanagerinstance 1" from console A fresh install of jcontainers (Apropos in my case) (although I don't know if that was actually necessary. Hope that helps someone else.
Alexsandritus Posted August 4, 2014 Posted August 4, 2014 Hello. I want to ask, why do all tattoo black? I work well colored. Please post color tattoo too, they will make every black! Thank you.
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now