Jump to content

z929669

Administrator
 View Profile  See their activity

  • Posts

    13,028

  • Joined

  • Last visited

 Content Type 

Everything posted by z929669

  1. z929669
    I'm aborting testing on this one, since this mod effectively requires ENB to function properly. We need everything to work with and without ENB.
  2. z929669
    Discussion topic: TMD Jars of Skyrim by TheMilkDrinker Wiki Link Improved glass jars. All screens are current Step Skyrim 2.3 development, which is essentially version 2.2.0 of the guide. ENB shots use Steap Heavy ENB with the Post Processing ModGroup enabled. Non-ENB shots are with ENB uninstalled and the Post Processing ModGroup disabled. vanilla jars, no ENB TMD Jars, no ENB vanilla jars, ENB TMD Jars, ENB (note: maniabuginjar.nif must be hidden in Elytra and Bliss Bug ENB Light to allow TMD Jars version to win)
  3. z929669
    I'm unable to get the TMD jars option to work as expected under vanilla lighting (no post-processing configured). It seems to be an issue with Rally's fireflyinjar.nif (CRC32: 5693C535) having massive refraction without ENB. I don't think it's a FOMOD problem. TMD Jars itself works fine and is my basis of reference. I posted a bug report on the Nexus with details to reproduce.
  4. z929669
    Then it's bombing too early to create the log, and it could be a driver issue or something at the OS level. I can only guess. Try system file checker from an admin command prompt: sfc /scannow. Then, I would uninstall/reinstall my .net 7 to see if that resolves and then update my video and relevant system drivers if not. You could look at your Win event log for clues.
  5. z929669
    I interpreted that comment to be addressing only the one warning line line in the Engine.log. If your interpretation is also true, then that would explain the files diff. I honestly don't know though. Regardless, I think this mod needs to be in beta before we seriously consider it again... and we'd need to be running actual custom animations to test.
  6. z929669
    I edited my post likewise. See edit comment. Nevertheless, there's still quite a discrepancy between the Nemesis and Pandora output of animation files with no LO difference (106 vs 12, respectively). This was not addressed by the developer.
  7. z929669
    I will post more deliberatively the proper compares I can stand behind 100%... not until tomorrow though, as I'm too disappointed that I spent all this time today and yesterday for naught
  8. z929669
    Well, one of my screens was wrong, so now I mistrust every compare I've posted. The issue is that for testing without ENB, I must disable ENB itself (remove binary + assets), disable the post-processing modgroup, and I must install this mod with no ENB options and either vanilla jars or TMD jars. Couple this with hiding textures and the like, it's easy to muck up testing scenarios. This is why I don't entirely trust my assessments and configs for all screens presented. I'm going to start over
  9. z929669
    I removed all screens from this post, because I mucked up at least one of my testing scenarios (and corresponding screen). Leaving the post for context, but please ignore everything. After further investigation, it looks like the vanilla jar mesh (USSEP modified) does not allow ENB lighting effects to pass through the jar. We only see this with Rally's versions of the bugs in jar OR with TMD Jars: Vanilla torchbug + vanilla jar + ENB (note that no bug light is striking the table top, whereas it does in the following three screens) Vanilla torchbug + TMD jar + ENB (note that Rally's [this mod] is NOT installed in this shot) Rally's torchbug mesh + vanilla jar + ENB Rally's torchbug mesh + TMD jar + ENB So... It's the ENB-compatible jar that causes the 'smoothing' issue of the firefly in the jar and not the firefly mesh. IMO, the smoothing problem is an acceptable trade-off for the ENB effect of light passing through the jar. For reference WITHOUT ENB: vanilla jar TMD jar (note The TMD jar is 'thick' relative to the vanilla jar, hence the refraction effect warping the bug.) TMD jar (Rally's installed without ENB support) The TMD jar is 'thick' relative to the vanilla jar, hence the refraction effect warping the bug. ENB effects coupled with Rally's version of the TMD jar makes the thickness even so the refraction effect is negated. I prefer the TMD jar (both with and without ENB), so I will post another topic for that mod. In summary, I vote to 'accept' this mod and simply not use its textures.
  10. z929669
    "Pandora Output.zip" is just an archive of your Pandora Output mod (if you redirect output into a mod in MO. I assume with WB, the output is generated in the game directory, but I'm not sure where. Search for 'Engine.log'. That's where your output is going. I have no ideas about the app failing though. My output consisted of the following:
  11. z929669
    I added a new compare to my post and a description at the beginning. In game, the new compare scenarios look best, IMO. The smoothing problem still persists with the higher-poly model in jars though.
  12. z929669
    I agree with this.
  13. z929669
    I removed all screens from this post, because I mucked up at least one of my testing scenarios (and corresponding screen). Leaving the post for context, but please ignore everything. Step 2.2.0 torchbugs (and blissbugs) use vanilla textures and modified vanilla meshes provided by Rudy HQ - More Lights for ENB SE - Torchbugs and Moths to enable ENB lighting effects. Blissbugs also use vanilla textures and modified vanilla meshes provided by Elytra and Bliss Bug ENB Light in the same manner as Rudy's. Both mods use essentially low-poly vanilla meshes with some added shader flags and similar adjustments for ENB compatibility. Rally's does the same thing, but also provides HR textures, which seem to be overkill for the size of these bugs. Rally's meshes are superior though, IMO. Here's some test screens (L to R) of the torchbug under Step 2.2.0 with changes introduced by this mod (Rally's) and TMD Jars. 'ENB' is Step Heavy. NEW compare is simply Rally's (this mod) with it's textures hidden so that only its meshes are used: No ENB (vanilla torchbug in jar) No ENB (Rally's torchbug in jar) ENB (Rudy's torchbug in jar) ENB (Rally's torchbug in jar) Rally's meshes, vanilla textures, ENB NEW compare Step 2.2.0, ENB Rally's, ENB Rally's meshes, vanilla textures, ENB NEW compare With TMD Jars + ENB: ENB (Rudy's torchbug) ENB (Rally's torchbug) Rally's meshes, vanilla textures, ENB NEW compare ... There's some ENB bugginess with Rally's torchbug and with both torchbugs in the TMD jars... the nearest part of the bug is very clear at times, while the other parts are faded. I prefer the TMD Jars over vanilla though. The vanilla glass is good, but man are those jars shaped like a Minecraft cartoon with all the jaggies ... hard to see in these screens. I really couldn't care less about this mod and am saddened that it took me two hours to get this evidence. ... that is to say, I don't think this is a bad mod. I just don't think torchbugs are large enough to matter texture-wise. As long as they glow, I'm happy. It's worth mentioning that the light trail is added by Rally's, which is nice.
  14. z929669
    I updated the guide. I think I hid all irrelevant content. Also updated the BEES explanation a bit. Let us know if there is still an inconsistency.
  15. z929669
    Tagged 'testing' for 2.3 I created a GitHub issue for my question about Pandora output. I have little faith that it will be addressed by the Pandora devs. It was addressed to my surprise, and the below warnings are proper and harmless. I'm essentially confused by the Pandora Engine.log warnings (errors, IMO). I suspect this is the cause of the difference illustrated further below. INFO : Skyrim Patcher 1.5.1-alpha WARN : Dispatcher > "Pandora Base" > dragonproject~dragonbehavior > Replace > Element > #0885/legs/Element0/maxAnkleHeightMS > FAILED WARN : Dispatcher > "Ice skating fixed for real" > defaultfemale~1hm_behavior > Replace > Element > #2521/event/Element0/id > FAILED WARN : Dispatcher > "Pandora Base" > dragonproject~dragonbehavior > Replace > Element > #0885/legs/Element0/hipIndex > FAILED WARN : Dispatcher > "Pandora Base" > dragonproject~dragonbehavior > Replace > Element > #0885/legs/Element0/kneeIndex > FAILED WARN : Dispatcher > "Pandora Base" > dragonproject~dragonbehavior > Replace > Element > #0885/legs/Element0/ankleIndex > FAILED WARN : Dispatcher > "Pandora Base" > dragonproject~dragonbehavior > Replace > Element > #0885/legs/Element0/isPlantedMS > FAILED INFO : Engine launched with configuration: Skyrim SE/AE INFO : Pandora Mod 1 : Ice skating fixed for real - v.1.0.0 INFO : Pandora Mod 2 : Pandora Base - v.1.0.0 INFO : Pandora Mod 3 : XPMSE Patch For Pandora - v.1.0.0 In comparison to Nemesis, Pandora generates fewer output files (animations): Nemesis (106 animations) Pandora (12 animations) I will say that I like that Pandora lists only the animation-related mods I have installed in addition to those shipping with Pandora. Nemesis provides a seemingly random and incomplete list of mods in addition to what I have installed. On the other hand, Nemesis provides more useful information and output in the GUI than Pandora. I'm leery on Pandora at this point, given the log warnings and relative lack of output. I have no idea if there's an issue or not, but I wanted to mention that I'm a 'no' for using Pandora at this point. The relative speed of Pandora is much better, but it's producing only a small fraction of the output generated by Nemesis. My guess is that if it ever goes into beta, I'll give it another look. It will also be more interesting to compare Pandora/Nemesis when we actually begin testing out custom animation mods for Step SkyrimSE 2.4-2.5. Pandora evidently seems to be working for other people using custom animation mods, but the Step guide only uses some vanilla replacers. And I don't like the 'warnings' in the Pandora Engine.log of reported failures of mods, including those presumably shipping with Pandora itself (or my lack of understanding of cause/resolution of said warnings). Nemesis has none of these issues/warnings/errors, and produces much more extensive output, so I'm inclined to continue using it.
  16. z929669
    I've scoped this one out and incorporated it into the Step Patches and can vouch for it. Tagging 'accepted' for 2.3.
  17. z929669
    Yes, I missed that.
  18. z929669
    We don't support Nexus Collections, so I recommend reaching out to the curator(s) for specifics, but it looks like you have a language/localization issue with Python/BethINI and your INI files. Delete your game INIs, and let the game regenerate them by using the Steam Launcher to start the game and then BethINI Pie again to modify them.
  19. z929669
    It should work handsomely with a new game. Greg was probably considering savegame compatibility.
  20. z929669
    Yes. My bad.
  21. z929669
    I also use 512 bytes/sector on all of my drives, and I believe this is the default under all versions of Windows. Using > 512 wastes space with many small files, so it's generally recommended to use 512 on the OS drive. I had experimented with using sectors as small as 4 bytes to maximize storage capacity. Maybe a good thing for pure backup drives, but probably a performance hit on the OS or game drives. This mod might benefit a very small subset of users, but probably n/a for 99% of them. It's good to have this topic though, as I recall just recently someone posting about sound issues, and it may have been related to large sectors.
  22. z929669
    I think the cloud 'flicker' and also the 'banding' could be due to ENB. You can tell that it's a proximity issue to the PC when panning left/right. It's much like the fog problem... and may be directly related to that. Test by toggling ENB off using shift+F12 to see if the problem goes away without ENB. If ENB is the cause, read on. I forget exactly how I resolved, but IIRC, these need all settings as indicated in all weathers and main enbseries.ini [ENVIRONMENT] FogCurveMultiplier ≥ 1.0 FogAmountMultiplier ≤ 1.0 It could also be related to the cloud* settings under [Sky] or settings under [VOLUMETRICFOG] There's also some testing info on our WTT mod page if that's of interest. We're not using any fix, AFAIK other than hiding the plume from Tamriel (I think, it's been a while).
  23. z929669
    Here's an example of a FaECF treatment of a fireplace that has two fires in vanilla... probably to make it 'bigger'. RS adjusts the position of the second fire, while FaECF eliminates it altogether. Here's the result: vanilla >> RS >> FaECL My opinion: Both RS and FaECL changes are an improvement over vanilla. I prefer the FaECF solution just slightly (removal of the second fire), assuming there will be a positive impact on performance. Relevant records: 000CE607 & 000CE624 Also, this is a small shack with only a single hunter, so a smaller fire seems more realistic.
  24. z929669
    Also, the FaECL-RS patch will not be needed. The Step LW patch will incorporate FaECF changes that matter and keep all RS initially disabled refs buried... the FaECL RS patch initially disables said refs but does not bury them, but RS buries them to prevent lighting conflicts with it's other lighting customizations.
  25. z929669
    You can use them as you like. The Step patches will take care of it in 2.3. I just checked the RWT patch, and it's entirely redundant if RealisticWaterTwo.esp is higher priority than Fires and Embers Clipping Fix.esp. I'm not sure why the MA created this patch.
×
×
  • Create New...

Important Information

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

  I accept