Complaint about pauses

[Wintermoon]

I was playing Memo. As usual, I had the text speed cranked up to the maximum. Here is what happened, with annoying regularity:

• I read a section of text, then pressed <space> to advance.
• Just as I was about to press <space>, more text appeared. Naturally, I missed it.
• To add insult to injury, when I pressed <page up> to read the text I missed, it wasn't there, and it didn't appear after waiting either. I had to press <space> again to make it appear.

I thought I'd complain here instead of in the Memo thread since this appears to be a Ren'Py problem.

In my opinion, the correct behavior would be:

• If the text speed is at the maximum, all pauses should either be skipped entirely or require a keystroke/mouseclick before advancing. Preferably the former, but I can live with the latter.
• In rollback mode, all pauses should be skipped.

[chronoluminaire]

I agree this is frustrating. This kind of thing gets me worked up no end. I also play with text speed at the maximum.

If the text speed is at the maximum, all pauses should either be skipped entirely or require a keystroke/mouseclick before advancing. Preferably the former, but I can live with the latter.

I agree with this suggestion. If not these, then at least have some obvious indicator of the difference between "waiting for you to click" and "waiting some time that the author's specified". The use of the {w} text tag generally annoys me.
But I can see that people like it, to add pauses to their text like they would when narrating a story. Personally I don't think it's worth it, but it's the kind of thing that a lot of authors want, so I can see why PyTom implemented it.

In rollback mode, all pauses should be skipped.

I can see why you say this, but rollback really tries very hard to be identical to when you saw the text for the first time, so I don't think I can agree with this. I don't understand why your rollback didn't show you the same text with the same pauses after rolling back. PyTom or anyone, any ideas?

Perhaps there should be an optional preference (disabled in VNs that don't use {w}) which is something like "Prevent advancing within this time after new text appears:" and a slider from 0 to perhaps 1.0 seconds? This would cause space/enter/left-click to be ignored if some new text has just appeared, but respect skipping via Ctrl/Tab/"Begin Skipping" as usual.

[Jake]

I also play with text speed at the maximum.

Likewise,

and:

If the text speed is at the maximum, all pauses should either be skipped entirely or require a keystroke/mouseclick before advancing. Preferably the former, but I can live with the latter.

I agree with this suggestion.

likewise. At first I think I'd lean a bit further towards preferring a click to advance through the pause, since it was presumably put in there for a reason, though...

I can understand the notion of wanting them skipped entirely on full text speed, though; putting in pauses in text is essentially forcing a slower text speed, and setting the text speed to full is saying "I don't want to have to wait for text to appear". By way of example, we have a tricky situation if you elect to require a click where it's possible to use the text pauses to string out a long utterance a bit more than text-speed normally would, so - for example - if a character yelled out an attack name:

FLYING SHURIKEN KIIIIIIIIICK!

then it may be spaced out with very brief dramatic pauses to further illustrate how long the character's screaming it for:

FLYING [-] SHURIKEN [-] KII[-]III[-]IICK!

such pauses would likely be very short, fractions of a second, but then the utterance probably takes much longer under click-to-advance full-text-speed than it would have originally.

So yeah, on balance probably skipping them entirely is the 'better' solution.

The use of the {w} text tag generally annoys me.
But I can see that people like it, to add pauses to their text like they would when narrating a story. Personally I don't think it's worth it, but it's the kind of thing that a lot of authors want, so I can see why PyTom implemented it.

Personally, it seems to me that it's primarily useful when you have a voiceover, so as to time the text to appear as the voice actor reaches that part of the line. Which of course gets messed up if you let people fiddle with the text speed anyway, so...

[number473]

It depends if you want the roll back to actually take you back to an earlier part of the game or you simply want to review what was said a little earlier. In the former case you would want it to display everything as faithfully to the original as possible i.e. re-show those sections. That is what Ren'Py currently does. In the second case you would simply want to see the text (and possibly the images related) again. I have seen some VN do this. In this case you would want to ignore {w} and {p} when rolling back and possibly when coming forward again (newline for {p} would still be displayed). I don't know if Ren'Py can do this currently, but it makes checking back easier, especially if transitions etc are also skipped.

[chronoluminaire]

Hehehe... you're getting on to the discussion about rollback vs readback there. Search the forum for "readback" to see some of the controversy it's generated in the past.

There are a couple of subtle ways that Ren'Py does support rollback being treated differently to first-time viewing of code. One of them is that there's a set of styles which can be applied to text (or windows etc) when in rollback. That seems like it achieves a lot of the difference that people are often after.

[Gumaster]

If the text speed is at the maximum, all pauses should either be skipped entirely or require a keystroke/mouseclick before advancing. Preferably the former, but I can live with the latter.

I agree with this suggestion. If not these, then at least have some obvious indicator of the difference between "waiting for you to click" and "waiting some time that the author's specified". The use of the {w} text tag generally annoys me.

Not really a solution or anything, but using ctc indicators for pause and continue (but NOT timedpause) makes it easier to tell the reader when to click and when to wait (this is precisely the reason why I tried hard to get pretty, working indicators in [by work hard, I mean I didn't instantly give up at the first error.])
I personally set text speed to just under maximum, and mash mouse click when I'm impatient, but that's irrelevant here.