z929669

The vanilla HRDLC female and male body are 2k. They look like 4k in terms of file size, because we are used to looking at compressed textures (2k ~= 2.73 MB), but these are uncompressed and about 4x bigger file size (2k ~= 16.39 MB). Non-human-skin body MSN are compressed, because they are not so smooth. ... these and all body MSN should be converted to R5G6B5 format in DDSopt (without reducing resolution or reducing to 1k in cases where the computer is on the low end). The in-game difference is imperceptible, but the size on disk (and in memory) will reduce from 16,385 KB to 10,983 KB. Reducing res to 1k is another 75% reduction (1k is 1/4 the size of 2k). ... now, many texture artists and/or connoisseurs will disagree that the quality of these relatively 'smooth' textures is not perceptibly reduced and that they can actually tell the difference in game. I would say that these individuals are either looking too closely for these specific diffs (as compared to what they would do if they were actually playing the game) AND have extremely good eyesight or monitor, or they have inhuman eyesight and/or a space-aged monitor.

I agree that there is formatting in the skin CSS that is not ideal, but it would be much better to change the default skin CSS than to do a bunch of custom stuff. I actually get around the heading padding issue (not enough padding at top margin of headings and too much padding at the bottom of certain elements like pre, fe) I'll check out what you have and see about updating the skin or the Mediawiki default CSS. The point is to avoid creating custom looks for anything outside of the User namespace. EDIT: I fixed the global margins for h2-h6, so you will want to eliminate those from your custom CSS (yours were a bit too large and are waaay too big now). The pre elements should stay as they are though. They should go all the way across, as that is standard on most wikis and allows, fe, CSS pages like the one you linked to display correctly. I can create a separate pre element for your stuff I think. Would need to define that (say, pre2), but I forget how to do that in CSS and will need to look it up.

Civ2 forever here. The new ones are good, but they lack the simple-yet-complex dynamics of the old-school game ... I just love Civ2. Welcome all newcomers since my last post on this thread ;)

I updated the guide somewhat. Removed reference custom CSS --custom CSS should NOT be used anywhere outside of User: pages ... we have a look and style to the site for consistency.Removed language about "anything goes" edits --we actually do have some "best practices" that editors should abideAdded info about HeaderTabs use (we need to modify all guides as indicated ... the MO Guide is a good example that would benefit greatly)Added info about Guide-related editing styles

Let's move this discussion to the original thread

First, let's clear something up: 2.04.4 != a number ... it is alphanumeric and analogous to a.0d.d. Therefore, a.0d.d = a.0000d.d = a.d.d ... leading zeros (IMXP) are understood to be padding in alphanumeric sequential codes, so I think it is pretty standard to equate 2.04.4 to 2.4.4. Second, I assume MO reports versions because it can --in turn-- because it uses them to drive its update system. It is one of several possible implementations and arguably works best. In addition to making it possible to test whether 'update1 > 'update2', this feature seems to opportunistically serve up something interesting, which I find useful. The question would seem to be "why does MO 'correct' manual input in an annoying way akin to autocorrection-autoformating 'enhancements' that are on by default in Microsoft Office apps?", fe. The only answer I have that explains this is that it is opportunistic information delivery where the actual information serves as a component of the true intention for the behavior: the intended behavior of the update system. Hence, there is no need to fix anything because this 'feature' is not broken; however, I might also argue that the user display and the functional driver could be separated at birth of the manual change. ... anyway, I don't think that this dead horse deserves any more beating, and MO enhancement requests can be submitted as described numerous times already on this thread.

That is just a description of what the combined settings affect. There is no missing value ... it is commented so that users can copy/paste with the notation in their INI

I just checked, and iPresentInterval is not needed in either INI for the opening sequence to work correctly. Are you sure that you did not change anything else? Try this: Load a new game and verify that your current config works through the opening. Remove iPresentInterval lines from the INIs where they exist (should only exist in skyrimprefs.ini). Load a new game and repeat step 1 Two outcomes possible: If it works fine, done. If it does not work fine, add iPresentInterval=1 into your SkyrimPrefs.ini under [Display] Repeat step 1 and verify it works again (this confirms that iPresentInterval is a contributing cause).

PM me on the Nexus if you want your Mod Author badge here on STEP

You are correct, thanks ... I will fix and reupload. EDIT: Uploading now

I am working on some wiki editing standards now and will post next week on that in DY's wiki editing thread (linked in second post of this thread). We also have some info listed in the STEP Community Citizenship Guide.

