z929669

When you invoke TexGen from MO2 and the TexGen window is shown, set the path to D:\DynDOLOD\TexGen_Output Did you bother clicking the link in the error message?

This issue was also discussed here on the CMoS topic with some potential things to check or consider in following posts.

These are all Py files. Did you recently upgrade Python? I don't know which Py version is expected but typically, applications either require Py 2.72 (IIRC) OR Py 3.x. Both can exist on the system, but one will be considered the 'default' Py installation. This can be changed by adjusting some OS/Py env variables I think. You can also try uninstalling and reinstalling MO, which should configure or reset these prerequisites.

No FO4 XP here, so considering that for this particular scene ... Best vanilla-friendly lighting fix: Thaylar Best overall aesthetic + fix: Lightweight Lighting then Thaylar then Aurelianis ... but that combo is a departure from vanilla. I would call it a fix though, because vanilla, Thaylar, and Aurelians are all waaaay too bright. Unless there is a gigantic, bright moon in the sky, it makes no sense unless it's necessary to have things this bright at night to play the game. I want big differences between day/night in any game, and Bethesda seems to love overly-bright nights and dungeons/caves in all of their games. Meh. If FO4 is known for its extremely saturated look then maybe Lightweight Lighting then FPSL then Aurelianis is a good choice, but it's a huge departure from vanilla, and I think the colors are waaaaay too saturated for my taste. The spotlights are much too cool in contrast with all other lights ... opposite the color wheel almost. Whats with that spotlight at top of stairs? Is it being cast from the post above and off screen? If it's supposed to be coming from that little spotlight pointing away from Nuka-World, then that needs fixing. Sorry for the crappy drawing:

Please use the YT tool with the complete URL next time. If it's a EVLaS issue, I haven't seen it, so more likely something not playing nicely with that. I recommend you post about this on the EVLaS Nexus page or search that forum for clues.

You should still be able to get a optimal near/far match with or without CG at all ToD under 1.6.xxx (DynDOLOD grass mode 1) by optimizing the TexGen brightness and the DynDOLOD backlighting settings, but it does require time and testing, so I understand it's likely overkill for your playthrough. After all, it's really only the tundra that grass can be clearly seen at distance and the noticeable loaded/LOD band becomes more obvious at certain ToD. Those settings I posted are optimized for Cathedral Landscapes, and it did require a lot of LOD regen and testing to find them.

