Aller au contenu

Photo

Supplemental .fsb Issue


  • Veuillez vous connecter pour répondre
14 réponses à ce sujet

#1
Avaraen

Avaraen
  • Members
  • 342 messages
I've run into a problem creating supplemental .fsb files for vanilla dialogue, as described by Archonyx's tutorial here.

As I noted on that thread, it's been working fine for me, except for one dialogue file; I'd made some additions to Zevran's dialogue and created a supplemental .fsb and .fev. Then I made some changes to my additions; since then, the toolset generated .fsb and .fev work fine, but when I try to split the .fsb into the supplemental .fsb and the new .fev, the in-game VO is mismatched (incorrect VO plays for the dialogue lines). I know what I'm doing works, and that I'm doing it correctly, because it's working for other dialogue files and supplemental .fsb and .fev... it just is getting messed up for that one dialogue file.

I'd prefer not to have to release the entire original .fsb package (3.6 mb), when I can just release a 200 kb supplemental .fsb... Has anyone else run into this issue, and/or have any idea how to correct it?

#2
Lady Olivia

Lady Olivia
  • Members
  • 374 messages
I had the same issue; never found a solution. As you might know, I'm modifying Alistair's dialog and I tried making a supplemental .fsb. It seemed to work fine until the number of lines I inserted gotten over 20 - then it started showing up. The more lines I added, the more original lines got jumbled up.

I lost many hours trying to find out what was going on. At first I thought it was because I deleted some lines from the original dialog (exactly two lines). So I started all over and used zz_return_false instead of deleting, but after a number of new lines went in, the issue came back.

I concluded that for each line you insert, somewhere some original line gets mismatched. If you only insert several lines, chances are you won't notice the problem. When you insert 30, though, it spreads all over. My guess is that the exported .dlg and the original .fsb don't match - and that's that.

I do hope I'm wrong. Although I gave up on making partial .fsbs some time ago, I'd be ever so happy to learn how to avoid this problem.

---

Something I learned in the process that might or might not be useful (more likely not, but here goes:)

You know how the original .fev files are a lot smaller than the ones created by VO generator in the toolset? It's because in the original .fevs, all or almost all the events have been deleted. The "index" of lines is instead kept in a custom property of VOConversation; the property is called "All lines" or something similar, and it holds a loooong string of alphabetically sorted line IDs.

I played with this, trying to make the partial .fsb work. Didn't help.

Modifié par Lady Olivia, 14 janvier 2010 - 12:48 .


#3
Avaraen

Avaraen
  • Members
  • 342 messages
Thanks for your input. I ended up reverting to the vanilla version of the dialogue and was able to re-create all of my changes, re-make the dialogue, and the supplemental .fsb worked fine. So whatever the cause, it was not a result of adding too many new lines to the dialogue, because my re-creation contained the same number of lines. The problem with my file occurred after I created a builder-to-builder version of some of the files in the mod, and after I'd loaded a builder-to-builder version of some other files (for a compatibility update) although I obviously can't say if that was a factor.

I'd also been working in a sub-module, and had to switch back to Single Player to generate VO, which may have been a factor; my latest strategy is to work directly in Single Player and only switch to the sub-module to package a dazip (for correct naming and version number inclusion). Since working in a sub-module doesn't preserve the original file within Single Player, and Resource History allows reversion to any checked-in version of the file, I figured that's the safest option in case working with the file in two different modules was at all a factor. So far, so good, although I haven't tried to make any changes to my modifications.

One oddity I did notice at some point during my supplemental .fsb attempts was that the line ID for my additions wasn't changing when I made edits to the dialogue line, which is very odd behaviour. I was also having some odd behaviour of the additions to my dialogue not actually changing in-game, even though I'd exported new versions of the dialogue. Clearly, there was a database corruption issue, but again, I can't say what might have been the cause, only that reverting to earlier versions that did not contain any new dialogue/VO lines and remaking the dialogue worked fine.

Modifié par Avaraen, 14 janvier 2010 - 04:41 .


#4
Lady Olivia

Lady Olivia
  • Members
  • 374 messages

Avaraen wrote...

I ended up reverting to the vanilla version of the dialogue and was able to re-create all of my changes, re-make the dialogue, and the supplemental .fsb worked fine.


