[Scummvm-tracker] [ScummVM :: Bugs] #15303: SCI: LSL5: Timed message skipped during LSL5 coffee scene (symptom of a bigger problem?)

[ScummVM :: Bugs]

#15303: SCI: LSL5: Timed message skipped during LSL5 coffee scene (symptom of a
bigger problem?)
-------------------------+-----------------------------------
Reporter:  eriktorbjorn  |       Owner:  (none)
    Type:  defect        |      Status:  new
Priority:  normal        |   Component:  Engine: SCI
 Version:                |  Resolution:
Keywords:                |        Game:  Leisure Suit Larry 5
-------------------------+-----------------------------------
Description changed by eriktorbjorn:

Old description:

> (Description updated after discussion below.)
>
> During the coffee delivery scene in Leisure Suit Larry 5 (the optional
> tutorial after the intro), I noticed that one of the lines was skipped,
> or rather the text box for it was dismissed so quickly that I could
> barely see it. The skipped message was supposed to be:
>
> "Yes, I know" you offer proudly, "I'm the Chief Tape Rewinder and
> Sterilizer on this project!"
>
> This glitch is quite timing sensitive, so I have include a savegame
> during the scene itself. Don't skip any text boxes, just let the scene
> play out with default settings for everything.
>
> The problem seems to be the way the `Talker` class times out text boxes.
> First the `doit` method calculates a duration based on string length and,
> I assume, text speed, and assigns it to the `ticks` property. Then `say`
> adds another 60 ticks for good measure, and adds the current game time as
> reported by `GetTime`. The `doit` method then polls `GetTime` to see if
> the text box should be dismissed:
>
> {{{
>                 (if (> (GetTime) ticks)
>                         (self dispose: disposeWhenDone)
>                         (return)
>                 )
> }}}
>
> What seems to happen is that if `GetTime` is close enough to 32,767,
> adding the duration causes `ticks` to become negative. Which means that
> `GetTime` is immediately greater than `ticks`.
>
> I believe this means that the glitch could happen at any point in the
> game, and I was just lucky (?) to catch it here. And the same mechanism
> seems to be present in several other games, but no one ever noticed. I
> blame the lengthy cutscenes in LSL5 for triggering it.
>
> I imagine it should be possible to fix, at least on a case-by-case basis.
> The arithmetic workarounds seem like a reasonable place to start, but it
> might need some extending to call a custom C++ function to do the
> comparison? We know that `ticks` should stay constant until the text box
> is dismissed.
>
> I'm more worried about what other things may potentially be affected,
> though.

New description:

 (Description updated after discussion below.)

 During the coffee delivery scene in Leisure Suit Larry 5 (the optional
 tutorial after the intro), I noticed that one of the lines was skipped, or
 rather the text box for it was dismissed so quickly that I could barely
 see it. The skipped message was supposed to be:

 "Yes, I know" you offer proudly, "I'm the Chief Tape Rewinder and
 Sterilizer on this project!"

 This glitch is quite timing sensitive, so I have include a savegame during
 the scene itself. Don't skip any text boxes, just let the scene play out
 with default settings for everything.

 The problem seems to be the way the `Talker` class times out text boxes.
 First the `doit` method calculates a duration based on string length and,
 I assume, text speed, and assigns it to the `ticks` property. Then `say`
 adds another 60 ticks for good measure, and adds the current game time as
 reported by `GetTime`. The `doit` method then polls `GetTime` to see if
 the text box should be dismissed:

 {{{
                 (if (> (GetTime) ticks)
                         (self dispose: disposeWhenDone)
                         (return)
                 )
 }}}

 What seems to happen is that if `GetTime` is close enough to 32,767,
 adding the duration causes `ticks` to become negative. Which means that
 `GetTime` is immediately greater than `ticks`.

 I believe this means that the glitch could happen at any point in the
 game, and I was just lucky (?) to catch it here. And the same mechanism
 seems to be present in several other games, but no one (?) ever noticed. I
 blame the lengthy cutscenes in LSL5 for triggering it.

 I imagine it should be possible to fix, at least on a case-by-case basis.
 The arithmetic workarounds seem like a reasonable place to start, but it
 might need some extending to call a custom C++ function to do the
 comparison? We know that `ticks` should stay constant until the text box
 is dismissed.

 I'm more worried about what other things may potentially be affected,
 though.

--
-- 
Ticket URL: <https://bugs.scummvm.org/ticket/15303#comment:20>
ScummVM :: Bugs <https://bugs.scummvm.org>
ScummVM