Lemma Soft Forums

I'm having a bit of trouble with something related to Character objects. According to the documentation wiki, a character with an empty string for a name is supposed to "[allow] a narrator character to line up narration with character dialogue." I assume that means narration text is supposed to place itself starting at the place where character dialog begins, as opposed to where the name label would be displayed. This doesn't seem to work for me.

I've tried both creating a character object like so: as well as simply placing a "" before the narration line. Neither method does anything differently. I've been able to get the functionality I want by adjusting style.say_thought.ypos, but that seems hackish, and doesn't work in readback mode. If anybody has done this before and can help me, please respond. It's not of dire importance, but I certainly would like this issue resolved as soon as possible.

Thank you.

The documentation is probably wrong about this, the way to do it is not to have an empty string, but a string containing only a space. You also want to set who_suffix to the empty string, giving a line like:

$ narrator = Character(" ", who_suffix="")

Are you actually using readback mode? It's not overly well supported anymore. I was considering deprecating it in the next version, on the grounds that it's a bad idea that nobody uses.

Yeah, that worked. And it makes more sense, too. I'll go update that in the wiki.

The readback thing was just an observation. I would more than likely use rollback in an official game release. Or maybe I can find a way to make it a user option. I don't see why anyone would choose readback over rollback, but then again, Apple Computer loves to add options for stuff that nobody uses, so why not?

Also, this is off-topic, but I don't think it's worthy of a new topic. While we're on the subject of extras, I noticed that the "east_asian.rpy" script mentioned that you wanted feedback on how it works with Korean. I'm not sure if you got an answer to that, but I'll answer anyway. As a matter of fact, Korean text is best used without that script at all. Korean hangul is more like English text than other Asian languages, in the sense that there are spaces between words and punctuation. It works better without special support. No need to mess with that script at all.

NetGenSuperstar wrote:I don't see why anyone would choose readback over rollback

Rollback appears to have several limitations compared to the readback modes implemented in most other visual-novel engines. Most specifically, it appears that Ren'Py's rollback doesn't have any facility to get you back to where you were once you've started rolling back. You have to roll forward again manually, and if you rolled back past decision points, it seems you have to remember which choices you made before. In an engine with full readback support, you can roll back as far as the engine permits and a single click will return you to where you were when you started rolling back, regardless of how many decision points you passed in the meantime.

Additionally, Ren'Py's rollback presents the text exactly as it was presented before. This is great if what you want is to go back and see the game as it was when you came through the first time, but if what you want is simply to review the text you've just been reading, then the system used in many commercial games - where readback text is displayed in a separate full-screen scrollable window, so you can see many screens of text all at the same time, is clearly better.