I envy you. :(

Can you please tell me how many lines you inserted? Did you move the original nodes around - up and down the tree or nesting them deeper? I'm asking in the hope that I'll discover something I'm doing wrong, something I can avoid - anything. Because I redone Alistair's dialog three times and it's squeaky clean - but still I triggered the issue every time.

#5
Avaraen

Avaraen
  • Members
  • 342 messages
I did not move any dialogue in my changes; what I did do was create links to existing dialogue, and in cases where I wanted to replace dialogue, I left the original dialogue intact, and simply moved my new dialogue ahead of it in the tree - so the original dialogue is still there, but will never be reached. That was a precautionary measure on my part, to make it easy to restore the original dialogue if needed.

In some cases, when I wanted to add options, such as a new opening line to existing intiated dialogue, I added a comment to branch to new NPC dialogue, added my new dialogue, and linked to the original dialogue. In those situations, I simply adjusted conditions or set plot flags where necessary to ensure the original dialogue didn't get triggered a second time.

The dialogue I added was primarily new PC options leading to new dialogue trees; primarily new "kiss" options for Leliana and Zevran, since I thought it wasn't fair Morrigan and Alistair got all the fun. ;) There were some other new additions and adjustments, if you want to have a look, I have a b2b version available here. Overall though, the file I've added the most to so far is zevran_main.dlg; I have a total of only 21 new NPC lines with associated sound and face fx. Comments and PC lines also have associated line IDs, but I don't think they'd have any affect on the .fev generated.

You mentioned things were working fine at first, then you started having problems with mismatched sound; I had that problem occur once when I had exported a new .fsb, but had an extra copy of a .dlg file floating around, which was overriding the "correct" .dlg. Just wanted to mention that in case it could be a factor, since the toolset likes to save things in all sorts of interesting locations.

#6
Lady Olivia

Lady Olivia
  • Members
  • 374 messages
Thank you. The conflicting versions of .dlg files - that gives hope. I might try again!

#7
Avaraen

Avaraen
  • Members
  • 342 messages
One other thing - and I'm trying to recall the exact sequence, but it was after only 3 hours sleep, late in the day, and following a 3 hour php lecture... I did an export of leliana.dlg, generated a new .fsb and .fev, did the "split" of the .fsb with the supplemental .fsb and new .fev. Then, I wanted to add face fx to a couple of lines I hadn't done yet, but the toolset won't generate face fx unless VO has been generated in the same session. So I re-generated VO and then did the face fx, but hadn't re-exported leliana.dlg; I forgot to delete the newly generated .fsb and .fev before doing a quick playtest, and the vanilla dialogue was completely mismatched. Deleting the toolset-generated .fsb, and reverting to my FMOD-created .fev with supplemental .fsb, everything worked fine with the earlier-exported .dlg. So sort of a weird sequence of events brought on by being too tired to work, but it is something to keep in mind. Sorry if that's too convoluted to follow, but the ultimate point I guess is to make sure that the exported .dlg is the same version as your .fev and supplemental .fsb versions. Hope things work out for you!

#8
Nitro9a

Nitro9a
  • Members
  • 107 messages
The mod I'm working on involves additions and alterations to Morrigan_main.dlg, alistair_main.dlg, leliana.dlg, and zevran_main.dlg. I followed this tutorial first for Morrigan because she has the least amount of new lines and everything seems to be working fine, though I worry that the only way to test it to see that no lines have been displaced is to run through the entire game. I then moved to Zevran's dialogue (which has the most new lines added- 71, due to how his dialogue is set up and how I had to remove links and recopy original lines resulting in them having new line ids). The added dialogue works fine but some of the lines I haven't touched are jumbled up. I tried Alistair next, about 50 lines, and the same thing happened. I then deleted his dlg, dlb, fsb, and fev files, re-exported his dlg and generated new vo to make sure the files matched and still had no luck. The lines were jumbled up in the same order. Have you guys made any progress in getting this to work flawlessly? What do you think about the idea that lines that you haven't come across in testing are possibly getting jumbled?

#9
Lady Olivia

Lady Olivia
  • Members
  • 374 messages
What I remembered in the meantime is that the exported .dlg/.dlb files have nothing to do with this. The line preview in the toolset uses the .fsb if it it's there, so the jumbling can be "heard" from the toolset before exporting anything. Meaning the .fsb (or rather the .fev) doesn't match the database.

I'm pretty pessimistic about this, not only because I couldn't make it work, but also because it's impossible to test. The only way to really make sure no lines have mismatched VOs is to check each and every one, and that's just not feasible.

#10
Avaraen

Avaraen
  • Members
  • 342 messages
I have a suspicion that working in a sub-module, then switching back to Single Player to generate VO is what causes the problem with the dialogue/VO mismatch. I'd initially thought creating a b2b version of the file might have caused the issue, but reverting back to a check-in prior to the b2b, I still had the same problem. I also tried making a copy of the "bad" dialogue file, reverting to vanilla, and copying my changes into the clean vanilla file, but had the same problem. So something in the data is getting corrupted and causing the mismatch, probably related to line IDs.

Unfortunately, the only way I could solve the problem was to revert back to an earlier check-in (prior to adding lines to Zevran's dialogue) and re-create changes... I could have used the toolset generated repackage of the original sound and my added sounds, but I'm a bit stubborn about doing things "right", and didn't want to force an extra 30k download if I could avoid it. I can understand with multiple dialogue files and additions of 50+ lines to those files, one might be reluctant to re-create everything though.

Since having this problem, I do all my modding directly in Single Player, and only switch to a sub-module with a Single Player parent to generate a dazip. So far everything is working fine, although I haven't made any edits to my additions, which is where I started having problems previously.

#11
Lady Olivia

Lady Olivia
  • Members
  • 374 messages

Avaraen wrote...

I have a suspicion that working in a sub-module, then switching back to Single Player to generate VO is what causes the problem with the dialogue/VO mismatch. I'd initially thought creating a b2b version of the file might have caused the issue, but reverting back to a check-in prior to the b2b, I still had the same problem. I also tried making a copy of the "bad" dialogue file, reverting to vanilla, and copying my changes into the clean vanilla file, but had the same problem. So something in the data is getting corrupted and causing the mismatch, probably related to line IDs.

Hm. I've been working in a module all along. I never switched to Single Player for VOs - the module does post VO data to AppData/Local/Temp/DAWhatever and I build the banks from the project file there. So switching in itself isn't to blame. But maybe the "working in a module all along" is? Gah. That would be a bummer.

I don't think it's the IDs either: no matter where I made the changes - SP or a new module, I got IDs from the 610000xxx range in the modified dialogs.

Avaraen wrote...

I'm a bit stubborn about doing things "right", and didn't want to force an extra 30k download if I could avoid it. 

I hear you. :(  I started over three times because of this, and although it gets easier and faster each time, it also gets more and more boring. Perhaps I'll get back to it if more people manage to do it successfully.

#12
Avaraen

Avaraen
  • Members
  • 342 messages
Well that's interesting; I could never get VO generation to work in a sub-module. I don't think it was throwing an error message, it just wasn't doing anything at all when I tried, which is why I suspected switching from sub-module to Single Player as a culprit.

My mention of line ID issues isn't to say the toolset is generating bad line IDs, but that the data for them is somehow getting corrupted. Like on edits to the added lines, it seemed to be keeping artifact data from the original lines, instead of saving the new data I was adding. In FMOD, I could play a .wav number and it would match the text, but when I generated the .fev, things were mismatched, and I am fairly certain is was a problem with FMOD, because the toolset .fsb (as we know) works fine, and the mismatch only occurs with the new .fev and supplemental .fsb.

Modders may end up having to release the full soundbanks (I would probably split them up into separate chunks of downloads if I hit a size cap). If the problem persists, especially when we start merging, editing, and adding lines (for our own changes, or compatibility updates), we're going to get to a point where we just can't continue re-creating (especially since re-creating doesn't always work).

#13
Nitro9a

Nitro9a
  • Members
  • 107 messages
I've been working only in my module as well. I had an issue generating vo once, but I'm not sure what the problem was- the next time I opened the toolset it worked fine. I think I'm just going to have to host my mod off site. Perhaps I will try again once it is perfected.

#14
Lady Olivia

Lady Olivia
  • Members
  • 374 messages

Avaraen wrote...

Well that's interesting; I could never get VO generation to work in a sub-module. I don't think it was throwing an error message, it just wasn't doing anything at all when I tried, which is why I suspected switching from sub-module to Single Player as a culprit.

Just to make sure we're on the same page: in SP, when I hit GenerateVO, I get a looong operation in the end of which a console window pops up and i can watch how FMOD builds the .fsb. When it's done, I find the .fev and .fsb files in the override.

When in a module, however, hitting GenerateVO does a very brief operation, the console window doesn't pop up, and I don't get .fev/.fsb in the override. The log window says something like "VO data posted to local", no errors, and when I go to AppData/Local/Temp/DAFolder, I see that the files there, the .fdp included, have been updated. 

That's what I mean when I say it "works" for me. It actually doesn't, but I don't need to switch to Single Player in order to build the output - I do it from FMOD designer, be it the whole .fsb or the supplement. 

#15
Avaraen

Avaraen
  • Members
  • 342 messages
Ahh, thanks for that; it hadn't occurred to me it might be generating an .fbp in sub-modules, and I don't think Archonyx's tutorial was up when I first tried, so I didn't think to look at it later - all I knew was I wasn't getting an .fsb or .fev out of it. I'll have to keep that in mind and may experiment with it when the inevitable mod compatibility versions have to be done.