SKYRIMLE Optimized Vanilla Textures (by tony971)

[TechAngel85]

I don't use the Optimized Hi-Res textures mods, but if I'm not mistaken the Hi Res DLC are not a 100% replacement for all vanilla textures so there are still benefits to using optimized vanilla textures.

[tony971]

There are ~5000 files in the vanilla textures folder that aren't replaced by the High Res DLC. And since the mod is using the skyrim.ini settings to load, it will automatically be loaded before Vano89's mod.

[GunerX]

@Tony

 

I read everything on your nexus description page, but am looking for further clarification as to the install order.

I assume I should untick the optimized files that STEP had us create and instead use your optimized BSA.

Assuming I assumed correctly, this is the install order I have.

 

 

 

 

Is this correct?

[tony971]

I've put better instructions for MO on the description page (ones that don't require ini edits).

[Kelmych]

In case there are any questions about the changes that were made, the details of what the STEP Skyrim vanilla batch files and associated processing instructions changed and did to the vanilla textures is shown in Q3 here .

[EssArrBee]

I've put better instructions for MO on the description page (ones that don't require ini edits).

You can also included INI edits in a mod if they are necessary.

[tony971]

You can also included INI edits in a mod if they are necessary.

I would but I'm no good at making batch files. Especially since the ini files could be in multiple locations. And I don't want to include full inis. That's a bit imperial for textures.

[EssArrBee]

Just look at the last release of USKP and it comes with an INI edit, so you could implement it the same way they did. It is really simple and the game actually merges just the tweak you make.

[alt3rn1ty]

INI edits done the same way as USKP also take priority over default INIs

 

They do not change skyrim.ini or skyrimprefs.ini, but the ini named the same as your mods esp and bsa will be loaded by the game last overriding the games default ini settings files

 

And just like "Load Order and You", if you had two mods both with custom ini's in your data folder, and both of them edited the same settings .. Loaded last wins if they have different values for the same setting.

 

 

The only thing with your mod .. You would want it to load early so that users can have mods with their own textures win over your all encompassing texture overhaul. So there is potential for other mods with ini's to override your settings even though its a bit unlikely. Also give the guys in the LOOT topic a request too, to give your mods esp a negative priority, and a Load After condition for Cutting Room Floor ( in case there are future developments with vanilla textures included, which you may want to optimize and include in your mod ) .. They did the same for my VRT ...

 

 

 

.. Only if you want to do it this way of course

Edited August 25, 2014 by alt3rn1ty

[alt3rn1ty]

Something else I forgot to mention earlier which I was going to post ..
 
Ethatron did extensive tests on BSAs, the results of which are mostly included in his linked documentation, but one that will not be obvious is on the NIFOpt documentation page ..
 
 

A little calculation
So lets see a little calculation for two operations of reading data from disk, uncompressed and then compressed:

• [*]Harddisk-throughput: 20MB/s [*]Memory-throughput: 2000MB/s [*]zlib-throughput: 80MB/s [*]uncompressed size: 100MB [*]compressed size: 60MB
  

This yields:

• [*]Reading 100MB at 20MB/s from disk takes 5s. [*]Reading 60MB at 20MB/s from disk takes 3s, decompressing 60MB at 80MB/s in-memory takes 0,75s, so a total of 3,75s.
  

In case the data is very small it's probable that seeking time will start dominating the times:

• [*]Reading 1MB at 20MB/s from disk takes 0,05s. [*]Reading 0,6MB at 20MB/s from disk takes 0.03s, decompressing 0,6MB at 80MB/s in-memory takes 0,0075s, so a total of 0,0375s.
  

