Oblivion talk:Attack on Fort Sutch

The UESPWiki – Your source for The Elder Scrolls since 1995
Jump to: navigation, search

Not a Real Quest[edit]

Ok guys, I don't think this is a "real" quest. The quest entries in the editor are only there to control the AIs of the soldiers.— Unsigned comment by Pascal (talkcontribs)

I suppose it depends upon your definition of a quest. No, this is not a quest that appears in your journal and gets added to your official stats of completed quests. Neither are any of the other quests listed under Quests that do not appear in your journal. On the other hand, yes, this is a predefined activity that you can do once and only once in the game, that has specific requirements before it can be accomplished, and has specific stages that it progresses through. There's alot more substance to this quest than, for example, most of the master training quests, that do appear in your journal. It's different from the random oblivion gates that appear, for example, because this gate always occurs after doing Dagon Shrine, and has associated NPCs and waves of attacking daedra/dremora. (Also, there's a chance that this one gate gives access to different Oblivion worlds, but I haven't investigated that properly yet). So, I believe that it is appropriate to give this "quest" its own page, so anyone who is interested in trying to fully explore the game of Oblivion knows that this is one possible activity. --Nephele 14:46, 13 September 2006 (EDT)
Count me in as not thinking this is a quest. All of the gates are predefined activities that you can only do once. The only difference because there is an event with the guards and the monsters before it. A very generic event at that. Does anything even stop you from ignoring the guards and running into the gate first? 74.135.100.99
I think it's a perfectly good quest. This one even has proper quest entries, as opposed to many of the Quests that do not appear in your journal. --RpehTCE 12:54, 28 October 2007 (EDT)
I do believe there are other such encounters of soldiers with Oblivion Gates, with almost identical dialogue (although Im not sure about the waves of daedra) One that comes to mind is just off the road somewhere between Skingrad and Anvil. Anyhow, this might be more appropriately labeled as "Player Triggered Encounters" as this battle simply wont occur unless the player walks into the area of the gate during the Main Quest (After Dagon Shrine) I understand why it is labeled as a quest (at least for the sake of organizing the site) and its definitely worth note for any players of the game.--209.134.75.234 14:21, 23 May 2008 (EDT)DarthShrute
No, there are no other similar oblivion gates. It is the only one with its own miscellaneous quest, including its own set of quest stages. It also has a unique configuration in terms of possible connecting oblivion worlds. "Player Triggered Encounters" would describe all of the 50 random oblivion gates, so I don't think it's a particularly useful designation. --NepheleTalk 14:54, 23 May 2008 (EDT)

() Hi! Hey, now shouldn't the official guide book count for something here? Because according to it, this is an official quest that doesn't appear in your journal, just like there are other quests that don't appear in the journal. My question about such quests though, is why wouldn't the Player Character write about them, given that he/she/it does bother to write about hiring a helping hand for the Skingrad home?! Leo Star Dragon 1 03:21, 4 March 2012 (UTC)

Keeping the Imperial Guards Alive[edit]

I found an easy way to keep all the Imperial guards alive. Just avoid the guards altogether and head straight to the Oblivion gate. Enter the gate as quickly as you can. Then inside the plane of Oblivion, take the sigil stone from the main tower to close the Oblivion gate. When you get back to Tamriel, all the Imperial guards will be there alive and waiting for you. -- Jargon 13:57, 7 March 2007 (EST)

City of Sutch[edit]

Discussion moved to Oblivion Talk:Fort Sutch --NepheleTalk 15:21, 8 November 2007 (EST)

Probable severe bug[edit]

I've noticed that after this quest is complete, coming back to the area where the closed gate is (or should be...) results in its map marker disappear along with the gate itself. But the worst is that it also makes the other 6 fixed gates disappear (the ones that show up after completion of Dagon Shrine quest). Perhaps this isn't something that occurs in "normal circumstances" (could be caused by unofficial mods, patches, etc), but I'd like some feedback on this one please. -- Not spambot 19:57, 28 March 2009 (EDT)

This happens whether you have mods or not... Same thing happened to me when I played it back on launch, I saved this time and went in both after killing the waves and just ignoring the guards... Within 24 hours of taking the sigil stone, the map marker and guards just vanish... You can even just sit there and watch it go poof while in the area... Very strange for such an awesome event. --75.52.169.78 18:30, 19 July 2009 (UTC)

