z929669

Yes, was just testing out some options. Fixed now. I also edited the default CSS to meet in the middle with regard to the custom looks Tech created to override default site CSS. I agree with some of his changes, but just a bit toned down. elements should go more across the page as originally intended. That is the site look, so I removed much of the custom CSS for the ENB INI Guide (example) ... and altered the default a bit as a compromised between s4n's original format and Tech's preference. I increased the left and bottom margins and let them inherit the rest. Total width decreased to 90%. I also darkened the background and lightened the text just a tad. elements were given a bit more padding and darkened background/lightened text a bit. They just did not stand out enough before. Heading 2-6 margins were increased a bit, bc they were too small, particularly on top. The result is that there is no need for any custom CSS overrides anywhere within the main wiki other than to define new properties that we currently do not cover in the site CSS. Do as you like on User namespace, but we want the rest of the site to use the defaults. S4n will not want too many changes to his original defaults. Next, I want to tackle the layout of the ENB INI Guide. It should take on TOC format and categorization hierarchy like in this example. The example shows the settings for the Environment section of the ENBSeries INI ... notice how much easier it is to get at specific info, which is more like an index and better suited to retrieving info. The categorization would be like so: Guides > INI Guides > INI Settings I am putting together some HeaderTabs vs TOC compares in the new Category:Example which in turn will house subcategories related to specific examples. I will mock up the ENBseries INI guide in here as well.

Fixed spelling in thread title ...

@Smitty Play the vanilla game at least until level 30. By vanilla I mean pure vanilla. Then come back and install STEP:Core and start over with same character and then tell us what you think. STEP does not postulate that it changes anything substantive. We are primarily focused on 'fixing' and 'correcting' and showing our users how to go about it in as simple a way as possible. We provide a relatively simple guide to modding Skyrim with all the resources and./or references you need to do it. It is actively maintained. Go try to mod Skyrim without referring to this site and let us know what we don't provide that we could provide ... or that others are doing a better job of providing --within the purview of the STEP Mandate. There just aren't any alternatives for modding Skyrim or any other game compared to what this site has to offer (+ other user guides like Skyrim Revisited) More XP needed, or you just expect more than what we can manage. Complaining about the hassle of installing a bunch of mods indicates to me that you are not really into the game enough to care much about its shortcomings (or the challenges of overcoming them) ... most likely because you are not experienced enough with the vanilla game to notice the differences. If you have played the vanilla game and STEP:Core each through level 30-ish, then you have a unique perspective that deserves mention within the annals of the critical literature of the entire Bethesda modding paradigm. If you are convinced that you are experienced enough to supply a truly definitive critique, then there is really not much STEP or modding has to offer you at this time. ~ Strength & Honor ... (name the movie)

Not so. Indeed, converting the *_msn.dds body textures from 888 uncompressed to 565 uncompressed makes the textures look borked, but that is only because most texture file viewers do not normalize un-normalized normals by default. DDSopt is an exception in that the Prieviewer automatically re-normalizes any normal maps that are not normalized. You will notice only a very minute difference if you look at the DDSopt Preview of the texture post conversion (use diffx2). The DDSopt Previewer has a built in diff and normalizer to compare source/processed. Looking at each version independently (also available in the Previewer), you will not see any diff. These 565-converted textures will appear correctly in-game, because they are normalized by the game engine when loaded. (you can normalize and re -save using Gimp or Photoshop, but it is only semantics to do so.) It is conceivable that neck/wrist seams could pop out, but not that I have seen (this will definitely happen if you compress, but we are only reducing the info in the uncompressed format from 888 to 565 using Ethatron's own custom algorithm, which is the most economical, near lossless normal-map conversion that I am aware of.) Also, seams may be moot anyway with Better Males, since it combines the body meshes (IIRC). Anyways, I don't see any issues at all in game with the vanilla body msn when converted to 565 uncompressed from 888 uncompressed.

I would again suggest going with R5G6B5 for any of the model space normals (*_msn.dds). This will result in 2/3 size of the originals without any detectable diffs in game and no loss in resolution (but the texture itself will look borked in any texture file preview other than DDSopt, because the converted result is not re-normalized in most texture viewers by default --normalizing the texture itself is not a requirement though, because the shader engine takes care of that in game when the texture is rendered on the model). For Better males, i would reduce all to 2k res and 565 uncompressed format (this is an approx. 83% reduction from the original) . We will eventually provide these conversions via the STEP 'mod' on the Nexus. WIP, no ETA, all TBD ;)

It should go away once we update IPB to 4.0 ... ETA TBD ;)

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