Jump to content

PRieST

Citizen
  • Content Count

    116
  • Joined

  • Last visited

Community Reputation

1 Neutral

About PRieST

  • Rank
    Guard
  • Birthday September 9

Contact Methods

  • Nexus Mods
    PRieST47

Profile Information

  • Location
    Germany

Recent Profile Visitors

274 profile views
  1. The latest version on Nexus is 2.98 - DynDOLOD or you'll have to use DynDOLOD 3 ALPHA...so which Step Guide are you using to get pointed to an outdated version of DynDOLOD?
  2. 000ACB04 is modified by DynDOLOD.esp and has the HasLOD flag set. The record from DTA (either the normal version or the Base Object Swapper one) are both Flora - FLOR and so couldn't have the flag set as I understand it correctly. I don't understand, why this happens, the only thing what I know is: Deactivating the Dynamic Things Alternative.esp is solving the issue. I do understand that this shouldn't have to do anything with LODs, but I just can tell what is happening at the moment.
  3. What a f*** headache this was. It took me the whole day to narrow it down as nothing worked. After step by step the cause is unbelievable...it's Dynamic Things Alternative - Base Object Swapper which is relying on Base Object Swapper a SKSE plugin and should've nothing to do with LODs. I don't know why this is interferring, but as soon as I am deactivating that plugin (even the already generated) LOD/full model swap is functioniong absolutely normal. I recently switched over from the normal version to the BOS version. So that has to be the point at where it got funky. I checked it double...it is the cause. The non Base Object Swapper version doesn't cause the issue. Could there maybe be some functions which are used by DynDOLOD and Base Object Swapper/Dynamic Things Alternative which could interferre with another? I don't have a clue, but deactivating BOS and/or DTA - BOS are solving the problem with the LOD/full model switching.
  4. If this is related to a plugin, than I'll have to find out which plugin causes this. Darkwater Crossing was just an example. Same things happen with all small/big towns or villages so I don't think it is reference specific. But I just don't know how to solve this as the models/records which are affected are from Skyrim.esm and not from any mod. Edit: To stay with darkwater crossing at the moment. The only record, which is affected by DynDOLOD in this area is the base record WalkwayStairs3 [STAT:0004D7B0] where DynDOLOD.esp is setting the 'Has Distant LOD' flag. The rest (of the reference records) is just vanilla. Edit 2: For me it's impossible to track it down to a specific plugin. I disabled all what I could what could be interferring with models/LODs in these spots. It's even stranger es some trees are affected, but not all in the Level 4 .bto by Darkwater Crossing. And again, I did not had this problem with earliere versions of DynDOLOD Alpha. Do you mind on giving me v. 53, I just want to test it (I just need the answer for myself). Also not only switching interior/exterior, making a save and loading is also letting the LODs disappearing. Edit 3: Just noticed, is it normal behavior, that if I deactivate DynDOLOD via MCM, that after a few seconds it gets activated again? There is no message box, but in the MCM I can again deactivate it which will also result in the deactivating message box.
  5. Reverting the Level 4 file (Tamriel.4.28.-12) to vanilla: difficult to tell as it's much difference between both, but as far as I could've seen, the LOD switchted normal to the full model without both overlapping) Deactivating the DynDOLOD.esp: LODs and Full models are switching normal. Edit: Looked it up in xEdit - DynDOLOD.esp isn't affecting this area at all (DarkwaterCrossingExterior01 where the farmhouse is referenced). Only DynDOLOD.esm has one record in this 'cell': Tamriel_Worshipper_29_%9 - DynDOLOD_WorshipperActivator [STAT:XX000926]
  6. So, first, I regenerated with Level32=1 and uLockedObjectMapLOD=32 -> no difference. Second, I got rid of FPS Stabilizer as I thought it would cause the issue -> no difference. I am using fBlockLevel0Distance at 35,000 (I think this is the vanilla/default value?) -> no difference. I went again from Ivarstead to Darkwater Crossing and made again two screenshots to show, that there are definitely LODs which are staying at the same place as the full models. I used the tll command the the LODs are disappearing as expected: Everywhere else the LODs and full models are switching correctly, but not in villages/towns if I come close. As said before, as I go into in interior cell and go outside again, the LODs are dissapeared as the should. I thought about at what time it happened: And I assume it wasn't with version .53 or .54 I could test it in generating LODs with one of these versions to know exactly at what point it happened. Never had this problem before and I changed nothing despite adding/removing mods completely unrelated to landscapes/worldspace edits. It still could be a user error as I did something fundamentally wrong, but maybe it's still a bug in the alpha, I don't know.
  7. Hey again, maybe this is an alpha 58 thing, I don't know, but I haven't had this issue prior to version .57 I think. Sometimes some LODs won't dissappear if I come closer. They will overlapping with the full models until I went in an interior cell and right back outsite. But I could only observe it near villages/towns and not all models are affected. There it is a tree, there a house (but than not all trees ore houses), rocks, etc. First I thought it has something to do like in this thread, but I had never made this ini setting: uLockedObjectMapLOD=32 (so I assume it was always =16) or could it be helpful to generate again, but this time with Level32=1 and uLockedObjectMapLOD=32? I did not changed my loadorder since the last generation without the issue - at least I assume so. If I did changed the loadorder and I used the Skyrim SE - Generate Large Reference script via xEdit, is it possible to regenerate them without redownloading the plugin. Maybe there are now references on the wrong position, because the loadorder changed? Or do I misunderstand this? Here are the logs from the last generation (as I don't exactly know which one you need, I put all in there) - and yes I know, there are some 'overwritten large references' and ' initially disabled references' in the report, but they were never a problem - if they are a problem now): Link to download And here is a picture as an example what happens (this is from Annekes House in Darkwatercrossing - if I would go from here to Ivarstead, there would be the same result with buildings, trees, etc.): I looked the building ID up in xEdit, it's only Skyrim related and doesn't get overwritten by anything. uGridsToLoad is set (and has always been) to = 5. Maybe I did something fundamentally wrong with flagging plugins as .esm and generate the Large References via script. This happened never before. For me it looks as if DynDOLOD 'is not fast enough' to switch from LOD to fullmodel and than both stick at the same place. I observe the 'flicker' while changing often (I know this is engine related) but in these cases the change won't happen. Let me know if I could do anything else before I try to generate LODs again - or is an updating enough?
  8. Yeah, I'm dumb, I downloaded LE version of the scripts, my bad. Sorry.
  9. I do have Racemenu installed, still the Option is not choosable in the mcm from dyndolod of is use the DLL Variant. With the papyrusutil Version it worked fine. Do you need any specific logs for this?
  10. Hey sheson, I switched recently from the PapyrusUtil Version to the DLL one (Version 1.5.97 as I am still stickig to SE without the free content/Update). Haven't found where to read it so I ask here: In the DLL Version I can't make use of the NiOverride feature - because it's not installed. But with the normal Version it was possible. Is it because RaceMenu for SE uses SKEE64 instead of NiOverride? Second question: what's the cause for the Option 'fix large reference' to be missing in the mcm? Is it not neccessary or am I missing this now? Thank you in advanve.
  11. Just wanted to ask: Would it ne possible to change this via ini? For me it's easier to see directly what's wrong, so that I have the Option to stop the Generation on point to fix the problems instead of looking at the logs afterwords.
  12. Yes, it is corrected now: https://ibb.co/P5nrhYs (left side is the wrong one, original from that mod) and so the error is also gone. PS: Ignore the filenaming itself, I had to do this, because of my loadorder/own changes to the mod. After rerunning DynDOLOD the only warning left is the one with 'myexplosion'... To solve it, I just have to delete the property from the record? As you have mentioned this is infact in error in dragonborn.esm itself?
  13. Ok, will solve the issues with Improved Shadowmarks than. Ah, I think I found what was wrong with Sounds of Skyrim...the bsa was packed wrong (maybe my own error) and so the path was 'sounds of skyrim complete\scripts\...' instead of 'data\scripts'....which also means the mod can't work at all in this state. After unpacking the error isnt' there as I recognized the wrong path and changed it. So this is also solved, thanks. Edit:Checked again, after repacking the bsa, no error, so it was the wrong path...it's even seen with the file browser in xEdit... It is 'Sounds of Skyrim Complete LITE' which I am using...will make an error report on the modpage. But still, why does it only show up with one record and not all of them in the DynDOLOD log?
  14. But if Windows is messing with that, would not all records report it as missing or does DynDOLOD only mentions the last record found which has the same error? Yes, the file is shown/found in xEdit: https://ibb.co/0CXJzXn Will have to check if this is repeatable. Maybe you have seen it, but I got some more warning in the same spectrum with Improved Shadowmarks - pointing to the 'attachedto' property, is this kind of the same error? Maybe because it's expanding 'ObjectReference' to use the 'AttachedTo' property? Edit: Yes the error with Sounds of Skyrim is repeatable and points everytime to the same record: Maybe something is wrong with the actor which should get the property/script applied? All other records seem to be fine/look the same, as said before.
  15. Hey sheson, with the alpha which introduced the script checking, I now have a hand full of script warnings. One example is this one <Warning: Property not found myexplosion in scripts\dlc2expspiderdeadspiderscript.pex Audio Overhaul Skyrim.esp DLC2ExpSpiderShockBombENEMY [ACTI:04028631]> I looked it up, but I can't see why I get the warning in this case, because even the vanilla record of the dragonborn.esm calls the 'myexplosion' property: https://ibb.co/WDvRCQL The logs are found here Beside that I also got this one <Error: File not found scripts\soscivsnore.pex SoundsOfSkyrim.esp [REFR:76008974] (places SoSCivSnoreTrigger [STAT:76007348] in GRUP Cell Temporary Children of IvarsteadExterior03 [CELL:000097A1] (in Tamriel "Himmelsrand" [WRLD:0000003C] at 17,-16))> which is kinda weird, because the file in fact is existing and all other records, which point to the script, don't produce the error and are looking the same - only the actor reference is not identical Record which caused the error: https://ibb.co/LQTYg2d Another one from the mod: https://ibb.co/NYg3RqH
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.