Aiyen

If you experience lag while scrolling around, and long load and transition times then optimization might be worth considering. Or just if you are very... strict about how much disk space you are using etc. However if you have a 4Gb card then you wont notice any difference what so ever with the textures in STEP core or extended.

Get GIMP, Photoshop, etc. Rescale the image to 1080p Export to jpg, and voila.

Depends on your timeframes 1 year until next upgrade Only GPU 2 years GPU and CPU Assuming the next gen CPU is actually out by then. At that point the i5 will probably begin to really show its age. 3 years Everything RAM is only vital if you actually do something where it makes sense. This involves multimedia editing, heavy duty CGI working etc. Also just if you like to swap around different programs constantly without any startup time to speak off.

Jawz jeg kan da sikkert godt få lavet noget der lyder som svensk.... på en god dag! :) And for the rest of ya.... atm I have no preference what so ever... timezone wise I think we are all in the EU, so that part should not be the most tricky... unless real life interferes too much. I will try to play with being all active and stuff later tomorrow etc... atm I am just too sleep deprived.

I had the issue back when I was testing out that mod, and it was one reason I dropped it again. Never did any extensive testing on it since I never do alt-tab when I play a bethesda game.. just never worth the hassle imo. If I need that sort of thing these days I just make a windowed mode and edit shaders that way.

Well I wont pretend to know all about MD5 hashes etc.... so for me that is more complex! Guess the going to sleep idea is not half bad! :)

Problems are only problems because everybody is editing on the same base, and in most cases with the same names for files, scripts etc. I just thought you wanted a feature that would only show the "meaningful" conflicts.. so only the mod you look at and the mod that actually does any overwriting, instead of everything. Would be a nice touch... but I guess you wanted something a bit more complex, which I do not really see a point in yet, since most of the problematic conflicts are not something MO should be tackling but rather tes5edit.

To get procedual to work you need to have everything contained inside the E_CC_PROCEDURAL define included in your file. As well as all the corresponding GUI elements above. The enbseries.ini is to enable this part of the file for editing if you so choose.

Because the size of the mod list really does matter a lot? :P Even more when one consider that about 70% of the mods are just individual texture/mesh mods. Also it only takes one mod to cause stuttering... does not matter if you have 150 or 2500000 mods installed.

The max size of the palette is 256x256. If you increase further I think it just rescales it back down again due to how Boris have coded it. But yeah, if you got the time and patience to do proper tonemapping techniques, and color correction tweaking then that is always the superior way of getting a look.. technically speaking ofc. If you got a good look using a palette then just use that. Just because something is technically superior does not mean it is artistically.

JawZ: Good to know we are on the same page! I agree that for new users/tweakers then it is perhaps not the most transparent way of saying it! :) Manga: He wants the following "technique Shader_ORIGINALPOSTPROCESS" back. This will trigger when the you toggle "use orginal game post processing" in enbseries.ini. Then it will use that technique instead of the default one. Afaik it should be enough to simply copy back in that technique and call it a day. Ofc. making sure the vertex shader name is the same I believe it is called VS_Quad() by default, and you might have renamed it. The rest of the defines should be done in the funky pixel shader he has made (which is just another way of typing the AGCC you can trigger above.). Hope that made sense, otherwise let me know! You got me on steam if the need arise!

I think what JawZ means is that when you limit yourself to a low resolution texture, you also limit the effective range of values you can work with. ENB itself have full 32bit color support, if you use a texture with only a resolution of 256x256 you severely limit what you can do. If you do not use it then you still have a more or less full range to work with. Also since it is linked in with adaptation that means you also have a loss that way. So from an artistic viewpoint it is not saying that palettes will make stuff look like crap, it is just that you technically limit your options by using it. It is a cutting corners option for tweakers, and there is a cost by cutting corners. At least that is what I understood when I read it! Might be totally off!

Perhaps add it as a function you can activate after startup? I see the point that it would not make any sense to have that sort of indepth analysis running at all times, however it would be nice to have such a tool for general testing.

The giant sun in blackreach for soft particles cant miss it. And ofc. just about any brazier in the game. And reflections only work on certain objects which have the correct shader flags that ENB hooks into. Wet rocks in waterfalls, and most armor.. as well as various terrain rocky textures are the best bet.

