Jump to content

PRieST

Citizen
 View Profile  See their activity

  • Posts

    212

  • Joined

  • Last visited

  • Days Won

    1

Everything posted by PRieST

  1. PRieST
    Right now the output looks this way in the xEdit info tab (from all valid selected records): Copy between this >> 0x23818~Skyrim.esm|posA(0,0,-30000),flags(0x00000800) 0x23819~Skyrim.esm|posA(0,0,-30000),flags(0x00000800) 0x2382C~Skyrim.esm|posA(0,0,-30000),flags(0x00000800) 0x2382E~Skyrim.esm|posA(0,0,-30000),flags(0x00000800) 0x23832~Skyrim.esm|posA(0,0,-30000),flags(0x00000800) 0x2CC60~Skyrim.esm|posA(0,0,-30000),flags(0x00000800) << and this If you have a _SWAP.ini ready you just need to copy this under [Transforms]. or you need to create a new one (example_SWAP.ini) and write [Transforms] first and than copy the output into it as well. So for example, if you want to hide everything in the quasmoke cell, it took only seconds to create a new swap file (I attached the example). dont_SWAP.ini Edit: made the format (hopefully) even more readable/informative: ;WhiterunWindDistrict03 (Cell: 0001A275) 0x805~test.esp|posA(0,0,-30000),flags(0x00000800) 0x804~test.esp|posA(0,0,-30000),flags(0x00000800) 0x23805~Skyrim.esm|posA(0,0,-30000),flags(0x00000800) 0x23612~Skyrim.esm|posA(0,0,-30000),flags(0x00000800) ;(Cell: 0001A273) 0x803~test.esp|posA(0,0,-30000),flags(0x00000800) 0x802~test.esp|posA(0,0,-30000),flags(0x00000800) 0x23811~Skyrim.esm|posA(0,0,-30000),flags(0x00000800) 0x23810~Skyrim.esm|posA(0,0,-30000),flags(0x00000800) ;WhiterunSkyforge (Cell: 0001A272) 0x801~test.esp|posA(0,0,-30000),flags(0x00000800) 0x800~test.esp|posA(0,0,-30000),flags(0x00000800) 0x10E42E~Skyrim.esm|posA(0,0,-30000),flags(0x00000800) 0x10E42D~Skyrim.esm|posA(0,0,-30000),flags(0x00000800) Added a line above every group of entries so you see from which parent cell (with formID if available) the records are from. Edit2: It's now published: xEdit Scripts - ESP to BOS _SWAP.ini
  2. PRieST
    That's how it's working at the moment This is how an example record looks like in xEdit: Example First script will just give you position, rotation, scale or set the 0x00000800 flag if needed - ready to copy it from the info tab into any _SWAP.ini: First script And the second one is the BOS equivalent to the 'initially disabled and set Z position to -30000 (with all other values copied from the plugin, so posA can be used) - ready to copy it from the info tab into any _SWAP.ini: Second scrip And as said above, scale, rotation, flags or position will only be added, if they are differ from the master the record is relying on OR if it's a new record (not relying on a master) and any value is set (only important for scale as position and rotation are always set). And, as you can see, you already get a shortend FormID ready for BOS as well as the name of the .esp/.esm/.esl plugin -> of the master plugin if the record you're selecting is overwriting another record or the plugin itself, if it is not overwriting anything else. @sheson: Will this work with DynDOLOD, or is there anything else I need to consider?
  3. PRieST
    So it's ok, if Z is not exactly -30000 when a swap.ini is used? I'm working on an xEdit script right now to get position and rotation ready to copy them over to an ini. A convenient way to get the exact values from the record with absolute position. That's why I'm interested, does DynDOLOD need all 6 decimal places for position and the 4 for rotation?
  4. PRieST
    But with position relative (posR) the Z position will be whatever Z was before you decreased it by 30000, so it will only ever be -30000 after the swap if it was 0 before. posA (absolute position) is the better approach, but you need to know/copy X and Y from the plugin to your _swap.ini so they are 'unchanged' after the swap. Can't tell how precise you have to be -> how many decimal places you need to copy so it will work as itended.
  5. PRieST
    Thaught the same as you confirmed it will not cause any LOD related issues. Thanks.
  6. PRieST
    Haven't seen any conflicts in my whole loadorder. And es said before, wasn't mentioned with earliere versions of xEdit/DynDOLOD. Oh, thaught it was mentioned in that one, too. I'll take a look myself and if I need further guidance I'll ask again.
  7. PRieST
    Started DynDOLOD second time without the error. 030090B4 is not overwritten. I know DynDOLOD is based on the most recent xEdit version - with that version I get the warnings regarding the FishingModsMerged.esp which wasn't the case with earlier xEdit/DynDOLOD versions. Do you know how harmful these are? I think they were from Simple Fishing Overhaul before I merged it with some other mods. Same goes for the mentioned navmesh error which is new - all mentioned FormID from the log are not overwritten, so is this a false positive? I could provide the new logs regarding these questions (from the successful run) if needed.
  8. PRieST
    Just wanted to report a one time Access Violation with Alpha-187: [Window Title] DynDOLOD [Main Instruction] Access violation at address 0000000001DD2629 in module 'DynDOLODx64.exe' (offset FF2629). [Content] Read of address 0000000000000000 while processing HearthFires.esm BYOHHouse1Room08BPart157Roof [REFR:030090B4] (Places BYOHBYOHWRtowerKEXT01 [STAT:03003C78] in [CELL:00000D74] (in Tamriel "Himmelsrand" [WRLD:0000003C]) at -3,-17) Click on this link for additional explanations and help for this message For qualified help and advice or to report a problem make a post on the official DynDOLOD support forum. [OK] [Exit DynDOLOD] [Footer] Online Help | Support Forum | Copy message to clipboard Haven't made any crucial changes in loadorder in comparison to the last successfull run with Alpha-185. After clicking OK I had to force shutdown the program. Logs: https://www.mediafire.com/file/u9tj4jruk824k33/Logs.7z/file Only bugreport.txt (attached). After starting over no violation happened. Unrelated, but TexGen still reports as version Alpha-186 instead of 187. bugreport.txt
  9. PRieST
    But you know you are participating on an open alpha test if you use DynDOLOD? Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which DynDOLOD log and debug log to upload when making posts. Don't just post pictures of errors. Also read from this post onwards as it might solve your issue - or post the logs and wait for help on debugging your error:
  10. PRieST
    https://dyndolod.info/Messages/Plugin-Limit DynDOLOD needs 2 (1x esm and 1x esp) to 3 (with occlusion.esp if it can't be flagged as light) plugins. You need to make space for it.
  11. PRieST
    At least now with the test version you provided you re-fixed everything again. Coding/programming is sometimes just a mysterious thing. Thank you for all your work you put into DynDOLOD - even if it's still considered an alpha it does such a good job an increasing the visual quality of such an old game.
  12. PRieST
    Yes, it absolutely did. So in my case it had the same cause as another issue?
  13. PRieST
    I've attached it. Natural Waterfalls.esp
  14. PRieST
    With Natural Waterfalls.esp (and though I also had to deactivate the DynDOLOD.esp) deactivated everything looks normal - no missing waterfalls are seen from position 10, -1. So I assume we have to look further into that plugin. As I mentioned before position of the waterfalls were edited, but the cell was the same as in skyrim.esm. Tell me which information from xEdit you might need. All three screenshots were made when the DynDOLOD output was fully disabled. And so Screenshot 2 was with tll switched.
  15. PRieST
    So I made following tests: Just renamed meshes and textures folder from output: No distant waterfall models visible (LOD), but instead kind of a default static waterfall LOD - which doesn't switch even if you get close, but Full Model gets visible. https://ibb.co/b69bc1y https://ibb.co/T0kvh3L https://ibb.co/S3Psj6H Disabled whole output (includeing .esp, scripts and the _SWAP.ini file): Same behavior as without the meshes and textures renaming. Only disabled the DynDOLOD.esm and .esp: No LOD models for these waterfalls (not from skyrim.esm nor natural waterfalls.esp) - and on getting closer they switch directly to the full model. Going from position 10, -5 in the direction of the waterfalls the switch (from non LOD to Full Model) happens at 9, -5. I hope this answers what you asked for. Edit: From position 11, -1 I can see a (static LOD) model for this refrence: xx08EBCC On Position 10, -2 (direction was to the waterfalls) this reference get disabled and so I see no other LOD replacing it. Also on both positions I can't see any LOD for either 0003AC79 or 0003AC7A only the full model as I am reaching the range for the switch. Yes, I am using the most recent one from nexusmods. But I could use test version if needed. Edit: Would it make a difference to use the 'Skyrim SE - Generate Large References.pas' script on natural waterfalls (and flagging it es esm before)? The one I have from the most recent xEdit version (4.1.5k) is dated 08/24/2024.
  16. PRieST
    I have to correct this, because the position is 7, -6, checked again what is shown in the MCM. Yes, nothing has changed and that is the exact load order. The position is slightly edited, but still inside the same cell. I've checked all of them, dynamic LOD model ist not shown (disabled). In comparison this one is correctly visible (don't mind the console commands, I was testing the other 5 affected waterfalls): BaseID: 181348C1 - ReferenceID: 7B08EBC8 (naturalwaterfallesp_9C6E2F_Tamriel_DynDOLOD_OBJECT) https://ibb.co/qgPwdGw From it's position it is located between the first waterfall I reported (0003AC85) and the second one (0001AC75, 0001AC76, 0001AC77, 0001AC8E and 0001AC8F) - located in Cell 7, -7 Block 0, -1 Sublock 0, -1 Edit: But not all LODs are activated, the one for this model: 0001B379 is still disabled and right above 7B08EBC8. If I had to make a guess: Every waterfall LOD directly related to skyrim.esm (just overwritten by natural waterfalls) is affected, the ones related to natural waterfall.esp (new records) are correctly shown. Sorry, I'll keep that in mind for the next time - I assumed you wanted to see the screenshot.
  17. PRieST
    MCM page from the position the LOD should be visible: https://ibb.co/KxDHjby And right next to the full model: https://ibb.co/cC8zRpK If I go interior and exterior again, dynamic LOD still not showing. If I go near the waterfalls (Full Model is loaded) and further away again, Full Models are switching to LOD models, but the waterfall is LOD is again disabled. Deactivating/activating DynDOLOD makes no difference, the LOD model stays in disabled state. Yeah sorry, this was one screenshot too much, ignore it. Also I posted them in the wrong order, doesn't matter you got the point I wanted to show. Seems to be the same issue, yes. The relevant FormIDs (reference) of the Full Models are: 001AC75,001AC76,001AC77 with the same Base ID 1A89C165: https://ibb.co/8z20k0b https://ibb.co/0jYy0T1 https://ibb.co/1Mp6VPh Edit: The two small waterfalls (seen on the bottom) are also affected as for these the dynamic LOD is also not showing. 001AC8E and 001AC8F with the Base ID: 1A89C163 https://ibb.co/JKhtHjV https://ibb.co/XCcjhqB And the location of that waterfall: https://ibb.co/TYsxZS4
  18. PRieST
    Yeah sorry, I'll try to be more specific: Exactly, the dynamic LOD model of the waterfall isn't showing. I did that and the model is indeed disabled. https://ibb.co/Kr9tc4X https://ibb.co/bzH08qr If I enable it manually it is showing: https://ibb.co/p4BttTj And this seems happen to more than just this one waterfall (I have no further info for the next example, yet): https://ibb.co/Tvy2X89 I've also attached the DynDOLOD.log from the SKSE Directory in case it helps. DynDOLOD.log
  19. PRieST
    I might have overlooked something regarding waterfalls in the forum, but I have an issue with waterfall LOD not showing/not visible - I'm not sure. Here are some screenshots (also with Full Model and LOD selected in the console): https://ibb.co/K2pSJYS https://ibb.co/sPyFBB1 https://ibb.co/gj3Yt4h https://ibb.co/rp1t5Pv https://ibb.co/6HRRv4T https://ibb.co/4gG4W5H Edit: It's hard to tell if I got the correct one. Here are a bunch more screenshots from a different angle. The waterfalls further away are visible (but it seems to not be LOD because if I toggle with tll they are still visible): https://ibb.co/4M6YXC3 https://ibb.co/ctDzyxW https://ibb.co/myc7TRk https://ibb.co/2KF2YfN And here are the logs from the most recent run: https://www.mediafire.com/file/hljjh6juq6dqaqk/Logs.7z/file I've also attached the mentioned file from my DynDOLOD Resource folder. This is how the record looks inside of xEdit: https://ibb.co/THp4q3N And as seen on the screenshots, I am using Natural Waterfalls (But I merged all 4 esp plugins into one, if that is relevant). fxwaterfallbodyslope_NW_490C5E3B_dyndolod_lod.nif
  20. PRieST
    Ok, than I know where I have to look and what I need to change. Thank you. It's not really outdated, but edited meshes from EmbersXD to match the flamestyle with (not really optimized) a bit less polygons. I deleted the collision, but haven't thought about the flag.
  21. PRieST
    Sure, hope this will work better for you: https://www.mediafire.com/file/hljjh6juq6dqaqk/Logs.7z/file
  22. PRieST
    Just made a new generation and got following 'file not found meshes' summary afterwards: Warning: File not found meshes\dyndolod\nohavok\campfire01landburning_dyndolod_lod_nohavok.nif Dragonborn.esm Campfire01LandBurningDirtPath01 [MSTT:0402C0B0] Warning: File not found meshes\dyndolod\nohavok\campfire01landburning_dyndolod_lod_nohavok.nif Dragonborn.esm Campfire01LandBurning_Ash [MSTT:040289E8] Warning: File not found meshes\dyndolod\nohavok\campfire01landburning_dyndolod_lod_nohavok.nif Dragonborn.esm Campfire01LandBurning_LDirtSnowPath [MSTT:04018619] Warning: File not found meshes\dyndolod\nohavok\campfire01landburning_dyndolod_lod_nohavok.nif Fires and Embers Clipping Fix.esp FaECF_Campfire01LandBurningGrassSnow01 [MSTT:FE04B861] Warning: File not found meshes\dyndolod\nohavok\campfire01landburning_dyndolod_lod_nohavok.nif Fires and Embers Clipping Fix.esp FaECF_Campfire01LandBurningSnow01 [MSTT:FE04B865] Warning: File not found meshes\dyndolod\nohavok\campfire01landburning_dyndolod_lod_nohavok.nif Fires and Embers Clipping Fix.esp FaECF_Campfire01LandBurningTundraRocks01 [MSTT:FE04B866] Warning: File not found meshes\dyndolod\nohavok\campfire01landburning_dyndolod_lod_nohavok.nif Skyrim.esm Campfire01LandBurningCoastalBeach01 [MSTT:000C2BF1] Warning: File not found meshes\dyndolod\nohavok\campfire01landburning_dyndolod_lod_nohavok.nif Skyrim.esm Campfire01LandBurningDirt01 [MSTT:000DB682] Warning: File not found meshes\dyndolod\nohavok\campfire01landburning_dyndolod_lod_nohavok.nif Skyrim.esm Campfire01LandBurningFallForestDirt01 [MSTT:000C6918] Warning: File not found meshes\dyndolod\nohavok\campfire01landburning_dyndolod_lod_nohavok.nif Skyrim.esm Campfire01LandBurningFieldGrass01 [MSTT:000FB9B0] Warning: File not found meshes\dyndolod\nohavok\campfire01landburning_dyndolod_lod_nohavok.nif Skyrim.esm Campfire01LandBurningFrozenMarshDirtSlope01 [MSTT:000CBB23] Warning: File not found meshes\dyndolod\nohavok\campfire01landburning_dyndolod_lod_nohavok.nif Skyrim.esm Campfire01LandBurningPineForest01 [MSTT:000B6C08] Warning: File not found meshes\dyndolod\nohavok\campfire01landburning_dyndolod_lod_nohavok.nif Skyrim.esm Campfire01LandBurningReachDirt01 [MSTT:000951D8] Warning: File not found meshes\dyndolod\nohavok\campfire01landburning_dyndolod_lod_nohavok.nif Skyrim.esm Campfire01LandBurningRiverBedEdge01 [MSTT:000E7C9A] Warning: File not found meshes\dyndolod\nohavok\campfire01landburning_dyndolod_lod_nohavok.nif Skyrim.esm Campfire01LandBurningRocks01 [MSTT:000CBB2F] Warning: File not found meshes\dyndolod\nohavok\campfire01landburning_dyndolod_lod_nohavok.nif Skyrim.esm Campfire01LandBurningTundra01 [MSTT:00101A51] Warning: File not found meshes\dyndolod\nohavok\campfire01landburning_dyndolod_lod_nohavok.nif Skyrim.esm Campfire01LandBurning_Heavy_SN [MSTT:000A9230] Warning: File not found meshes\dyndolod\nohavok\campfire01landburning_dyndolod_lod_nohavok.nif Skyrim.esm Campfire01LandBurning_ReachDirt01 [MSTT:00090CA4] One example record mentioned in xEdit: https://ibb.co/LZqZr5X And the corresponding record inside of DynDOLOD.esp https://ibb.co/JcMZpys And here are the logs: https://www.file-upload.net/download-15445308/Logs.7z.html I am using DynDOLOD Alpha 182 and the most recent SE Resources from Nexusmods. I've searched my mod folder and with the resource explorer from xEdit but wasn't able to finde that specific nif file BEFORE generation. After the generation has finished, the file is indeed present (in the directory as it's mentioned in the report) and part from the DynDOLOD output. So maybe this is a false positive?
  23. PRieST
    OK, thank you for the answer.
  24. PRieST
    Just curious as I'm about to start a new generation, is it possible to name any ETA for the next release?
  25. PRieST
    To me it looks like, if this belongs to the red mountain flower as in the atlas next to it are the blue and violet version.
×
×
  • Create New...

Important Information

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

  I accept