Unused/untriggered dialogue

mogul · Post by **mogul** » Thu Nov 17, 2011 1:28 am

WOW, nice going, guys!

Ezekiel000 wrote:The official patch includes an extra lab file that I assume takes precedent if there is a duplicate file right?
So what if you include in the patch extractor a process that will take the incorrect script from the original lab, fix it and then insert it into the lab file from the patch.

I was just going to suggest something like this. Providing a new .lab with the corrected resources is the proper way to patch script bugs in GF. I used it when I patched subtitles in for the Rusty Anchor song, for example. We also used it during production to resolve blocker bugs cleanly without burning new builds during QA cycles.

I don't believe you need to insert it in the patch's existing lab file... If memory serves, the game will read multiple additional lab files in alphanumeric order, and "stack" them on top of the ones loaded earlier. Requests for assets only go as deep in the stack as they need to before they are successful.

Incidentally, you can probably also use this functionality to make labs of any "special editions" assets and distribute them separately from the unmodified assets.

PS: We'd never even heard of this bug before, but Tim assures me it's all his fault.

somaen · Post by **somaen** » Thu Nov 17, 2011 4:23 pm

mogul wrote:I don't believe you need to insert it in the patch's existing lab file... If memory serves, the game will read multiple additional lab files in alphanumeric order, and "stack" them on top of the ones loaded earlier. Requests for assets only go as deep in the stack as they need to before they are successful.

That's almost precisely how ResidualVM handles the files currently, although the patch is currently explicitly moved to the top of the stack (I guess to avoid sorting issues on case-sensitive systems, although I might be wrong, as I don't have the code in front of me). I did add support for a specific userpatch.lab in much the same manner, although that might have been unneccessary if we just make sure that higher-numbered LABs have precedence over lower-numbered ones in a case-insensitive way.

mogul wrote:PS: We'd never even heard of this bug before, but Tim assures me it's all his fault.

Wow, well I guess there was little additional feedback after the original patch was pushed out the door? (As I guess you already were moving onto the next project at LA) A bit funny to hear though

JohnnyWalker2001 · Post by **JohnnyWalker2001** » Mon Nov 21, 2011 10:37 pm

This is great news! I'm not sure if the patch is now in ResidualVM or what, but someone has made a patch file, too.

http://lucasforums.com/showthread.php?p=2795980

JohnnyWalker2001 · Post by **JohnnyWalker2001** » Mon Nov 21, 2011 10:38 pm

mogul wrote:Incidentally, you can probably also use this functionality to make labs of any "special editions" assets and distribute them separately from the unmodified assets

Excellent!

giucam · Post by **giucam** » Tue Nov 22, 2011 3:20 pm

JohnnyWalker2001 wrote:This is great news! I'm not sure if the patch is now in ResidualVM or what, but someone has made a patch file, too.

http://lucasforums.com/showthread.php?p=2795980

We can't distribute the fixed file, since that would bring legal issues.
I have anyway an idea that, if feasible, would allow to make a patch without modifying the original file.

Blackmonkey · Post by **Blackmonkey** » Thu Nov 24, 2011 2:58 pm

giucam wrote:I've found a solution. Not automatized yet but probably the best one.

I've followed your instructions, but I have a doubt: when I had to modify the first line of dlg_dom2.lua, I created a new dlg_dom2.lua file and copied the text printed on the terminal (after using delua) in it. Then I corrected the first line ("CheckFirstTime(dlg_domino.lua)" ---> "CheckFirstTime(dlg_dom2.lua)").
And then I used this new .lua file to make the new DATA000.LAB.
Is it correct? Or did I had to do something different?

Thanks a lot!

giucam · Post by **giucam** » Thu Nov 24, 2011 3:24 pm

That's correct.
I've explained a different solution on my blog however, that doesn't replace data000.lab.

Blackmonkey · Post by **Blackmonkey** » Thu Nov 24, 2011 3:41 pm

Yes, I've read the blog, but I'm using Ubuntu, and there still isn't an updated version in the download section (updated to 24 september, and support for datausr.lab was added later, right?).

I also read the news. "One of the more interesting bugs found and solved, was the one about missing dialogue" means that the bug is solved "inside" residual without need of "manual fixing"? Or do I still have to create a new data000.lab or a datausr.lab file?

Thank you.

giucam · Post by **giucam** » Thu Nov 24, 2011 4:12 pm

Blackmonkey wrote:Or do I still have to create a new data000.lab or a datausr.lab file?

Yes, that will be most probably always needed.

MeddlingMonk · Post by **MeddlingMonk** » Thu Nov 24, 2011 5:01 pm

Maybe this is the way it has to be, but it looks like datausr.lab isn't all that portable. I created mine on my PPC Mac and it seems to work. I don't have a saved game from the factory island so I can't exactly test it out, but when I start GF I get the expected warning. But that doesn't happen on my Windows machine. I wonder if that's to do with the different architecture or endianness, or something else. I don't relish the idea of trying to work with mingw to compile residual-tools. But maybe there's something that can be done with the tools. It just seems odd that datausr.lab created on a PPC Mac won't be recognized by ResidualVM in Windows, when the original game data files were created in an Intel PC environment but work fine with ResidualVM on a PPC Mac. Maybe the problem is just with me.

giucam · Post by **giucam** » Thu Nov 24, 2011 5:15 pm

mmh, probably that's just a bug in mklab. There's nothing inherently not portable with datausr.lab.

MeddlingMonk · Post by **MeddlingMonk** » Thu Nov 24, 2011 5:27 pm

It certainly surprised me. And there's nothing in the ResidualVM log in Windows about the file, so it's as if it's not aware that it's even there. But that doesn't really help you, does it.

YakBizzarro · Post by **YakBizzarro** » Sat Nov 26, 2011 9:48 pm

About the licensing problem of this fix, why don't you patch the script on the fly, before it's executed by the lua interpreter? I have made a simple proof of concept here: https://github.com/YakBizzarro/residual ... 95efa5a25f
Moreover it also allows us to implement workarounds in a cleaner way, for example the bypass of the check for the cd in _system.LUA.

MeddlingMonk · Post by **MeddlingMonk** » Sun Dec 11, 2011 2:59 am

Just tried the latest Windows build. Looks like it now recognizes the datausr.lab I made on my Mac. Nice one.

Blackmonkey · Post by **Blackmonkey** » Wed Dec 14, 2011 10:00 pm

Could it be that your old Windows build wasn't as recent as that for Mac? From what I read on giucam's blog the new method relies on recent developements.