z929669

STEP continues to assist Skyrim enthusiasts in enhancing the vanilla experience. However, STEP has not consistently addressed a lighting/weather solution to top off all of its existing visual enhancements. The reason being that lighting and post processing both can have dramatic impacts on each other, and there are many solutions for each with a near infinite array of possibilities. Couple this with the subjectivity of lighting and PP, and it gets pretty difficult to decide upon a single Baseline STEP solution. We have an admin discussion about an official STEP lighting solution and if we should break down and support a default lighting solution to round out the STEP experience. My answer is "yes", and I think most others feel the same way. The trick is to decide on which is the best Baseline solution. To make the task of deciding more efficient, we are bringing the conversation here, in the public forum, to help arrive at a solution. The task is greatly simplified by the STEP Mandate (enhance the aesthetics of vanilla Skyrim). Thus, all of the more "creative" lighting solutions are non-starters. The goal then is to use the simplest and most efficient solution that does not change the sort of fantastical vanilla lighting style, but rather enhances this experience and corrects any of the more obvious issues with vanilla lighting and shadows. Here are the rules: No ENB shall be part of the Baseline lighting solution for STEPVanilla light levels should be fairly well approximated (i.e., no darker dungeons/nights)Vanilla style should be preserved as much as possibleVanilla lighting inaccuracies and inconsistencies should be 'fixed'Performance impact should be minimalThe main contenders are ... No lighting adjustments (the present state)RLOEL&FXRelighting SkyrimClimates of Tamriel... awaiting community feedback .... See the stickied threads at top of Mod Suggestions Forum for details

@ torminater Are you are running a high uGrids? Did you get crashes associated with the logs posted above? They all have the same ending ...