I agree with you on all points, Tech. My trial 2 test results did not include any extra analyses as your did, but by placing iPresentInterval into Skyrim.ini > [Display], I was able to convert every single 'UNEXPECTED' result ... the only exception is when AMD drivers should be forcing vsync 'off'. The lesson here is that AMD drivers are not able to override either ENB-based or Skyrim-based vsync settings. For good measure, I tested every combination of iPresentInterval in both Skyrim.ini and in SkyrimPrefs.ini. The latter has no effect at all on anything I can see, but I wonder if either placement of this setting affects timing/event sync (both? One or the other? difficult to say. I think the recommendation to DELETE iPresentInterval lines from BOTH Skyrim.ini and SkyrimPrefs.ini is good advice. Doing so allows default Skyrim settings, which are to be left alone ... I confirmed this via testing with these values removed from my INIs ... the result is like having the 'source' of the flow 'on' and allows ENB to manage effectively (and NVIDIA drivers as well, but not AMD). NOTE: I think that the navmesh issues you saw are also related to high FPS and nothing more. Event sync issues could also be attributed to high FPS, so I think that we can use those assumptions (FPS >> monitor refresh rate = BAD!) I think we can update ALL the Guides now to use: Drivers: vysinc --> "app controlled" or "'off', unless application specifies"enblocal.ini --> EnableVsync=trueSkyrimPrefs.ini (and Skyrim.ini) --> DELETE iPresentInterval linesEDIT: in NVIDIA Inspector, what is the vsync dialog like? What is the default setting and the terms used? Need to update the STEP Guide to use the right settings for vertical refresh. EDIT2: Tech, would you mind updating the ENBoost notes to reflect the 'best practice' according to all of your recent ENB research? I think that some of our recommendations may be outdated.

Great find ... I had done the same, but set it to '1' and never '0' ... when I found no difference, I quit playing with it. I will test tomorrow afternoon to confirm on my end.

OK, I understand the hose/faucet thing now ... that analogy is not so clear though and why I did not really get it at first. A better way to say it is that iPresentInterval is the supply and Enablevsync is the valve. The real mysteries are trials 5, 11, and 23 (no supply, no valve, should be no FPS limit) as well as trials 7 and 19 (no supply, valve open ... should be no FPS limit according to Boris if we understand him correctly). I think it is safe to say that iPresentInterval does NOT control vsync as almost everyone thinks. It probably does control time-event sync, but I have never noticed myself. Also for the record, this setting does not belong in [Display] section of skyrim.ini as so many people suggest on many forums. It belongs in skyrimprefs.ini. It probably would not hurt any, but such advice really drives a wedge into troubleshooting issues that may be related to the setting when the value is set in 1+ places. As I said before, we need to test against vanilla to confirm 5, 11 and 23 and on lower systems in order to get more of an idea about optimal settings for microstutter and screen tearing (I get no tearing or microstutter at all indoors or out in all cases). I will get to vanilla and various AMD driver settings that remain untested this weekend. If anyone out there has a low-mid range computer and would not mind running the trials, that could be enlightening.

Thanks for the data, Tech. based on your and my findings together, I have aggregated our results (attached for edit and shown below): Observations: Driver Settings: NVIDIA software effectively controls whether or not Skyrim and ENB apps can control vsync ... are there other settings besides "Force off" and "App controlled"? AMD driver settings don't seem to affect other apps' effect on vsync, given all of the evidence (at least ENB seems agnostic of AMD driver settings ... see trials 1 & 2). AMD allows app-specific 3D settings independent of the 'master', which adds a layer of complexity (I tested using my custom-defined TESV.exe-specific driver settings and confirmed that they override the master settings, but AMD dirivers bundle app-specific profiles into the drivers, and this is supposedly overridden by my custom profile, so that adds a layer of control that confounds the driver settings). This all points to ENB not originally (or as successfully) being implemented for AMD-based GPUs. AMD has four vsync settings: Always off Off, unless app specifies On, unless app specifies Always on ENB settings: Work dependably and consistently to control vsync (when allowed by NVIDIA) Are NOT dependent on iPresentInterval=1 as Boris has stated (at least not in v264, which is what I used or in whatever version Tech used if more recent). This is evidenced by trials 7 & 19. Whenever ENB vsync is set to 'false' (irrespective of driver or skyrim INI settings), we have FPS/havok issues. Since this is not necessarily the case when ENB is disabled (removed from ./skyrim), we must conclude that ENB has some impact on FPS limits/vsync when enabled with vsync turned off (compare trials 10 & 12 and 22 & 24). iPresentInterval Setting: No conclusive evidence exists that this setting has any impact at all. Where it may seem to have an impact (see trials 12 & 24), it can be explained away by its obvious lack of impact in trials 10 & 22 FPS >> 60 is the most likely explanation of any havok issues unjustifiably attributed to iPresentInterval=0. The INI setting only possibly affects havok issues indirectly by allowing FPS to greatly exceed monitor refresh rates on systems with powerful video cards. Given the evidence of the actual impact of this INI setting, I would say that this evidence debunks that hertofore spurious theory. Tech and I have powerful GPUs, so we are possibly not seeing graphics glitches like screen tearing and microstutter because of this (but high FPS issues are apparent).These kinds of inexplicable results are what lead me to attributing the "black box" to unknown hardware/software diffs among systems. There is more to be done though before i accept the black box nonsense. Test again under minimal Skyrim install with just ENBoost mod instead of STEP:Core to reduce the possibility that unknown FPS limiting is caused by some other mod-specific parameter.Test again in mid/lower-end systemsTest additional AMD driver settings EDIT: in response to Freyrgjurd's last post, you should test only the impact on the supposed havok issues by turning on/off iPresentInterval in a minimal setup without any other vsync control enabled. If the issues are not consistent, then a definitive test is not posible and the role of iPresentInterval on havok issues remains in question. EDIT2: looking more closely at that Russian conversation, it would seem that iPresentInterval does not set vsync at all but rather sets game-character-event sync and this may somehow influence the ENB vsync (and other vsync) implementation. That explains why our FPS impact is still affected when Enablevsync=true and iPresentInterval=0 (i.e., some other aspect of ENB must be influenced and not vsync per se). I think that it is sensible then that we recommend iPresentInterval be set to 1, which is default, so we should get rid of that recommendation. Book1.xlsx

The tags are usually already present in WB, but LOOT still reports them just in case. You almost never need to add any tags unless working with a very new or custom plugin/patch that requires them.

If you look at my results, you will see that --even with no software defining vsync-- I am effectively getting vsync behavior (FPS limit) ... I cannot say if this is just on my system or if there is some other setting somewhere (a mod INI, fe) that is setting iPresentInterval=1. (I said "frame rate" but meant "monitor refresh rate" ... corrected in my post) translates to: I am puzzled that my FPS is limited to my monitor refresh rate even though I am not toggling vsync in any of the applications able to set it. This happens specifically when ENB is totally disabled, so there must be something else either limiting my frame rate or toggling vsync, and this behavior stops if ENB is enabled with EnableVSync=false I did not use KB shortcuts to toggle ENB ... I made all changes directly to the INI.

@Tech You should update STEP Guide and mod notes when you have definitive evidence that the settings should be changed, especially since you are getting all of this info from multiple reliable sources now.

@Tech I am glad you are doing the research on ENB settings ... just read the latest on the wiki for ENBoost, and I think that you should update the STEP notes in accordance with your findings. Now, regarding iPresentInterval and other settings we are discussing here, the testing regime is very obvious, and you and hishutup nailed it (it really goes without saying IMO). Here are my results for STEP Core 2.2.9 ... I tested by COCing to whiterun with a brand new character. I ran from the bridge to outside of Honningbrew Meadery, summoned a dragon, then entered the meadery and threw around some plates. I noticed that in some runs --when looking away from Sabjorn and otherwise remaining still-- I could hear the havok noises of the stuff I threw around as if someone else were walking all over them. Since nobody else was moving around, these noises represent a havok glitch ... (see specs in sig): This tells me some important facts regarding my own unique system: iPresentInterval has absolutely no impact at all on any of the variables in the context of my testing. ENBoost vsync settings are the sole determinant of vsync toggle when ENB is installed. When ENB is not installed, vsync appears to function irrespective of either iPresentInterval or driver settings havok sound bugs are caused by high FPS or other source, and not vsync directly on my system in the context of this testing, there is no reason to use vsync at all, because I get none of the graphic glitching that calls for it My video drivers seem to have no impact on vsync, except toMy overall interpretation is that ENB is the main player in any wierdness of my past testing, and as was mentioned a few posts up, Boris' releases each have variable effects that are not well understood, documented, or observed (let's face it, each release is a beta). I am perplexed by the limiting of my FPS to my frame monitor refresh rate when I have no apparent app forcing vsync and by the lack of impact of my video drivers on vsync. There is obviously more at play here that I am not at all aware of (any ideas?) Regarding variation in user environments: Even if all is set up correctly and all drivers updated accordingly, user variation still exists due to differing environments, and these diffs can cause different results for just about anything, including vsync/FPS behaviors. It is all still pretty unclear to me, but I would really like to have corroboration from other AMD card users as well as from Nvidia users. Question: is iPresentInterval set in any STEP mods or other INIs? (I checked skyrim.ini, and it was not there) ... my enblocal.ini is attached enblocal.ini

