z929669

I am pretty confused by the OP screens. TCG sounds like a mesh replacement, and we'd need to know what textures go with the new meshes (if the mod does not supply). NJ is a mesh or texture replacer or both? Some of the mods in question have no apparent effect. Need to know what overwrites what in those screens maybe.

I'll do that, and will report backthanks!

From the OP, I like Ren's best, and I don't think they depart from vanilla really. They are just better than aMB and vanilla, IMO. Also, STEP should be using aMB right now, since BoS installs the Creatures pack (assuming these are in that pack)

Look at the diff between SkyLight ENB and HRK ENB versus the others in the compare thread next door (they use CoT, but the others do not). I do not use better dynamic snow, so I wonder where these decals come from if not CoT.

Wrye Bash INI Tweaks are manually implemented under WB. That is to say that WB allows the user to point to any INI (type a, b, and c) and create a user tweak for that INI. The term 'override' does not apply in WB, since these are always 'overwrites' directly to the INI once a given tweak is implemented by checking its box. Therefore, changing an INI setting under WB is done manually by the user through action in WB INI Tweaks tab (this is reversible) or by direct manual edit or overwrite of the INI itself. Based on the descriptions above (and from my own observation), Skyrim INIs (type a) are easy. Each profile has its own Skyrim INIs, which are editable either directly or via MO INI config editor tools. I am still unclear on a couple of things regarding mos-specific "INI Tweaks" (type b) and "mod attached INIs" (type c): Type b are also mod INIs, but as described, they are under a mod folder called "INI Tweaks" at the top level of the mod ... are these tweaks to Skyrim INIs? Does the "INI Tweaks" folder sit beside "Data" or the assets/folders under "Data" or either one? Do these modify the profile Skyrim INIs?Type c are 'loose' INIs within the mod and effectively go under /Data/. Do these modify either/both type a and type b INIs (they would do so under WB, since they are loaded at game start and are not part of the static config)?Finally, we should definitely supply type b or type c INIs with STEP, as it enhances the value of the STEP Nexus downloads for all users, not just those using the patches. The question is whether they be type b or type c. the former would be for those running full STEP, but the latter would be mod-specific, right? If they were named according to the corresponding STEP mod plugin, they would effectively be type c, and if they were in an "INI Tweaks" folder beside the STEP patch, they would be type b and applicable to the Patches?

Sure. I'll upload them this evening Sent from my SPH-L720 using Tapatalk

FYI I noticed during my testing that the ENB shaders menu is not navigable in game ... that is, I think that this mod's mouse and focus capture preclude the use of the in-game ENB mouse cursor as a means to edit the shaders. For ENB testers and creators, this is a problem that could use a solution. The in-game ENB shaders can be accessed normally by pressing Shift + Enter while in Skyrim. Can anyone else confirm?

OK, I have a debug archive at this link. ... and here is a smaller one from ASIS, which is what is failing (previous one works) I will mess with another version of SkyProc tomorrow. EDIT: I tried nearly every previous version of ASIS without luck. Many different errors. The only versions that partially run (but lock up) are 1.20 and 1.33

There is only one global interior setting in my preset. If you check you will notice that all interior values are the same, day and night and in every ini file. Interiors vary greatly, and largely it comes down to how the lighting mods behave and not how the ENB is setup. ENB´s only alter the base values the mods provide after all. Also Water and subsurface scattering is texture dependent, hence I urge people to tweak them into perfection for what they use. I wont be making a different set of files for every texture combination out there. Just too much work for too little gain. I will cover in my guide eventually on how to do this. Also what sort of snow texture are you using to make your roofs look that bright ? I never noticed my roofs being so bright! :) Edit: I also checked out on the weather thing... apparently it is only snow weathers that are brighter then every other weather... guess this is a weird mod edit somewhere. Guess I can try to find it. I understand that, but I am using your recommended configuration and textures (which are mostly the same as other ENB recommendations other than CoT). Paticle patch and subsurface scattering patch are both in use too. You should check it out for yourself to confirm. Go in game to Broken Oar Barrow just outside the entrance and face North near dusk. Weather should be xxx58148. I have yours set up under a MO profile, since it is one of the more complex configs, so I can provide you details of exactly what I have going on. The snow on roofs and on roads is only present when I test ENBs recommending CoT, so that is the culprit I think (see HRK). I am not a fan so much of that aspect of CoT. Also, it is not the CoT Weather Patch. Also, the latter could be the cause of the bright water in the last image, but I cannot confirm (again see HRK, shich also uses CoT but not the CoT WP). OK, if you have one global setting, the the CoT weathers are really off between day/night (or your setting between day and night needs to converge and flip-flop, since in the day, it is much darker, but the same sources of light exist). If the lighting issues are due to CoT, I will find out soon enough. Many more to test.

I can do all that this evening (late) ... I'll look into it Thanks for helping!

Updated OP with MT needs.

Added a few more compares tonight.

