Jump to content

z929669

Administrator
 View Profile  See their activity

  • Posts

    13,028

  • Joined

  • Last visited

 Content Type 

Everything posted by z929669

  1. z929669
    Running latest alpha for the first time after upgrade from Alpha 44 (clean directory). TexGen runs fine, but DynDOLODx64 is failing without reson. LODGenx64 completes without issue long after DynDOLOD fails. No bugreport.txt, and no DynDOLOD log or debug log generated. Tree report is fine. This is now acting like my xLODGenx64 unresolved issues. I am running DynDOLOD in the same manner with same settings as I have been for months now. Alpha 44 ran without issue, and this is essentially a repeat using Alpha 47. It seems the error occurred during logging of this file or immediately after: App window closed. Event: Faulting application name: DynDOLODx64.exe, version: 3.0.0.0, time stamp: 0x615ec9a2 Faulting module name: KERNELBASE.dll, version: 10.0.19041.1202, time stamp: 0xc9db1934 Exception code: 0x0eedfade Fault offset: 0x0000000000034f99 Faulting process id: 0x7c08 Faulting application start time: 0x01d7be43e42f7282 Faulting application path: C:\Modding\Tools\DynDOLOD\DynDOLODx64.exe Faulting module path: C:\Windows\System32\KERNELBASE.dll Report Id: dd705d9e-af4b-46e4-acd9-879a7c1b1261 Faulting package full name: EDIT: Ran without issue the second try. No changes otherwise. EDIT2: This is my first time experiencing this. Not a DynDOLOD issue but rather a model issue I am thinking. The aspen hybrids are very dark relative to full and other trees seem fine. Any idea offhand what might cause this? Using default TexGen settings, and only the aspens seem impacted. I'm thinking it is something with the crowns, but they are copied over from the full models as usual. Model examples follow if you care to have a look (tree mesh rule is Level0/Level1/Level2 with all else default):
  2. z929669
    ... so what is the status of this mod for 2.0.0? N/A?
  3. z929669
    We will need to add instructions for both mod versions for all ENB and non-ENB, since we are now supporting both. NOTE: whenever you open an OP with a prefix for edit, Radical Tags will stupidly add the prefix as a redundant tag, so always try to remember to remove the redundant tag before saving. Same thing for adding prefix via the quick tag system. Just never use quick tag edits unless removing a tag. It seems to work for tag removal.
  4. z929669
    Added dropped version tag or posterity
  5. z929669
    I have yet to install all accepted and remove all dropped from my mod list. Once I do this, I will be able to validate instructions. I am also installing 2.0.0 from scratch in Vortex, so that will be an opportunity for me to fine tune and validate everything. All mods downloaded (not installed) but will need to drops a few and add a few new ones from today's changes and anything else coming down the pipe in the next few days.
  6. z929669
    Immersion seems reasonable, especially if the flowchart got you there. OP tags updated
  7. z929669
    Added guide version and testing tags
  8. z929669
    I added the 2.0.0 tag to this as well. Whenever we are considering a mod for a particular guide version OR reconsidering a previously added mod, they should be tagged testing and with the guide version in question. This way, mods added now will get 2.0.0 and be easily queried for updates to our mod lists (prior to being modified for drop/accept, since the dev guide mod list is not reliable for this info during testing). If it is later dropped, it would also have that guide version tag. This keeps the version records on the forum mod topic for posterity.
  9. z929669
    I'm glad someone else noticed this. I had wondered about this from day one but never dug into it and forgot to post about it. It didn't seem like these would be compatible since they both made changes to the perk tree.
  10. z929669
    Agree. It adds assets to /data/interface, so it should be excluded from extenders or resources for this reason ... hopefully the definitions for extenders and resources state this pretty clearly. I know that my wording did.
  11. z929669
    I completely agree, but mod instructions may need to change as well with certain mods when moved ... in some cases, this could impact instructions for other mods not changed. May or may not require some guide changes, depending on the mod. Changed tag
  12. z929669
    That is where I would have put it even without the flowchart, I think. Passes the smell test
  13. z929669
    @TechAngel85 Just checked how this behaves with EVT, and there are no plugin conflicts. Also, Dilon Vul looks good with EVT. I think I know the one dark dead (oak?) tree you refer to. It doesn't bother me, but it arguably seems a bit out of place. Ignoring that, what do you think? I think it's a big improvement to the marsh. Perhaps we can hide that tree via the CR patch or just accept that tree. It seems OK to me though. EDIT: No screens taken though, as I would need to regen DynDOLOD, and I am not there yet.
  14. z929669
    No worries. Agree that blanket approaches aren't best ... this is why I was mentioning that we should not just assume ELFX meshes are better where they conflict.
  15. z929669
    Yes, I do get that but just want to avoid favoring ELFX if these meshes better support our textures and lighting (with ENB and without). If no real obvious difference, then simple is better (ELFX). But we are favoring this guys meshes over ELFX in some cases, so we should do the same wherever these other meshes have analogous improvements to those with respect to ELFX. Maybe not feasible to check easily, but just wanted to have a clear reason for choosing one or the other.
  16. z929669
    Yep, I know. Conflict management is the only reason for the deviation. This is the ONE thing that Vortex does better ... allowing logical categorixation with more configurable conflict management in this particular case.
  17. z929669
    Seems like some compares or verification might be nice either way. If you have done that, I will take your word for it.
  18. z929669
    these new mesh replacers could all be improvements to ELFX in terms of efficiency aside from shape/performance improvements. Heck, they could even be modifications to ELFX resources, IDK. If one of these MrNeverLost meshes is better, then there is a good chance that all of them are.
  19. z929669
    these new mesh replacers could all be improvements to ELFX in terms of efficiency aside from shape/performance improvements. Heck, they could even be modifications to ELFX resources, IDK. If one of these MrNeverLost meshes is better, then there is a good chance that all of them are.
  20. z929669
    For this reason, I want to check if all of MrNeverLost changes are improvements to either directly or inspired by ELFX. There's a good chance that they are all/most improvements.
  21. z929669
    I tend to agree, but these new mesh replacers could all be improvements to ELFX in terms of efficiency aside from shape/performance improvements. Heck, they could even be modifications to ELFX resources, IDK. I guess I'd want to investigate a bit. If one of these MrNeverLost meshes is better, then there is a good chance that all of them are.
  22. z929669
    I understand that perfectly. I repeat my comment exactly. If this mod splits the meshes more efficiently, then I guess I'd want to use it ... if it provides split meshes not provided by any other mod, I'd want to use it. It should go into Foundation in that case, along with all of the other mesh replacers for which we must strategically manage conflicts.
  23. z929669
    Worth a look. Better check against all of the mesh replacers we have picked up recently.
  24. z929669
    I guess I'd want to understand if the conflicting meshes are substantively different. If so, I'd want to know if this one is better. If not, agree we should drop or see what it provides and hide the rest.
  25. z929669
    Particle Patch and USSEP, I agree, but DynDOLOD Resources does perfectly.
×
×
  • Create New...

Important Information

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

  I accept