Jump to content

Unnecessary Invisible Continue during Thieve's Guild Holdup


BrotherBob

Recommended Posts

I'm pretty sure that this has not been fixed yet because it's not in the patch notes, and I'm sorry if I'm posting this in the wrong place.

 

The wilderness encounter with a thief who tries to rob you (the quest is WERJ02) has an Info (000B8154) that I believe has something unnecessarily checked. The info, listed under WERJ02Persuade, is spoken when the player succeeds in the Speech check. It has the "Invisible Continue" box checked, which doesn't really serve a purpose in the Vanilla game, since there are no Infos linked to it. Effectively, I don't think that there would be any effect on the Vanilla game if it were unchecked.

 

However, I believe that it can cause conflicts with mods. CreationKit.com mentions: "If there are no Topics in this list, or none of the Topics have a valid Info, the Actor's top-level Topic List will be displayed". I think that this implies that, because of Invisible Continue, any mod that adds a top-level Topic that can be spoken by the Thief, will automatically be triggered without a player prompt, which is certainly undesirable.

 

Of course, I have more than mere speculation. A user of one of my mods recently reported this issue to me, saying that, when the user passed the speech check, the thief would say the normal line of dialogue and then, without any user input, say an Info from a top-level topic from my mod that would normally require user input. It should be noted that that Info has several Conditions, all of which the Thief would be able to pass. I was able to confirm this bug as well. Moreover, another user of my mod was able to confirm a similar bug, except that the thief said an Info from another mod after saying the usual Info. After suspecting that Invisible Continue might be the issue, I created a save where a Thief was able to forcegreet me, allowed him to initiate dialogue with me, and successfully passed the Speech check to once again verify that the bug would occur (which it did). I then opened my mod in the Creation Kit and unchecked the Invisible Continue box for the the Info in question (000B8154) and reloaded the save. The bug no longer occurred.

 

I know that USKP is meant to only fix the bugs in the Vanilla game, but I think that an unnecessary edit is within the boundaries of that. Beyond this, I think that any mod that adds a top-level topic that can potentially be spoken by the thief (LvlWEThief) can suffer from this.

 

The forum thread where I discussed the bug with the users of my mod is here: http://www.loverslab.com/topic/21973-sexlab-tdf-prostitution-and-pimping-the-former-aggressive-prostitution-v173/page-23. The bug is first brought up at post number 458. Thanks for your time. Also, I apologize if the subject of the mod is distasteful, but I believe that my point still stands.

 

EDIT: I've added an attachment: an .esp that simply adds a new quest with Priority 70 that adds a single top-level topic, with Priority 50, with a single info that has no attached conditions so anyone can say it, including the thief. The dialogue is:

Player: Hello...

NPC: I am saying unwanted dialogue.

I haven't included an SEQ file, but a save-reload should work. I'm not sure if it matters, but I am using Fuz Ro D-oh. With the plugin active, and without some other plugin to uncheck Invisible Continue, the thief will say that Info after the normal one.

Proof ESP for Thief Dialogue Bug.zip

Link to comment
Share on other sites

I was meaning to mention something about that particular encounter as well. It seems as though the thief will say a friendly dialogue line after turning hostile on the player such as "swift hunting" or "safe travels". I'm not sure if it is related to what is being described in the above post in any way, but it sounds similar.

Link to comment
Share on other sites

Could well be related, yes. If the generic good-bye topics are also top level then the invisible continue issue could be present in other sections of the dialogue too.

 

I would suggest posting this issue in the tracker so we can get to it when work resumes on the patches after New Years. It'll get lost and forgotten if it's only here in the forum.

Link to comment
Share on other sites

Okay, the bug I experienced has been added to the tracker with a direct link included to the original post (above). For reference, this issue is #14442 in the tracker.

Link to comment
Share on other sites

  • 4 weeks later...

FYI for those following, this has been addressed and will be out with USKP 2.0.1.

Link to comment
Share on other sites

  • 1 month later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...