We realized that ILs have no distinct timing rules visible. Since there's no recollection of what they outright were, we've clarified the timing rules and will retime ILs.

Two things will be implemented for now but are up for discussion:

1. The time for the end of an episode will be refined from "when the to be continued screen appears" to "when the screen is visible or the crack of thunder signalling it is audible". Due to the known problem with animation duping, it is possible (and I just managed it) to dupe the final cutscene and overwrite the to-be-continued screen. IMO, it is preferable to allow checking for the sound effect as well, as the animation dupe is still poorly understoof and not under the runner's control. Once we understand it better, this can be re-addressed.

2. I brought up with thewoofs, but am looking for further opinions, that we should start timing from the first meaningful input of the run. There are no real cycles to take into account, and right now the amount of delay before the gameplay starts is somewhat random. A clean restart of the game straight into a new game is usually reliably instant, but also, there is no reason to start fiddling with constantly resetting runs for optimal start menu RNG when nothing meaningful is changed by starting timing on the first input.

Do not advertise for personal Discord servers, even if TOMI-adjacent.

• Notebook skip is the most important thing we could discover
• Backpedaling does not seem as detrimental as in the first game?
• Does key+mouse mashing skip faster than mouse mashing?
• Is the current pie route (entrance, Mandy, entrance, stage, flowerpot, shop, hot tub, Mandy) reasonable? Could a route change save time for eg. avoiding turning around?
• Can you manipulate the phone or the wizard through walls/objects?
• Is duping money possible?
• Is it best to open/close the notebook when you get it, while moving to the door, or just before opening the door?

So, I don't currently have a video convenient for this, but the steps to reproduce:

• Start opening the case on the bed
• Immediately turn around and run out of the room and then to the right, past your neighbour

I'm not sure what happened, but trying to do this quickly essentially broke the conversation. The neighbour's text prompts were getting cut off a second into being printed, and dialogue choices were being automatically selected (though I can't be sure if it's actually automatic, or if the game simply buffers your inputs very aggressively and my pre-emptive mashing lined up too many).

I suspect? It has something to do with forcing a conversation but then being outside conversation range.

We noticed that load times can vary quite a lot in the game. For example, I play on SSD and Makke from ramdisk, and our runs have about 2-3 seconds of total difference from different loading screens. In the same way, someone playing off HDD would be far worse off.

We could try to see if we can get a loadless timer going somehow, but in the interim, what do we do? Should we add a loadless time to the leaderboards, sort by it and check the time for runs on submission?

I've seen some people bring this up before. I can personally see the case that the run comes down to movement and mouse precision, but I'm honestly a little bit opposed to making dialogue skip easier. It feels to me like that's the major obstacle and the make-or-break tech for running this game.

I've submitted an 8:47 WR where dialogue skipping is done by binding mouse wheel scrolling to LMB. I would personally prefer that run be rejected, but that will depend on how our little community feels.

So what thoughts do people have on the dialogue skip? I've only made a couple of observations so far that I feel are reliable:

1. Mashing too fast is counter-productive
2. Enter seems to be better in general
3. If you mash LMB fast enough, you can "block" enter inputs from triggering the first conversation choice
4. Moving your mouse around seems to help, but I'm unsure if that's related to input event handling or just a symptom of your hand slowing down or something

Which in turn leaves two questions:

1. Based on observations 1 and 3, is there something with the input handling where input events cancel each other out?
2. Do enter and LMB skip in different ways?