Jump to content

fadingsignal

Members
  • Content Count

    14
  • Joined

  • Last visited

  1. OK thank you. I don't understand enough about the form versions, so pardon my ignorance, but what is the reason they're still form version 34 in the master Skyrim.esm but become version 44 when they're copied/overridden by xEdit?
  2. Zilav -- Correct, editing shaders in the CK completely breaks them. If you simply load up the base ESMs and make a change at all, then save, the resulting plugin will not work in game (invisible particles due to crazy numbers and box size 0), and the values shown in SSEEdit when inspecting will be insane large numbers everywhere like I showed in that first post a few days back. In fact, simply opening a plug-in that contains particle shaders in the CK, making an unrelated change (i.e. a keyword) and saving the plug-in breaks them the same way, then have to be repaired in SSEEdit. The version of SSEEdit I was using, and just reverted to works fine however; shaders work great in-game as expected (SSEEdit 3.1.3-164-3-1-3). I released True Storms today on Nexus/Bethesda.net without any issues even.
  3. Hey there, back again with another question. The newest update is showing lots of Shader Particle Geometry errors and I'm not sure how to proceed. Screenshot: http://i.imgur.com/BojiOuZ.jpg Do I just need to rebuild them? And is the form version (44 vs. 34) a problem? Here is what it looks like with the version I've been using before I updated today (SSEEdit 3.1.3-164-3-1-3): http://i.imgur.com/AJaElgL.jpg
  4. Zilav: You're a machine! Thank you! I've confirmed that editing the SPGD in the SE CK is what breaks it. When I open it with SSEEdit and repair the values, it works fine in the game again, even with the previous version before you added the fixes. In short, the CK has a bug.
  5. I apologize if this is not the place to post this, but in working on True Storms for SE, I realized that making any changes to the particle shader geometry in the SE CK causes it to become invisible. Loading the saved plug-in in xEdit shows completely crazy values in the plugin after saving in the CK and loading it up, specifically box size and density of 0, which explains the invisible rain/snow. I would be grateful if someone could test this to vet the issue. Load Skyrim SSE CK and load Skyrim.esm Edit RainStormParticles, change any value (say make particle density 3) Save a new plugin Load the game, enable the plugin Force rain storm weather using console command fw C8220 Rain will be invisible This is with everything else being vanilla.
  6. Shader Particle Geometry records appear to get jumbled a bit. I made some changes, but when re-loading the plugin the values were all different (for example x scale was 1.5, but reloading it became 40, etc.) Very excited, thank you guys for always being on top of this. EDIT: It looks like this is likely a CK bug. Making any changes to shader particle geometry in the CK renders those particles invisible. It seems the CK is writing bad values. I reported this to Bethesda. EDIT 2: Could be an issue on both sides. Loading a plugin made in the CK with edits to particle geometry gives me: <Warning: Unused data in: \ [01] ParticleProblem.esp \ [1] GRUP Top "SPGD" \ [0] RainStormParticles [sPGD:0010780F] \ [2] DATA - Data> <Warning: Unused data in: \ [01] ParticleProblem.esp \ [1] GRUP Top "SPGD" \ [1] RainParticles [sPGD:00023C48] \ [2] DATA - Data> <Warning: Unused data in: \ [01] ParticleProblem.esp \ [1] GRUP Top "SPGD" \ [0] RainStormParticles [sPGD:0010780F] \ [2] DATA - Data> <Warning: Unused data in: \ [01] ParticleProblem.esp \ [1] GRUP Top "SPGD" \ [0] RainStormParticles [sPGD:0010780F] \ [2] DATA - Data> Sorry to blather on, as always just shoveling info in case it helps.
  7. You are awesome, thank you so much.
  8. Minor issue: When copying sound descriptors into another plugin, comparison values and function references on conditions are lost (set to 0 and null respectively) and cannot be edited, either directly or with drag/drop from the original plugin. See image here: http://i.imgur.com/wFqgccE.jpg
  9. Not sure if this is at all helpful, or is simply one of the record types that will be better suited to try and map post-CK, but working with the shader particle geometry (SPGD) I found a few values are now mapped differently, and here is what my tests in-game yielded: Gravity Velocity = This is the same Rotation Velocity = Doesn't appear to do anything in game that I could tell Particle Size X = Doesn't do anything Particle Size Y = shows NaN <-- being used or something new or pointing to a new record type? Center Offset Min = this is actually Particle Size X Center Offset Max = Doesn't seem to do anything Initial Rotation Range = This is actually Particle Size Y Number of Subtextures both X and Y don't seem to do anything Box Size doesn't seem to do anything Particle Density shows NaN MNAM - Unknown is just the old texture path, which is now the path to the material file (BGEM), which contains material metadata and texture paths (can be de-compiled to JSON using Gibbed's Fallout 4 tools, which the game will natively read without needing to compile back into binary.) Hoping to get a wrangle on the particle density, if that's even exposed anymore.
  10. Oh nice! Thank you! Well maybe in that case, I'll keep reporting back my findings just in case they are legitimate So happy you're all working on this.
  11. Yeah that makes sense. I know it won't be in any way complete until the definitions are finished being decoded, and those are probably the issues I'm seeing. For example, in weathers records, there are several "Error: Expected 4 bytes of data, found 0" for the various new color data cells, and under WGDR - God Rays the references to the god ray records load and display in the record OK, but an error occurs when that weather record is copied to a new plugin, with "Found a GDRY reference, expected: IMGS, NULL." Like I said, I'm sure all this stuff is just due to lack of definitions, so I'll just hush and be patient for now
  12. Awesome work on the FO4 update! I asked Zilav to give me a heads-up when this was released so I could start testing / playing with it and am firing it up now. I noticed a few problems, but what is the protocol for submitting issues, feedback, etc? I definitely don't want to pester anyone with something that's a known issue since I know this is still very far from a full release. Thanks again!
  13. Is there still a place to get 3.0.33 while 3.1.0 is in the experimental stage? TES5Edit is incredible, and I'm so grateful for all of the work put into it.
  14. This is a godsend. I'm the author of "Simply Bigger Trees" and the only missing component is the LOD, which has thus far been a surprisingly confusing issue to tackle (not a lot of clear information readily available.) Pardon if this is a ridiculous question, but do the LOD NIFs that sit next to the regular tree NIFs factor into the scaling of the LOD when it is generated? Or does the text file strictly control that? Reason being is that I resized all of the LOD meshes appropriately to the size of my regular trees and am hoping that is enough to do the trick. Going to play with this a bit, any tips would be amazing.

Support us on Patreon!

×
×
  • Create New...