z929669

I am finished with my edits to the guide: Removed redundant information that already exists elsewhere on the wiki:Offloaded ENBoost quickstart to the mod page and replaced with brief description and link to mod pageOffloaded all enblocal.ini section/parameter descriptions into their own subguide (same as ENBseries INI subguide)Removed most of the INI-section/parameter descriptions due to redundancy with ENBseries INI subguideReorganized some of the chapter hierarcies and headingsReformatted applicable path strings to use HTML tagsResized a few images and removed others that seemed totally redundant.Regarding redundant info duplicated throughout the wiki: It is best to either link to a single source from ancillary doc or create a template to hold information that we think should be reproduced in more than a single location. The problem is that one location will be updated, but the other will not, which leads to conflicting info (=bad). Better to manage in a single place, as it reduces potential for error and significantly reduces the maintenance burden. Some existing elements are already reproduced in various locations (e.g., Skyrim INI settings, GPU driver settings, others). EDIT: There may be an extension to handle centralizing text snippets from normal pages to be transcluded into other pages for reuse: Labeled Section Transclusion

Sounds like a caching issue ... did you hard refresh? What is the page location for the source image and the page location where you are trying to call it?

STEP does not recommend ENB, so any shadow-striping issues will need to be addressed without ENB. I am installing STEP:Core for the thousandth time now, so I will see if I get striping or not and come up with a solution if Tech et al do not have a solution already.

Nevertheless, that really looks like the FloatPointRenderTarget issue ... Are you running MO? If so, are you editing the right ini (i.e., in Profile rather than the main INIs)?

Yes, we will use this. Thanks for the notification ... I have not touched that guide yet, so it will be awhile before I get to it ;)

We could also start looking at the user system specs and recording the info that way ... or we could even associate "known bugs" toggles with video cards and capture Semantically once the member enters their system specs into the wiki.

Ahhh ... that looks like bFloatPointRenderTarget=0 in SkyrimPrefs.ini ... set to '1' ;) EDIT: as a side note, for some strange reason, we had instructions in the main guide to set to '1' :/

I was referring to the OP-er ... and I too have long know the suppositions around the wrapper versus injector version, but for the past 3 years, all I have ever seen is a black box without any specifics as to why the wrapper version does not work with "some cards" ... ... why? what cards specifically? This info would be nice to have so that we could head those use cases off at the pass (so to speak)

Could someone please confirm this? I know there is an "injector" version, but if the wrapper version does not work, it is almost certainly due to a configuration error. The injector version is probably side-stepping the underlying reason that the wrapper version does not work. ... that is, unless someone can explain exactly why wrapper version does not work under specified conditions but injector version does.

Not sure if it has been mentioned here on this thread or if it applies to the issue stated in the OP (sorry, no time to read through this entire thread), but look at this piece of the ENBlocal INI guide and note the warning.

Duly noted. I will update accordingly. Thanks!

My first pass for the day (I think) is complete. Removed ENBlocal "Quickstart" section content (we already have it on the ENBoost mod page, so that is linked instead)Removed "Enblocal.ini" section content and ported to INI Guides/Settings pages as we do for ENBseries INI (replaced content with a link to subguide)More later tonight or tomorrow ...

Yeah, sorry about that ... Thanks for the updates. Once I am done (may take awhile), maintenance of this guide should be greatly simplified. Currently trying to compact info that is reproduced in several places. Taking a break now, so content should be fairly stable for a couple of hours ;)

I am doing an extensive readability overhaul of this guide. Why? Because I am currently following STEP 2.2.9 in laborious detail, using all guide articulation to mods and ancillary guides/info and noticing that some aspects of this articulation and content are quite difficult to follow. What I am changing: altering document flow properties and general organization so that it is easier to readorganizing headings so that information is easier to findenhancing articulation with other site guides and infoincreasing consistency with how we handle presentation in other guidesWhat I am NOT changing: content (other than fixing typos and syntax)links to external info

I am pretty sure that $wgEnableParserCache must be set to 'false' to allow the functionality intended by that extension ... that would be a big performance drain and likely why we aren't using it.

