Is the dragon encounter fight scripted at all or just a standard dragon fight? Fought in the out open or an interior environment with restricted movement? Should he be excluded from DCO modifying it's abilities and combat behavior?
I saw a few of these references in IR mod. "TrapRune(____)Projectile" should only be applied to objects. while "Rune(___)Projectile are the floor traps. It can lead to invisible rune trap bug if the wrong one is used,
I just did, and it's really messy when it encountered in full force. I think some mods are changing how frequent this can happen, but for sure IR is the catalyst.
Like I said before, if this were a widespread issue, I would be absolutely FLOODED with such reports... So far a grand total of two users have reported such an issue. That's less than 1% of the total downloads thus far (6,384 as of this writing...).
Update: I just investigated the possibility of a wild cell edit to the vanilla cell which contains the traps & found none. I remember Asaforg mentioning that very cell edit in his Hope's Abandon mod which he fixed eons ago. Said wild edit does not exist anywhere in this mod's plugin so I reckon you have another mod that is causing said bug to occur in your game. However, I did find a couple other issues with the mod & these have since been addressed in the new update I just uploaded. See the Changelog for further details...
I think the reason is because a lot of people don't know the cause and there are a lot of mods that have the potential to cause it. Ruined Temple of Phynaster comes to mind as another one. And yes, it happened in Hope's abandon as well.
On a side note. Is this mod more so intended for a high level character, and how long roughly does the dungeon take to get through? Just curious as I generally assign a specific map marker to "uber dungeons" for the mod "Experience" so they grant a higher experience reward when cleared.
The mod is tailored to higher-level characters since all vanilla Shouts are needed in order to complete it if I recall correctly. As for how long it takes for completion - depends upon one's skill level & pace one plays the game at...
Just to not be accused of slandering... in short, the only difference between the two projectiles is: If you place a 'non-trap' one, it goes "bang" but deals almost no damage (just 2 HP); if you place a 'trap' one, it goes "bang" and deals the proper damage.
Spoiler:
Show
Compare for example the two shock projectiles: They are identical except for the attached explosions. Compare now the two attached explosions: They are identical except that the 'trap' one has an 'object effect' attached. Why the difference? Because the 'non-trap' projectile is for spells' 'magic effects' and the damage is provided by them, while the 'trap' one is to be placed in the world and the 'object effect' deals the damage by activating the same 'magic effects'. What does Bethesda do? The 'non-trap' runes are placed only in the magic test cell -- with two exceptions for the frost one which is placed in two dungeons, either by mistake or just to "scare" the player. The 'trap' runes are always the ones placed in the world (and the ones you find in the 'WarehouseTraps' cell.) This mod has the correct runes: The 'trap' ones.
As I suspected, the issue lies with another mod in their load order... Hope's Abandon did have an issue which caused invisible shock runes to spawn all over Skyrim but said issue was fixed long ago via update.
Recent mod version and while not a bug, then sure is a weird behaviour: if you fast travel directly to Iomaungandr after finding a note in Hrothgar you can get Cataphract instantly. Note that this is not the case when location is found "naturally" regardless having all map markers unlocked with console or not.
That's because the map marker you fast travel to is placed inside a trigger with an OnCellLoad function that performs a series of actions and then disables the trigger itself. But the same trigger also has an OnTriggerEnter function which should run when it's re-enabled, later, to enable the amulet which is "initially disabled". Quite a lot of enabling and disabling :D When you pop out directly inside the trigger, the second function runs immediately and the amulet gets enabled right away. Solutions A) Move the map marker outside the trigger or B) Separate the two functions or C) The obvious one: Play normally without cheating with the console.
Hi, I'm not sure that this qualifies as a "bug" per se, so I'm posting this in the comments section. After cleaning my current save following an absolutely brutal run in with KS Dragon's version of dragonactorscript, I noticed Fallrim tools flagging fxDustDropRandomSCRIPT as a problem that was leading to nearly a hundred stacks and frames, as well as hundreds of left over script instances...which shouldn't be happening, ever, since this is a playthrough that dates back to mid 2020 and fxDustDropRandomSCRIPT was supposed to be fixed by USKP (yup, that's how long ago!) and USSEP years ago.
But sure enough, when I had a look in my scripts and source folders there it was, a version of fxDustDropRandomSCRIPT unpatched to add a check to see if the object the script is supposed to be applied to is still actually loaded. So the question was Where did it come from? And after some sleuthing it turns out it's from this very mod.
So, it turns out that this mod doesn't carry forward USSEP's fixes to fxDustDropRandomSCRIPT, which gradually leads to a bunch of "Error: Object reference has no 3D" Papyrus errors potentially for every cell in the game (vanilla or modded) that has random dust drops. Depending on your rig, this can contribute to lag or stuttering, or even CTDs as the Papyrus engine dies choking on a lungful of random dust drops.
Solutions? Well, this mod's fxDustDropRandomSCRIPT should really be swapped for the one in USSEP, or USSEP could be made a requirement. The USSEP version has a couple of checks that will prevent the script from executing if it's no longer pertinent, thereby preventing errors from adding up in your save.
Umm...removing the script from the mod is not something that I would recommend. The specific script is edited to include a rumble function (makes camera and controller to rumble) when entering specific trigger zones in some cells. Which means that by removing it you have removed this function and its properties (which are declared in the ESP) will be lost, spamming papyrus of unknown/unresolved properties.
The right way to do it is to patch this script with the one of USSEP which will basically carry over all USSEP's fixes and the new additions (rumble) from this mod.
If ff7legend wishes I can send him a patched script version that includes this mod's features and USSEP fixes. It is working properly...I had it installed for quite some time I had even forgotten about it :)
If ever you want to upload that script version to Google Drive or elsewhere, I'm willing to...er...do some further testing Otherwise I may be cleaning my save with Fallrim Tools for nothing, or just have to uninstall this mod.
Uh, yeah, sorry about that. Just to be clear, I don't think there was any reason for you or the original authors to know there was an issue with the vanilla script or that a patched version was available in USKP/SLEEP/USSEP (there are so many changes in there...who can keep tack!). And I know this isn't a mod with tens of thousands of users, but with nearly 3000 unique downloads, that's still a lot of people that may benefit from a fix. At least you got a free patch for the USSEP patch from Astakos ;)
By the way, for users whose saves are already affected by this issue, even after installing the 1.0.4 update you have three choices:
1) Live with the existing errors until a new playthrough
2) Revisit every affected cells with the new script active. A list of potentially affected vanilla + DCL areas is available here under the first Spoiler tag. To find the areas affected in your specific save, you'll need to turn on Papyrus logging in Skyrim.ini. run the game then consult your Papyrus.0.log in C:\Users\<you>\ Documents\My Games\Skyrim Special Edition\Logs\Script. Look for "Stack" entries with fxDustDropRandomSCRIPT and "Error: Object reference has no 3D". The hexadecimal code in front of fxDustDropRandomSCRIPT tells you the location and you can find the matching name in the aforementioned Spoiler tag then just use the console to COC straight there. Yes, I know this starts to suck hard as you go over a dozen locations. Which brings me to my final, most expedient, but also most dangerous fix of all (but given that I have hundreds of locations affected)...
3) Clean your save using Fallrim tools based on the instructions here (this is an LL forum, btw), specifically post #4 by GenioMaestro. This is kind of risky so make sure you have a backup of your save and that everything seems to be working correctly post cleaning before pushing on with your playthrough. BTW, don't bother doing this if you haven't upgraded to v. 1.0.4 of this mod, as you'll still have the old script and the problem will just come back.
Fallrim Tools isn't guaranteed to work so I would strongly recommend starting a new game if one is affected by the bug you outlined here. The scripts are BAKED INTO THE SAVE GAME no thanks to BUGthesda game engine programming...
Decent shout puzzles, which we don't see used often in mods. Endorsed.
But there was an overwhelming amount or earthquake rumbling noise being repeated over and over in some parts of the dungeon (it started in one of the trial rooms). Not sure if its a bug or design choice, but the noise was quite unpleasant.
Hi, i try this new dungeon, and it's a pleasure until now.. i can't get the boots, there is no interaction to get them... i don't know what to do. I've already try to uninstal the mod. thx
I'm having the same problem; I think hardkilleur means that even when you get to the boots you can't add them to your inventory, which prevents activation of the chamber's recall stone and progression of the mod's questline. There's definitely something odd going on because (unlike the playthrough videos available on YouTube), the boots are lying backside down on the pedestal when I enter the chamber rather than being upright. Also, they are completely "intangible" (unselectable in the console), like there's nothing really there. I also made sure this wasn't the result of a conflict with another mod using xEdit and there weren't any.
Yeah, no problem it was just for testing's sake. And, crap, now I feel cheap 'cause I know you support like, literally hundreds of mods and ports and I should have done more digging before I bothered you with this.... <sigh> I just found the issue and it's definitely on my (our) end. It's not a conflict with an other ESP per se, but with a NIF, which is why SEEdit didn't turn up anything. I use a couple of armour replacers and it turns out that the one I used to generated the boots with bodyslide (the DB Armors CBBE conversion) has a boots ground object WITHOUT collision data (unlike the other armour pieces). Doh ! Explains why I was just clicking through the boots in the console. Anyway, this is fixable by using another NIF with proper collision data. Sorry.
apparently a mod even referencing the vanilla warehousetraps cell and changing that location reference can cause some fairly unpredictable and bizarre problems elsewhere in Skyrim...
I've reached out to the author to be sure. But the other mods I've been investigating, any reference or changes to this cell/location have been wild edits from CK noise; Hope's abandon and Ruined Temple of Phynaster. There shouldn't be any reason that this mod is disabling stuff in a vanilla cell.
Referencing or changing anything in that cell seems to break traps elsewhere in skyrim. in the case of isle of ashes and ruined temple it creates invisible rune traps in random places in skyrim simply from touching it. removing the edits/reference to this cell fixes it. Disabling the TrapNorFirePlateSafe01 within this cell is likely to cause unintended problems elsewhere.
There are exceptions to this. One example is my Gemstone Prophecy ports. These disable certain things in vanilla cells to make room for certain objects that are essential for mod progression. Said objects include the various books & the pedestals they sit upon which guide the player through the entire mod. The Gemstone Prophecy mods are book-driven quests so the player must read the books in order to progress...
We are digging into it further since we seem to have the cause yet not the reason. the cell is apparently a testing cell so there might be some weird scripts or code related to it. So strange.
Dungeon mods in general should not be merged. Eslification is impossible due to the sheer amount of records involved. However, esmifying the plugin is possible if one utilizes the proper SSE Edit script...
First off, not everyone uses SkyTest so feel free to forward the change made by SkyTest to your plugin or patch it on your end... As for the USSEP changes, those can also be forwarded using SSE Edit...
Give Feedback
102 comments
Note - There are several ways to start the quest/journey. Check the description for details & the Images for the location of the dungeon on your map.
Link to dt1000's Nexus Interview: https://www.nexusmods.com/skyrimspecialedition/news/13976
Updated .esp uploaded. See Changelog for details. All credit for this update goes to Sandman53.
Critical update now available. USSEP is now a HARD REQUIREMENT. See Changelog for further details...
I saw a few of these references in IR mod. "TrapRune(____)Projectile" should only be applied to objects. while "Rune(___)Projectile are the floor traps. It can lead to invisible rune trap bug if the wrong one is used,
Update: I just investigated the possibility of a wild cell edit to the vanilla cell which contains the traps & found none. I remember Asaforg mentioning that very cell edit in his Hope's Abandon mod which he fixed eons ago. Said wild edit does not exist anywhere in this mod's plugin so I reckon you have another mod that is causing said bug to occur in your game. However, I did find a couple other issues with the mod & these have since been addressed in the new update I just uploaded. See the Changelog for further details...
On a side note. Is this mod more so intended for a high level character, and how long roughly does the dungeon take to get through? Just curious as I generally assign a specific map marker to "uber dungeons" for the mod "Experience" so they grant a higher experience reward when cleared.
Compare for example the two shock projectiles: They are identical except for the attached explosions.
Compare now the two attached explosions: They are identical except that the 'trap' one has an 'object effect' attached.
Why the difference?
Because the 'non-trap' projectile is for spells' 'magic effects' and the damage is provided by them, while the 'trap' one is to be placed in the world and the 'object effect' deals the damage by activating the same 'magic effects'.
What does Bethesda do?
The 'non-trap' runes are placed only in the magic test cell -- with two exceptions for the frost one which is placed in two dungeons, either by mistake or just to "scare" the player.
The 'trap' runes are always the ones placed in the world (and the ones you find in the 'WarehouseTraps' cell.)
This mod has the correct runes: The 'trap' ones.
But the same trigger also has an OnTriggerEnter function which should run when it's re-enabled, later, to enable the amulet which is "initially disabled". Quite a lot of enabling and disabling :D
When you pop out directly inside the trigger, the second function runs immediately and the amulet gets enabled right away.
Solutions
A) Move the map marker outside the trigger or B) Separate the two functions or C) The obvious one: Play normally without cheating with the console.
But sure enough, when I had a look in my scripts and source folders there it was, a version of fxDustDropRandomSCRIPT unpatched to add a check to see if the object the script is supposed to be applied to is still actually loaded. So the question was Where did it come from? And after some sleuthing it turns out it's from this very mod.
So, it turns out that this mod doesn't carry forward USSEP's fixes to fxDustDropRandomSCRIPT, which gradually leads to a bunch of "Error: Object reference has no 3D" Papyrus errors potentially for every cell in the game (vanilla or modded) that has random dust drops. Depending on your rig, this can contribute to lag or stuttering, or even CTDs as the Papyrus engine dies choking on a lungful of random dust drops.
Solutions? Well, this mod's fxDustDropRandomSCRIPT should really be swapped for the one in USSEP, or USSEP could be made a requirement. The USSEP version has a couple of checks that will prevent the script from executing if it's no longer pertinent, thereby preventing errors from adding up in your save.
Umm...removing the script from the mod is not something that I would recommend.
The specific script is edited to include a rumble function (makes camera and controller to rumble) when entering specific trigger zones in some cells. Which means that by removing it you have removed this function and its properties (which are declared in the ESP) will be lost, spamming papyrus of unknown/unresolved properties.
The right way to do it is to patch this script with the one of USSEP which will basically carry over all USSEP's fixes and the new additions (rumble) from this mod.
I've also posted about the issue on the LE side so that, hopefully, it can get a fix there as well, or someone can correct the issue.
Other than this, this is a really great mod!
It is working properly...I had it installed for quite some time I had even forgotten about it :)
If ever you want to upload that script version to Google Drive or elsewhere, I'm willing to...er...do some further testing
Well...here you go: https://www.dropbox.com/s/d8mdb87pt9yc9qe/Iomaungandr%20Rising%20SE%20-%20USSEP%20Script%20Patch.7z?dl=0
ff7legend feel free to include it in the mod if you so wish.
By the way, for users whose saves are already affected by this issue, even after installing the 1.0.4 update you have three choices:
1) Live with the existing errors until a new playthrough
2) Revisit every affected cells with the new script active. A list of potentially affected vanilla + DCL areas is available here under the first Spoiler tag. To find the areas affected in your specific save, you'll need to turn on Papyrus logging in Skyrim.ini. run the game then consult your Papyrus.0.log in C:\Users\<you>\ Documents\My Games\Skyrim Special Edition\Logs\Script. Look for "Stack" entries with fxDustDropRandomSCRIPT and "Error: Object reference has no 3D". The hexadecimal code in front of fxDustDropRandomSCRIPT tells you the location and you can find the matching name in the aforementioned Spoiler tag then just use the console to COC straight there. Yes, I know this starts to suck hard as you go over a dozen locations. Which brings me to my final, most expedient, but also most dangerous fix of all (but given that I have hundreds of locations affected)...
3) Clean your save using Fallrim tools based on the instructions here (this is an LL forum, btw), specifically post #4 by GenioMaestro. This is kind of risky so make sure you have a backup of your save and that everything seems to be working correctly post cleaning before pushing on with your playthrough. BTW, don't bother doing this if you haven't upgraded to v. 1.0.4 of this mod, as you'll still have the old script and the problem will just come back.
But there was an overwhelming amount or earthquake rumbling noise being repeated over and over in some parts of the dungeon (it started in one of the trial rooms). Not sure if its a bug or design choice, but the noise was quite unpleasant.
I've already try to uninstal the mod.
thx
Oh, I'll also look at reinstalling 1.0.1 on a new save to see if this is present on that version.
edit: yes it would appear it is.
http://icecream.me/uploads/63fdf72953f418a0cce547fb7685bbda.png
apparently a mod even referencing the vanilla warehousetraps cell and changing that location reference can cause some fairly unpredictable and bizarre problems elsewhere in Skyrim...
Referencing or changing anything in that cell seems to break traps elsewhere in skyrim. in the case of isle of ashes and ruined temple it creates invisible rune traps in random places in skyrim simply from touching it. removing the edits/reference to this cell fixes it. Disabling the TrapNorFirePlateSafe01 within this cell is likely to cause unintended problems elsewhere.
We are digging into it further since we seem to have the cause yet not the reason. the cell is apparently a testing cell so there might be some weird scripts or code related to it. So strange.
http://icecream.me/uploads/759a3164dd3d006b75d9828bec40014e.png
Even just that, and that alone with Ruined Temple was causing invisible frost runes to spawn in random places throughout skyrim.
https://www.nexusmods.com/skyrimspecialedition/mods/28046
http://icecream.me/uploads/d407ba0ddfb4d1b7d346911fff690c20.png
This also reverts changes made to VoiceClearSkies effect by USSEP (Script -> Stagger) ... and also overwrites a USSEP script asset.