d3d9.dll is pretty necessary for ENBoost to work. You should not delete it. you will need to revisit the ENBoost installation and be sure to turn of Windows UAC or take ownership of all files/folders under and set all *.exe and *.dll to 'run as admin'

It is probably not a game issue but something related to Windows or some other program or DLL interfering. Try updating Steam or checking that your Steam settings are all default. Also check AV and running programs. Look at your Windows event logs. Try restarting, etc.

Hope this does not mean you are abandoning your efforts .... ?

This is an improvement over vanilla. What are the other possible contenders? We may as well get this right the first time ;)

Awesome ... nice work. I will gladly use to provide more info. Right now, I can only tell you that my error spits out only that small bit of info and that ASIS can't complete if run by itself or under SUM. I am astounded that more people are not reporting this error if it is not related to my mods or something user specific.

thanks for dropping by ... Sadly, I cannot reproduce my issues either :/ I do sometimes have issues running from MO, but again, not reproduceable. at this point, I have to assume user error. It does clarify some things for me that the app modifies the skyrimprefs.ini Full Screen value. that explains why it was opening in windowed mode when I bypassed the app (that was very perplexing for me until I found the source and just learned that skyrimprefs.ini setting is altered by the app). I still like it for STEP, but would like other new users to run via MO before adopting ... just to be sure that my issue is an island :P

This format was learned from original Anglo-Saxon' date=' in Britain. For various reasons the Britains converted to the modern version of DD-MM-YYYY and those across the pond continued the older tradition. One could say DD-MM-YYYY is more logical, but only strictly from a mathematical perspective. Both cultures have sorted it according to how they mentally process the importance of all three pieces of information. A justification for continuing MM-DD-YYYY is largely how we, as Americans, interpret it while speaking: "The 13th" - The 13th day of the current month, February. A communicative assumption for the American culture. "March, 13th" - March is used, immediately, to indicate that the upcoming date is not for the current month. I feel this avoids an important mental confusion (however brief) when otherwise we'd hear "13th" first. Because there's a simplification of communication (efficiency is human nature), the usage of MM-DD for us means we are never undoing information. To use DD-MM would mean, in a mental example to the listener: "On the 13th. Got it. February 13th. Oh, in March, so not this month? Got it.", where as MM-DD for us is mentally processed as "March, so not this month. 13th? Got it." To give you a visual: Imagine someone handing you a giant calendar. The very first move would be to find the month in question, followed by the day. However, by specifying the day, first, the person holding the calendar is waiting for a second piece of identifying information before the search can even begin: the month. There's no right way or wrong way, logical or illogical way. Cultures design efficiencies in communication based on their interaction with the world, each other, and their perspective. MM-DD-YYYY simply fits cleaner with how Americans mentally process the information when combined with the communicative assumption from earlier. Additional food for thought: The US, and previously British, date notation was chosen because it followed middle and big endian systems.[/quote'] good analysis. I completely subscribe. Are you a historian? @Aiyen Although I use it mentally and by default, the English system of measurement is definitely flawed (based on arbitrary physical constructs). the metric system makes so much more sense being based upon the bas-10 system of mathematics ... or maybe the base 1000 system ... or maybe orders of magnitude based on the base-10 system ... :o_O: ... does this all translate somehow into moon size?

My terminology must be flawed ... I assumed 'custom INIs' were the mod-specific ones with the little paperclip. that is what I am talking about above. I have never used any of the custom mod INIs, but my profile INIs work great under MO.

I confirmed taht I had not been loading CoT weathers after all :P I am starting another round of ENB compares on the adjacent thread, and the 'correct' screens for SkyLight are now included. looks good ;) Question: what mod adds the snow to the ground around Whiterun? I want to fix my SL screens so that they match the other ENBs if possible (without snow all over the place in WR)

Good idea about moving the INI recommendations into a custom INI tweak for MO (and for WB). We could provide these with the STEP Patches ;) I cannot verify ho MO handles custom INIs, but I know that any *.ini in directory gets loaded, so if custom INIs are included in the virtual files system of MO, then they should get loaded.

Good point, will change. Fixed

Problem is that mod pages are associated with the main guide and we don't want to have any information on them that is not maintained by us. If pack authors begin adding their own specific notes to this, then it gets very cluttered and confusing ... and potentially will not be maintained by pack authors (and we don't want to have the added burden of maintaining and servicing Pack-specific questions) The best solution is to have ancillary mod pages that are associated with specific Packs. Definitely worth developing and implementing, but not as a hack to current mod-page format as a short-term solution. As I said, it might be best to devise a form linked to mod pages that creates the associated Pack-specific mod pages that produces a link to that page on a special Pack section of each mod page. The list of links (probably using Pack PAGENAME would be updated automatically via SMW). The form could be invoked from the mod tables dev form. Would need to ask s4n how best to design though. I will add it to the Packs 'wish' list on the Data Dictionary project talk page. EDIT: dev note added to the Dictionary page (scroll down on the Mods tab). Anyone fel free to add any additional wanted features to the notes on this wiki page under the appropriate tab.

see previous ... anyone?