Jump to content

Mousetick

VIP-Supporter
 View Profile  See their activity

  • Posts

    1,268

  • Joined

  • Last visited

  • Days Won

    112

Everything posted by Mousetick

  1. Mousetick
    Who said it was a bug? Nobody. This is the Feedback and Bug Reports topic. If the guide's goal is to educate and serve as a "best in class" modding reference to STEP users and potentially to the community at large, but it provides incorrect, wasteful advice, it's a problem. Not a critical issue, though, I agree. I'm not following. Terrain LOD textures are generated from scratch by xLODGen from the full landscape textures. Nothing else uses the terrain LOD textures beside the terrain LOD meshes. How does it matter if the landscape textures are mipmapped or not? That has no bearing on whether the terrain LOD textures should/shouldn't have mipmaps, or whether the game uses them.
  2. Mousetick
    Now you want to undo the whole thing? That doesn't make much sense. Restore the original plugin from backup. Manually remove the 'Initially Disabled' flag from the trees you want to keep first. Then run the script you originally asked for to permanently disable everything else that is Initially Disabled and doesn't have an Enable Parent.
  3. Mousetick
    In case you miss it:
  4. Mousetick
    I just wanted to confirm my understanding and vet my assessment with you first so I wouldn't look like a clown by providing erroneous feedback. Also as you know the STEP Guide folks are the same crew hosting this forum, and they regularly read this topic, so by posting here I could kill 2 birds with 1 stone Thanks.
  5. Mousetick
    Very interesting discussion about LOD4 Optimize Unseen. I'd like to bring up another point: From https://dyndolod.info/Help/xLODGen#Generating-Terrain-LOD-Textures: Sorry to ask, but "Skyrim" and "the game" can be a bit ambiguous. So just to make sure, can you confirm this applies to Skyrim SE? The STEP Guide which I've been following up to now for Terrain LOD generation instructs to enable mipmaps for LOD 4 normals: This seems incorrect, then. Harmless, but a waste of time (longer generation), of disk space (larger texture files) and possibly VRAM as well. What about LOD 32? Does it differ from LOD 8 and 16 regarding all mipmaps being useless? The STEP Guide instructs to enable mipmaps for both LOD 32 diffuse and normals: This looks incorrect, too. Thanks.
  6. Mousetick
    You don't need to be good at scripting, simply edit with a text editor to match the right side of the comparison. Looks like you missed some pieces or put them in the wrong place, though.
  7. Mousetick
    Slightly better and safer version which skips Initially Disabled references if they already have an Enable Parent: As discussed above, the script doesn't check if the reference might be used any other way by the plugin, which would require cross-referencing the reference in the plugin. I'm not willing to spend more than 10 minutes on this, so this is the best you'll get.
  8. Mousetick
    The context wasn't clear in your OP. You may know exactly what you're doing but random readers may not and could get the wrong idea. You can do it yourself, it's not very complicated. Copy the existing Undelete and Disable References.pas to Permanently Disable Initially Disabled References.pas. Edit Permanently Disable Initially Disabled References.pas as follows (left side is original script, right side is edited version): Only the differences are shown above, everything else remains the same. Load the plugin in xEdit. Right-click on the plugin, select 'Apply Script', choose 'Permanently Disable Initially Disabled References', click OK. Done. Save plugin. The messages window will display the list of modified references, for example: The xEdit script seems to work fine for me but YMMV. USE AT YOUR OWN RISK.
  9. Mousetick
    I'm not 100% sure but I think the green poison status icons are only visible when the weapon is in the player's or an NPC's inventory.
  10. Mousetick
    Those console commands cannot modify the object. That's impossible. Either you applied a poison and forgot about it after you lost the blade or it became stuck, and panic ensued, or a dragon fairy sneaked in and applied snake oil while you were sleeping. You never ever used poison or noticed the green icons on any weapon before while playing Skyrim? Hard to believe, but why not. I'm not judging. Anyhow, the poison will be consumed the next time you successfully strike an opponent with the blade. The green inventory icons will also disappear. Until next time you apply poison again.
  11. Mousetick
    This is true when the goal is to permanently disable an object not used by the mod in order to completely remove it from the world. There are other cases where a mod may initially disable an object, which may later be re-enabled: By a Papyrus script. By an Enable Parent. In these cases, setting Enable Parent opposite of Player and Z to -30000 would break the mod. So an automated procedure is not possible without analyzing how each initially disabled object might be used, or not, by the mod. In the worst case, an initially disabled object might be enabled by a Papyrus script but its usage be "hidden" from the mod plugin, because the script hardcodes the RefID of the object instead of passing it as a script property. This is a very bad practice, which fortunately is uncommon nowadays, but it exists, particularly in old mods. This case cannot be determined without reading the Papyrus script source code. So if you've determined and are absolutely sure that the mod doesn't use the object at all and it doesn't re-enable it by any means - which is by itself a time-consuming process - you can flag it in xEdit as Deleted in its record header. Once you're done with all the Initially Disabled objects, you can just run the plugin through xEdit QuickAutoClean which will automatically change Deleted objects into Initially Disabled + Enable Parent opposite Player + Z = 30000.
  12. Mousetick
    Yeah, that's exactly it: snake oil! LOL. (Seriously: yes, it's poison you applied)
  13. Mousetick
    According to the mod Bloodskal Blade - Tweaks and Enhancements, which I use, the energy blast effect only works on the blade instance obtained during the quest. This would explain why it doesn't work on a copy added via console: No specific idea about the blade disappearing when dropped. Don't drop it, stash it in a container instead I rarely drop items, except when I need to look at them with the console. Sometimes they disappear into the ground or floor, it can be anything: book, potion, food, weapon... I don't know why. So I always save before dropping any item I know I'm going to pick back up, and retry elsewhere if needed. About the weapon rack: this discussion (reddit) may provide some solution(s). If you've lost the blade forever, or it's stuck in the rack forever, you could give the aforementioned mod a try. MAKE A SAVE, install, enable, load, grab a new copy via console. If it works, great, keep the mod enabled, but be mindful of that mod's other changes and tweaked mechanics. If not, disable, uninstall, and reload the previous save. Alternatively, you could try to retrieve the dropped and disappeared blade instance from the quest by moving it to you via console. Make sure you stand on clear flat hard ground. If it works, it should appear at your feet. prid 0401E201 moveto player
  14. Mousetick
    OK, makes sense. This brings more questions Is the size (X/Y/Z dimensions) of the combined chunk by the underwater triangle optimization a constant or a function of the LOD mesh quality? If it's a function, wouldn't it make sense to use a low x value (e.g. 25 for LOD 4) for optimize unseen with high quality (e.g. 5 or greater for LOD 4) to prevent z-fighting and avoid steep drops while retaining some not too flattened detail?
  15. Mousetick
    Thanks for the clarifications. Is the following picture a correct representation of what might happen as a result of using optimize unseen = x? x is the depth at which the terrain LOD is sunk. But what characterizes shallow vertices? E.g. at what distance from the water surface is a vertex considered shallow?
  16. Mousetick
    I understand what 'Optimize Unseen' does but I'm not knowledgeable/smart enough to determine by myself what is best or why, so I follow others' recommendations in this regard. Would anyone care to explain the difference of opinion between sheson and Z, specifically for LOD4, and the reasons why they both might be correct under different circumstances or considerations. I should point out that xLODGen's default 'Optimize Unseen' is OFF for LOD Level 4. xLODGen and DynDOLOD's defaults are usually pretty good for all users in general and balanced for 'good enough' quality with minimal performance impact. Thanks.
  17. Mousetick
    Typically mods which require XPMSSE specify whether they only require the skeleton resources (i.e. without the plugin) or the whole shebang (i.e. with the plugin), or something in between (mainly for the physics stuff). Those that I've come across or use(d) in my experience only required the skeletons. I don't care about boob/butt/shlong physics and stay as far away from those mods as possible, so my experience with XMPSSE-dependent mods is quite limited. Better ask the mod authors themselves, who probably have no clue, especially regarding the new XPMSSE 5.0x version.
  18. Mousetick
    Thanks for all your clarifications. I understand now: copy/overwrite: low priority overrides for DynDOLOD ESM that can be overridden by mod plugins copy2esp/overwrite2esp: high priority overrides for DynDOLOD ESP that win over everything else Instead of following your suggestion I opted to forward the changes into a separate plugin using xEdit, so that I could easily test the changes by enabling or disabling the plugin without performing a DynDOLOD generation-update pass: Your 'Force Hide Land' fix really improves the view outside the walls. It seems the defects or the fix can only be noticed if the player flies/glides or somehow manages to climb over the walls or buildings, otherwise they're obstructed by them. This was taken by disabling collision and walking on the wall: Without Fix > With Fix However I managed to find a spot where the defect is visible from inside the walls, without performing unnatural acrobatics. I simply stepped on a small ledge: Without Fix > With Fix But one has to really pay attention and look hard to notice. There may be other viewing spots like that inside the walls, I didn't find them. Anyway, I'm going to keep forwarding the fix -- Following are thoughts to be taken with a big grain of salt. Feel free to skip, or read at your leisure during your coffee break. As noted above, the missing landscape defects appear to be hardly noticeable in normal gameplay, so the issue is arguably not worth sweating or losing sleep over. I'd like to point out a couple of shortcomings about the "any non vanilla plugins changing the areas/cells should win any conflict" rule of thumb used to apply the fix. You're probably already aware of them: Due to the position of DynDOLOD.esm in the load order, the rule is actually: any non-vanilla non-ESM plugins changing the areas/cells should win any conflict, in which case the fix is not applied, while non-vanilla ESM plugins changing same the areas/cells "lose" and the fix is applied. Which doesn't really make sense, because ESM or not ESM does not indicate how specific plugins might change the areas/cells or how they might visually conflict with the fix. The rule doesn't account for (potentially, but unlikely, extensive) changes made to the areas/cells by mod plugins in the persistent cell of the worldspace, since it considers only conflicts with the specific cell record. The approach is very conservative in order not to break anything with random load orders, but it means the fix is not applied for the majority of (non-ESM) mods which make very few or minor changes, or changes only inside the walls - changes which actually wouldn't be affected at all by the 'Forced Hide Land' fix. A somewhat ambitious idea for an alternative approach: Refactor the patching infrastructure to make it dynamic / conditional / context-sensitive. In its simplest form, tailored to this specific patching issue, a mod plugin blacklist is used rather than relying on the cell conflict rule of thumb. The patch is not applied if the loader order contains at least one mod plugin listed in the blacklist. The patch is applied to DynDOLOD.esp otherwise, so it wins over all other plugins in the load order. The contents of the blacklist need to be determined empirically. In all likelihood, only very few mods would need to be blacklisted, e.g. the Big City Overhaul type of mods. Would the amount of 'plumbing' work to implement this approach be justified by the minuscule 'Force Hide Land' fix that most users may not notice? Arguably not at all. I'm just throwing the idea out there anyway. Also once the 'plumbing' is in place it could be reused or extended to handle other dynamic patching scenarios... I can't think of any reasonably feasible heuristics- or analysis-based approach. Like the exceptions for the Parent > Child copying, it seems to be way too complicated to handle algorithmically. ChatGPT maybe? (joking) Thanks for reading.
  19. Mousetick
    It was harmful in previous versions and required a bunch of fix patches that didn't completely solve all the troubles. In the new 5.0x version, choosing 'Basic' or 'Minimal' installation options still install an ESP plugin, but it's "harmless" in comparison. Whether it makes a positive difference vs. no plugin at all is open to debate. Unless you'd like to thoroughly test the behavior of ragdolls (and other possible side-effects) in-game with vs. without this plugin, and report your observations, it's recommended you don't use it. See this earlier post for more details.
  20. Mousetick
    Thanks for the explanation. I must be missing something, but I don't understand the reasoning or the rule of thumb. Here I have unhidden some mod plugins to the left of DynDOLOD.esm: Let's assume CWRepairs.esp is not in the load order, this would give: In which case, the changes from DynDOLOD.esm would apply. If the DynDOLOD.esm changes are considered to be OK for USSEP and OK for Legacy of the Dragonborn, why wouldn't they be OK for Civil War Repairs as well? Or taken from the opposite perspective, USSEP and Legacy of the Dragonborn are "non vanilla plugins changing the areas/cells", and yet DynDOLOD.esm changes win over them. I understand this is an extremely complex and inextricable problem to solve generically when dealing with arbitrary load orders. A 'perfect' solution may not exist. What if hypothetically I wanted the DynDOLOD.esm changes/fixes to apply to my mostly vanilla Windhelm load order, on which I used the Parent > Child feature. Could I forward them into a custom patch so they're not lost? -- I noticed a similar loss of DynDOLOD.esm change, unrelated to previous: arnimaDUPLICATE003 "The Reach" [WRLD:XX000D62] (from Beyond Reach) DynDOLOD.esm changes the LOD Water Type. This change is unique to DynDOLOD so it must done on purpose. But it's lost because it's not forwarded to DynDOLOD.esp. Is this for the same reason as above? I.e. "It is assumed that any non vanilla plugins changing the areas/cells should win any conflict." Thanks.
  21. Mousetick
    DynDOLOD 3a134 / Resources 3a38 / DLL NG + Scripts 3a11 Not a problem report per se. Wondering if the observed plugin output is expected, as it doesn't look "right" in principle. I don't know how that translates practically in-game. DynDOLOD.esm makes some changes to the 'Force Hide Land' flags of some WindhelmWorld cells. These changes must be done on purpose by DynDOLOD because they're not forwarded from any previous plugins in the load order. However they're not forwarded to DynDOLOD.esp, so they're lost due to other plugins overwriting DynDOLOD.esm. WindhelmPalaceOfTheKingsExterior [CELL:00038380] (in WindhelmWorld "Windhelm" [WRLD:0001691D] at 32,10) [CELL:00038384] (in WindhelmWorld "Windhelm" [WRLD:0001691D] at 31,10) (Some mod plugins to the left of DynDOLOD.esm were hidden so that the remaining could fit in 1 screenshot) Full logs here if needed: https://drive.google.com/file/d/19EQbVwyzUSpR3ReaOWITDJFmMuKv5JYF/view Apologies if this is a stupid or not pertinent remark. Thank you.
  22. Mousetick
    I've been using this mod for a long time. But I've also been using Relaxed Bards at the same time for even more peace and quiet. Relaxed Bards prevents bards from initially auto-playing, they only sing or play an instrument when specifically asked to by the player. After completing the player's request, they can start auto-playing, or remain idle, depending on Relaxed Bards' configuration (via MCM). If they're auto-playing, they can be asked to stop via dialogue.
  23. Mousetick
    Right. It's not a big deal for STEP users IMHO. But you could use DDDM console font for your own setup. As you said it's monospace, but it has also a lot other small tweaks for better legibility of computer code-like text, such as slashed zeroes to distinguish from capital o: 0 vs. O DDDM console font is Windows' built-in Consolas font converted to SWF format for SSE. If you want to use it for your own setup: Copy Font Overhaul's interface\fontconfig.txt to your personal config mod folder. Edit as follows: There are "reskins" of DDDM that may be more appealing to a broader (and younger?) user base: Immortal UI - (Dear Diary Dark skin) New Horizons UI - User Interface Overhaul Untarnished UI I don't like any of them, but I think the last one is the highest quality and best looking.
  24. Mousetick
    The size of the splashes can be tweaked in the configuration. I agree they're way too prominent by default. I reduced the size in the configuration, for example: (For illustration only, Not all settings shown) The above suits me but they could be even smaller if desired. Or they can be disabled for certain weathers (e.g. Light Rain). There is also this mod: Rudy fix for Splashes of Storms and ENB which allows for tweaking the splash effect via ENB settings. I don't use ENB so I can't comment on its usefulness/effectiveness.
  25. Mousetick
    Successfully fixed Thanks.
×
×
  • Create New...

Important Information

By using this site, you agree to our Guidelines, Privacy Policy, and Terms of Use.

  I accept