Aiyen

SSL : Yes Skylight ENB supports Night vision, Both vanilla and predator vision. I use predator vision myself, and would recommend that anyday over the vanilla thingy. CJ2311: Ah yes the farting dragon! Amazeing what happens when you are bored! Hmmm I never really considered support for those mods since I do not use them myself. I am fairly certain there already are CoT patches for them though. If not then it should not take long to create. Would perhaps be something I would consider if it does not exist. Also yeah those damn vanilla tint heavy image spaces.... I am considering just doing them all and include them in my WISE patch... It is a simple enough fix to solve the darkness issue. But in order to make them really good I would have to include vanilla weathers in my weather system, which would just add another 5-7 ini´s to adjust every single time. That wont happen until I am really happy with the way it looks so I know I do not have to overhaul everything in a week... again. As for night vision all you need is the image space brightness modifier. In the default enbeffect.fx file then there is a section called APPLYGAMECOLORCORRECTION (AGCC). This is what normally forwards all the image space modifiers so take effect. The one for brightness is called _c3.w. So what you would need to add right after the color is loaded is just this color.xyz = _c3.w * color.xyz; There have also just been released a new Night vision enbeffect.fx file from some dude I cant recall... it even adds in bloom and grain etc. to the night vision.. quiet impressive really. The above just increase the brightness when you use nightvision....might implement some coloring at some point though to make it look nicer.

It does and is probably the best custom vanilla weather preset currently out there... I helped him myself implement night vision support since it is so easy to do... once you know which parameters control it. I would definitely recommend you try it out if you do not use CoT :) Also perhaps one day down the line I will find it fun to do something for vanilla weathers.... but I just get so annoyed at the lack of variation in vanilla weathers when I play. Also I would have to redo my mod list... which would take up time as well.... so many things one can do.... so little time.

My opinion of it is as it has always been... it is a nice gimick... but in general any mod that involves scripts, and involves you being at a specific spot at a specific time is not really worth it in the long run. In this case the specific place and time is also really rather limited.

The weather system I implemented is basically divided into this scheme. Clear, Cloudy, Fog, Overcast, Rain, Snow, Dragonborn, Dawnguard. All CoT weathers have been subsidivided into the first 5 groups, while the Dragonborn contains the settings for the vanilla Dragonborn weathers that are in use if you use my Dragonborn patch. So far the Dawnguard one is not released... it is ready but I want to finish up on other stuff as well before releasing. It will come next update. It contains my take on how the vanilla soulcairn weathers should look, as well as the special eclipse effect that Dawnguard introduces. In general the weather.ini´s only contain the info related to weather related options. Hence some stuff is not editable in them. I have just been lazy and copied over the entire enbseries.ini so the files are a bit larger. In terms of visuals then you can think of the enbseries.ini as the middleground where all weathers sort of look semi decent. The weather inis are what allows each group to shine. For example if you use just the enbseries.ini then the sun will glow through heavy cloud layers during overcast and storms. Also all nights will be sort of equally dark. With the weather.ini´s then clear and cloudy are far brighter while storms and overcast are darker. In your case then you would need to change the clear/cloudy files only since they are the only ones where you can actually see the sky. However like I said, then I found a small error in my bloom code which caused a too heavy emphasis on red tones. This will be fixed for the next update as well. Also I might alter the sky intensities a bit for clear and cloudy since they seem a bit too high. (I have noticed that some weather have tonemapping issues). Hence I hope you do not think they are too low, since already there are issues with the current settings. But well feedback is limited and I am just one guy! :D Also when you open the ingame GUI then the shaders window is also opened up by default.. at least for me. If you open up the weathers menu as well you can see all the settings that weathers can affect. For example EFFECTS is not one of them, like Time of Day too. There are a few others as well. Hope that answers all... and now I know about one more thing I need to put in the readme as well.

For spoiler tags just search BBcode spoiler on your search engine and you will get the info. Really going to need info on what sort of mod you put in and then removed again as well, as well as the actual list. A mod might not be script heavy, but ANY mod with scripts should not be removed again from an active mod list. It is just bound to cause issues.

https://forum.step-project.com/showthread.php?tid=3507 That should help! I hope :o