Confirmed[edit]

It happened to me too, though I didn't notice until I got round to the 'Allies for Bruma' quest... It's incredibly annoying, will just have to use console command 'setstage MQ11 100' to bypass 'Allies for Bruma'.

Allies for Bruma bug?[edit]

(moved from article) Note: This quest does not appear in your journal and it is possible that if you complete it before Allies for Bruma quest, you will get bugged and will be unable to complete Allies for Bruma quest (none of the fixed gates will appear)

Can anybody confirm if this is true? Krusty 09:35, 6 September 2009 (UTC)
I can confirm that this isn't a bug in the Oblivion.esm: it's one introduced by a bad bit of code in the Unofficial Oblivion Patch. See this thread. Not sure if that's something that should be added to the wiki or not. -- Tyraa Rane
Definitely confirmed. Until the UOP gets fixed, either don't close the Fort Sutch gate, or if you do, don't return to the area before finishing Allies for Bruma. Arthmoor 20:39, 8 October 2009 (UTC)
I wouldn't cover the bug on the article, as it is related to the UOP (instead of the original game). Likely it is quite quickly fixed anyway. --Timenn-<talk> 14:53, 9 October 2009 (UTC)

Same thing here

This surely is an incredibly annoying bug and has absolutely nothing to do with any mods. Thankfully there's the new UOP hotfix 323 to get rid of this annoyance. — Unsigned comment by 88.192.139.247 (talk) on 10 December 2009

Non-Spawning Gate[edit]

(moved from the article)
  • The gate may not actually spawn, although the Oblivion Gate Markers Mod will show a Quest Target arrow there. (This may be caused by the current UOP Hotfix (3.2.4), or it may just be a Generic Random Bug). On the PC, entering "setstage MS94 40" in the console will cause the gate to appear.
I moved this because it doesn't really add anything useful at the moment as it's too equivocal: the gate may or may not spawn, and may or not be caused by one thing or another. It needs some more research to establish exactly what happens and why. rpeh •TCE 17:55, 19 March 2010 (UTC)
If the IP who wrote the original tip reads this, I'm the creator of the mod and I'd love to get a copy of any saved game you might have that exhibits the problem. I'll double-check if there are any obvious bugs in the mod surrounding this gate, but it would be easier to check exactly what's going on if I had your saved game file and a list of mods you're using. Please e-mail me here with a zipped copy of your saved game if you have the time. Thanks! Robin HoodTalk 18:59, 19 March 2010 (UTC)
Just as a follow-up, I have now tested this with both UOP 3.2.0 and UOP 3.2.4 and in both cases, it appear to work fine. UOP 3.2.4 does add some scripting around the Fort Sutch gate, though, so the bug may only occur under specific circumstances. If anybody can reproduce this, I'd really like to hear about it! Robin HoodTalk 03:47, 21 March 2010 (UTC)

<- I think I know why it doesn't work: what I don't know is why yours does...

MQ06 stage 100 starts quest MS94

MS94OblivionGateScript "really" starts the quest by advancing it to stage 40 when the player gets close:
        if getquestrunning ms94 == 1 && getstage ms94 < 40
                if getdistance player < 5000
                        setstage ms94 40
                endif
        endif

MS94 stage 40 enables the map marker and all the other "stuff" like the soldiers.

So all of that's fine. The problem is, MS94OblivionGateScript is attached to MS94OblivionGate, but if you look at its parent info, it doesn't have any. All the city gates do. It looks like the link to it from the MQ11OblivionGatePARENT that gets enabled by stage 100 of Dagon Shrine has simply been lost.

With the last "official" UOP version, the gate always spawned (which is how I found out about the hotfix, because I closed Fort Sutch and triggered the bug that broke the Main Quest). With the 3.2.4 hotfix version, it never has for me for the two characters I've played since. If you go to Fort Sutch, there's no map marker for the gate either, which is what you'd expect since the same script that never runs enables that too. I suppose the hotfix may not have installed correctly or broken in some weird way, but it's definitely the cause of the bug. I removed it via the launcher, went back to an old save, re-ran Dagon Shrine, and the gate (and all the soldiers etc) spawned just fine.

