z929669

Do you intend the underscore in DynDOLOD_Output? Cannot create file "E:\SkyrimTools\_DynDOLOD_Output\textures\pbr\architecture\markarth\mrkrockdesigns01linear.dds". Maybe it should be: E:\SkyrimTools\DynDOLOD3\DynDOLOD_Output\ These things almost always reduce down to a simple thing.

What is your game resolution ...and monitor/desktop resolution (they won't necessarily be the same)?

Good to know. The paths can be simplified with: %USERPROFILE%\Documents\My Games\Skyrim Special Edition GOG\ BethINI is aware of this path when launched via MO, no? @DoubleYou

Re-enable all mods and plugins related to the Step guide, and sort with LOOT. Note any warnings/errors in LOOT. You most likely have a missing master or something like that. Pay attention to the MO warning icons on mods and in the app at upper right.

Using MO: Just create a temp folder somewhere for extraction of the archive.

I did some testing of the indicated DynDOLOD settings with respect to the Step SkyrimSE 2.3 build. Testing Parameters Step SkyrimSE 2.3 build Step Heavy ENB BethINI Ultra preset DynDOLOD settings used to generate different outputs are identical except for the setting tested Testing limited to Whiterun (other child worldspaces may have more/less pronounced outcomes) All comparison screenshots were created after loading a new game, so the position of the camera is slightly juxtaposed among like compares. ToD is slightly different but weathers are identical. In other words, compares were not captured via loading the same savegame, which is typically the best approach for screenshot compares. This is not the case when comparing certain aspects of different DynDOLOD outputs, since the plugins need to be reinitialized for each output in many cases. "Upgrade NearGrid large references to FarGrid" "Parent > child" "Child > parent 'Lose' vs 'High'" DynDOLOD settings tested Upgrade NearGrid According to the DynDOLOD documentation, "Upgrade NearGrid large references to FarGrid" should not be enabled if the large reference system is used, because it adds an unnecessary performance cost. SSE uses the LR system. I found only a slight performance difference and no visual difference: Upgrade UNticked-55 FPS Upgrade ticked-53 FPS ) I tested other areas with similar results with no performance difference at all in some cases. Note that I have a relatively high-end PC, so let's assume that small differences I see will be more significant on the average PC. Note that ToD in the second shot is probably closer to noon than the first shot, which is closer to 10 AM. This is why there are some shadow diffs. Step recommends: Leave this option off. Reference child/parent documentation for the following... Parent > child This setting indeed has a performance cost as a tradeoff for more accurate LOD seen outside of child worldspaces from the inside. Is it worth it? Probably not, but you be the judge. No p-c, c-p=high p-c, c-p=high Results show a 11 FPS hit for me, with the only difference being a few buildings and some near-ish rocks/mountain LOD visible from inside WR when enabling this option (see left-center of images). There was no performance difference outside the city walls (data not shown). Step recommends: Leave this option off. Child > parent Low vs High This setting had no performance impact for me. Nevertheless, the visual difference in these shots is extremely subtle. No p-c, c-p=high No p-c, c-p=low The only difference I could make our was that the LOD for Gildergreen and possibly some rocks are visible inside WR when High is used. Step recommends: Use the 'High' option, but the default 'Low' is probably just fine.

Just following up on this. I did some testing and confirmed that "Upgrade NearGrid Large References to FarGrid" doesn't have any consistent performance impact on my system. Some areas seem to gain a few FPS, while other areas seem to lose a few. I will continue testing this and a few of the other settings before arriving at a refined recommendation. Either way, we will recommend that "Upgrade NearGrid Large References to FarGrid" not be ticked.

https://discord.gg/32f353Jt

No. I don't have this issue. It's probably related to video drivers or something specific to the user config as I said previously. Consider posting on the ENB Discord to troubleshoot or seek answers.

Because the Step Patches take care of it. ... and in a way that applies to the Step build specifically.

Yep

You are not being 'obtuse' in the least. You are being pedantic, which I think is a good thing in these situations Again, I agree that we should NOT be ticking that box, so we will likely add change this in a future update or guide release. I would like to quantify the performance impact at least to some degree. Unfortunately, I have a fairly powerful PC, so I may not see much impact. I'd love to know the impact on a low to mid-end PC, but reason dictates that it would be more apparent.