@Tech With your training then you should know that expansion cards plug into the motherboard, and the mobo drivers and architecture are not the same among systems. If you plug a given video card into two different systems, you will get two different results. My point is that there is more that can affect frame buffer memory management than just the video drivers, Skyrim INIs and ENB. Even the software devs don't claim to know how a given piece of hardware will behave in one system to the next for all systems in all configs using the software they develop. The fact that there are so many varying reports of the effects of the various settings we recommend is testament to this. (and the question here is not simply about how to enable vsync ... it is about how to get the best video behavior possible in terms of stutter, FPS and screen tearing.) I am not challenging you personally on your knowledge, I am challenging you and everyone else on the facts, and the fact is that we are not sure of the facts or all of the reasons that we see such variation (please point me to the proof). Boris himself alludes to this kind of thing all the time and so does anyone that uses the statement "your mileage may vary". No two systems are the same, and they fall within a veritable continuum. Regarding iPresentInterval ... where are the facts that this setting is the cause of havok issues? All I have seen is hearsay and assumption. It is more likely that those issues were caused by high FPS, which --in fact-- does cause rendering glitches that can indeed manifest as havok problems. I have never seen such havok problems in my setup (which uses the guide rec of iPresentInterval=0 BTW) ... so this is either 1) because my system is different than others' or 2) because iPresentInterval really does not cause these glitches directly. I am naturally skeptical of all of the data we have on the matter, because the reports vary. I am not citing any 'complicated' testing regime. I am merely asking users to test various settings for these three components (Skyrim INI, ENB and video drivers) ... is this really too complicated? It is looking that way, given the amount of banter on this thread.

