DarthVitrial
-
Posts
209 -
Joined
-
Last visited
-
Days Won
1
Everything posted by DarthVitrial
-
I sent the MO2 devs the full debug log, but...I've sent them bug reports in the past and I've never even gotten a reply, so I'm not optimistic. :/ I can try the latest TexConv. EDIT: Latest TexConv worked! Or at the very least it launched through MO2 without any errors, we'll see if TexGen fully runs and completes. EDIT 2: Ran and finished with no errors.
-
1: yes, I repaired/reinstalled. 2:Works perfectly if started directly instead of through MO2 (though obviously it can't see my mods) 3: yep, returns nothing with no error. 4: Through MO2 or by itself? If you mean by itself, yes, that's what it shows. Should I upload that?
-
Using alpha-165, TexGen is unable to launch through MO2 (2.5.1RC2), always failing with "Error: Executing Texconvx64.exe returned error code C0000005. "E:\Dyndolod\Edit Scripts\Texconvx64.exe"" I've already ensured my graphics drivers are up to date and with all extraneous bloat disabled, checked to make sure my antimalware isn't blocking anything, and made sure I have the most recent Visual Studio Redistributables. I've reported this to MO2 already since it might be a MO2 bug but I figured I'd report it here as well just in case. TexGen logs attached. TexGen_SSE_log.txt TexGen_SSE_Debug_log.txt
-
That build seems to have fixed it. The .net error still showed up in the event log but LodGen finished with no issues, no assertions or error messages in the log. Mind if I ask what you changed in that test build? DynDOLOD_SSE_log.txt
-
It's repeatable. Different cell, same error. Same error in the event log too. I have the x64 version of the .Net Runtime 7 installed (with the Desktop Runtime, yes). Bugreport and log attached. Debug log: https://mega.nz/file/g9chHZRR#z3flhjM-b6rKAQsX8eRsrddQgbPMEEkQi7273i-D2pQ bugreport.txt DynDOLOD_SSE_log.txt
-
Got an Assertion Failure message in Alpha-127. Assertion failure (C:\Delphi\Projects\DynDOLOD3\Core\wbImplementation.pas, line 17505) while processing Glenmoril.esm [REFR:1C00DE69] (places NorTempleExterior01Base [STAT:00026FDE] in GRUP Cell Temporary Children of GHKyneTemple02 [CELL:1C00DE64] (in zGHWitchForestWorld "Vahdin Holt" [WRLD:1C00DE4D] at 0,2)) Error: Assertion failure (C:\Delphi\Projects\DynDOLOD3\Core\wbImplementation.pas, line 17505) while processing Glenmoril.esm [REFR:1C00DE69] (places NorTempleExterior01Base [STAT:00026FDE] in GRUP Cell Temporary Children of GHKyneTemple02 [CELL:1C00DE64] (in zGHWitchForestWorld "Vahdin Holt" [WRLD:1C00DE4D] at 0,2)) User says "Exit DynDOLOD" log and bugreport attached. Debug log (it's big): https://mega.nz/file/F1NChSxb#HZkBC1X-UVLWwNiNBgEgMhH5aG8wAZ0CbKi8ezQqesA I also found the following in my Event Log: Description: A .NET application failed. Application: LODGenx64Win.exe Path: E:\Dyndolod\Edit Scripts\LODGenx64Win.exe Message: You must install or update .NET to run this application. App: E:\Dyndolod\Edit Scripts\LODGenx64Win.exe Architecture: x64 Framework: 'Microsoft.NETCore.App', version '6.0.0' (x64) .NET location: C:\Program Files\dotnet\ The following frameworks were found: 7.0.4 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] If this is the same issue, does that mean LodGen doesn't work with .Net 7? I always thought .Net 6 onward was backward compatible (actually doesn't installing 7 remove 6?) but if not I'll roll back to .net 6 and try again. (I'm certain I've used DynDoLod/LodGen with .Net 7 before with no issues though, as recently as two months ago, which is odd. Maybe the two errors are unrelated?) bugreport.txt DynDOLOD_SSE_log.txt
-
I think I figured out the file size thing - it’s because this drive is formatted as exFAT, which has the really large cluster sizes (256kb vs ntfs' 4kb). So yeah the only actual bug was the race conditions. That test build fixed the first one and then running it work -speed worked around the other one, I guess, so that’s all good. Now that I've moved it back to an NTFS drive, do you want me to run without the -speed flag once more to get more logs about the race condition crash?
-
Seems to have worked, in that instead of a race condition it just generated 250gb of files and crashed my ssd xD (40gb meshes, 210gb textures, though with a rather strange thing - the"actual size" of meshes is 600mb, "size on disk" is 40gb, and the same thing for the textures - "Actual size" is 5 or 6 gb, "size on disk" is 210gb? Not sure what that really means though). I'm going to examine the textures folder, I want to see if it's one specific worldspace that's so large. Anyway that argument did do something to help the race condition though. Out of curiosity, is the reason I get so many race conditions because I have a ryzen 5900x? I know it has a lot more cores than normal processors and the scheduler sometimes has issues with it. Edit: Hm, the biggest culprits seem to be dlc2solstheimworld and arnimaduplicate003 so far. Especially Solstheim, its texture folder is triple the size of Tamriel's...I wonder why. Sovngarde was also 5gb, which seems a bit excessive. I'll check the texture format in a bit. LODGen_log.txt
-
It crashed again after about an hour. :/ Bug report attached. Logs: https://mega.nz/file/k0lg1ZjT#3652CmIiichoTEKhdP00fVkqD9xihEATJchMyFn0tNk For when it does work, how do I check texture compression format? bugreport.txt
-
No crash so far! Still running, been about an hour. though it is a little surprising that the file size is already over 100GB on low quality settings.
-
it crashed again with the test version, no errors found in my plugins. Bugreport and logs attached. bugreport.txt LODGen_log.txt SSELODGen_log.txt
-
OK, followup - this time it just got to "Operation aborted" and it had 250GB free, so space doesn't seem to be the issue. Maybe another race condition? Bugreport.txt attached. Logs: https://mega.nz/file/glcgBRrK#8pKFL3gRI-cL--RVbHtTqvJi54ia3eazPCslvaT3wB0 bugreport.txt
-
Quick question - the last few times I've run xLodGen to generate Terrain LOD (just terrain, no object or tree), it's run out of space due to generating nearly 300gb of files in about 10 minutes. If this is just my setup (too many high poly meshes, too many mods with custom worldspaces, etc), that's fine then, I'll just free up more space, but I wanted to post my logs here just in case it's not actually supposed to be generating that much stuff (I could swear in the past it's never been even 100gb and I haven't changed my LO that much) and something is going wrong with the actual generation process (since there are errors in the Bugreport.txt that don't look like space related errors?). I'm going to try with all the quality settings at lowest for now, see if that uses less space, but I figured I'd post my logs and bugreport here on the off chance that it's a bug and not just my setup having too many things in it. SSELodGen log: https://mega.nz/file/Y1lSVDJZ#9OliNEWrDjbwBjnYzbVlOmCqgA42QJMkcTxvbkt_Vis LodGen Log: https://mega.nz/file/Eg8ikJ6J#FcAwJft9nUBqJ8DyofAm4sSpDrBzp3kIwafhUx_0yI0 bugreport.txt
-
Texconv error C0000142
DarthVitrial replied to DarthVitrial's question in DynDOLOD & xLODGen Support
I tried again and the error didn't repeat, oddly. Might have been a one-off thing. It did seem to happen during the Seasons part of the generation. I used the NifOptimizer texture scan tool, it didn't find any issue with that texture. -
Got Error C0000142 while running LodGen ("Error: Texconv error C0000142 textures\lod\trees\treeaspenbranchcompautumn03.dds "H:\Dyndolod\Edit Scripts\Texconvx64.exe" -nologo -y -m 1 -aw 256 -f R8G8B8A8_UNORM -o "C:\Users\redhe\AppData\Local\Temp\DynDOLOD_SSE" "C:\Users\redhe\AppData\Local\Temp\DynDOLOD_SSE\596A512B1597405D82F3AE2B6B49D6CD.dds"). (https://imgur.com/a/xVTojWT) Logs: https://mega.nz/file/Z9NiHbwC#XrZ2gCBv5n-FYC7lycy47NqkcwSqYZJ2C8x3ytxxuTM No bugreport generated. The key part from the debug log seems to be this:
-
Hard to tell for sure, but it seems to work.
-
Good luck ^^; Sorry the logs/bugreport didn't have the full details on what was racing with what.
-
No, not always the same.
-
Maybe 10% of the time or so?
-
Got another Assertion Failure in alpha 95. Probably another race condition? Assertion failure (C:\Delphi\Projects\DynDOLOD3\Core\wbImplementation.pas, line 17465) while processing cckrtsse001_altar.esl [REFR:FE03EF28] (places RockPileL03Snow_HeavySN [STAT:0005B506] in GRUP Cell Temporary Children of [CELL:FE03EE5D] (in ccKRTSSE001QNWorld "Giant's Tooth" [WRLD:FE03EA5F] at -1,1)) Logs: https://mega.nz/file/l1UD3L6S#DePgP5PJUq3nUPXBFdFm7pITaAA-6Otg6x5SaF-L3ks Bugreport attached. key point in the debug log: bugreport.txt
-
Seems to have worked perfectly! Mind if I ask what the bug was? EDIT: Though there was one odd thing in the log: [00:04] Background Loader: <Note: [REFR:0190001B] (places [0F0B1985] < Error: Could not be resolved > in GRUP Cell Temporary Children of WhiterunTempleofKynareth "Temple of Kynareth" [CELL:000165A7]) was injected into Update.esm> But when I put my Load Order into Xedit that reference works fine. It's the USSEPUnwantedEffectsRemoverBook from USLEEP.
-
been running for about 30 minutes, no crash yet. I'll keep you posted.
-
Same error, different cell. [05:48] Error creating textures for cell [18,19] Assertion failure (C:\Delphi\Projects\xEdit\Core\wbImplementation.pas, line 17354) [05:55] Error creating textures for level 4 quad [16,16] Error creating textures for cell [18,19] Assertion failure (C:\Delphi\Projects\xEdit\Core\wbImplementation.pas, line 17354) Logs attached. The ntdll bugreport overwrote the assertion failure one before I could grab a copy this time, sorry bugreport.txt logs.7z
-
OK it crashed again, different worldspace this time. [31:00] Error creating textures for cell [-2,-9] Assertion failure (C:\Delphi\Projects\xEdit\Core\wbImplementation.pas, line 17354) [31:07] Error creating textures for level 4 quad [-4,-12] Error creating textures for cell [-2,-9] Assertion failure (C:\Delphi\Projects\xEdit\Core\wbImplementation.pas, line 17354) This was a weird one. It gave about 40 errors in a row (with each bugreport overwriting the prior one). the first 39 were identical - ": Assertion failure (C:\Delphi\Projects\xEdit\Core\wbImplementation.pas, line 17354)." link to one of the bugreports, they were all mostly identical: https://pastebin.com/pPaT6aqn The 40th and final error was "Access violation at address 00007FFEF930416A in module 'ntdll.dll'. Write of address 0000000000000024.", which might be an unrelated error just caused by xlodgen crashing as a result of the assertion failure above? Bugreport for the ntdll one and the LODGen_Log attached. SSELODGen log was too big, mega link: https://mega.nz/file/050nEBqQ#ixvN3tGvjJw37SXXYJXU7Gidw9k0V-UrUze7EAVwj_0 bugreport.txt LODGen_log.txt
-
I'll try running xlodgen again and see if it happens at the same point. ...last time I did it my PC fan started making very concerning sounds though, I've never had my CPU temps spike that high before.