Make sure you setup your enblocal.ini file properly... you cannot just use the one the ENB author just provides and expect it to work. Most stuttering issues when ENBoost is involved can be traced back to this. Best suggestion is to play with the values in the enblocal.ini file. If that fails entirely then you most likely need to use smaller resolution textures since the load is just too much for your rig to handle.

wow.... thank you for the nice words... I will try my best then! :) Truth be told I have not done much in terms of interiors with version 2.0a since it has mainly focused on getting the weather system and exteriors up and running. However for next update I am going over them again and overhauling bloom as well. The haze you see is because of the bloom. And you are indeed correct that quite a few interiors have a red feel to them... this is because I applied a red/orange color focus for interiors. This depending on which textures you use will make some interiors look more red then others, since brown colors tend to amplify up the effect. Also it highly depends on location if a place is darker or brighter then vanilla. Inside inns etc. ELFX have not made it so that it is almost pitch black in the corners... while in dungeons it will be much darker. However it is quite simple to get the haze to be less pronounced. Under the shaders window and the enbbloom.fx tab, then at the very bottom there is a parameter called Bloom Contrast. Simply increase this to reduce the haze and increase overall contrast. edit : You have been entirely correct and in the next update this will also be implemented properly! Thanks again for the feedback! That said since I am overhauling the bloom code anyways for the next update I will take it into account that the interiors might need to sharpen up a bit! Thanks for the feedback and hope that the above helped out! Edit: I just found some bad math in my bloom shader, it is now fixed and the redness issue should now be fixed.. at least it mostly is on my end! Next update will be out tomorrow or the day after I think.

Hehe yeah it was more a joke then meant in all seriousness. However it is vital to say to people that unless you actually know what you are doing those textures are just best left alone as the author has made them. There is no harm in letting the skin textures being large files, since most of the time the visual benefit is quite noticeable since it is a texture you are going to be seeing up close and personal most of the time during the game.

Nice detailed info, thanks for that. But really we should just write with big red letters.... DO NOT TOUCH THE SKIN TEXTURE FILES AT ALL! hehe They are just so sensitive to both resolution and compression technique, and I found that the result varies a bit from time to time. Also most setups would not hurt from having a 2-4 detailed textures even with 1Gb of VRAM.Â

Heheh I figured it was that Z... you can get the alpha version of my guide / readme on my nexus site... it has a section on how your skyrimprefs.ini should look to not cause any of those issues. But glad to hear that you got it sorted out! :)

Make sure when you get an enbeffectprepass.fx file that you check the resolution set in those files... most of them require manual settings to look properly. Most files use this type of line float2 fvTexelSize = float2(1.0 / 2560.0, 1.0 / 1440.0); Make sure your playing resolution is input there. This info is requires for the file to make sure that the proper center point is used in the calculations.

Also make sure that hardware and ingame AA techniques are disabled ofc (making new profiles in MO will use default files with AA enabled as I recall). Or they will cause such events. But still if it keeps up then throw some screenshots my way and I will take a look.

Yeah I am not good at the proper descriptions I know! The change log more or less just gets thrown up with what I think of first and then I do not really read it, since nobody says it is unclear! :) But what I mean is that since I implemented a weather system then CoT clear weathers will look very much different then CoT overcast ones. CoT is now the only supported weather mod.. since vanilla will just look dark due to some code changes I made. You can switch off the weather system and then everything will look like it did in v.1.9 I did not alter the default enbseries.ini at all, and I do not plan to either unless it cant be avoided. You can think of the enbseries.ini as the middle ground that makes all weathers look sort of decent. Where the weather system allows for specific edits that will make each class of weather look more epic then otherwise possible. Specifically then I have made dawns and dusk for most weathers brighter since I increased the amount of bloom. However for stormy and overcast they are darker... In general then stormy and overcast weathers where there is no sun are darker all around. And clear and cloudy are a bit brighter. Also my aim is to hit that spot between realism and playability. Hence why I am working on making a proper guide on how tweak the brightness/darkness values without ruining something else. If your issue is just with dawn and dusk, then just increase the bloom amount there a little bit and it will become brighter without really ruining much. If you need more specific help just throw me a pm with what weather and I will take a look.

