Jonado
-
Posts
39 -
Joined
-
Last visited
Jonado's Achievements
Noble (3/12)
0
Reputation
-
You already got the logs. It is the same generation as in my other recent posts. There is also nothing else that is conflicting for that record - literally all information is in the screenshot I sent you, and that applies to my entire load order as well. But to be fair, I have changed the load order a bit since I last generated LOD. Seasonal Landscapes is FE0A4 in the logs. The relevant reference (with double windmills) is 00050C5A. What I am reacting to is that DynDOLOD is trying to apply the texture swaps to 3D index -1 for all the trishapes - they should be 11, 12, 13, and 14 respectively, just as for the regular SWindmill object. There is nothing wrong with the model. I also haven't had any issues with this model before - likely because Seasonal Landscapes already removed the Windmill fan and Dyndolod didn't do anything to change that.
-
Okay, I'll test it next time I run DynDOLOD (not sure when that will happen though). I found another issue, though. I am getting duplicate windmill sails on the Solitude Windmill - this time for the autumn object (from Seasonal Landscapes). Checking what happens in xEdit, it looks like in the screenshot. That doesn't look right.
-
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.