EssArrBee hosts the patches on Git, but I am not sure how easy it is to determine changes made to each commit or how detailed he was about including notes on changes in the very first patch. The STEP Patch wiki page may address though.

OK, got it. On another note, I think this thread has lost any relevance, eh?

Skyrim requires DX9 I think, so DX11 should not be running anything to do with Skyrim (would that it could). Are you supersampling? NVIDIA has many driver-based settings for AA/AF, so you might want to verify and test some variations. I use AMD, so no help here. It's (probably) not the OS and almost certainly your GPU and/or driver settings, but it still could be something you have set in one of your INIs.

@fireundubh Not sure if you had second thoughts on the name or not, but if you want to name it anything other than xEdit, now is the time ... before it begins catching too much. Then we will sync that name all around. Otherwise, all is well.

BETHEdit (or BSWEdit) seems to follow the nomenclature better, IMO. I had no idea what xEdit referred to when I first saw it. I would have guessed what BSWEdit was though.

Since this is asking about the functionality of the tool that is being discussed/tested within this topic, I think it is perfectly on topic. The OP links to the tool's description and download. Use this tool to modify the headers of your plugins to include the 'correct' bash tags so that WB can (more) appropriately construct the Bashed Patch without having to enter the bash tags manually (and possibly incorrectly or incompletely), since LOOT-WB apparently don't handle this ideally right now:

Once you do, please post your findings in the STEP Patches subforum thanks

Correct. I must manually copy the saves amongst the profiles. Symlinking is the most elegant method, but I would use WB to MO only. An alternative is to set up a batch sync between folder pairs as a task at some frequency. Yes, not advisable for anyone but testers EDIT: I may give symlinks a try myself after testing a bit more of the behavior without. Will let you know what happens. Note that another issue is that save and profile folders at either location have inverse relationship to the other. Seems like infinite recursion may be possible with wrong symlinks. Each folder would need to symlink I think without recursion. Not sure though.

I have copied saves from amongst all of my MO and WB profiles, and they show up as expected when launching WB stand-alone or via MO. I am not sure that symlinking MO profiles to %USERPROFILE%\Documents\my games\skyrim\saves\ would work as expected, due to MO virtualization nuances that I don't understand; however, symlinking %USERPROFILE%\Documents\my games\skyrim\saves\ to .\Mod Organizer\profiles\\saves might be better. The profile glitch you speak of is not manifest in my setup, so I question whether or not the symlinks you had set may be the culprit.

OK, I recently reinstalled Windows and am running on a clean system. When I launch WB (Py version, using launcher) directly, I get exactly what I expect. I have no profiles set under WB, so I see none, and I have not generated bashprofiles.dat. WB default save-game directory is under %USERPROFILE%\Documents\my games\skyrim\savesand MO's is under .\Mod Organizer\profiles\<profilename>\savesI set my directory locations in MO exactly like I set them in Bash.ini, so either way I launch, I see different save games. I created a new profile under WB stand-alone, and this created a blank profile with assets located in a like-named folder under my WB save location. If I run WB through MO, I get exactly the same behavior with respect to all aspects but for two fundamental differences: MO virtualizes %USERPROFILE%\Documents\my games\skyrim\saves\ as .\Mod Organizer\profiles\\saves MO virtualizes \Data as Everything above these directories is identical from the WB viewpoint, but everything below them is dictated by independent user profiles and game directories. Since this is all configurable, and you have messed around with Windows symlinks of certain folders, you very well may have relics causing strange behavior or something related to directory locations. If you made any other config changes to either MO or WB, then that could be the issue as well. I would save all of my profile info under each and then recreate fresh folder structures and uninstall both programs completely. Then reinstall and copy the files (less their parent folders) back over and try again. I am assuming that you have all of the WB dependencies installed ... there should be 3 I think ... Python 2.7, PyWin, and ComTypes. Your config may seem OK now, but I would not trust it ... nor would I want to track down the root cause in your situation. Anyway, you probably know all this stuff, but I have played around enough with WB to have been burned on my config errors more than once over the past 9 years or so ... especially the Python versions for Oblivion, when you could install all kinds of addons to enhance functionality.