My pixel trigger area and top padding was significantly bigger than the doc suggested, I think. My trigger is 32x32 px and all the way in the lower left corner @ 127/127/127. My top padding is 24 px ... just checked, and these absolute sizes appear to be fine for both 1K and 2K textures. I'm not sure if you are running 1.5.97 with NGIO and extending grass or if you are using 1.6.xxx and LOD. For the latter, your LOD grass won't react to light in the same way as the loaded grass, and this dark band looks like that. I set all my T/B DynDOLOD brightness at 0.500 , since I want to keep the native colors in my LOD grass and use TexGen to control brightness. This is for Cathedral under Step: ComplexGrassBillboard=5 ComplexGrassBacklightMask=25 ;try 0/50/100 to see what works best for your setup ... be sure to check under clear weather (TU is the least forgiving so best for testing. Some cloudy weathers are also unforgiving) and at dusk/dawn as well as noon. Unfortunately, you need to rund TexGen/DynDOLOD for each variation. I suggest doing so three times and placing the outputs in 6 different mods to test all at once. There's also the ENB-CG settings to consider. This won't impact LOD grass. This is how our ENB is set up (ENB gurus' input was provided for these values): [COMPLEXGRASS] IgnoreWeatherSystem=false IgnoreWeatherSystemInterior=true ApplyToAllGrass=true ApplyToBasicGrass=true EnableSpecular=true EnableSubSurfaceScattering=true EnablePointLights=true EnableInterior=false SpecularMultiplierDawn=1.0 SpecularMultiplierSunrise=1.0 SpecularMultiplierDay=1.0 SpecularMultiplierSunset=1.0 SpecularMultiplierDusk=1.0 SpecularMultiplierNight=1.0 SpecularMultiplierInteriorDay=1.0 SpecularMultiplierInteriorNight=1.0 SubSurfaceScatteringAmountDawn=0.2 SubSurfaceScatteringAmountSunrise=0.4 SubSurfaceScatteringAmountDay=0.5 SubSurfaceScatteringAmountSunset=0.4 SubSurfaceScatteringAmountDusk=0.2 SubSurfaceScatteringAmountNight=0.2 SubSurfaceScatteringAmountInteriorDay=0.2 SubSurfaceScatteringAmountInteriorNight=0.2 BasicGrassSSSAmountDawn=0.2 BasicGrassSSSAmountSunrise=0.2 BasicGrassSSSAmountDay=0.2 BasicGrassSSSAmountSunset=0.2 BasicGrassSSSAmountDusk=0.2 BasicGrassSSSAmountNight=0.2 BasicGrassSSSAmountInteriorDay=0.2 BasicGrassSSSAmountInteriorNight=0.2 BasicGrassFakeLightDawn=0.0 BasicGrassFakeLightSunrise=0.0 BasicGrassFakeLightDay=0.0 BasicGrassFakeLightSunset=0.0 BasicGrassFakeLightDusk=0.0 BasicGrassFakeLightNight=0.0 BasicGrassFakeLightInteriorDay=0.0 BasicGrassFakeLightInteriorNight=0.0 FakeLightDawn=0.1 FakeLightSunrise=0.2 FakeLightDay=0.1 FakeLightSunset=0.2 FakeLightDusk=0.1 FakeLightNight=0.0 FakeLightInteriorDay=0.0 FakeLightInteriorNight=0.0 SpecularPowerMultiplierDawn=1.0 SpecularPowerMultiplierSunrise=1.0 SpecularPowerMultiplierDay=1.0 SpecularPowerMultiplierSunset=1.0 SpecularPowerMultiplierDusk=1.0 SpecularPowerMultiplierNight=1.0 SpecularPowerMultiplierInteriorDay=1.0 SpecularPowerMultiplierInteriorNight=1.0

If you want someone to help, you should provide information like how to reproduce your crash. What exactly did you do or change that is resulting in your crash?

Discussion topic: Oxygen Meter 2 by Powerofthree, OsmosisWrench Wiki Link This is a revised version of Oxygen Meter (Powerofthree) that uses a custom widget rather than the enchantment bar widget, so it has better compatibility. It also integrates seamlessly with Dear Diary also in testing.

It's still best to create these as distinct mod topics, linking them in the descriptions of each. In this way, they can each bevdiscussed in their own right and more easily be added to a release, because that also creates the wiki link s needed to create the wiki mod pages used in the guide.

NG version requires that all mods are cleaned of errors. Run QuickAutoClean on all mods indicated by LOOT. We have some instructions on this here.

Thanks for this. Looks like it's all working correctly with the patch added back as expected. Sorry about that!

The OP posted prior to my goof, so that's a different issue most likely related to not strictly following our guide.

Actually, I think I see the problem. The CACO patch was mistakenly removed (by me) from the 2.2.0 KPH instructions, because it's no longer a master of our CACO patch. I will revert this last update, so everyone revisit Kryptopyrs Patch Hub and check that each was installed.

Please disable that patch and test again, because that patch should be 100% redundant with our patches, which are doing the same thing. Test using the same save you loaded after installing that patch. If you can confirm, then we may have missed something in our patch that I can address. Test with a few cooked foods and others. If you can get the Editor ID of the food via More Informative Console, that would be ideal. Just drop it on the ground and check that way via the console. Are you running survival mode or not?

Seems like an issue maybe with the patch, since three people have confirmed independently. I've looked at the Step Patches in general around this, and I don't see a problem. It should be working fine. Do any of you have plugin deviations from the Step 2.2.0 guide? If so, what plugins? Most importantly, please give me a specific example: What food item? (Record ID or Editor ID preferred)

Yes, this is how it works, because the alternative would completely break the usefulness of the app. A simple test would be to create a small 127/127/127 default-RGB image and save it. Then analyze the values using some other application (e.g., open in a browser and use the dev tools to sample color, or open in Paint.net). Then you could test what modifications to that file might mess with this. I have NEVER had my hex color value mysteriously changed by any app unless I modified something else in the image that included the pixels I didn't intend to change. Now, the impacts of downstream apps like the game or the mesh on the rendered values is another matter, but I think everyone agrees that their digital specifications are expected to be maintained with something as basic as color, regardless of the rendered result on the monitor or in-game. The target pixel resolution does depend on the total resolution, but I recall it not being a specific size or proportionate-size. Same with the top padding on the normal. I just made both big enough according to my eye. All of my assets were either 1K or 2K with like two 4K stragglers I did manually. This is my Ps macro for the trigger pixel area, so it looks like I use absolute size and position using a fill layer, depending on resolution of the image. Then saved as PNG downstream after creating the top padding in a similar manner, so all was merged on save. Building the atlas was a separate action later in the process: That's just the way I did it, and it's likely not optimal either.

Looks good! So I'm not clear on Ps "messing with the trigger area" ... the neutral gray (15/15/15 or 80/80/80 or 127/127/127) would only change if the trigger area was created and the entire specular map was changed. I never had such an issue in Ps, and I was using Ps RGB default RGB (not sure what it was). I don't think it matters as long as the trigger-area color modification is basically the last step in modifying the specular. Then simply copying it to the alpha of the normal just 'works' ... so maybe your workflow for these two textures was a bit different than the rest (maybe the first two normals you created?)? Yes, neutral gray < 127 reduces the ENB-CG effect proportionately, and values > 127 are invalid, so that makes sense. YTou finished this pretty quickly, so kudos on that. It took me waaay more time

That pixel trigger area is only to ensure that ENB can identify it as a normal map in case the normal map has some unexpected noise in that 'testing' part of the normal. I think 127 gray is the baseline of a 'blank' normal map. Lowering that value to 120/120/120 also works, but I believe it basically reduces the 'weight' of the ENB complex grass effect like SSS

Do you know the exact meshes involved for each and which grasses each uses? How many different grass/mesh combinations have this problem? Have you tested Skurkbro's is using those same meshes? Compare each impacted grass texture with Skurkbro's and that each one from that mod corresponds to your modified versions in terms of resolution/dimensions/atlas. The axisgrass seems to be rendering only the normals, but I can't tell if that's the case with the other grasses affected. Test if replacing only the affected grass textures in your mod with Skurkbro's versions fixes the problem, with no other changes at all. If they are using the same meshes, then the issue is the textures, and I would guess it has something to do with NiAlphaProperty on the meshes and how that plays with the alpha test threshold of the textures. If resolution is exactly the same for diffuse/normal/atlas for yours and Skurkbro's, then we can't blame UV mapping. Grass meshes are odd in that they almost never render the texture in NifSkope in my XP. How did you get the textures to render in NifSkope? Did you alter the NiAlphaProperty value in the mesh?

If Skurkbro's specular is overall brighter, the the diff will be in the normal alpha and likely will have more reflectivity. As I mentioned previously, I don't think the shapes make much difference with respect to flat things like leaves. The main difference is in the 'direction' of the 'light' (shading) creating the 3D. As long as they are all consistent, it shouldn't matter ... it may not even matter that they are consistent.

I cleaned up all of the noise on the original alpha cutouts, many of which had lots of holes (white specs). So most of the problematic alphas were cleaned of specs, edges corrected where necessary, and saved with aliasing. EDIT: I wound up preferring the aliased over anti-aliased to eliminate some of the edge artifacts downstream in the process and would up using these as the final alpha, too. Ideally, I would have preferred to use very slight anti-aliasing, but the source was just too limited. Example of obvious 'holes' that would show these specs on the mesh in final render in-game. There's a lot of small ones that can't be seen easily at screen-capture resolution in many of the source files (2K): Before --> Cleaned Using the corrected alphas, I cut out the diffuse to yield a transparent background, inverted the alpha mask, and used Flaming Pear / SolidifyC filter in Ps to yield a more 'bleed-proof' background to prevent artifacts at varying mipmap levels related to alpha test. Note that I also very-slightly darkened the resulting background, because grasses in this game look better this way, because higher mip levels (farther away) better match the first level (up close). After I had the final diffuse, I saved out the diffuse grayscale as PNG (cutout only with transparent background). I probably changed the B/W curve a bit to yield slightly higher contrast. This was the basis for the normals and specular. Flaming Pear (Free Plug-ins at bottom of page)

Exactly. Finalize LO, sort, and examine all of the conflicts (xEdit red/orange colored records), "Copy as override into" and "Copy as deep override into" final patch. I usually "Hide no conflicts" to simplify things, and sometimes copy from something like vanilla or USSEP, combining various records from different sources into one. I feel like when using a patch-making helper tool, you still need to check all of the records anyway, so doing it manually just saves a step for me. It can be a bit of a mind twist at times, but I just keep plugging along, saving as I go.

As Mouse states, the manual process patches that which should be patched and nothing else. Typically, most plugins are fairly limited to specific goals/changes and don't require patching unless they touch all kinds of records (land/combat/magic/crafting/economy overhaul mods). Of the 300-ish plugins in Step SSE (with Anniversary Upgrade), only about 50 are masters to our conflict resolution patch, so about one sixth. My guess is that this is fairly typical for an SSE-AU build, and non AU builds probably have more like one-tenth the total as masters. It will vary quite a bit though, depending on your plugins and desired outcome. With the ability to ESL-ify and merge plugins, the limits mentioned can always be easily avoided, even with a ridiculous plugin count.

Nope. We do nothing but manual patching, since it's really the only way to control everything as intended. Basically one single patch for the entire sorted plugin list. I think it's less work actually ... unless you completely trust your patching algorithm (WB, Synthesis, or otherwise). The only reason you would need dozens of individual patches is if your assortment of plugins is always changing. Then it makes sense to have patches with only one or two masters rather than like 20+ masters.