One of the easiest and best spots for reflections would be the huge sections of waterfalls on the road between whiterun and riverwood. Lots of rocks that are affected and easy to get a good idea on how it works.. Ofc. also just equip iron armor and put on a sunny day and you should be stellar.

I do have a rather busy weekend, but if nobody manage to get around to it I guess I can whip up a quick code piece that should restore the "use original" functionality again. Wont be until sunday at the earliest though. :s

All of the shaders and respective functions are just plain text... so I am sure there are many fancy ways that it can be done using a wiki. What I was hoping for was some input on how we should do it, what it should contain etc. Also what level of documentation are do we want ? I would suggest at least some basic level of documentation if the idea is to allow prospective tweakers etc. to have an easier time playing with the stuff. A while back I was tinkering on adding a guide that would show people how to start playing around with my file structure in order to build up the enbeffect.fx file. Essentially starting with a as blank file as possible and then show people how to add in the respective #include statements and call the various functions. Never really did get time to do it since every time I was in the mood I redid another of the .fx files instead.

The collection of functions that we have been talking about, as well as plain files that are easy to start editing etc. In general that sort of stuff.

Okay so does anyone have an idea on how to technically do the archive? I got no clue how the finer points of wiki or website maintinence is done. Do we want to upload as files or just as plain txt ? I guess we could do something like they have done over at the oblivion wiki. Once we decide on that I guess I can start to upload the files I have and then start to look a bit at what other authors have laying about.

There is no workaround to make a smaller resolution look good on a monitor that has a native higher resolution. Lower effects to match your FPS requirement or live with the stretching... or get a larger GPU that does not care about 1440p. The only workarounds are the other way around where you can ask the GPU to render at a larger resolution and then downsample it to your display resolution.

ah its a 1440p .. I read the topic of 1140p... thought it was some weird fancy monitor lol Yeah the aspect ratio is then the same, the only thing you are going to have is a bit of stretching due to lower res then the optimal.

Set your own resolution manually in the skyrimprefs.ini That is about it. You will ofc not be able to retain aspect ratio´s and there will be visible stretching if you play on a lower resolution on a larger monitor.

Well for enbeffect.fx it works really nicely since it has just a single pass... for the multi pass ones it becomes a bit more tricky since there you cant "outsource" everything. But yeah I like the idea of building blocks for shaders... already have a nice amount of them... I have considered converting other peoples work into that format as well... but time constraint and general "fun" factor has thus far prevented me from doing it. But I do not mind helping out with it if it suddenly becomes a joint effort. I guess we should also offer a more clean default .fx file selection so people do not have to start to go about and remove all of Boris´s default stuff. Most of it is not really needed at all, and only serves as very basic examples.

Every single specific .fx file have their own terminology so that is a can of whupbehind (yes I just made that word up!) that we will need to figure out how to deal with. Also some files are ... monsters of variables and permutations of various ways of doing the same thing. Documenting all of that would be a rather.... immense task. Considering that most authors did not write any detailed descriptions about what their codes are actually doing to begin with then it would be an even larger task. I think it would be more appropriate if we actually made a repository of functions instead... since there is no point in documenting how 10 different files went about doing a saturation control.. since at the end of the day the end result is always going to be the same. Everyone who viewed my files know that is the way I am doing it with my own files, and I think it would be healthy if more did it that way rather then.... mass it all up. Also as for the SSAO thingy... You could make it so that everything is drawed only of a specific color in just about all of the .fx files if you want too. That way it will look like that up to a certain point. I imagine the way Boris is doing it is to simply prevent any .dds draw calls to be forwarded and then simply view the game as meshes.

The most common way is to activate Post process method 2 in the default file and then start altering the enbseries.ini. Even to this day quite a few screenarchers still just use the default file and do tweaks rather then playing around with the actual files. Even though the files are so easy to use now compared to how it was.... but well it is understandable since once you got a style you like then it can be tricky to find the same on a new file! My main motivation to make my own stuff was because I was really tired of just seeing PP2 variations everywhere... it just got boring. These days ofc. then most of it is boring since I look at an image and more or less just see the code that could produce it... and in general I think high quality textures do more for shots these days then the actual tweaking. In general the main limitation these days is that every time one come up with a new idea you realize it cant be done without asking Boris to do something...And that is not an easy thing to do. And lol at prods comment! Typical prod hehe But he is right.. that is what each does... however with the small twist that not all power functions actually behave the same way.. some of them are inverted in their behavior by Boris.