More that an out of date version of FRD may be exacerbating the problem, I think.

I know some people have reported the problem who never used FRD so it's unlikely that this is a fix. Unless what we're seeing is the latest incarnation of the too-fast dialogue problem, I suppose, in which case it might. Does anyone see this happening with voiced dialogue, or is it just unvoiced that has the problem.

I'm also not convinced it's entirely fixed my issues. I have quite a lot of testing to do, now that I can test, and there are bound to be bugs that have crept in while I've not been able to test properly.

Nah I have silent recordings for my dialogue, so thats not the problem.

I have tested this dozens of times now with a number of different test quests and ESP files. All with the same results, dialogue topics I make only show when I save then reload that save.

Okay, thanks. I've never heard of FRD before Arthmoor made that comment, so I've never used it.

Both my mods are using voiced dialog.

And as I mentioend in an earlier post, I wouldn't even call this a "dialog" bug, it's bigger than that as the problems people are having with the Scenes demonstrates. I'm calling it a Quest Bug, but I know that won't stick

Now another new detail: people are reporting that my previous version of ScenicCarriages which uses the dialog in the vanilla carriage quest is working just fine. Almost all the condition checks are identical in both version, I just seperatated them in to my own Quest (proved useful in the 1.6 bugs).

FRD is not working for me. With debug you can see that the dialogue is not firing at all, yet the phases start and end normally. It is a 1.7 patch bug. pre 1.7 my scenes work.

Scenes also use dialogue though and they're likely the same underlying record type. That's why you always find problems in one will show up in the other too.

Okay, so that makes sense. So it's either the dialog conditions are broken causing problems for dialog record types, or it's something in the quests. I'm still thinking it's Quests though because I disabled a vanilla quest from starting but after "save and reload", the vanilla quest is now running. I could be wrong, but I'm thinking the "Start Game Enabled" isn't a condition?