When getting kits then the modules come from the same wafer, and hence are identical in almost all respects. When buying separate then their specs might be the same but you can experience one stop working before the other and other weird stuff, due to manufacturing issues. However as long as they are from a quality brand then it should not matter, since those only use the highest quality parts of a given wafer are used anyways... but Quality control can fail. What you get with kits are just much better quality control and nothing more. That said..then I would also never buy separate modules... Have had it happen more then once that only 1 stick works at a time.. for god knows what reason, even though the brand and specs where the same. Also had it happen that they just down clock and refuse to go back up unless one is removed. It is like the reason to buy EVGA is the much better sleep you get knowing that you can just throw the stuff back if it fails due to bad quality control. With issues like I just said.. the manufacturer is not obligated in any way since the individual stick is working.

Even when it was working it was still just a baseline suggestion. You most likely still would need to tweak it further depending on your system. I can understand that people are scared of messing things up with it etc. but it really is not that spooky, or difficult. It will take less then 30 mins to home in on the best values for your system if you start out at just your VRAM amount. Most stuttering can be removed by disabling precache these days as well. And with the latest minor updates people are reporting that it is in general a bit easier to work with. And the best part.. once you have the file setup you never need to touch it again. That most preset creators tend to provide a file is just bringing more issues then good... even more so when people use that stupid ENB manager since it will auto overwrite the file, and then you need to resetup it all the time. (Got to start counting how many reasons I have found not to use that silly piece of weirdness.)

not sure what you mean by working blind. I can get the texture both showing in nifskope preview, and inside the game just fine. For the preview I just link to the MO mods folder that contains the texture, and then I have GIMP setup so I save to that dir as well. So I can edit the texture on the fly as well as the mesh. Just make sure that a mod folder for your work is already created and contains both meshes and textures and you got it all. Also ofc. make sure it is lowest in the priority order so that if it shares a name with a vanilla resource that you overwrite. I honestly do not see what more you would want.

Ah okay. I thought you only meant how to get the textures to show inside nifskope! What I normally do is create my new mesh, texture mix, and then create a new mod in MO and load them in like any other mod to test them ingame. If they are still purple after that then some texture path on the actual mesh is not properly setup. Hope that is a bit more clear, or just let me know!

You simply link to the MO mods folder that contains the textures directly inside nifskope and it will work just fine.

edited my post to make it clear that it is only on how to do it in general.

Generally speaking then the process is this. As I understand it then it is not applicable to the specific issue though. Open tes5edit. Remove all the entries that create the dependency. Open up the file header and remove the master requirement from the list. Do make sure you get all the dependent records though or you will get a crash regardless.

Ah okay then I misunderstood! My bad. And yes certain weathers in the weather patch have some distance blur enabled since I personally do not use a DoF, and I do like the far distance to be blurred most of the time. And if people do not like it then it is as simple as setting it up on ENB to remove it. It has been a while since I tested out dynavision last, but it would make sense that it would do what you describe.

Occlusion culling in ENB is for water parallax, not lighting. This project it for lighting and meant to help improve performance by shutting of shadow casting lights you cannot see anyways. The names are the same since the method "occullsion culling" is the same.. just applied on different things.

There are no "right" settings to suggest set for ENBoost based on just one thing. That is the main issue, there are only rough guidelines. The reason is that it does not just depend on the graphics card you have. You can have the best graphics card in the world, but if you have a cheap Motherboard some Chinese graduate student made for his exam with lousy bandwidth all around you will get horrible performance and massive stuttering none the less. Also it is not just VRAM that matters it is also RAM, since textures are loaded onto available memory you might have. Hence if you only have 8Gb then one set of values are optimal, if you have 16Gb then another set of values might work better. Also depending on how high you have set your ugrids settings will matter since that effectively for more or less textures to be loaded at once. And again ofc the resolution of said textures. In short.. this is why we do not just say "If you have graphics card X, use this value"... since it is just not that simple. Hope that made sense hehe.

Dynavision works by using imagespace modifiers and scripts to use the already existing depth blur in skyrim to create the DoF as I recall. The main difference between this method and the one used by ENB DoF´s is that one requires scripts the other does not. Also ENB DoF´s tend to eat up a bit more performance since they are more advanced and not really super optimized by the authors.