Correct (*_n.dds) ... Yes, reducing normals causes slight blurring, but not really noticeable, and the color map retains all of the detail, which helps. I never go under 1024 for normal maps, no matter what the size of the model, and I never constrain texture size as a percentage. Rather, I use the 1024x1024 cap. The filter on the [browse] tab should be used to selectively process textures. You can also type in custom filters (don't forget to hit [Apply] after each filter modification). Along with settings under [ignore] (main menu), you can devise efficient algorithms to get the results wanted in the destination directory. @Kelmych Edit the guide as you see fit. Better to have correct info out there than not.

I had no interruption, but I may not have been on at the time (or may not have noticed).

120 GB Samsung 840 SSDs on sale from Tiger Direct right now for $79 each (limit 2) Here is the link

The BSAs are irrelevant, but Steam will reacquire if you let it. As far as the rest, I am not sure what you are asking. The vanilla textures fix never included the DG and HF DLCs.

bummer. Get some sleep, drink a ton of water

It looks like we will be good with SFO overwriting/overriding and using both. Is rendering controlled by the ESPs?

Updated to v1.6 today.

rpsgc needs to recreate him/herself as "AntiFarlo" and register to all of the same forums :P

I have long verified that this is true. The trick is knowing how to spot changes to INI structure and what they mean. Sometimes, very strange things can happen, but you just need to know what of the current INI settings are causing the issue and reset those values. It is just a matter of a lot of trial and error.So you're saying that adding the updated DLL also adds any missing parameters to the enbseries.ini file? That's how I'm reading this and this doesn't seem likely as it would need permission from Windows to modify a file that is in it's installation directory. From my 8 hours of testing a few weeks ago, I can confirm that popping in a newer DLL doesn't add new parameters to the enbseries.ini file on my system. The new parameters are present in the DLL file, but would not be in the enbseries.ini file unless they are added manually. In many cases, Boris's updates only include tweaked parameter settings and not new parameters. The result of adding in the v0.139 DLL into the older SkyRealism version that used v0.119 was a fish bowl effect with the lens in interiors because the new parameters for interiors were not present in the enbseries.ini file.Not necessarily. If you replace the DLL with something that uses a new parameter not located within the INI file, then once launched, the default configs for the missing parameters will be populated within the existing 'outdated' INI. I have UAC disabled, so that could be one reason that you may not have seen this.With no UAC I could see this might happen, but usually Windows protects these files even without UAC...not to mention if you have a good antivirus, it should pick up on this with an alert. Here's that fish bowl effect: This is the Camara settings. I don't know much about those, but try disabling as a first test.

I updated the format a bit, that way we don't need to change the notes when we release. This is also why I suggested making a separate guide for it, because clicking that link while on the guide will simply jump you up above the tables.Yes, I had intended it as a link to that section of the devguide, which should remain fairly consistent. We could also add logic to STEP:Main to handle which version of that Guide section to link to, depending on if it is from the dev or the current release.

Thanks SSL. These should be reported to BOSS so that the BOSS notes reflect the need to clean. We also should add notes to clean these on the mod pages (see BDS notes for the format I am using)

I have long verified that this is true. The trick is knowing how to spot changes to INI structure and what they mean. Sometimes, very strange things can happen, but you just need to know what of the current INI settings are causing the issue and reset those values. It is just a matter of a lot of trial and error.So you're saying that adding the updated DLL also adds any missing parameters to the enbseries.ini file? That's how I'm reading this and this doesn't seem likely as it would need permission from Windows to modify a file that is in it's installation directory. From my 8 hours of testing a few weeks ago, I can confirm that popping in a newer DLL doesn't add new parameters to the enbseries.ini file on my system. The new parameters are present in the DLL file, but would not be in the enbseries.ini file unless they are added manually. In many cases, Boris's updates only include tweaked parameter settings and not new parameters. The result of adding in the v0.139 DLL into the older SkyRealism version that used v0.119 was a fish bowl effect with the lens in interiors because the new parameters for interiors were not present in the enbseries.ini file.Not necessarily. If you replace the DLL with something that uses a new parameter not located within the INI file, then once launched, the default configs for the missing parameters will be populated within the existing 'outdated' INI. I have UAC disabled, so that could be one reason that you may not have seen this.

I have long verified that this is true. The trick is knowing how to spot changes to INI structure and what they mean. Sometimes, very strange things can happen, but you just need to know what of the current INI settings are causing the issue and reset those values. It is just a matter of a lot of trial and error.

The RefSkope route seems as simple as it gets. I am sure any of the seasoned modders could whip this up using that as a model.

And finally, anyone running STEP can simply install the TPC last. If using a decent mod manager, one could easily switch between the two (with/without TPC).

Very good info Kemlych. I still have a lot to learn with regard to CK and TES5Edit, but things like this help me get more comfortable with those tools. You're right, it's not a simple process, but I certainly appreciate any knowledge and I'm sure it will be useful for me I can reciprocate a little. I know how to identify what texture file a mesh uses, but only using NifSkope. An in-game solution would be ideal, but alas I doubt that will ever be possible. Based on your \landscape\rocks\rockM01.nif example, if you open that file in NifSkope, you can click on the mesh in the viewport and the relevant "NiTriShape" will be highlighted in the Block List. Or you can just select the "NiTriShape" if you know what it is (in this case it's the only one). From there, you can expand down to the "BSShaderTextureSet" under "BSLightingShaderProperty". Then at the bottom, under Block Details, you can expand "Textures" and in this case you will see it's associated with \textures\lanscape\mountains\MountainSlab02.dds and \textures\lanscape\mountains\MountainSlab02_N.dds. We need RefScope for Skyrim ;) This solution is soooooo great and so possible for anyone that understands the CK. Just download the mod and emulate the same behavior in Skyrim. I'd try to figure it out, but I am no natural scripter. Too much stuff I do know how to do that needs doing.

You could go into Nifscope to look at the references in the NIFsEDIT: don't mind me, I should have read past this post

Yes, Tech has been a good sport seemingly in the face of the a bit of hostility delivered with lethargic indifference ...

The description page mentions version 1.4 of RaceMenu which has fixes for the weapon disappearing and, it looks like, the problems with Apachii Hair and switching between male and female races that Neovalen mentioned as well as other improvements and fixes. It says the updated version is written but awaits SKSE 1.6.7 .I seen that but there's no news on when that will be released on the SKSE website.There must be an applicable pre-release then ...

I suspect that it is a quick fix to the ESP, so let's give it some time. Possibly, there could be other issues though ... I'll look at it when I have time tonight or tomorrow. Thanks for reporting, and anyone interested in testing may test, but it would be helpful if they enter in their system specs and meet the benchmark guidelines in the 2.2.1 Guide.

I must congratulate Razernok in at least maintaining his cadence and not lashing out against the glaring posts. Seems a bit Asperger's, but that is OK. I can attest to the difficulty of getting ENB to look good, particularly under Crossfilre or SLI. I must say though that Unreal's shots, while gorgeous are not realistic IMO. They look like beautiful graphic landscapes to me (wait ... :? ) I am running pure STEP right now BTW, without any ENB, and it looks really good, so a lot of what results can also be dictated by the graphics hardware and driver settings (My pure vanilla screens are posted in this gallery (using SFO variations).