z929669

Yes, that is the best option, since it fits with all of the other TSN in the game (DXT5 since there is an alpha). We could go 8888, but that would be disproportionate. I am not clear as to why there is no A5R5G6B5 option, but I assume that there is a logical reason (but that would still be unique to this one texture among all TSN in the game). Hmmm, I am not seeing that. Did you edit this page? (I added the three missing placeholder.txt lines and sorted them alphabetically)

The new package should not be gray. The original can be removed from Bash Installers.

Great, thanks for confirming. Makes sense to keep the original DLC versions. EDIT: Several more TXT files: textures\actors\dlc02\placeholderfile.txt textures\dlc02\architecture\placeholderfile.txt textures\dlc02\clutter\placeholderfile.txt Also, the following directory can be deleted: textures\dlc02\markers\ I will add these (plus all updates to date) to a current version of the wiki BAT script. This way we can see all of the changes, and you can use that as a source for the files. EDIT2: Here is a link to the maintenance pages for this work. Following is my proposed nomenclature for the files. Feel free to change them, but also do the same for the wiki page names for consistency. (I added the above updates already, but otherwise copied over your updated file contents to the wiki). 01_ReadMe-HRDLC_Clean.txt 02_ReadMe-Pre-Optimization.txt 03_Readme-VanillaFolderArchive.txt 1_HRDLC_Clean-START.bat 1_HRDLC_Clean.bat 2_Pre-Optimization.bat 3_Compress-7z_in_folder.bat 3_Compress-7z_in_path.bat

@Kelmych I found a problem with the HRDLC. HighResTexturePack02\textures\dlc01\architecture\snowelfruins\seruinsmarble01_n.dds ... is DXT5, but it is lacking information that should be present (see seruinsmarble01_n.tga, which is adjacent). I have found that the only way to get a proper result is to use the source TGA to manually compress to DXT using the preview tab in DDSopt. It turns out that DDSopt will not process this texture correctly (it seems to only rename the file to use the DDS association without changing the actual format). Perhaps there is a bug with automated handling of TGA, but even with INI edits, the automation will not convert the file properly. You need to convert as a single case in the Preview tab. These INI edits do not work as expected: dlc01\architecture\snowelfruins\seruinsmarble01_n.tga=DXT dlc01\architecture\snowelfruins\seruinsmarble01_n.dds=SKP Can you confirm? Also, if there are any other TGA lurking around, we might want to check those too.

I can't download the file :( Anyway, I am hoping that going from 888 to 565 (still uncompressed) will be a good trade off.

You can ignore that error. the Py script has a bug. Is the text gray or is the background gray? The BCF only applies to a file in Bash Installers that matches the CRC referenced by the BCF. The result should always be a new installer package that will appear as the last in the install order.

I plan on running the updated BATs to test against my manual results. Will do this coming week sometime.

You can generate a clean save from this one. It is level 50 something I think. Mostly an early version of STEP. You can look at the dependencies in WB.

@Kelmych A wee or two ago, I had updated the BAT script on the wiki to account for a few placeholder.txt files that I found in dlc01 and dlc02 directories. D1d you get those into your new BATs? Also, I have not confirmed my treatments of the HRDLC terrain normals yet ... have you used that treatment and tested yet? ALso want to deal with the rest of the DLC standard-res textures ... assuming the same treatment as Skyrim - Textures will be suitable.

Could you specify that tweak for clarity? This one will likely not be in v2.3.0. For the time being, it is not in Core.

I agree. Thanks everyone.

No, actually, it is not. You misunderstood the poll. It's basically a straight vanilla vs modded comparion. The reason why there are more than two options was because the mod has multiple optional variants, and the one that is the most popular is the one that will be recommended by STEP. If you add the 2 votes for Modded without any optionals, you get 7 votes for modded, over 4 for vanilla. That's a 3 vote difference, and that's enough for it to get into STEP. The poll asks users to pick their favorite single variant. Vanilla has the most votes of any single variant (and is better IMO). The non-vanilla variants should not be combined since they are each different. All we can say is that 7 people prefer some non-vanilla option, whereas 6 prefer vanilla. No single non-vanilla option wins. I don't think a retex makes sense unless there is a good reason for it. The difference alone is not significant enough to warrant this one, IMO, and unless there is some kind of quality improvement or performance enhancement I am missing, I don't see why this one should be Core. Let the poll speak for itself if my reasoning seems flawed, right? EDIT: I'll bet that most of the highly-qualified texture artists would agree that vanilla is more meticulously crafted upon close inspection ....

It was dropped from Core.

Robocopy is in System32. About the path, should I just type ''echo %path%'' in cmd(as administrator?) or something else, too. What should I do check when I run the command?Should Robocopy.exe be in SysWOW for 64 bit? Pardon me If this is a stupid question. There's much I don't understand.Yes, it should be in both System32 and SysWOW

