z929669

Does Skyfalls replace the meshes or only the LOD?

Agree that the Nexus mod is not necessary. Boris has pretty much abandoned it anyway by the look. If he ever updates it , we can use it (but that enblocal.ini is missing several useful switches).

I am just now reading this and commenting prior to reading others' comments (so this is not biased) Just what I would have suggested. Drain stamina is another option. Enhanced critical strike is another good option and even enhanced stealth for the wielder. Definitely an inherent property of the metal(s). Like silver. Moths obviously. Maybe glow bugs EDIT: just saw DY's post about vamps. I actually think that crafting at night is a great idea. However, I think that werewolf characters should get a bonus when wielding. The moon gives wolves power. Black soul gem possibly.

I more or less prefer aMB in all cases but three: 1) I prefer the STEP brown fut pelt (looks like deer, so if it is supposed to be deer, I like vanilla style best) 2) I prefer the STEP outdoor thatch roof (SRO I think) ... aMB looks like the straw ends are inconsistent with the middles (if that makes sense) ... like the ends were brushed or blurred a bit to make them whispier. 3) STEP Core rope wins for me My first time seeing aMB farmhouses stuff ... Nice work CaBaL ;) EDIT: just seeing DoubleYou's stone floor comment ... yes, I like SRO, but I think that aMB shows good wear with an originally more course stone. SRO looks like poured concrete that is old and cracked (not the parallel grain as made by a brush) EDIT2: Doors are better in SRO, but I was focusing on the lumber surrounding ... aMB is better there. EDIT3: Windows. aMB needs work on the glass; however, I can at least tell that these are window panes! What the hell is that stuff in the first two?? Vanilla windows styule looks great in the distance, but is just bad up close.

Accepted

Hopefully I did not interrupt a big edit I also found two sites with potentially useful info for you and anyone writing that guide: https://www.simforums.com/forums/drivers-nv-inspector-fsxcfg-complete-guide_topic36586.html https://www.giantbomb.com/pc/3045-94/forums/nvidia-inspector-driver-tweaking-for-fun-and-profi-467728/

Given that nobody is going to provide testing feedback on my previous post that I have glaringly placed in everyone's faces to no avail, I have made an executive decision and edited the ENBoost mod note according to what I know to be the simplest way for users to get a nice working config (assuming that everyone will achieve a result similar to my own or at least a result as good as or better than using any other settings). The mod note is not meant as a starting config for ENB, but for STEP and other config recommendations in the new guide. The ENB Guide will also need to jive better with this (not necessarily reflecting, but definitely not contradicting), but I will leave that to folks that have been working on that guide.

Could somebody with Nvidia please go into the guide and ensure that the images for the settings actually reflect the recommended settings in the STEP guide? This tool has many, many options, and there sill be a ton of variation that does not apply to all users. I'd like to only recommend those settings that work well for EVERYONE, and leave the rest to the user to decide. Specifically, per the STEP Guide, could someone see that the images reflect these settings but otherwise let the application decide? The ancillary guides should expound upon the main STEP Guide but not conflict with it ... at least there should be a section that relates to the STEP Guide and reflects that advice exactly. The rest of the Inspector Guide is fine, but I want to avoid confusing people. (and I'd like for someone to validate the advice linked above for the 2.2.8 Guide) Thanks

It would seem that the SKSE team has some more coding to do (and more explanatory comments within the code might be helpful :\ ), given the alpha release state, and I will test a beta when available (thanks to tony971, thalixte, and keithinhanoi for providing feedback on the alpha). I think that it is pretty clear from my own exhaustive testing at uGrids 11 under [ STEP:Core + Requiem + kitchen sink ] that 768/512 (VMMap) is unnecessarily large an allocation. Nobody here (and to my knowledge, anywhere) has empirically shown that 768/512 is needed in any scenario. This is pure speculation and evidence would suggest otherwise. I have been running now for 30+ hours using Neo's version of sheson's patch at 512/256 ... It may *feel good* to allocate more, but why unless empirical evidence lends to doing that? Perhaps the SKSE teams version uses a different base value for DefaultHeapInitialAllocMB (MemBlock1) and has made other alterations/omissions (why without explanation and in a silo is completely beyond me ... an aloofness I have found in many developers), and 768/256 might be the new norm in terms of this version, but this is still 512/256 as mapped to sheson's version. As I said previously, 420/200 is just enough for uGrids 11 on my box (450/200 would be maybe a little 'safer'). Even at uGrids 17, 470/210 was enough for a long trial run. These values might correspond to SKSE block sizes of around 730/210 max.