Persons wanting to learn how to use DDSopt in general terms should read the modified main guide, particularly the section discussing the browser tab and filters.

Just use this (I recommend using SMAA, but change EnableProxyLibrary=false if you don't and please don't use any other proxy for the time being). The guide does not define every setting, and I suppose it is possible that your iteration of the file may have some slight differences. If you still get the crashes, then either one of your other setup parameters is different from what we recommend, or there are settings or environment diffs in your setup that we are not accounting for. enblocal.ini

We are working to arrive at a consensus. So far, there is no solid evidence either way, so we will need to systematically test the effects of all of these settings. For the moment, I would go with Tech's advice, since setting iPresentInterval=1 is the most prevalent advice from various sources. We will update the guide accordingly unless someone presents evidence that turning on this feature interferes with ENB vsync. I will look into it at some point, but as I said, I recall that turning this feature on was detrimental to my setup at one point ... but there are three potentially interacting mechanisms here, and I do not remember the details of my findings (just that I wrote the current STEP recommendations based on my rather extensive testing ... notes would have been really helpful though!): Driver vsync/AA/AF settingsENB vsync/AA/AF (other?) setting(s)SkyrimPrefs.ini vsync/AA/AF settings

ditto to last post

Hardware system busexpansion cardsdisplay adapterslots of other stuff software: drivers (tons of them)services (tons of them)There are literally thousands of differences in each system, and many of these variations can affect other things indirectly. You are simplifying too much, and this is why one prescriptive will not work for everyone, especially considering that we are talking about a custom app that plays around with Windows memory management (not just vsync). All of this may or may not be related to whether or not ENB settings and INI settings have same effects across systems. EDIT: and I did not even mention sortware/firmware versioning diffs and interactions. EDIT2: in my personal testing iPresentInterval did have an impact on performance relating to vsync, stutter and FPS. This impact may have been due to combinations of other settings or it may have been due to my own unique system (or perhaps I had not exhausted all possibilities or sources of variation). There is no consensus on whether or not that INI setting is even a little important, because there are likely other variables in play.