RobinHood: your mod works fine. That shows the marker that "should" be there even though the gate itself isn't. Bear in mind that the breakage happens at the completion of Dagon Shrine. If you did that on a working version, i.e. no mods (or with UOP 3.2.0), the gate will be correctly spawned then, so switching versions afterwards won't break it.

You're right, that seems to be the key factor here. I likely saved after talking to Martin during my testing, so I never triggered the bug. I've let Arthmoor know, so hopefully he'll be able to fix it for 3.2.6. Robin HoodTalk 01:36, 16 April 2010 (UTC)
I'll take another look into this. The link to MQ11OblivionGatePARENT was severed intentionally because closing the Sutch gate would in turn cause the game to close all of the other city based gates even if you hadn't performed their quests yet. This would naturally break the MQ if you hadn't finished Allies for Bruma yet. This was actually working properly in the vanilla game and had been broken by the UOP somewhere prior to 3.2.0. I hadn't realized the fix ended up breaking MS94 in the process, but I think everyone can agree it's better to break an isolated side quest than the MQ.Arthmoor 06:17, 16 April 2010 (UTC)
Definitely. :) The best (and easiest) option would seem to be simply adding "MS94OblivionGate.enable" to stage 100 of MQ06: that keeps it separated from MQ11, and avoids activating "the scene" until the player is close enough for it to matter (the setstage hackfix should really only be used once the player is actually in the gate's cell). Thanks for all your work on UOP. - Ali
Ok. Was able to take a look at this today and found the following with UOP Supplemental 3.2.5 loaded into the CS:

MQ06 stage 100 issues StartQuest MS94.

As the player arrives in the area after this, the script attached to MS94OblivionGate contains the following logic:

        if getquestrunning ms94 == 1 && getstage ms94 < 40
                if getdistance player < 5000
                        setstage ms94 40
                endif
        endif

MS94 stage 40 issues the following result script:

; start the battle
MS94GateSpawnMarker.enable
UOPSutchGateSoldiersMarker.enable
setfactionreaction OGSoldiers DaedraFaction -100
setfactionreaction DaedraFaction OGSoldiers -100
MS94GuardSoldier.evp

MS94OblivionGateRef is listed in the CS with it's enable parent set to MS94GateSpawnMarker, which just got enabled. So I don't know why it's being said that the gate has no parent, because I'm looking at the screen right now saying it does. Stage 40 was altered to add the two marker enables.

Checking in just Oblivion.esm, MS94OblivionGateRef is also parented to the MS94GateSpawnMarker, but that was in turn parented to the MQ11OblivionGatePARENT marker which was the root of the problem with the way the UOP tried to fix this gate up to 3.2.0. This issue was in fact why I even made a hotfix for the UOP to begin with.

In order to set things right in games which have already passed the point where all this should activate, UOPFortSutchGateFixScript was added to enable MS94GateSpawnMarker and UOPSutchGateSoldiersMarker when MS94 is still running. The quest this script is attached to is set as "start game enabled" and stops itself once the fix is done.

This bugfix was tested and verified working by several people, myself included. I'd dig up the thread for it on the official forums but it's been too long already and I wasn't the one who started it. There should be no reason for this to fail to operate as it currently exists. Arthmoor 20:17, 17 April 2010 (UTC)

Thanks for the incredibly detailed response. I'm not too good with the CS stuff, so maybe RobinHood or someone can explain it at a level I can understand, but it seems to me that:
  • the script attached to MS94OblivionGate "does stuff" including the crucial "setstage ms94 40"
  • ms94 stage 40 does "MS94GateSpawnMarker.enable"
  • "MS94OblivionGateRef is listed in the CS with it's enable parent set to MS94GateSpawnMarker, which just got enabled"
Let's call those 3 steps A, B, and C. A happens when MS94OblivionGateRef is enabled, which is done by C. B happens when A runs. C happens when B runs. So, C->A->B->C ad infinitum: all three are completely co-dependent in a circle, and none can start until one of the others has run, which can only happen when something else kicks them, which is where UOPFortSutchGateFixScript comes in. Yes?
If I got all that right, I've found your bug. UOPFortSutchGateFixScript is attached to a quest that is Start Game Enabled. It checks to see if MQ06 >= 100, and then UNCONDITIONALLY stops the quest whether it is or not. So if you STARTED a game with 3.2.4, which I did, the script runs while I'm still listening to Dreth, sees that MQ06 is NOT completed, doesn't enable the Fort Sutch Gate, and then never runs again.
You fixed the case where someone has TRIGGERED the bug via 3.2.0, and THEN patched to 3.2.4, but missed the case where someone HASN'T triggered the bug by the time 3.2.4 is installed.
Man, this stuff gives me a headache... Hope that helped. - Ali
I just re-checked on 3.2.5 and the Fort Sutch gate is clearly not appearing. The game I was loading was at MQ06 Stage 70, which I then completed and ran over to Fort Sutch. I can send it to you if you'd like. I'm a little too tired to wrap my head around the specifics tonight and see if I can figure out why.
@Ali: Off-topic, you should create an account...you're making enough high-quality edits and responses that you should get credit for them! Besides, it's easier to talk to a name than a bunch of numbers. :) Robin HoodTalk 01:19, 18 April 2010 (UTC)
@Ali: I've taken another closer look and spotted something I missed:
   if getquestrunning ms94 == 1 && getstage ms94 < 40
                if getdistance player < 5000
                        setstage ms94 40
                endif
        endif