Driver AF (AMD here) yields the same exact result as ENB AF for me, but the former gives me a 3-4 FPS gain, so I suspect that ENB AF is more costly without any gain (this is for you EssArrBee!). Also, it doesn't make sense to user FPS limiter with vsync (Ref 1, Ref 2). And there is no reason at all to set iPresentInterval=1 in skyrimprefs.ini, as it does not work nearly as nicely as the ENB versions, which I suspect also includes D3D-compatible triple buffering, since it is soooo smooth. iPresentInterval should always be set to zero in favor of ENB version: EnableVSync=true VSyncSkipNumFrames=0... I have examined this in much detail, and find that ENB's version of vsync is the best around (at least for my card, but I would guess it is a good bet for anyone). This is particularly helpful indoors when frame rates are potentially high. I will be playing around with RadeonPro as well to see how that does, as it has D3D-capable triple buffering.

Again, I think that there is a lot in Extended that should not be there. The Daedric armor mod for one, and Moon Size Tweaks is another. Many more as well, and with all of the additional modern candidates currently under testing, there are more attractive options for Extended. I honestly am only thinking about STEP:Core until after 2.3.0. But go ahead if you want.

I have seen silver within steel (Requiem does this ... or one of its incorporated mods), but never alone. I assume it is because 'silver' is really a modification to 'steel' in that the weapon base is steel with silver augmentation.

It is tagged for removal in the changelog.

I confirm to be rid of this. I like the default bard behavior just fine anyway. I had already tagged for removal in the 2.2.8 changelog

MO needs a WB wizard plugin!

me too. I am running this now in my mega-requiem build just for my own personal entertainment. No crashes on that huge, script/graphics-heavy build as yet (running at uGrids=11 for over 25 hours game time now). So far, so good for EBT (default settings).

Yep, we will remove anything that is not accessible.

OK, I updated that post with additional information (also corrected any of my previous misinformation). If anyone would kindly be willing to go through this testing and report back, it would be a big help in preventing me from overcomplicating the updated STEP Guide as well as preventing spread of more misinformation :P I have since learned that FPS limit + vsync = unnecessary/bad (see my modified monster post above with links to good info) Nope, not at all. I was getting microstutter previous to using any ENB. Could someone please read the post above and confirm my findings under different GPU/RAM? Well, for what it's worth, I never had any stuttering in Skyrim when NOT using ENB. The cause of stuttering issues tend to be different depending on type of card and/or individual system configurations. I know at the AMD boards some people have huge problems with a particular model while others have no issues with the same model (and same game). In my experience on my HD6950, some vsync software works better than others, but this is also circumstantial. For instance, RadeonPro Vsync is superb for most games but with ME3 (or Skyrim) I cannot use radeonpro vsync because there is still tearing even though the fps is at 60. With regards to ENB vsync, if I use ENBoost but do NOT enable the ENB vsync ánd leave the game's vsync (ipresentinterval) enabled, then the result is screen tearing all over the place. Stutter on my system is completely dependent on the memory settings I choose for ENBoost. For me the stuttering started when I've started using MemPatch 3.0... Never experienced it before. I recently lowered down my ENB Local ini settings to mirror my VRAM (2048) and the stuttering stopped. ReservedMemorySzieMB purports to somewhat optimize or reduce FPS, shich can cause stuttering, but that kind of stuttering is memory related and more classic stuttering. I am talking about 'microstutter', which is frame-rate sync related and manifests as jerky camera movement, somewhat reminiscent of watching movement under a strobe light. Very different, but equally inconvenient. That is indeed expected behaviour. Boris says though that with regards to reservedmemory, setting it too high reduces stutter but may also increase the chance for CTDs. So one should start with 64, see if it stutters. If it does, increase to 128, 256 etc. until stutter stop. This is the best procedure to find the optimal value, assuming you have correct values set in the other parameters. ReservedMemorySzieMB whould be 64 for 2 GB+ VRAM cards and 128 for 1 GB VRAM cards (per Boris). This should not vary much, and the other VRAM setting is probably more important for stuttering.

Nope, not at all. I was getting microstutter previous to using any ENB. Could someone please read the post above and confirm my findings under different GPU/RAM?

Looks good ... now you will just need to jot down the recipe on this thread ;)

I do like this for Core and don't think the extra slot is a violation. It is indeed balancing.

Perfect, Thanks!

Updated OP with new mem log version.