Jump to content

Mousetick

VIP-Supporter
 View Profile  See their activity

  • Posts

    1,263

  • Joined

  • Last visited

  • Days Won

    112

 Content Type 

Everything posted by Mousetick

  1. Mousetick
    The crash log seems to show the game crashed while Cyrus was pursuing your character (Miretifs). https://en.uesp.net/wiki/Skyrim:Crime If there was another NPC in the room, they may have given you a warning. I don't know, I don't have a crystal ball of what happened in your game. Bottom line: you almost certainly got a 5 gold bounty because you were trespassing. Don't trespass next time and everything should be fine.
  2. Mousetick
    5 gold is the standard fine for trespassing. At what time were you in the East Empire Company office? Try entering during regular business hours and early enough to have plenty of time to speak with Cyrus. I played this quest not too long ago. It worked fine.
  3. Mousetick
    https://dyndolod.info/Help/Combine-Worldspaces-for-LOD Not a problem report. Asking for clarification. Are neverfades supported and if so how are they handled? For example, I'm trying to combine the Vvardenfell island from DLC2SolstheimWorld into the Tamriel LOD. In vanilla, the island is only represented by terrain (LAND records). There are no object references (as far as I can tell) except the lone volcano plume: VvardenfellPlume [REFR:040251B1] (places DLC2VvardenfellPlume [STAT:0401BBBD] in GRUP Cell Persistent Children of [CELL:040142EC] (in DLC2SolstheimWorld "Solstheim" [WRLD:04000800]) at 40,-22) This reference is flagged Persistent + Is Full LOD. The base object DLC2VvardenfellPlume [STAT:0401BBBD] is flagged Never Fades. Combining worldspaces with DynDOLOD results in this neverfade reference being ignored. The only mention of the reference or the base object in the debug log is this: [03:20] [BuildBaseRecords] <Debug: Looking for dlc2vvardenfellplume for Dragonborn.esm DLC2VvardenfellPlume [STAT:0401BBBD]> Result in-game (no plume): I'll submit a proper problem report depending on your response. Thanks.
  4. Mousetick
    Yes it's fixed and it works great. Thank you.
  5. Mousetick
    Yes, they are quite confusing. Start by writing the conditions where the player is immune: (Wearing Helmet OR Wearing Hat) AND (Wearing Cuirass OR Wearing Robes) Then negate them to get the conditions where the magic effect applies: (NOT Wearing Helmet AND NOT Wearing Hat) OR (NOT Wearing Cuirass AND NOT Wearing Robes) The above can't be transcribed directly into Skyrim conditions, because OR has precedence over AND, it would be evaluated as: NOT Wearing Helmet AND (NOT Wearing Hat OR NOT Wearing Cuirass) AND NOT Wearing Robes Which is incorrect. You need to rewrite the conditions so that they evaluate OR with the correct precedence: (NOT Wearing Helmet OR NOT Wearing Cuirass) AND (NOT Wearing Hat OR NOT Wearing Cuirass) AND (NOT Wearing Helmet OR NOT Wearing Robes) AND (NOT Wearing Hat OR NOT Wearing Robes) See OR and Complex Conditions on the CK wiki for more info.
  6. Mousetick
    B) is correct though it requires the player to wear both head and body armor, or wear both head and body clothing. If the player is wearing head armor and body clothing for instance, the effect will apply. If this is what you want, then great, if not, you need to rewrite the conditions. The AND/OR apply to the next condition. So it doesn't matter which you put on the last condition.
  7. Mousetick
    DynDOLOD 3a150 + xLODGen b101 Combined Worldspaces Using a <worldspace>_Combine.ini containing multiple instances of the same source worldspace in order to map different rectangles to the destination worldspace, results in DynDOLOD failure during object LOD generation for the destination worldspace. Relevant DynDOLOD error message: [26:34] <Error: LODGenx64Win.exe failed to generate object LOD for DLC2SolstheimWorld. LODGenx64Win.exe returned 427. Check G:\( Platform )\Tool\DynDOLOD 3a150\Logs\LODGen_SSE_DLC2SolstheimWorld_log.txt> Relevant LODGen error messages: Using UV Atlas: G:\( Platform )\Tool\DynDOLOD 3a150\Edit Scripts\Export\LODGen_SSE_ObjectAtlasMap_DLC2SolstheimWorld_Combined.txt Texture name already defined in atlas file textures\architecture\highhrothgar\hhcol01.dds,textures\architecture\highhrothgar\hhcol01_n.dds Log ended at 22:06:26 (00:00:03) Code: 1063 Full logs and other relevant files: https://drive.google.com/file/d/1k6jnPCs8QSUmgPea7xGQMPsypSi7wrDN/view Thanks.
  8. Mousetick
    Thanks. I tried it, it seems to work fine with xLODGen but then DynDOLOD fails when generating the Tamriel object LOD because the same atlas textures are listed twice (once for each Tamriel rectangle, I guess). I'm going to make a separate report in the DynDOLOD topic. I like the Combined Worldspaces approach better than https://www.nexusmods.com/skyrimspecialedition/mods/48889 because it 100% reflects the load order and the process is completely automated.
  9. Mousetick
    xLODGen b101 Combine Worldspaces Does the <worldspace>_Combine.ini file support specifying the same source worldspace multiple times, to combine several rectangles into the destination, or should separate INI files be used? Example of combining 2 separate rectangles from Tamriel into Solstheim: The Readme says: Thanks.
  10. Mousetick
    xLODGen b101 Combine Worldspaces I'd like to try the provided Tamriel_Combine.ini to put Solstheim LOD in Tamriel. Before I do, I have a one question. [DLC2SolstheimWorld] (... stuff omitted for brevity ...) ; Always replace existing cell/land data for terrain LOD inside these cell coordinates of the destination worldspace ForceSouth=37 ForceWest=50 ForceNorth=63 ForceEast=76 I understand the above settings are going to place Solstheim in the upper right corner of Tamriel in a rectangle bounded by cell 50,37 to cell 76,63. That's not very far from the Tamriel coast, but there is a lot of water around Solstheim so the island would appear farther. https://dyndolod.info/Help/Combine-Worldspaces-for-LOD I don't use a satellite view map, I use a paper map of Tamiel instead. I don't generate object LOD Level 32. So this feature would not be useful to me. I'm wondering if the Solstheim LOD would still be a visually useful addition when viewed from the Tamriel "overworld". Could you give a rough idea of what kinds of detail are visible from the College of Winterhold, for example? I could try it and see for myself of course, but I thought I could ask first. PS: More than one question, actually. Are there any plans to do the counterpart, that is combine a part of Tamriel LOD into Solstheim? I guess this would require extending the Solstheim worldspace similar to Tamriel-Extend as vanilla Solstheim is too small? Thanks.
  11. Mousetick
    Is this the code verbatim or is there more to it? The formulae can overflow or produce out-of-range values. For example, with threshold=27 and alpha=255, assuming alpha is an integer, the result is 1 or 257.
  12. Mousetick
    I was not talking about that, so there's no arguing there. What I meant is that mods like Lucien Lachance AE cater to ES lore-obsessed freaks, which must be extremely few among the STEP user base. Most users likely don't care one bit. Including this mod is odd in that it creates an isolated special case. In order to be ES lore-obsessed freak-friendly, the guide would need to cover similar lore consistency details equally and more comprehensively throughout the game - which is not one of its goals, AFAIK - such as applying the same treatment to Jiub. So instead of making the Spectral Assassin a special case, while other lore consistency details are ignored, this mod and its changes might as well be omitted entirely. The guide then becomes consistent and balanced in how it treats lore details.
  13. Mousetick
    It makes it redundant yes. This mod's plugin could be removed. It would make the load order simpler to install for users and lighter. But doing so creates new problems for the STEP maintainers. The same issue exists for anything that already is, or could be, incorporated into the STEP Patch(es), such as the recently discussed Lucien Lachance AE. First there is the question of permissions. Does the mod author allow integrating their changes into another mod or plugin, and redistributing that? Assuming the permissions allow it, incorporating small changes directly into CR Patches creates a long-term maintenance nightmare for the STEP Patch maintainers. Once the original mod plugin is removed from the load order, it's impossible to tell the origin of the changes in the CR Patch. If you look at the patch a few months from now, you can immediately see the merged changes from other plugins, but you'll likely be wondering what the heck are these torch things (from this mod) doing in the FormList. Or if you're rebuilding the CR Patch from scratch, the incorporated changes will be lost because they didn't appear separately in the load order. To prevent these issues, I use this method, FWIW: I have a custom plugin dedicated to incorporating small changes from various mods. It's called 'Miscellaneous.esp'. If there is mod that I like and want to keep, but it makes trivial changes into a tiny plugin, I merge it in to Miscellaneous.esp. I keep a list of all the mods that are merged into Miscellaneous.esp. Miscellaneous.esp is included in my load order, obviously. My CR patch(es) exclusively contain conflict resolutions, including with Miscellaneous.esp which changes appear on their own in xEdit. It's clear and there is no ambiguity as to where the changes in the CR Patch(es) come from. Hope this helps. My notes for Miscellaneous.esp: That's about 90 plugins combined into one.
  14. Mousetick
    That's right. There is mipmap resampling which changes the ARGB values too. But compression and resampling only create marginal errors and/or small gradations between values. Changing the alpha from 128 to 255 and from 127 to 254 is something else. I haven't been able to pinpoint what it is. -- I had this idea of a drastic brute-force approach in the back of my mind for some time, but wasn't sure how to practically do it. Directly edit a previously generated object LOD atlas and paste in the special textures for alpha test testing, completely bypassing DynDOLOD. After much fumbling, I managed to achieve that by using uncompressed atlas textures. Results using a solid green pine branches texture: Alpha 127 > 128 > 129 So you were right all along, of course LOD alpha test is > 128 (or >= 129). I wouldn't believe it initially because it doesn't make logical or mathematical sense to me, and the rationale for it is unknown. For texture artists preparing mipmaps with alpha-to-coverage, the target should be at least 129 opacity, rather than 128, for consistency with LODs. It may be helpful to clarify the documentation on https://dyndolod.info/Help/3D-Tree-LOD-Model: This refers implicitly to the NIF NiAlphaProperty default alpha test of Greater than 128. This can be ambiguous for readers not familiar with the context or the terminology. It would be clearer, and easier to understand, to simply state that alpha <= 128 is transparent, or that alpha > 128 is opaque in LOD. Thanks.
  15. Mousetick
    Ok. The results I'm getting are definitely unexpected then. It gets weirder. I added two rectangles to the previous test texture: one with Alpha 0, one with Alpha 255. In the atlas the mipmap is all Alpha 255, except the rectangle with Alpha 0 is still Alpha 0, but its border is Alpha 160. I'm beginning to think the changes are not caused by the alpha-adjustment which should be a no-op based on the code you gave. Perhaps the alpha channel is altered when the atlas is resaved and compressed? Am I assuming correctly that DynDOLOD creates an uncompressed atlas first and then compresses it with Texconv? If so could you provide the Texconv command line that DynDOLOD runs? Also, from DynDOLOD_SSE.ini: ; 0 = no mipmaps, 1 = texconv, 2 = internally ObjectLODGenerateMipMaps=2 TreeLODGenerateMipMaps=2 What would happen if I set ObjectLODGenerateMipMaps=0 with UseMipMaps? Are the source texture mipmaps still going to be copied to the atlas, or are they going to be skipped? Thanks.
  16. Mousetick
    I merged this mod into a custom personal patch, long ago. The mod didn't warrant a full plugin slot. Personal choice aside, it struck me as odd that this particular NPC, who is only encountered during the Dark Brotherhood questline if the player joins the faction, received particular treatment by the STEP Guide among all the Skyrim adult NPCs, who are untouched. By the same logic, Jiub's spirit in the Soul Cairn should be made to look like he did in Morrowind. There is a mod for that: Jiub - Morrowind Appearance. The changes from this mod could easily be incorporated into the STEP Patch as Z suggested.
  17. Mousetick
    I'm not sure I'm going to test with Community Shaders, I'd rather not add another (unknown/unproven) layer in the middle. But thanks for the information, it could be useful if needed. With or without Community Shaders, I've hit a roadblock anyway. The previous test I made is invalid. I discovered that the mipmaps copied to the atlas by DynDOLOD have been changed. The source texture and its mipmaps are R:255 G:255 B:255 A:128 for all pixels. In the atlas it has become R:255 G:255 B:255 A:255. Before that discovery I had made a more elaborate version of the test texture with a R:255 G:255 B:255 A:128 background and some small R:255 G:255 B:255 A:127 rectangles partially covering the area where branches are normally placed in treepineforestbranchcomp.dds. In that case, DynDOLOD also changed the mipmaps: R:255 G:255 B:255 A:128 background became R:255 G:255 B:255 A:255, and R:255 G:255 B:255 A:127 rectangles became R:255 G:255 B:255 A:254. I have no idea what's going on but this is completely unexpected. This looks like alpha-adjustment gone wrong. No changes were made other than using a specially prepared treepineforestbranchcomp.dds texture. All LOD models have not been touched, they're all using Alpha Threshold 128, which should "neutralize" DynDOLOD's alpha-adjustment. I double-checked the source texture mipmaps, they all have correct alpha channel values. This is how the specially crafted texture mipmaps look on full models in-game. It's all a bit messy and you may need to zoom in but you can see some branches have "holes" in them, showing the background through, corresponding to the R:255 G:255 B:255 A:127 rectangles. These full models have been configured with NiAlphaProperty Greater Than 127. I intended to replicate this test on the LODs. Could you share the exact formula/algorithm that DynDOLOD uses for adjusting the alpha channel? Thanks.
  18. Mousetick
    You should re-run xLODGen first and foremost.
  19. Mousetick
    I don't know why it's difficult for you to answer the question: is alpha 128 transparent or opaque in LOD? You don't need to keep repeating the same things over and over. I know what you're saying. Anyway, I went and tried it myself. Using the same white texture as in the previous NifSkope test: solid white, all alpha 128. This texture's mipmaps were not generated with alpha-to-coverage. LOD ON | LOD OFF What do you make of this? If alpha 128 is opaque in LOD, either the alpha test function is 'Greater than 127', or the function 'Greater than 128', that you claim is being used, doesn't work. I'm inclined to believe it's the former. Thanks.
  20. Mousetick
    I wasn't super-happy with the aspen mipmaps which were duller in color than the full texture. I found that enabling gamma correction fixed the problem. Much better. I've been using GIMP's mipmap generation, with Lanczos sampling filter. There are other filters like Mitchell and Kaiser, which I compared to Lanczos and didn't find much difference. I briefly tried Microsoft Texconv with its Cubic and newfangled FaNT filter. The results were a disaster. But I may not have used the correct options. This needs more testing. I found it useful to examine the mipmaps in an image editing tool to check them up before running DynDOLOD and looking at them in-game. If your image editing program can't directly open DDS mipmap levels as individual images, the Texdiag program from Microsoft can extract all mipmap levels of an uncompressed DDS and store them as separate images.
  21. Mousetick
    The key point for me to understand, and for texture artists as well I'd guess, is what is the minimum alpha value that passes the LOD alpha test: 127: transparent or opaque? 128: transparent or opaque? 129: transparent or opaque? This makes no sense, but it's Bethesda. If DynDOLOD uses 128 then it means you consider that the minimum alpha value that passes the test is 128. There are only two alpha test functions that would produce this result: Greater than 127 Greater than or equal to 128 Neither of which is 'Greater than 128'. Would you agree? If you agree, then this contradicts your previous statements: It doesn't matter what the NIF default is for LOD and I don't understand why you keep bringing that up. All that matters is what the game actually does, and what you were able to observe and determine based on your Community Shaders tests. It depends on the texture. If large pieces of the texture use a constant alpha channel, it's important to get the alpha value or the alpha test right. Even more important when preparing mipmaps for LOD. Example using a vanilla tree. I made a solid white texture with constant 128 alpha (50% opaque) for demonstration purpose. Results in NifSkope: Initially the NIF uses Greater than 112 as the alpha test function: Then I change the threshold to 127, so the alpha test function is now Greater than 127, still opaque: Then I change the threshold to 128, so the alpha test function is now Greater than 128, everything's gone: Thanks.
  22. Mousetick
    This doesn't quite answer what I was trying to ask. Let's start over, if you don't mind. When you say: The BTO mesh doesn't have any NiAlphaProperty with operator flags or threshold, so we don't know if it's greater than or greater than or equal, or if the threshold is 127 or 128. But if you what you say is true, then that means the minimum alpha value for a LOD pixel to be opaque is 129 and 128 is transparent/invisible. I find that highly unlikely and unusual. But if it is true, then this has huge implications that ripple down the whole chain. Starting with DynDOLOD adjustment of mipmaps alpha: the correct "neutral" value should be 129, not 128. Etc... How does one go from a threshold to a multiplication factor? Is DynDOLOD performing some kind of linear interpolation on the entire mipmap alpha channel? How does it matter if the alpha channel is linearly interpolated or not with LOD? The LOD response to alpha input is not linear, it's binary. But you mentioned "alpha channel of source texture", so I guess the linear interpolation is applied before DynDOLOD creates the mipmaps, which would make sense. What happens exactly in the case of UseMipMaps? Thanks
  23. Mousetick
    I'm just going by what sheson told us, there is no reason not to believe it. I know for a fact that even when using UseMipMaps, DynDOLOD performs alpha adjustment on the mipmaps because I experienced it. When testing UseMipMaps I had initially set NiAlphaProperty Threshold to 127. Then I switched to 128 (not knowing at the time this was DynDOLOD's passthru mode for UseMipMaps) and everything went haywire because the texture mipmaps as provided by the MA were not generated with alpha-to-coverage. This is described in the OP, and in sheson's replies. The observed behavior is consistent with what sheson stated. There is no justification for setting to 128 other than disabling DynDOLOD alpha adjustment.
  24. Mousetick
    For context, the above was in response to my inquiry regarding perceived differences in lighting effects between 3D tree LOD models and full models. Ok, the 3D tree LOD models from DynDOLOD Resources are exact copies of the vanilla full models, indeed. But... When the 3D tree LOD models are merged into the object LOD BTO mesh, their BSLightingShaderProperty is not copied over. The whole tree object LOD node has its own BSLightingShaderProperty. treepineforest01passthru_lod.nif | Tamriel.4.0.4.bto I understand some are useless/ineffective with LOD, such as shadows and animations, so are omitted in the BTO. I'm not sure about the other differences, though, whether they are significant or not. Thanks.
  25. Mousetick
    It may be useful to clarify that the NiAlphaProperty record in the 3D tree LOD models is meaningless and completely ineffective from the game engine perspective. Its only purpose and indirect effect is to instruct DynDOLOD, via the Threshold value, to adjust the alpha channel of its own mipmaps or of the full texture's mipmaps duplicate, so that no pixel has an alpha lower than Threshold. That's all. In fact, when the 3D LOD model is merged into the object LOD BTO mesh, the NiAlphaProperty record is stripped out along with other fluff. There are no NiAlphaProperty records in the BTO mesh. None are necessary or possible, since LOD only uses binary alpha: less than 128 is invisible, greater or equal to 128 is fully opaque. Could you please confirm strictly greater than or greater than or equal? It would seem unusual and peculiar to consider 128 as being in the lower half of a 0 to 255 range. Typically the range is divided into equal parts - 0 to 127, and 128 to 255 - and in a binary test using 128 as a threshold, 128 would evaluate to 'true'. Thanks.
×
×
  • Create New...

Important Information

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

  I accept