| 7 | | But that message was only shown for a split second, before skipping to the next message. I ''think'' what's going on here is some sort of integer overflow. This is how the message is displayed in rm150.sc, sCartoon: |
| | 7 | 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. |
| | 8 | |
| | 9 | 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: |
| 20 | | If you load the attached savegame, and let the messages time out on their own (don't click to speed it up!), the skipped message happens at a point when KGETTIME_TICKS in the kGetTime() function comes (dangerously?) close to 32,767. Could that somehow cause the timeout to trigger prematurely? |
| | 20 | 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. |
| | 21 | |
| | 22 | 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. |
| | 23 | |
| | 24 | I'm more worried about what other things may potentially be affected, though. |
