
Jonado
Citizen-
Posts
37 -
Joined
-
Last visited
Everything posted by Jonado
-
I am getting snow on some seasonal LOD objects that are not supposed to have it. See screenshots (left one is close-up view, the right one is when viewed from a distance). This time I think I know what is going on, and it is likely a bug on the DynDOLOD side. Searching for 0200CE5E in the debug log tells me that the object is getting swapped to GlacierRubbleTrim02 (FormID 00065CA2) in summer. Well, you can see from the screenshot that this is not correct, so I did a file search for that form swap. It turns out the only reference to it is in the file zzz_Icebergs_SUM.ini.vortex_backup, i.e. a backup copy of a Seasons config file, which is not used by Seasons of Skyrim. I can of course remove the file to fix the issue (I don't really need it), but since Vortex tends to create backup copies like that, I thought it is better you fix this on the DynDOLOD end. Logs can be found here: Logs.7z
-
1. It affects both object LOD and terrain LOD (but I guess terrain LOD to a larger degree). If you look carefully, some objects have snow on them in the second sceenshot, but not in the first one. In some other areas, almost no objects had snow. Also, seasonal LOD shows up fine in game, it is just the map that is affected. And I have not experienced this before. I don't know whether this is directly related to DynDOLOD, but how would I troubleshoot it? It is obviously related to seasonal LOD, and as far as I know I need DynDOLOD in order for seasonal LOD to function. I guess it could be an issue with Seasons of Skyrim, but then I don't know how to fix it. powerofthree is notoriously difficult to get in touch with. 2. I'll send you my entire Seasons folder, because I have a lot of seasonal config files. These include WIP files for mods that I have not published yet, so please don't share this outside this forum (I will likely also take it down when you have had a look): Seasons.7z. The autogenerated formswap has been disabled. What I can tell though is that there should be nothing in there that touches those references. What I suspect has happened is that the MATO has failed to apply to those objects, which I know from experience sometimes happens with Seasons of Skyrim (I don't know what is causing it though). The console tells that DynDOLOD uses a different mesh for the LOD object - therefore I suspect SoS is not able to apply snow to that mesh. Normally, I would solve that by creating a new object based on that mesh and with a snow shader applied to it, and then use a custom form swap for it. But since it in this case only affects the LOD object and not the regular object, that is a route I would rather avoid if possible.
-
I am having some strange issues with the latest version of DynDOLOD: When starting the game from an interior, the world map looks weird (with Seasons of Skyrim). It looks like the game is trying to load the seasonal map at the same time as the default map, see the attached screenshot. To fix the issue, I have to enter an exterior, save the game, and then restart it (then it looks like in the second image). I have packed all seasonal LOD files (terrain and object lods) in bsas to save disk space, while the regular files are retained as loose files. I have done this for convenience, so I can load all LODs in the Creation Kit without extra steps. I don't know why that would matter though. Some LOD objects don't appear snowy in winter, despite that the base objects have snow on them. See screenshot. If I walk to the pier, those objects will get back the snow. Logs can be found here: Logs.7z
-
Improvements for mods, rules, LOD models
Jonado replied to Jonado's question in DynDOLOD & xLODGen Support
FYI, I have created DynDOLOD meshes for Capital Whiterun Expansion (along with some mesh mask rules). You can found them here: https://www.nexusmods.com/skyrimspecialedition/mods/85797 Please let me know if you want to include some of them at the DynDOLOD resources. -
The problem with the old patch was the bleeding rock seen in the attached screenshot. You asked me back then which plugin was the last to edit that reference, which was BluePalaceTerrace-LegacyOfTheDragonborn-Patch.esp. I don't know how you resolved it, but I interpreted is as you were going to apply certain rules for that plugin. If that is the case, those rules need to be updated to the new plugin, DBM_BluePalaceTerrace_Patch.esp. I have not checked whether the issue has reappeared, just notifying you that if it was resolved that way, some action will be needed on your side. I haven't saved my log files from that DynDOLOD generation, but the screenshot should be informative enough for you to be able to look up what is currently being done for that reference.
-
Hi Sheson, This file has got a name change for the LOTD v6 update. The updated patch - available at the official Legacy of the Dragonborn patches - is called DBM_BluePalaceTerrace_Patch.esp. Could you copy the rules for BluePalaceTerrace-LegacyOfTheDragonborn-Patch.esp to also cover the new version? There might also be some slight edits to the cliff placements in the new patch, so if needed, could you update the rules to take this into account as well? Thanks in advance.
-
Improvements for mods, rules, LOD models
Jonado replied to Jonado's question in DynDOLOD & xLODGen Support
Posted in the wrong thread. You can ignore this message (although it would be nice if you could have a look at incorporating the missing LOD rules into DynDOLOD at some point). -
I thought as much. Just want to make sure you get it right this time, though. Intuitively I think the order should be _AaBbCc..., not ABC...XYZ_abc... as you claimed it is. At least I think that is the sorting that is used on Windows.
-
There was a typo in SoS_Seasons_Vigilant_WIN.ini, but I didn't notice because SoS_Seasonspatch_WIN.ini is taking priority on my build. I would have expected that at least one of the 10,000 people who have downloaded the mod would have noticed it and reported the bug, but apparently not. I have updated the mod now with a fix. Thanks for the clarification. I was a bit scared when you said you were using load order for determining priority rules, since that could have caused a lot of mismatches for other types of objects (like trees). But isn't Base Object Swapper also sorting alphabetically? It isn't documented, but I assumed that was the case, which is also what I have experienced during my testing. And are you sure about the case sensitivity? It sounds weird to me that a would load after B.
-
I think this analysis is partially incorrect. Being aware that there are several versions of sbluepalacegate*.nif, I have applied the following mesh mask rule: LODGen153=sbluepalacegate,Full,Full,None,None,FarLOD,Unchanged,0, which produces the above result. The wall is definitely related to sbluepalacegate.nif, but it must be for the duplicate, 0x5A004B~BluePalaceTerrace.esp (I need to get rid of that one; I have created the Open Cities patch for JK's Blue Palace Terrace myself). Was this the only thing you found by looking into that reference? The issue anyway seems to happen for all instances of SCWgateWinter/SBluePalaceGateWinter (the JK's Blue Palace version works just fine now when I look at it carefully). I think you might be at something, though. If DynDOLOD loads form swaps by plugin order, you are doing it wrong. Seasons of Skyrim applies rules in the alphabetical order of the config files, which is written clearly in the documentation (but I don't know what that means in this case, given the underscore - ask powerofthree). Normally, there should not be any problem applying two different rules for the same object (I have good reasons for doing so here), because it is anyway the one that loads last that wins. But if you are not using the same file order, I guess that could cause problems when mesh mask rules are involved. I could try commenting out one of the form swaps and see if it helps, but you need to fix this too.
-
Here you go. The gate has been replaced by a wall of some kind in the object LOD mesh. As for Level2 LOD models, would it work to simply copy the Level1 models and rename them as *2.nif? That would be easier for me than to mess with the mesh mask rules again. Otherwise I can just wait until you fix it, I am not going to actually play the game in quite a while anyway.
-
I did provide detailed information further up in the thread. Let me dig it up for you: This should also help: That said, the Simplicity of Seasons meshes have been quite heavily modified by me, and for good reason. rtstables01snow_lod.nif was provided by me, and is a copy of rtstables01_lod.nif from the DynDOLOD resources. rtfarmhouse02win.nif is shipped with the mod Seasons for Vigilant for the time being (but will be published elsewhere later). Anyway, I think this fully explains the issue I am facing: I don't understand why those rules are not set by default, though. Those buildings are big enough that it is noticeable that they do not show up on the map. I am not saying I cannot fix it myself, just that I think it should be a main part of DynDOLOD. If you want, I can add it as a request to the mesh mask rule thread we started a while ago. I also think that it is weird that some of the winter models get different rules than the base models, despite using exactly the same LOD mesh, and having the same LOD rules attached to the object.
-
Hi, I have finally been able to produce a valid debug log (took me two attempts, and I didn't have the patience to rerun it when DynDOLOD again failed to produce a debug log, hence the wait). To recap, the issue was a badly mismatched LOD model during winter, likely due to something breaking after applying mesh mask rules. The issue still persists. You are probably able to get the details by backtracking the conversation. The log files and other requested files can be found here: https://www.dropbox.com/scl/fi/ef90b9t3zloufid6620xn/Logs.7z?rlkey=nnt7uh9ohtanmkzlqktnsttdx&dl=0 I also reported that a certain building was not showing up on the map, despite having proper LOD models and the level 4 and level 8 LODs being successfully generated. That issue remains too. I have a bit more information on the issue, though, having found no less than six objects which suffer from the same issue (the list is likely not exhaustive). See the list below (with examples of references in parenthesis): RTKeep01.nif (e.g. 00080C57) RTFarmhouse01.nif (e.g. 167A~RiftenExtension.esp) RTFarmhouse02.nif (e.g. 16A7~RiftenExtension.esp) RTStables01.nif (e.g. 000BB7B4) CWTower01.nif (e.g. 7EDC~Bells of Skyrim - OCS Patch.esp) SHouseForSale.nif (e.g. 0008E2CA) All of these meshes have specific form swaps for winter. Interestingly, three of them, RTFarmHouse02WIN.nif, RTStables01Snow.nif, and CWTower01Snow.nif do have level 16 LOD, despite using the same LOD meshes as the base objects (or copies thereof). I don't know whether it is related to the issue.
-
Improvements for mods, rules, LOD models
Jonado replied to Jonado's question in DynDOLOD & xLODGen Support
That worked, thanks. I have now uploaded the render files to the same page as the Seasonal Landscapes LOD files. -
Improvements for mods, rules, LOD models
Jonado replied to Jonado's question in DynDOLOD & xLODGen Support
I don't get this to work. I did as you said (and carefully read the information on the page you linked), yet TexGen is not generating any of the new textures. Is there some extra step needed? -
Okay, if the issue persists after my next LOD generation, I will return to you then. Don't know when I will have time for it though.
-
Improvements for mods, rules, LOD models
Jonado replied to Jonado's question in DynDOLOD & xLODGen Support
All those textures except slod04WIN.dds should be used in the Seasonal Landscapes LOD files that I requested to get incorporated into the DynDOLOD resources (check my post from 21 January). The last texture is for other mods I plan to publish in the future. But sure, I can include the relevant rules when publishing the mods. I didn't know how it was done. -
I think this requires some explanation from my side. SoS_Seasonspatch_Solitude.esp is from the mod Simplicity of Seasons, which is an IMO broken mod which I have spent a lot of time in the last months to try to patch up. While working with that I decided to incorporate some of its features (with fixes) into a seasons mod for Vigilant, which I have published on Nexus with the mod name Seasons for Vigilant. As a workaround to avoid my mod to depend on Simplicity of Seasons, and while waiting for my bug fixes to get finished, I simply copied the relevant objects from Simplicity of Seasons to my mod (it should be fine according to the mod's permissions). That is the reason for the duplicate. But I am using FormIDs and not EditorIDs for seasonal swapping, so should it matter? The full-model swap is likely from the mesh mask rules (the object in Simplicity of Seasons is using the same flags as the base object). I simply copied the rule from a similar line from RedBag's Solitude's custom rules (which I think are incorrectly configured, because that mod does not include any file called SBluePalaceGate.nif). But that should be same as for the non-formswapped object. The mesh mask rules only depend on the mesh, which is the same. Also odd that the debug log seems to come from a different LOD generation. I noticed they have different timestamps, but it is the most recent debug log that I have. Perhaps the newer DynDOLOD generation did not produce any debug log, I don't know. Regarding this issue, the reference form ID is 00080C57.
-
Improvements for mods, rules, LOD models
Jonado replied to Jonado's question in DynDOLOD & xLODGen Support
Could you add the following seasonal textures to Texgen generation too: slod04.dds -> slod04AUT.dds (replace SGrass01.dds and SGrass01_n.dds with SGrass01AUT.dds and SGrass01AUT_n.dds, respectively, from Seasonal Landscapes) slod04.dds -> slod04WIN.dds (replace SGrass01.dds and SGrass01_n.dds with Snow01.dds and Snow01_n.dds, respectively) wrbuildingslod02.dds -> wrbuildingslod02SUM.dds (replace WRFieldGrass01.dds and WRFieldGrass01_n.dds with WRFieldGrass01SUM.dds and WRFieldGrass01SUM_n.dds, from Seasonal Landscapes) wrbuildingslod02.dds -> wrbuildingslod02WIN.dds (replace WRFieldGrass01.dds and WRFieldGrass01_n.dds with Snow02.dds and Snow02_n.dds, respectively) sbridgelod.dds -> sbridgelodAUT.dds (replace SClovers01.dds with SClovers01AUT.dds, from Seasonal Landscapes) -
All the logs are here, just as they were before: https://www.dropbox.com/scl/fi/ef90b9t3zloufid6620xn/Logs.7z?rlkey=nnt7uh9ohtanmkzlqktnsttdx&dl=0. I have added the object report log to the zip file too now. I can see if I can upload some screenshots later, but it at least affects the reference 0xC938~Open Cities Skyrim.esp and all objects with FormID 000801ED.
-
I found some other LOD issues from the same generation. For some reason, I am getting a total mismatch for the LOD model for sbluepalacegate.nif during winter (but during the other seasons it looks fine). I am using a custom form swap for this object during winter, but the replacement is using the same mesh. I tried using mesh mask rules to get LOD for this building, perhaps I screwed something up? The generated object LOD mesh can be found here, please tell me if you need anything else: https://www.dropbox.com/scl/fi/yui7f3dhiqo5y62eylu30/Tamriel.4.-16.24.WIN.bto?rlkey=fohj4dpjul471rmn3e4i13afh&dl=0 Moreover, Mistveil Keep is not showing up on the map, and I have no idea what is causing it. It is getting level 4 and level 8 LOD, but not level 16 LOD. I am using Open Cities, but I don't know why that would matter. As far as I can tell, the generated DynDOLOD files are not touching the object, nor its worldspace references.
-
Thanks! I don't plan to regenerate LOD in a while, but will tell you if it doesn't work when I have done so (but checking the contents of the file, I don't see why it wouldn't).
-
As I said, the windmill model is partly my own work and currently not published anywhere. It contains features from RedBag's Solitude, Simplicity of Seasons, Seasonal Landscapes, possibly USSEP, and a lot of bug fixes with Simplicity of Season's model that I have fixed myself. I plan to publish it along with a lot of other related stuff later this year, so I would still appreciate if you could take a look. You can find it here: https://www.dropbox.com/scl/fi/jqdd087n8b6dr6f73efev/swindmillsnow.nif?rlkey=8esdakkj3abcfyvdhhb105c5y&dl=0. Or is it possible for me to fix it myself by e.g. reordering the blocks? xx13DD6B is disabled by OCS + LOTD5 Patch.esp, which is provided at the Open Cities mod page at AFKMods. I thought the missing LOD objects were due to Open Cities, but could it be resolved? Not seeing the museum building on the map is an eyesore, so I would appreciate if you could create a custom rule for it. There is an instance of the museum building in the Tamriel worldspace, but it is disabled and that is not changed in the Open Cities patch. For RedBag's Solitude, I could provide a list of the affected references if you are willing to look into it. Otherwise I could just create a patch myself that copies the relevant objects to the Tamriel worldspace.
-
I am getting some weird LOD issues in Solitude. First, I get a duplicate rotor for the Solitude windmill, like in the screenshots. This only happens in winter, where I am using a custom mesh for the windmill, which is based on the mesh from RedBag's Solitude, but with quite heavy modifications (it is not the same as you will find on the mod page of its reference). During autumn, I am using a retexture of the original mesh, and that works fine. Another issue I think is related to Open Cities. RedBag's Solitude has quite a few statics that are only placed in the Solitude worldspace, but they are marked as persistent, so they show up just fine in the Tamriel worldspace. However, they don't get LOD, despite checking the High rules for child-to-parent worldspace LOD inheritance. Is that functionality disabled entirely with Open Cities? If so, I think you should include some exceptions. Similarly, the museum building from Legacy of the Dragonborn (0B8D4B2F) is not showing up on the map. That object does not have any correspondence in the Tamriel worldspace, either. It is getting LOD, but I think that may be because I am selecting "Upgrade near grid to far grid" for large references. Another weird issue is that Erikur's House (00090E57 or 0008E2C9; the second one is the OCS reference) is not getting any LOD at all. Other instances (from RedBag's Solitude) are getting LOD, so I don't understand what is going on here. Here is a link to the logs (not sure why the debug log ended up so large): https://www.dropbox.com/scl/fi/ef90b9t3zloufid6620xn/Logs.7z?rlkey=nnt7uh9ohtanmkzlqktnsttdx&dl=0
-
Improvements for mods, rules, LOD models
Jonado replied to Jonado's question in DynDOLOD & xLODGen Support
Perhaps I should add that the rock is referring to these specific references: 0xB3A7C~RedBag's Solitude.esp 0x7B2BE~RedBag's Solitude.esp I also noticed while studying the existing mesh mask rules for RedBag's Solitude that there was a reference to RBSolitudeMeshes\SBluePalaceGate.nif, which does not exist. Perhaps this was intended for the Vanilla object? Some of the other objects I reported for RedBag's Solitude do have mesh mask rules (but not all of them), so I think there is a bug making them not showing up on the LOD mesh for my mod build. I have a good idea of what is causing it, but will do a bit more testing before reporting it in the main forum.