From the end result, the question my be academic, but from the perspective of what Bethesda needs to fix, I think it would be good if we could narrow down EXACTLY what is causing all the symptoms. (Maybe wishful thinking... especially as many people don't even have the problem at all!)

I can testify that a clean save does not solve it.
A clean save with quests "Start game enabled" disabled and have it start via oninit somewhere solves it.
Save->reload also works.

As has been discussed Say Once currently doesn't work. Each time the game loads people have said that the save doesn't remember Say Once dialogue has already been said.

I'm a bit annoyed this bug has happened because I'm finally making headway with my mod and almost ready to upload the quests and dialogue update. Obviously it's no big deal, bugs can happen at any time.

My NPC had a Say Once branch for the first time you speak to him. This was in the dialogue for a quest. As a workaround, I added another stage before the final one, and added a SetStage(15) script to the end fragment of the Say Once dialogue. Also added a condition of StageDone (10). So when he says it, the stage moves forward (not affecting the actual quest and objectives). Then the next branch of dialogue has a condition StageDone(15). So it works just as Say Once should, but without the Say Once checkbox.

It seems ForceGreet is also broken. Can't get that package to work which has previously worked.

Sigh, yes I'm having problems with SayOnce, too... really bad problem .

My companion Vilja has a huge number of quest-related entries that she should only say once (i.e. related to the vanilla game quests), but she now repeats them each time the game is started. It's too many for a functional system with your workaround, B1gBadDaddy, so I'm very much keeping my fingers crossed that Bethesda will solve this, and do it soon.

Wow, I hadn't considered that they wouldn't fix it... silly me.

Edit: I mean, I just assumed all this time they would be fixing this problem, but I don't have very much experience modding games, so maybe I'm just being stupidly optimistic?

Did Bethesda ever fix the gray-face issue? I remember I kept waiting and waiting for that one, before a modder finally figured it out and I completely forgot about it. 4 months later I still get questions about it.

Definitely Emma I'm lucky in that I only have one line pretty much. I hope they fix it to.

They can only fix what they know about, and I'm not sure if anyone has specifically brought the issue to their attention. Mainly because we don't know precisely what all is broken yet. Or, if we do, that information has been scattered across so many threads as to be untrackable.

Yes, it's fixed. For quite some time now even. You need to make the CK export your facegen data by highlighting the NPCs you edited (or added new) and hit ctrl+f4. That dumps a bunch of files to C:\Steam\steamapps\common\skyrim\Data\meshes\Actors\Character\FaceGenData\FaceGeom\ and C:\Steam\steamapps\common\skyrim\Data\textures\Actors\Character\FaceGenData\FaceTint\ which will both have folders beneath them with the mod's name. These files need to be included in a mod's distribution or the grey face bug is what results. You can leave out the .tga files in the texture folder as the game only uses the .dds files.

Alexander mentioned that he had pinged GStaff about it http://www.gamesas.com/topic/1399783-dialogue-no-longer-works/page__view__findpost__p__21305729...but I imagine the devs have been busy getting Dawnguard out, plus QuakeCon. AV, did you ever hear back from Matt?

Not yet. I imagine he is indeed probably really busy with Quakecon. Hopefully once it ends the devs can get this thing fixed.

Oh I know. My question was whether Bethesda did anything about it. This was like late February or something, but I remember having to do a workaround by saving in snip to get the game to recognize the files(using CTRL+F4) I exported.

So as I stopped caring about it the second it was fixed, I was curious if Bethesda actually fixed it so you didn't have to do the workaround, or if they just let the modders figure it out, as that might augur what will ultimately happen with this bug.

It might be worth bringing the updated symptom list to his attention at some stage. This thing has worked out rather worse than we initially thought.

On the subject of Bethesda, I've been wondering how they never noticed this for themselves. it might be worth seeing if the problem persists inside an ESM file...

From my experience, the problem does not occur with (vanilla) ESM based quests. An earlier version of my mod that expands on a vanilla quest dialog works fine with 1.7 (I built that under 1.5.) In the current version of my mod, also releaseed under 1.5, I moved everything to its own quest. The newer version does not work, even with the save and reload.

Please excuse me for making silly suggestions, as I have no direct experience of the matter, but I wonder, if anybody has had the chance to see whether Dawnguard would show any signs of this issue, and whether there might be anything different about how new quests in it are set up?

If Dawnguard does not suffer from this issue, but user-created ESM-mods do, there must be a difference somewhere, and hopefully that difference might be observable, if it is in the ESM rather than hidden inside the game engine itself.

Also, I tried reading this thread very carefully, but in the end I did not get a perfectly clear picture of whether the following is strictly true, which I would think is very essential for understanding the nature of the issue:
I was especially confused by the following:unless there is something I missed that would reconcile these observations.

Dawnguard has thus far not suffered from the dialogue problem.

Dawnguard is an ESM, right? (I don't have it, but that's what I've read...)

Since ESM's don't seem to have the problem, has anyone tested with a player made ESM? (As I said before, my ESP modifies a dialog from Skyrim.ESM and it works fine.)

If I have understood correctly, Alexander J. Velicky suffers from this issue in his large ESM-based mod.

Also, I don't have Dawnguard, but if I had it, I would be interested in checking whether it contains any "Start Game Enabled" quests, just to get a rough bearing on the matter, as those seem to be close to the core of the issue.

That does sound an awful lot like the "say once" bug affecting a vanilla/esm quest.

But why are so few affected? it could be that there's a trivial workaround, did we but know what it was.

From everything I'm seeing, this is less of a dialogue, quest, or scene bug than a Topic/Info bug. It seems the core problem here is that some topics are initially not appearing when they should, while after saving others are appearing when they shouldn't (ie, the Say Once errors). It doesn't seem to have anything to do with the audio files playing or not playing, simply that some or all initial topics won't fire unless you use the save/reload workaround. Even then there is no guarantee.

I'm willing to consolidate all the info that is known so far into a troubleshooting post/an article on the Creation Kit wiki, if it will help Bethesda track down the issue.