Jump to content

z929669

Administrator
 View Profile  See their activity

  • Posts

    13,028

  • Joined

  • Last visited

 Content Type 

Everything posted by z929669

  1. z929669
    Those are Kryptopyr Patch Hub plugins. I just checked that wiki page, and they are correct since summer for 2.1.0, so maybe you need to grab them still. That mod is tedious to install with all the different files.
  2. z929669
    Echoing DY in part here. I'm not sure if it's always been that way, but this very thing was pissing me off just the other day. It's definitely a bug. I got around it by copying my source from the post I'm was currently editing (so as not to lose it) and pasting that into TextPad. Then I quoted the post I wanted in a new post, went into source mode and merged my saved source. Frickin' annoying to say the least. Hopefully will be fixed in a release, but I will point their devs to this discussion to make them aware of it if they aren't already. The time limit for merging double posts is 5 min. After that, it will be a new post.
  3. z929669
    Thanks .. but it shouldn't matter if they are LRs or not. They are REFR records in worldspace, so shouldn't some of my changes trigger the DynDOLOD warning regardless? This is the gist of the whole debate around which some people cry foul for DynDOLOD reporting non-issues ... the issue being "general bad practice" and making the LR bug possible whether manifest or not. I don't question the ESM in the least. I was just wondering about the ESL and the need to forward the ESM records. I also forgot to acknowledge that it's not a light master but just a light plugin (ESM flag not set). So I'm probably fixating on it being an ESL and was incorrectly presuming it to be a light master. So regarding ESM/ESM-flagged plugins: I think I understand the significance that ESM records are locked into memory at runtime and for the duration, while non-master changes are transient in memory, correct? Using a master-flagged plugin ensures that the changes are 'baked' at runtime, I assume? Which is important for this particular mod's functionality (and any mod that adds new worldspace records or possibly 'new' anything)?
  4. z929669
    MorrowLoot Ultimate is an excellent concept, IMO. It makes the game so much more enjoyable and addictive (like an RPG should be). For my personal build, I also prefer ultra realism granted by mods like Requiem. I haven't touched that mod for a long while (still waiting to perfect Step SSE), so I don't know if that mod makes similar changes to de-level and 'mystery-orize' powerful loot and equipment as was done in Morrowind and RPGs of old (before new-age 'entitlement' loot became popular ... Destiny 2 is a great example of this sad trend). "New-schoolers" want to hurry through and 'beat' as many games as possible as quickly as possible these days, getting all the buffs and bragging rights inherently just by playing ... no thank you very much.
  5. z929669
    Using the 2.1.0 SSE guide I assume? The 2.2.0 DEV guide is a WIP and will not work for most people without tinkering with custom patches. The 2.1.0 CACO masters are: So maybe you missed one of these? What does MO say about this?
  6. z929669
    I checked 06F26D, and this isn't forwarded into the ESL. Did you intend otherwise? I'm not challenging your logic, but rather trying to understand by relating to what I'm seeing: I also did some testing for DynDOLOD errors by creating/enabling a test plugin and disabling your ESL then ran DynDOLOD: Forwarded a few of the REFR records (persistent and temporary) into a test ESP (NULL flagged, "WTT test.esp") Made edits to a few of these records: Left most of the persistent records alone (just forwarded into ESP) Added Deleted, Initially Disabled flags to 06A131 (persistent) Added Initially Disabled flag to 06A132 (persistent) Removed Initially Disabled flag from 06F294 (persistent) Added Initially Disabled flag, set Enable parent to opposite of player, set z to -30000 on 034355 (temporary) - essentially created a UDR as I understand it Added Initially Disabled flag to 06F295 (temporary) Here's the overview: The DynDOLOD warning/error report only identified the Deleted reference (#2) as an issue: Error: Deleted reference WTT test.esp [REFR:1006A131] (in GRUP Cell Persistent Children of [CELL:00000D74] (in Tamriel "Skyrim" [WRLD:0000003C])) Since the other worldspace records I tested in the test ESP did not trigger any DynDOLOD large-reference warnings, I'm thinking that your ESL isn't really needed to suppress DynDOLOD errors. Admittedly, I find the Large Reference triggers and issues a bit confusing still, so have a look at my answered questions on this topic if you want to learn more. It may make more obvious sense to you. Although not all/any of the records I forwarded are necessarily large references, DynDOLOD should call out issues regardless. I was expecting a couple of the records I forwarded to trigger DynDOLOD errors (e.g., #3 and #5), but they didn't. Maybe someone who understands this better like @Mousetick or @sheson can provide some instructive insights. I haven't had my "aha" moment yet on LRs (but I'm close I think). I assume it has something to do with ESM setting this in memory at runtime 'permanently' versus ESP (ESL?) doing so dynamically/temporarily, but this is a wild guess. Ultimately, I'm questioning the current implementation of the ESL and if it's necessary (I had thought one should be creating an ESM to hold the LRs and an ESP to hold their overrides into distinct, new records). Take no advice from me at this point! ... next, I will see about implementing the plume option as you suggested. Haven't taken that up yet, so I cannot speak to it.
  7. z929669
    This is very helpful. I'm going to let this sink in a bit and read over your WTT content again. Thank you!
  8. z929669
    I see your point. In that case though, I would have said: Delete the contents of your INIs. Don't forget to use BethINI (especially if you are not familiar with game INI files/file-locations/editing). All of your issues in this regard will be moot, and you will never need to mess with or be concerned with them in the future. Your problem setting made its way into your Skyrim.ini by you yourself either editing that file directly, your copying/pasting one from the internet, or possibly some overly-invasive script or tool or process you used to do an "automated" install like Wabbajack or something along those lines. I can think of no other way that this could possibly have been accomplished.
  9. z929669
    Tested and works nicely. I think it's a great addition. For those that have used this and Viewable Faction Ranks: What does that mod offer that this one doesn't? This mod seems more comprehensive on cursory examination, so I'm inclined to use only one (i.e., this one).
  10. z929669
    You will need to either ask the authors of this mysterious guide (maybe it's outdated or instructions are 'loose'), or provide the log files and details required to assist (see forum rules and DynDOLOD OP for requirements and links to more information)
  11. z929669
    Hey @Sacralletius, I'm working on some of our latest patches and wondering about the late-loading WTT ESL and it's purpose. I did see your note that it "ensures all worldspace data gets forwarded", but I guess I don't understand. We'd rather provide the option to hide the plume from Tamriel via a optional plugin patch than deal with the console (it's just simpler for our guide instructions and support headaches). When I look at the ESL though, the only conflict between your ESL and the ESM-flagged ESP is that one single record. So two questions on this: This one conflict seems to disable the plume from DLC2SolsteimWorld PoV (04000800) just to make it visible from that PoV with the ESL. What's happening here? Why are all of the other worldspace blocks/records included in the ESL when they are identical to those in the ESM (and they have no intervening conflicts with other mods in our lineup, which tells me that intervening conflicts would be very rare for these records). I'm guessing this has something to do with PoV from either side (Tamriel vs Solstheim), but I don't understand it! Now to the plume visibility from Tamriel (0000003C) ... we are hiding it via optional plugin like so: It seems to work fine, but is there any theoretical issue you know of doing it this way? I ask because you added a method to do it from the console rather than like this.
  12. z929669
    I thought I already said the same thing?
  13. z929669
    Confirmed. Rather than work around this, I'd like to report it to the MA. EDIT: Reported. Thanks both for the closer looks.
  14. z929669
    Yeah, I noticed this too and decided that Dr Monops must've purposefully made the changes for some reason. I did not investigate further. WACCF wins in our LO (these specific meshes are not in the WACCF BSA). Those choosing not to use WACCF will get Leanwolf's version.
  15. z929669
    I don't know what those screens are supposed to be showing. The line is uGrids loading transition, I assume. The lighting/colors are completely different, and these shots are not taken at load of the same savegame. If you generate terrain LOD, then you should have a mod with that output that can be enabled/disabled, loading the same savegame and getting a screenshot with that mod enabled/disabled. This would show the precise differences based on the exact same viewing angle, time of day, and weather. Furthermore, if you have such output from xLODGen, then it worked, and you will have terrain LOD meshes and textures based on the mod list used. Before/after should show a difference. I guess I'm not really sure what the question is, but I can glean nothing from any of the screenshots posted other than they look very different. Terrain LOD are not pretty and don't look great either way. The main purpose is to generate proper meshes/textures and contours to match the mods installed. It's just the canvas on which all other LOD will be rendered later.
  16. z929669
    Terrain LOD Redone is modifying things in addition to terrain I think (like mountain LOD meshes maybe). Just ignore that mod, since it has nothing to do with xLODGen, which is a superior method. Yes, it does also generate textures. read through the OP to discover what the mod does and how to use it.
  17. z929669
    You shouldn't be using terrain mods like Terrain LOD Redone if you are generating terrain LOD based on your mod list using xLODGen. Just install all of your mods (including any landscape mods you use but not any terrain LOD mods), and run xLODGen to generate terrain LOD corresponding to your mod list. Please read the OP completely to get a sense of what is accomplished. xLODGen simply yields terrain LOD meshes for your mod list that are better and more accurate for your mods. Once completed and enabled, then you can run DynDOLOD for object LOD and more accurate occlusion based on your mod list (now including the xLODGen terrain mod)
  18. z929669
    Jumping in here since you seem to be linking to an old version of some of our xLODGen settings recommendations (and referring to this as skyrimprefs.ini, which is incorrect). First, Step's recommended xLODGen settings relate to using Cathedral Landscapes as the main landscape/terrain mod. If you are using anything other than CL, then our settings probably will not be ideal. Also, the post you linked is very outdated and no longer apply. The most recent recommendations are in our most recent guide linked at top of forums. Again, this relates to the Step SSE mod list and load order. Second, you should not be testing terrain LOD before/after with DynDOLOD active. This obfuscates your ability to see the actual terrain LOD difference, which itself is very subtle visually. Don't expect a big difference to your terrain LOD before/after xLODGen. The most noticeable differences will be the shape of rivers/lakes/coastlines. To test, disable any DynDOLOD/TexGen mods and get a screenshot of something that shows a lot of terrain LOD (like the tundra from some slightly elevated point. like just north of Whiterun looking West). Create a save here and get a screenshot. Then run xLODGen per instructions in this OP and load that same save and get a screen for comparison. It won't be a huge/obvious improvement. It will be subtle as mentioned. xLODGen is for terrain LOD. DynDOLOD is for object LOD done later.
  19. z929669
    2.2.0 nstructions updated likewise.
  20. z929669
    I just checked this and updated this mod's and LW's wiki instructions accordingly.
  21. z929669
    Same. We'll likely need to update the instructions again, since I'm sure the SKSE folder will almost certainly be fixed soon. I also reported the texture naming issue, so that will likely also be fixed soon as well.
  22. z929669
    Keep in mind that if you want to go the the forum topic for a given mod, you should go to the wiki mod page to find the convenience link:
  23. z929669
    Given these issues, we'll not be using the latest version until fixed. In the meantime, I'll review the changes.
  24. z929669
    Ugh. I will need to take a look and see how this may or may not impact latest patch in development.
  25. z929669
    This was exactly my interpretation, and I thought I had phrased my original question in such a way as to imply this ... but perhaps not well enough. I was hoping to avoid experimenting with it to elucidate the behavior (potentially erroneously) by instead asking for clarification on this Even with the clarifications of the above responses, I'm still not entirely clear if vanilla tree replacers that include overrides to vanilla trees defined in the vanilla ESM are expected to yield their trees as large references when "Large" is ticked. But it would seem that "Large" should have no impact on mods like this (HLT, EVT, SRO, and most tree mods ... I am not aware of a single tree mod that uses ESM to define new trees, but I have never explicitly checked this either). ... seems to confirm my assumption that EVT doesn't apply ... and probably not AA either, since the new trees it adds are small. Apologies for "beating the dead horse", but I must respectfully disagree that this is expected behavior from the user ('my') perspective. As I mentioned a couple of times, my LO still has "initially disabled LRs" and "overwritten LRs", whether I tick the "LR workarounds fix" or not, so I expected those messages would still appear with perhaps some additional info regarding the workaround resolutions. I certainly expect to see Summary messages about missing scripts and such as well if that option is ticked ... so maybe I would if those messages applied to my LO with that option ticked? Anyway, it's not a big deal. I was just curious and wanted to report what I thought was possibly unexpected behavior ... only trying to be helpful, so I will not mention it again
×
×
  • Create New...

Important Information

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

  I accept