Jump to content

z929669

Administrator
 View Profile  See their activity

  • Posts

    13,028

  • Joined

  • Last visited

 Content Type 

Everything posted by z929669

  1. z929669
    If you delete all but aspens from HLT\meshes\landscape\trees\. then the models from the Add-On can also be deleted (but they won't interfere with anything if left, since they are CRC-matched to the deleted full models). Also, as I mentioned, each of these tree mods has a plugin that probably conflict for some or many of the same tree records or placements, so DynDOLOD cannot construct the LOD properly unless it finds the full/LOD resources for the winning conflicts. Look for these files in each tree mod to see if they have the models needed for generating billboard textures via TexGen (#2 [flat trunks for hybrids in Level0/1/2] and #3 for hybrid/full LOD models TexGen uses to create tree billboards used by Billboard# and that LODGen uses to stitch these models into *.BTO for Level0/1/2 in the DynDOLOD process). #1 is the full models with CRCs corresponding to the file names of trunk and LOD models in #2 and #3:
  2. z929669
    I assume you can submit a metadata change to LOOT so that Smooth Shores overrides LFfGM. I looked a t the first record posted above, and the ITMs are only for the vertex normals and height map in the header. The layers are all changes from master (for both SS and LFfGM). I do believe that the SS changes are probably the keepers in many cases, but maybe not all.
  3. z929669
    'Billboards' are textures of whole trees (or tree trunks), and TexGen 3 (included with DynDOLOD 3) generates these when using the "HD tree" option (4x billboards per tree) and "Tree" option (1x billboard per tree with text file for traditional LOD billboards). "Billboard models" are just flat meshes used to display the billboards --but I don't like calling these 'billboards', as it's confusing. They are still 3D models but very basic, flattened models. For 'ultra' tree LOD to work, each tree must have a stripped-down LOD model based upon the full tree mesh. The billboards created by TexGen 3 use these models to render the full tree and trunk billboard textures (the latter are for use with hybrid 3D tree LOD) for creation of billboard textures. The LOD models are packaged with Happy Little Trees Add-On, so you must install HLT and the Add-On mod. I don't know if BlubboPines or Jedi have LOD models, but they are required for auto-generation of billboards. If they ship with billboards and the billboards text files (both having the tree FormIDs in their file names), you can only use "Billboard#" in your tree mesh rules for those trees (no hybrid or 'full' tree LOD (Level0/1/2), only mesh 'Billboard#' LOD) Don't install HLT billboards from the main mod. They will only cause conflicts with TexGen-created billboards when running DynDOLOD. Use DynDOLOD 3 and TexGen 3 to generate the billboards as I described. For this mod, you can use either Level0/1/2 or Billboard# in your mesh rules, depending on the quality of the LOD you want. Tree mods generally don't work together if they modify the same tree records without plugin patching them so that DynDOLOD can find the correct references to use for each tree. You should generate LOD using only HLT and the HLT Add-On to confirm that you are properly generating tree LOD. See the HLT mod description for general instructions and links to support and further instructions. Then try each of these other mods if they have proper LOD models or billboards if not. Otherwise, those will need to be created by creating the LOD models and letting DynDOLOD do the rest.
  4. z929669
    I will definitely do that once I find the relevant assets. There could be others as well.
  5. z929669
    Yes, I missed this ... the compares aren't backwards. This mod just doesn't correct that whereas WMF does. Correct. That's what I mentioned in the compares post. This mod fixes some things that WMF misses and the inverse is also true. That's what I mean ... sorting these out will be difficult, because I'm sure there is a mixed bag of fixes, and both mods are needed with some hiding of files. The question is which order we should be installing to result in the fewest files needing to be hidden. I was guessing that we should install this mod first and overwrite with WMF, but I haven't looked deeply enough to sort that out. Just verifying that what Tech was saying is true.
  6. z929669
    Yes, my bad. @Greg was pointing out the inconsistency of categorizing this mod in Patches while we are categorizing USSEP in Foundation. This is what I was saying previously on this topic, so USSEP should be fine in Patches as well in that case.
  7. z929669
    I had the same thoughts, and it's mentioned earlier in this topic. The reasoning is that this mod forwards changes from CC content that the USSEP doesn't cover, so it's thought more of as a patch. The counter argument is that many of the changes introduced by the USCCCP will wind up being forwarded into many other plugins as we see with the USSEP. And if this mod does wind up packaging a BSA with replacers of any kind, then it would probably need to go earlier in the mod list.
  8. z929669
    I vote to accept this one for 2.0.0 without further ado. It is forwarding many changes that we won't need to add to our patches, and several records that can be removed from our CR patch (those that are jumping the USSEP via this patch).
  9. z929669
    Yeah, The shadows are indeed off. I forgot about FPS Stabilizer. I don't understand what you mean by "jagged ends". Maybe circle what you mean. This mod looks better than WMF in that compare, IMO. The roof beams are rounded for this mod but not for WMF (maybe that's what you mean). Also note the fascia on the left roof is made consistent with the others with this mod. The pattern is now on that left fascia in the last shot.
  10. z929669
    I have installed this mod into M&T in alphabetical order with WMF moved one priority lower than this mod (so this mod wins conflicts). Whiterun compares only Step > this mod WMF is enabled in these compares, but it doesn't contribute anything. Step wins over this mod IMO: This mod wins IMO: Step > this mod (optional plugin enabled) I am not seeing moss in any but the second set of these images. These need to be studied carefully to determine what's best. Both WMF and this mod are better than Step for these, but in some cases WMF may be best and in others, this mod may be best: Step > WMF only > WMF + this mod There is a ton more that can be checked in Whiterun and other cities. Overall, this mod is a huge improvement in Whiterun. I am inclined to leave WMF in alphabetical order so that it overwrites this mod, and we can hide any meshes from WMF that conflict with this where necessary. The optional plugin from this mod doesn't conflict with any other mod plugins, so the supposed hanging moss is a mystery to me. As mentioned, only the second compares in the previous set showed what i would call English ivy inside the grate. More investigation/opinions needed. Note that i have ENB enabled, but I don't have the Post-Processing ModGroup installed in these compares. I also haven't checked at night.
  11. z929669
    I think we should check the optional file as well. These changes sound fitting for Whiterun.
  12. z929669
    Sounds good. Marked accepted, added to ModList, etc. As far as making the FO patch optional though, I think it should be always used, since this is the only way one can change font size via this mod's INI. With the patch, this can be used to change the font size to be as large as FO Realistic Print option with no difference than if that option were installed with FO and this mod's patch not used. In other words, not installing the Optional File for this mod needlessly constrains user options for font size. So I propose FO installed without the Realistic Print option and always install the Optional File from this mod. User can set options via this mod's INI according to personal preference. Install order will also not matter this way, so alphabetical in Interface.
  13. z929669
    The new optional file removes the softening effect. This is using our standard FO settings without the "Realistic Print" option, with this mod + the new FO patch Optional File. Without the FO patch: With the FO patch: @Greg @TechAngel85 Does this resolve for you both? If so, I again vote to accept this one with the 'steal' font color tweak with otherwise INI defaults for this mod and FO install per our historic options but without Realistic Print.
  14. z929669
    Two is the magic number. Unmarked for testing.
  15. z929669
    Good summary. I predict that this functionality will cause significant waves and disruption but will probably spur ideas and wind up having a positive impact if/when it evolves ... and is 'regulated'/'constrained' properly and prioritizes conflicting rules according to long-established precedents.
  16. z929669
    Thanks, I obviously missed that. I thought it was a name change only.
  17. z929669
    @DoubleYou's algorithm should increase red sufficiently to make a difference, but you essentially want to increase GrassBrightnessTopR relative to GrassBrightnessTopG and GrassBrightnessTopB. (@DoubleYou what's the basis for the inverse factors you are using? Just curious, as these are precise.) Default in DynDOLOD_SSE.ini is: ; grass LOD brightness multipliers GrassBrightnessTopR=0.400 GrassBrightnessTopG=0.445 GrassBrightnessTopB=0.450 ; make bottom darker to fake shadowing GrassBrightnessBottomR=0.200 GrassBrightnessBottomG=0.223 GrassBrightnessBottomB=0.225 ... we have a similar issue in Step's SSE build with ENB, which is essentially fixed using (note that R is increased relative to G/B): ; grass LOD brightness multipliers GrassBrightnessTopR=0.295 GrassBrightnessTopG=0.315 GrassBrightnessTopB=0.300 ; make bottom darker to fake shadowing GrassBrightnessBottomR=0.170 GrassBrightnessBottomG=0.175 GrassBrightnessBottomB=0.180
  18. z929669
    Thinking aloud here and sharing: I just want to point one thing out with respect to this discussion about a 'root' folder. For Bethesda games, mod managers by default understand 'root' as the directory in which (most) mods are installed ... so ../Data ... 'root' mods are one level above this, so mod managers don't handle the installation properly. To me, discussions of a root folder lead us (me?) to think about this literally as ../root. I believe what is being discussed is a change in this default 'root' definition such that it is defined at the {game} folder level, so ../{game}/Data (not ../{game}/root/Data) A mod packaged such that its 'root' definition is implicit as ../Data could be repackaged one level up. So the original zipped file may contain meshes/. and textures/. as top-level folders, and the repackaged top level would be Data/meshes/. and Data/textures/. I believe MO and most other worthy mod managers gracefully recognize either structure and handle them accordingly? The folder structure always implicitly defines the root as ../Data and if that is present in the package structure, then this level is ignored?). Therefore (if so), I don't see why 'root' needs to be added to the list of valid folders in https://github.com/ModOrganizer2/modorganizer-game_skyrimSE/blob/master/src/skyrimsemoddatachecker.h Why not just NOT ignore ../Data instead? So a root mod would always have Data/ and files beside it. The Data folder could be empty or have valid files/folders under it (but always Data/ and always one or more files beside it). I'm not that familiar with the code-base definitions/functions used by the various mod managers, but having done some very basic programmatic code alterations along these lines, I think it should be trivial to add an implicit "root check" and create a branch for the existing method and a new branch for the RB method in the mod-manager code? Non-Bethesda games would use a different folder-name basis, but I would think that they all have an analogous one like Data/ In this way, only root mods would need to be repackaged (or include some metadata definition), and all other mods would be implicitly conveyed down the 'old' code branch. Anyway, I don't have time or inclination to get sidetracked down yet another rabbit hole in testing this, but these were my thoughts in reading through this discussion. Perhaps helpful or more likely just noise
  19. z929669
    Yes, this is definitely not aligned with the general pattern and throws an exception into the mix. The more I think about it, the more I think the idea of a plugin is to rationalize this insanity. If I were a newcomer sorting out the history and evolution of these mechanics, I would assume that the runtime method was first and was improved upon by the plugin-load method (which creates consistency for load-order prioritization of INIs, BSAs, etc). This method essentially breaks the already well-understood mechanics, subverting the expectations of mod authors. Until someone explains in detail exactly what this allows that cannot be achieved by plugin-driven changes, I will view this method as a sort of temporary "unit-testing" tool that is (arguably) useful for a mod author in plugin dev. What is the problem, and how does this mechanic allow one to circumvent it? I'm getting twisted just thinking about it.
  20. z929669
    Thirded. I feel like this mod or some other will perform this function with compatibility for 1.6.xxx at some point, but not in the foreseeable future.
  21. z929669
    True, it's more dynamic, but it places the burden on the user, who will often get this wrong and claim something isn't working (more support queries). It's great for people quickly testing things before making the 'static' changes via a plugin, but still six one way and half dozen the other.
  22. z929669
    I tick the middle three boxes on that FOMOD page, but I have ticked them all before. I suspect that ticking them all might be best, but I haven't gotten around to comparing the results for all fires for each of those settings.
  23. z929669
    I think XD has rounded the corner and is superior now, especially since it is ENB compatible out of the box. It works nicely for Step using the install instructions we recommend via the wiki link in the OP
  24. z929669
    Well that's definitely interesting, IMO. I will need to play around with the possibilities. Seems very useful for guide curators, particularly when curating multiple guides within/among games.
  25. z929669
    Yeah, increasing variety as the farmhouses example or by swapping several references with alternates for a single tree if that's possible seems interesting ... but as you mention, this can also be accomplished via plugin. ESL sort of takes care of plugin limits too. EDIT: I'll bet Arthmoor et al really hate this mod and the potential support headaches it will cause them ...
×
×
  • Create New...

Important Information

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

  I accept