Effectively, yes, Nexus Collections use the equivalent of a file hash using gameID, modID, and fileID from the metadata Nexus associates with each file since inception of their updated system (and is also available via the Nexus API). Presumably, this change was implemented to facilitate Collections (to circumvent the drawbacks you pointed out): https://www.nexusmods.com/{game}/mods/{mod_id}?tab=files&file_id={file_id} I'm not sure if Wabbajack does the same. However, files uploaded to Nexus are never unavailable if accessed this way, because they are all retained perpetually by Nexus. It became part of their policy a few years ago and caused a bit of an uproar at the time. Therefore, your valid assumptions are moot, given that one can identify a specific file on Nexus and always acquire it. Similarly, "latest version" is also possible to acquire. This metadata is used by MO and Vortex to alert the user when a file has been updated. Step recently adopted a policy to avoid using the file metadata in situations where mod authors might not want a particular file to be used (based upon the hidden reason); however, we still direct link to Nexus files in rare situations where the file would otherwise be unavailable. I have a better understanding now, and will keep an eye on the project. Thank you.

The "rule of thumb" is actually to tick the box "in case the LR system is not used" ...not untick the box. Also, with the BethINI Ultra preset, uLargeRefLODGridSize = 11 (it's 9 in the guide, because the guide recommends the BethINI High preset as a baseline before testing performance impact). We didn't find any performance impact with "Upgrade NearGrid Large References to FarGrid" ticked or unticked in our setup back in 2018--all else being equal. We did not do any extensive testing though, and opted for the "better visuals" option at the time. That said, it would be useful to do more thorough testing to determine if it matters visually and if there is any significant performance impact if it does. Keep in mind that we're talking about dynamic LOD, so you need to have large refs that are impacted by dynamic LOD to test visuals. Performance impact should be testable regardless though. Let us know what you find, but I agree that we should 'theoretically' not have this setting toggled in our GUI reference image. It's one of many things that are on the back burner.

I think I understand now, but I was just asking if SUMMON used AI to deduce EVERYTHING from the text of an existing guide ... or if the first step is to produce a completed, validated, error-free build and then use SUMMON to deduce and 'record' json instructions from the result (files/folders in the VFS or mod manager or whatever) which can then be reused by someone wanting the same build. Have you investigated Nexus Collections? They are Nexus' answer to Wabbajack and seem very similar to SUMMON. I don't know much about Collections other than they basically log the reference build via some instruction set that can be used by another to automatically create the build. It only works with Vortex now, but someone could write a MO plugin. I don't think Collections has the post-installation mod file 'awareness' functionality of SUMMON (i.e., keeping a detailed, post-installation 'diff' of mod files/folders so that the user knows what's been changed in the mods ...or can revert said changes). This is indeed cool functionality. Incidentally, Collections use direct links to mod files on Nexus, so versioning isn't an issue. The Collection curator is responsible for updating a given mod version used when updating the Collection. I would imagine SUMMON could leverage Nexus' archived files to get around any versioning issues where it matters. One of the tedious jobs of maintaining our guides is updating mod instructions, which often include significant changes to FOMOD instructions (see Embers XD update history as a case in point ...and these are just the changes we've made with respect to our 2.3 SSE guide). That mod has had tens or possibly hundreds of significant updates over the past couple years, such that previous instructions would be nonsensical to those acquiring the currently-available file(s). Collections get around this by referencing the archived file version, which never changes when the mod is updated (whether the mod page is unpublished or the file is archived/hidden for some reason). I was alluding to the "open source" concept here and wondering if the code base of the actual application (in addition to the plugins) would be publicly available. I assume the 'plugins' are the json scripts for mod-installation instructions. Given you work for an Irish company, the app may be proprietary, but the development of instruction sets will be open? I'm just wondering if SUMMON is merely an open-source component of an otherwise proprietary application or if the project is entirely open source. Just curious. Step welcomes innovation, and we support and advocate the 'cathedral' modding paradigm. That is not to say that we don't use proprietary tools, but we always favor open-source and "free to use" when there's a choice. Anyway, I find it interesting on a personal level and am following the project. Whether we use it in the future or not is an open question, but we're not really looking for an automated solution. Anyone is free to use it for installing Step builds just as they can do now with Wabbajack and Collections. We just haven't curated our builds for use with either of these tools, because it's a lot of additional work and maintenance for us.

Thanks for the added details. I'll ingest this over the next day or two and follow up.

As long as you are not advertising for 'company' or posting spurious links/information, and SUMMON is in support of modding and is open source --and will remain as such perpetually and independent of said company and having no other proprietary dependency-- I don't have any issues with your query. Just a few questions and comments regarding your GitHub: I'm still not clear on exactly what SUMMON is supposed to be. It sounds like a Py program that deductively arrives at cause (mod[s] installation details) from effect (installed mod[s]). I also see mention of post-installation manipulation by applications that modify or augment installed mods (e.g., NEMESIS, BodySlide, ACMOS-RG, DynDOLOD). But it's also being cast as a mod manager in and of itself. I would follow better if there were an 'objective' statement followed by a series of 'problem' and 'solution' statements. Maybe the focus right now is only the POC of a way to deductively rationalize a mod install? A hypothetical example might also help to clarify. "Support for creation of automated install guides" - creation of 'guides' (human-readable instructions)? Or perhaps you mean mod 'builds' (VFS configured/installed files/folders)? "estimates of the time needed to install them, are hugely underestimated." - I don't think we've underestimated. Our estimate is realistic if you consider all that we say and just follow the instructions without following all the shiny objects you will pass along the way. Step has never subscribed to "click & play". We've always been about "process & learning". Is the goal to read text guides and convert them into json scripts that are then used by the application to perform the installation(s)? What about mistakes in instructions and mods? And guide/mod revisions/versioning? Isn't there still a need for someone to first create/test the construct before SUMMON can be of use in reconstructing it? Is there an AI component? The Git repo is brand new as if it's been developed in a private sandbox up to now, so can we expect to see all development on Git going forward with a listing of contributors?

Download with mod manager option is no longer available for Resources Alpha-55. I'm hoping this wasn't intentional, as it overly complicates installation and instructions for doing so. It also prevents MO from automatically updating the metadata for proper version tracking.

I don't know what 'SME' is, and it sounds like an issue with that. No mod list should be reliant on a particular DynDOLOD Alpha version. Always use the latest version and then post in the DynDOLOD support forum with logs to troubleshoot. Only generate the LOD patch once your mod list and LO are final.

Shortly after loading a save, you get get a frame drop due to the game initializing. Wait 20 seconds and turn 360 degrees before testing a walk or a sprint. Do so (after loading the save) from the same starting point and going in the same direction. Your GPU software may have a logging feature.

I see your FPS dipping but not really in association with walking/running/sprinting but rather when plugins/scripts/MCM initialize. You should test on the WR tundra from a specific save and moving in a specific direction in the distance and begin testing only once all of the messages clear when loading the save. Test running far enough that another cell loads and well into that cell. If your drivers support logging, then do that and save/clear logs after each test so that you can examine the results in a spreadsheet for the two nearly-identical tests (but for walking vs sprinting). Your walking distance will take longer to reach the same point and have more log entries, obviously. Panning up/down/left/right will spoil the results to some degree so avoid that. I recommend using the automove functionality (I forget the kb button for that or if you can do it while either walking or sprinting as desired).

It has to be that MO metadata has this info, but the plugins are not located where they are expected. It's as if the game location has changed.

First, please upload all relevant logs as described in the OPs and parent forum Guidelines. It helps to delete all previous logs and retry all launches via MO to generate smaller, fresh ones. Don't rename the executables, and don't downgrade MO2. Those are not the issues. My own working examples (lattest MO2 and software): I suspect Windows Security is the problem, since you get the warning when launching outside of MO but no opportunity to bypass when run through MO. Disable Microsoft Defender and reboot to test: For some Windows Security hints, see this post. I use ESET AV rather than Windows Security defaults like Defender.

For the image insertion to work, you must use the direct link to the image file, not shortcut, which they use to force the user to their site and branding. Simply right click on the image and "copy image link" to get the direct link. Here it is: not found error MO screenshot

We obviously don't know much about it, but it's been discussed around here. Maybe there's something helpful.