Basically, they're different features with different purposes. The Ren'Py rollback feature (at least as used in the Ren'Py demo game) doesn't seem to be very convenient for players who just want to quickly remind themselves what a character said thirty screens ago, while traditional readback is useless for players who want to experience a scene again in all its glory, or who want to change their mind and go back and make a different decision.

Anyway, I'm not arguing that Ren'Py should implement readback (or even that the existing readback extra should be retained - if it doesn't provide any of the possible advantages described above, then it might genuinely be redundant compared to rollback). Just explaining why someone might conceivably want to choose some readback implementations over rollback. :)

My 2 cents on the matter - I prefer the "timetravel" readback to the logfile approach, especially when I want to quickly re-live the situation again when I'm interrupted somehow - a scrollable logfile is a bit cold and worst of all is when a game simply rolls back text inside the game window (and not in an overlayed scroll window) with the current image on screen...

So maybe there should be 3 ways (and each with its own variation ^_^)...
- rollback
- readback
- logfile

Personally, I find the logfile very annoying and counter-immersive, but of course it can be useful for others who like it.

Rollback is kinda like rewinding a video tape to rewatch the scene, indeed. But I understand the appeal of a simple backlog, for quick reference.
Still... while playing the True Tears demo yesterday, I tried to roll back... and failed... Ren'Py, what have you done to me ? ;o;...

The only use I see for an external logfile is to be able to do out-of-game stuff, like count the number of words, or paste things for walkthroughs and reviews. I find them useless for reviewing the game while playing.

Rollback is pretty neat, but I find it gets on my nerves sometimes if I pass through a section that had fancy slowdown effects and I have to wait through them again. I'm afraid I've only implemented the kind of backlog mikey hates. (The other is a little difficult to put in at this point, since the engine wasn't designed with that in mind, and rolling back is a lot more complicated than just keeping a text log to display.)

This discussion is giving me some ideas for how to change the behavior of rollback/roll-forward.

Right now, roll-forward is implemented fairly simply. When the user hits roll_forward (page down or mouse scroll down), we check to see if we've finished the current statement recently. If we have, roll_forward dismisses the screen. If not, roll_forward does nothing. This causes transitions to be shown again, and can also lead to roll_forward taking us past the starting point if the game contains loops or calls, like a dating sim.

I'm thinking of changing this to add a memory to roll_forward. The idea would be that rolling back would store where we were, and then rolling forward would jump us to to that point again. So if we made a menu choice, rolling forward would re-make that menu choice. If the user makes a different choice, then roll-forward will be disabled. This would also limit roll-forward to the point where the user began rolling back.

(I'm not quite sure how to implement this yet, however.)

I'm not planning on implementing a fullscreen readback log, as I don't see a good way to invoke it that doesn't interfere with rollback.

Imo rollback is only good for developper, because I use it a lot to check the "fancy stuff". As mentionned above, this feature work like a good old video tape, you could check again and again the same scene (I guess this could be called in cinema : scene retake work or something like that).
Removing this feature will make me a bit sad, but I could still use scite warp (though the reload feature shift+r would lose its interest in this case), no biggie.

We're debating eliminating the (unused) readback feature, not the heavily used rollback one.

Hmm... well, I'm always fond of the argument that if a feature hasn't been used, it isn't the feature to blame, but the users. For example, trying to be creative here, I can envision a logfile readback having the following interesting use:

"Timothy sighed as he looked at me."
"He was damp with perspiration."
"Every pore of his oozed sweat, like a massive wave of stinky fluid."
"Perhaps, in his mind, he was trying to look cool."
"Although, judging from the state of things, he was failing."
"Still, it was possible."
"Sometimes, people were able to control their bodies with their minds."
"Who wouldn't like a power like that?"
"Or, more specifically, would there be any instance where it would not be good?"
"Rarely, I would think."
"Didn't seem like the most relevant of observations at the moment."
"In any case, the security door was still locked."
"Stubborn old coot must have changed the password on me."
"He was unlikely to change it to something unfamiliar, though."
"Even if he was a paranoid old man, he had to have some reference point."
"Let me see... what would be easily remembered?"
"Perhaps, if I looked back at my train of thought, I would be able to decipher the password."

(And then we get a nice little text-entry screen that says:)
Aha! The password must be...
_


How's that for an interesting way to use a logfile readback system? But, it's probably a moot point, as Py'Tom says he can't figure out a way to implement it without interfering with everything else. Still... something for the ONScripter people to think about.

-Dizzy-

How about have readback be more powerful than rollback, like having that 'memory' you mentioned, as well as reaching deeper?

Perhaps in the future, it can even have a Search function. So the more powerful a feature is, then it's just bound to be used?

Rollback, in my opinion, doesn't need to go beyond that "whoa, cool animation, I need to see that again"... which is at most, only a couple of scenes. However I still stand by rollback. Maybe its because I'm a developer now.

dizzcity wrote:Hmm... well, I'm always fond of the argument that if a feature hasn't been used, it isn't the feature to blame, but the users. For example, trying to be creative here, I can envision a logfile readback having the following interesting use:
...
(And then we get a nice little text-entry screen that says:)
Aha! The password must be...

Damn, we didn't have logfiles when making K*A*O*R*I.... ^_^ (in case you played it)

Anyway, the readback could be called REWIND, it would emphasize that you're going back in "time". Again, I use to quickly get back in the mood after something interrupted me, it's quite useful. Although if I think about it, rollback has the same effect, right?

...Twelve replies spawned from me not putting a space in my code? Anything else you want to tell me, before I find out from someone else?

I'll just add my two cents to whatever comes to mind...

Haeleth: Good point. Now that I think about it, someone actually might prefer at least some of the functionality of readback. (See the reply to PyTom)

monele: That's similar to my two recent experiences. In many games, I've tried rolling back, and only got a readback. I keep forgetting. Also, Ren'Py defaults to not skipping past unread text when [CTRL] is held, but that can be turned off if necessary. This is unlike Puni Puni Handmaid which, as far as I can tell, has no way of skipping past unread text, except with constant clicking. Not normally a bad thing, but I don't actually speak Japanese; I only have the game because of the whole kemonomimi theme...

PyTom: I like the sound of that. That would make rollback have my favorite readback feature; I don't have to relive an entire section just because I missed something.

PyTom wrote:The idea would be that rolling back would store where we were, and then rolling forward would jump us to to that point again. So if we made a menu choice, rolling forward would re-make that menu choice. If the user makes a different choice, then roll-forward will be disabled. This would also limit roll-forward to the point where the user began rolling back.

This would be great: it would remove the rollback system's only serious weakness, namely the possibility that getting back to where one was might be difficult.

If rolling forward shows transitions, then it might also be an improvement to change that -- i.e. assume that the act of rolling indicates a desire to navigate quickly, and that a player who wanted to view animations and transitions would stop rolling and start clicking normally. Just a thought.