This looks like a perfectly valid block in the gamemode portion of the script, except for this:

   if getdisabled == 1
                return
        endif

While MS94 may be starting, the gate's parent is still disabled. I don't really know why my tests all concluded that this was working, but even today with an old save I dug up for this it still pops the gate open properly despite that disabled check being a hard return. Only stage 40 can enable the marker parent for it, which can't execute because it's check is in the wrong spot in the script. I'll move this up above the disabled check and that should fix it for good. Arthmoor 07:20, 21 April 2010 (UTC)

Thanks. Most of that was over my head, but I'm going to assume you know what you're doing.  :P
Re-reading my earlier breakdown of what I thought was happening, it still looks right (i.e. broken) to me, and the behavior you actually see if you start the game (or at least, complete Dagon) with 3.2.0 and then patch to 3.2.4, vs patching to 3.2.4 and then starting a new game, exactly matches what I said I would "expect" to happen in both of those cases. So I think there may be one more Sneaky Buglet in UOPFortSutchGateFixScript, because the stopquest should be inside the if block, but is after it instead. Anyway, good luck - I'm sure you'll sort it out whatever it is. --Aliana 08:37, 21 April 2010 (UTC)
The stopquest is in the correct location in that script. UOPFortSutchGateFixScript has only one purpose, and that's to make sure everything is back in a working state if 3.2.0 was in use and the Supplemental was added after the gate was closed, or you were close to doing so. Otherwise you're too far back for it to matter anyway and the other scripts that have now been fixed will behave properly. Arthmoor 20:55, 24 April 2010 (UTC)

Took me by Suprise[edit]

Seems a little strange to have a quest that doesn't enter in your journal? I had no idea what was happening and I still didn't know until I looked it up here (I was doing the bad medicine quest) — Unsigned comment by 68.226.126.37 (talk) at 08:08 on 9 June 2010

what tower do you enter?[edit]

what tower do you enter to finf the sigil stone if i dont know what the main tower is and they all look the same — Unsigned comment by Tyufvfv (talkcontribs) at 12:37 on March 27, 2011

It depends on which world you were randomly transported to: Random World 2, 3, 4, or 7. More information can be found on their own pages. --DKong27 Talk Cont 18:00, 27 March 2011 (UTC)

Daedra corpses disappear when gate is closed?[edit]

Playing the game through again and I'd collected loot from the fallen daedra before entering the gate and closing it. When I got back, my store corpse (a Xivilai near to the gate entrance) had vanished as had all but one of the daedra corpses from the initial waves. Is this normal behaviour for this quest? — Unsigned comment by 95.172.224.131 (talk) at 12:50 on 9 October 2018 (UTC)

It's not unusual behavior for a corpse to disappear, no. --AKB Talk Cont Mail 12:50, 9 October 2018 (UTC)