Seeking may be as much as 0,002s. Nevertheless it doesn't change the fact that reading compressed data is faster as long as the decompressor is faster than the disk. It's a rather theoretic notion, but when using compressed solid archives even the seek-times go down as the disc-head has to reposition a smaller distance while bulk-reading from the same archive.
Also, in reality with a modern system the decompression speed of zlib reach realistic 250-500MB/s (as you can see here), which can be far beyond any SSD-speed.

 

 
( To find the above its here https://obge.paradice-insight.us/wiki/NIFopt - Scroll way down the bottom, and back up a little from there to the paragraph titled "A little calculation" )

Highly compressed BSAs are brilliant, especially for old laptops like mine which is minimum specification for this game. Just dont go highly compressing any sounds, music or scripts, Bad things happen ( Bethesda use a much lower compression ratio in their BSA's - BSAOpt as you know can squash the hell out of files much more than the official Archiver ). Textures, Meshes and Animations seem fine compressed to BSAOpt 10, anything else avoid compressing so much.
 

 

 

Edit : Probably too much information, going off topic slightly, my apologies

Edited August 25, 2014 by alt3rn1ty

[tony971]

INI edits done the same way as USKP also take priority over default INIs

 

They do not change skyrim.ini or skyrimprefs.ini, but the ini named the same as your mods esp and bsa will be loaded by the game last overriding the games default ini settings files

 

And just like "Load Order and You", if you had two mods both with custom ini's in your data folder, and both of them edited the same settings .. Loaded last wins if they have different values for the same setting.

 

 

The only thing with your mod .. You would want it to load early so that users can have mods with their own textures win over your all encompassing texture overhaul. So there is potential for other mods with ini's to override your settings even though its a bit unlikely. Also give the guys in the LOOT topic a request too, to give your mods esp a negative priority, and a Load After condition for Cutting Room Floor ( in case there are future developments with vanilla textures included, which you may want to optimize and include in your mod ) .. They did the same for my VRT ...

 

 

 

.. Only if you want to do it this way of course

My mod is ESP-less. I wanted the textures to either be a direct replacement or load immediately after their respective originals. This way updates wouldn't be needed every time the USKP team released an update. I was able to have direct replacers for the Skyrim - Textures.bsa and three HighResTexturePack BSAs, but had to make new ones for the DLC for reasons you stated. Achieving the correct load order for the DLC BSAs was done by using the skyrim.ini to load the BSAs rather than a dummy ESM file. In the end, users will have a BSA load order that looks like this:

 

Dawnguard - Original.bsa

Dawnguard - Textures.bsa

HearthFires - Original.bsa

HearthFires - Textures.bsa

Dragonborn - Original.bsa

Dragonborn - Textures.bsa

Unofficial Dawnguard Patch.bsa

Unofficial Hearthfire Patch.bsa

Unofficial Dragonborn Patch.bsa

 

Their plugins will still load in their original order, though. I've already checked for conflicts resulting from loading the BSAs in this order. There are none. The only issue is that after renaming the DLC BSA files, Wrye Bash throws a warning that the DLC are missing String Localization files.

 

Since I am plugin-less, if I use the USKP ini trick, I'll have to make 3 of them named Dawnguard.ini, HearthFires.ini, or Dragonborn.ini and use the FOMOD to determine if they get installed. But in all 3, I'll have to make the same edit:

 

[Archive]

sResourceArchiveList2=Skyrim - Voices.bsa, Skyrim - VoicesExtra.bsa, Dawnguard - Original.bsa, Dawnguard - Textures.bsa, HearthFires - Original.bsa, HearthFires - Textures.bsa, Dragonborn - Original.bsa, Dragonborn - Textures.bsa

 

And then just tell users to delete the entries for DLC that they don't have.

Edited August 25, 2014 by tony971

[tony971]

Question: does the USKP ini trick only adjust settings in skyrim.ini or will it adjust things in skyrimprefs.ini, too?

[z929669]

Dont worry about the legal stuff, it will be fine so long as every texture has had some form of process to alter them in comparison to the original .. Passing them through DDSOpt will do that even if the results are barely distinguishable

 

See this topic https://forums.bethsoft.com/topic/1481184-is-it-legal-to-edit-bsas-nifs-etc-and-use-it-in-modding/

 

My Vanilla Reduced Textures would have been pulled a couple of years ago if that was not the case :)

 

 

Edit : And if anyone does not accept CCNA's word as a BGS Forum moderator in that linked topic, tell them to read the Creation Kit EULA, its all in there ( same as it was in the Construction Set for Oblivion and Morrowind, Bethesda encouraging us to mod is beneficial to them because it increases the longevity / life expectancy of the game, and attracts far more customers buying the game as a result of seeing all the things modders have created for the game ).

I agree personally; although, strictly speaking, any distributed modification of the original textures is not legal, and Beth could legally move to act and win. Copyright law dictates that derivative work is still a copyright infringement (X + Y = X + Y != Z). One must create something completely new from scratch (X != Z).

 

That said, I also think it is 'safe' and Beth will allow it, but it would be nice to get the permission straight from Gstaff (I have a PM pending ... just sent).

[EssArrBee]

I agree personally; although, strictly speaking, any distributed modification of the original textures is not legal, and Beth could legally move to act and win. Copyright law dictates that derivative work is still a copyright infringement (X + Y = X + Y != Z). One must create something completely new from scratch (X != Z).

 

That said, I also think it is 'safe' and Beth will allow it, but it would be nice to get the permission straight from Gstaff (I have a PM pending ... just sent).

This means that SRO was never legal since it included a bunch of vanilla textures that Starac did not remove. The one thing that beth might be considering though is that you can't play the game with just texture BSAs. It's just not doable without the other files.

 

INI edits done the same way as USKP also take priority over default INIs

 

They do not change skyrim.ini or skyrimprefs.ini, but the ini named the same as your mods esp and bsa will be loaded by the game last overriding the games default ini settings files

 

And just like "Load Order and You", if you had two mods both with custom ini's in your data folder, and both of them edited the same settings .. Loaded last wins if they have different values for the same setting.

 

 

The only thing with your mod .. You would want it to load early so that users can have mods with their own textures win over your all encompassing texture overhaul. So there is potential for other mods with ini's to override your settings even though its a bit unlikely. Also give the guys in the LOOT topic a request too, to give your mods esp a negative priority, and a Load After condition for Cutting Room Floor ( in case there are future developments with vanilla textures included, which you may want to optimize and include in your mod ) .. They did the same for my VRT ...

 

 

 

.. Only if you want to do it this way of course

Shouldn't your esps be between the main plugin and the UP or after the UP? Does it even matter?

[alt3rn1ty]

@ Tony - As I understand it .. Both : So you can have a value in there that would affect skyrim.ini, and another that would ordinarily be only found in skyrimprefs.ini = Modname.ini settings override both default ini settings. I havent tested personally but it would be easy to do, and logically it makes sense ( I think I saw it mentioned on the CK wiki somewhere but cant remember where, Arthmoor confirmed it in a topic on AFK Mods ).

 

@ Z - I have seen GStaff mention it was okay before .. However memory and search fails me to find a post that was probably about 6-7 years ago.

Would be nice to see the result of that PM public instead of PM .. Could you ask him if he would be kind enough to confirm it in the link where CCNA ( BGS forum moderator ) confirmed it previously https://forums.bethsoft.com/topic/1481184-is-it-legal-to-edit-bsas-nifs-etc-and-use-it-in-modding/?do=findComment&comment=23197662, and append a reply to that topic ?

 

@ SRB - It matters that it should be positioned after the UPPs in my case, because I always also include any textures extracted from the UPPs which have been fixed, but reduced for the purpose of my mod. If the UPPs followed mine then there would be a few textures taking the VRAM count back upwards again. Although there are a couple which I dont touch, because they are the same size as I want them, or because to do anything with them would ruin them ( for example lnki textures, the manhole grating in Solstheim, and the Bridge Road Edge texture .. Both of which were a pig to figure out what was wrong with the vanilla versions, lnki did an excellent job on figuring the mipmap alpha problem out on these, and attempting to reduce / optimise these loses the fix )