It could be that he needs to explicitly run "robocopy" before every command. Perhaps it is not in his Path? Check if robocopy.exe is in C:\Windows\System32\ and that this is in the PATH (type #env:path in a Windows Powershell (or echo %path% in cmd))

No, thanks though. Stopping and I are handling the dev and management, respectively. Hopefully, this will happen soon, depending on our availability for development and testing of the server instance (which is necessarily a security-sensitive realm of activity).

Then why have the version system at all? The current setup fools people into thinking there is such a thing as STEP 2.2.6, but there isn't. If you don't keep changes and the version number in sync then other than looking all official what is the point of the number? You should just ditch the version scheme because it's totally meaningless at the moment and serves only to confuse people. Our version system makes perfect sense. As you've already been told by myself and Z, this release is a bit different than other releases from the past. Small changes will be made (which are mainly corrections to the guide); however, it has been discussed and nothing major, such as adding or removing mods, will take place until 2.3 is released. I will say this one last time and any further pushing of the topic will be considered for moderation action because you have already been told several times: 2.3 is a major shift in the way STEP will work. This means there is going to be a longer gap between releases than normal. Because of this gap, the 2.2.6 release and minor updates to it are being handled differently than in the past. Any time a minor update is done, the change is posted here and on the changelog. This is our effort to keep members informed. From that point on, it's up to the members whether to implement the minor changes or not. There will be no version changes until 2.3 is released unless we deem it is necessary. Version changes come coupled with a lot of maintenance in the background that you are unaware of; thus, constantly changing the version number is simply too much of an overhead when our time can be better spent elsewhere in working towards our 2.3 release. No further discussion on this matter needs to take place. ... and version numbers are necessary for keeping the community at large updated on our significant releases (as we deem them "significant"). Remember, Nexus users depend on versioning, and small tweaks to a current version are not mandatory changes but rather largely arbitrary or corrections. STEP is a dynamic-release guide to which everyone can contribute and follow strictly or loosely, not a fixed-release software dev project to which only a very few can contribute.

It looks like the diffuse terrain didn't get remipped (5093 skipped textures), by the way. Did you manually select the different categories you used? When you finished how did you repackage the data into archive files? Are you planning to do the DLC textures also?I processed the diffuse terrain along with all the rest in my final run, so they passed the verification I assume. I forgot the PNG though, so I'll need to copy those over as well as the interface textures that make sense. It may be a good idea to put anything like these in the DDSopt INI so that you don't need to treat them in your BATs. I have yet to test everything and confirm the results I expect. I ran as many runs as you see logs using filters applied manually. Just repackaged into 7z fast/non-solid. Still have not messed with the DLC other than HRDLC. Part of the reason for the new batch file is to automatically take care of any direct copies like the .png files so it doesn't require a separate set of user steps. It also eliminates the need for special handling to eliminate any text and other non-texture files since they are never copied from the extracted BSAs to the folders that DDSopt itself uses; DDSopt runs on some temporary folders that contain only texture files and it doesn't run directly on the Vanilla Extracted folder. Which interface textures should be copied over directly, or is it best to just put them in ddsopt.ini; I expect the latter is the better approach for these if they are .dds files? I think that most of the interface directory does not need optimization if for no other reason than these textures appear only in the "mini-game" interfaces, where mip-mapping isn't necessary (no angular/scalar changes) and the loaded texture resources are very limited. I would consider adding everything in this folder to the INI (unless there is something that I am forgetting about). I had use your first "revamped" BAT release from last week, and it worked like a charm, so if you are adding functionality or efficiencies that aren't breaking anything you had set up previously, it should work fine. I had looked into the possibility of adding user-prompted input dialog on the command line to allow people to input custom source and destination directories. This would work well, but I stopped short of this for the time being. Still a possibility though. When I ran the BAT, I changed the folder references to my custom directories, and it worked as expected. I am 99% certain that the issue is in your folder names or locations and/or the directory location of the BATs. Understand that "%cd%\" refers to the current directory. Also, be sure that whatever text editor you are using does not add/remove any of the line breaks or add any funky characters when copying from the Wiki (i.e., use Notepad++, TextPad, UltraEdit, etc and avoid Windows default text editors). @Kelmych We may want to upload the BAT files within an archive that will construct the proper directory structure when extracted. This would alleviate any copy/paste issues people could have.

2.3 is a ways out yet. We need to focus on building a new server node first. This will be transparent to the community, but it is a requirement prior to our implementing the infrastructure to support 2.3. Hopefully, we will have the new server instance up by end of the month.

The BCFs can be removed using the "Edit" link on the mod page. Anyone should be able to do this.

It looks like the diffuse terrain didn't get remipped (5093 skipped textures), by the way. Did you manually select the different categories you used? When you finished how did you repackage the data into archive files? Are you planning to do the DLC textures also?I processed the diffuse terrain along with all the rest in my final run, so they passed the verification I assume. I forgot the PNG though, so I'll need to copy those over as well as the interface textures that make sense. It may be a good idea to put anything like these in the DDSopt INI so that you don't need to treat them in your BATs. I have yet to test everything and confirm the results I expect. I ran as many runs as you see logs using filters applied manually. Just repackaged into 7z fast/non-solid. Still have not messed with the DLC other than HRDLC.

Sounds great. Could you begin your work on the wiki under your User namespace (click on your user name in the upper right of the wiki)? Otherwise, just write it up in text format and post on this thread, and I will post to the wiki to get you started.

google AMD and enter your info into the form ... are you using a laptop? Drivers for some cards need to be "customized".