4.8 Feature Requests

[PyTom]

Well, a new thread for 4.8 feature requests. Please note that I probably won't get to any of these until April, but you never know. It might be that what you want is already in Ren'Py.

Anyway, I got nothing. Post here if you want a new feature.

[Megaman Z]

No feature requests here. (yet...)
It even works correctly when half of the windows on one monitor and half is on another (yes, I have two monitors. the only reason I mention this is that another program I have doesn't work correctly unless I have them set up in a specific way, and then only on one monitor!)

[PyTom]

Actually, I've been running it on two monitors since I first developed Ren'Py, save for a short period where half of my video card died. I'd expect all of Ren'Py to work on two monitors except for full-screen video playback, which may not work when split in half, due to the hardware acceleration involved.

Just an FYI.

[Megaman Z]

Okay, completely random idea that may actually have a use by someone else. why not add a secondary timer that can be displayed on-screen and, if it reaches a certain value (or 0, if it's decrementing), have a certain set of code statements executed.
(odds are, I'm going to look back at this and wonder "what the heck was I on that day?!?", but it might actually be used by someone...)

[chronoluminaire]

TBH, given how quickly Py'Tom codes things and how the main requirement in a ren'ai game is the script, I'd say it's a bit pointless to go bothering him with requests that you're not sure you even want... Sorry, that's not meant as an attack! Just a call along the lines of "he treats us so well, let's not use up his patience excessively"

[PyTom]

Actually, I should probably point out that this can be done already, without a need for a change to the engine. (Not very conveniently, but it can be done.) The hard part is figuring out what to do when the timer runs out... but that's a specification thing, not so much a programming thing.

[PixelWrangler]

Apologies for any of the following suggestions that have already been implemented, or are easily possible with the current version of Ren'py.

Also, I hope I'm not "necromancing" this thread, as the last post was almost a month ago.

1. The ability to "kill"/stop a sound mid-play. This will allow for better voice acting control, as well as avoid lingering sounds during skip mode.

2. The ability to have rollback not include menus. Many commercial ren'ai games allow you to read back as far as you want, but not re-make choices. (That's what proper use of the "save" function is for )

3. The ability to specify graphic position relative to another graphic or element (displayable, etc). Uses of this functionality would include, but not be limited to:
- Altering small portions of a background images (opening a door, changing the sky for time of day/weather, etc.)
- Swapping out of various elements of characters, allowing for fine control of facial expressions, wardrobe, etc.

4. The ability to remove the text box using a hot key or right mouse click. This is especially helpful during "special event" or "ending" sequences, where there are full-screen custom graphics. This will take the burden of displaying such graphics off of the scripter, and allow the player to view the full graphic at any time.

Usual implementation:
RC/HK click while text box present - remove box
RC/HK click while text box hidden - show box
LC while text box hidden - show box and move forward in the script.

5. The ability to have menus appear outside (usually above) the text box. This allows the player to make a selection with the last bit of relevant text still on the screen. As an example:

MENU:
Yes
No
Only if you come with me

TEXT BOX:
Sayuki :
Will you speak to Murayama-sensei for me?

6. The ability to "zoom" a displayable in/out. Though a quick and dirty approach, it will allow for a neat effect without adding to file sizes. So if, for example, a character moves in for a quick peck on the cheek, the programmer just has to scale up the image, and possibly reposition it. If the character walks away, scale down, etc.

If relative positioning/layering of elements is used, all elements would scale and reposition appropriately. To limit issues with relative positioning, the following aspects should be more than adequate, and allow for accurate interpolation and repositioning of the graphics:

0.25X (quarter-size), 0.5X(half-size), 1X (normal), 2X (double-size), 4X (quadruple-size)

7. Thumbnail image next to dialog box. Though possible using the current version, it would be great to have the option to include simple "thumbnail" expression images next to the text box. This would be expecially helpful to indicate a character's mood if they are speaking from off-screen.

8. Ability to include scaled-down screen captures for display in the Load/Save screen. This allows for quick reference by the player when determining which game to load or overwrite.

That's all I can think of right now. Again, apologies if any of these suggestions are unneccessary (I am fairly new to Ren'py), but they are all cool features from some of the better RAGs I have seen in the past, and ones that I haven't seen (or at least noticed) specifically implemented in the current version of Ren'py.

P.W.

[PyTom]

1. The ability to "kill"/stop a sound mid-play. This will allow for better voice acting control, as well as avoid lingering sounds during skip mode.

Not yet. Due in the next version.

2. The ability to have rollback not include menus. Many commercial ren'ai games allow you to read back as far as you want, but not re-make choices. (That's what proper use of the "save" function is for )

There is the ability to limit how far the player can roll back. I have, while playing other games, accidentally clicked too fast and made the wrong choice, so I'd like to leave this in. Plus, readback would require a whole different set of code to support it.

3. The ability to specify graphic position relative to another graphic or element (displayable, etc). Uses of this functionality would include, but not be limited to:
- Altering small portions of a background images (opening a door, changing the sky for time of day/weather, etc.)
- Swapping out of various elements of characters, allowing for fine control of facial expressions, wardrobe, etc.

You can use a tuple to overlay one image on top of another, aligned at the upper left. This lets the layer be mostly transparent, saving space.

4. The ability to remove the text box using a hot key or right mouse click. This is especially helpful during "special event" or "ending" sequences, where there are full-screen custom graphics. This will take the burden of displaying such graphics off of the scripter, and allow the player to view the full graphic at any time.

I believe most games have this bound to the center mouse button, so that's where Ren'Py has it.

5. The ability to have menus appear outside (usually above) the text box. This allows the player to make a selection with the last bit of relevant text still on the screen. As an example:

MENU:
Yes
No
Only if you come with me

TEXT BOX:
Sayuki :
Will you speak to Murayama-sensei for me?

This can be done. First, copy the button_menu.rpy file from the extras directory into your game directory. Then, you can write code like:

Code: Select all

sayuki "I need someone to argue on my behalf."

$ sayuki("Will you speek to Murayama-sensei for me?", interact=False)

menu:
     "Yes":
           pass
     "No":
           pass
      "Only if you come with me."

This assumes Sayuki's character object is named sayuki.

6. The ability to "zoom" a displayable in/out. Though a quick and dirty approach, it will allow for a neat effect without adding to file sizes. So if, for example, a character moves in for a quick peck on the cheek, the programmer just has to scale up the image, and possibly reposition it. If the character walks away, scale down, etc.

If relative positioning/layering of elements is used, all elements would scale and reposition appropriately. To limit issues with relative positioning, the following aspects should be more than adequate, and allow for accurate interpolation and repositioning of the graphics:

0.25X (quarter-size), 0.5X(half-size), 1X (normal), 2X (double-size), 4X (quadruple-size)

That's an idea. I'll see if I can make scaling fast and accurate enought to be useful.

7. Thumbnail image next to dialog box. Though possible using the current version, it would be great to have the option to include simple "thumbnail" expression images next to the text box. This would be expecially helpful to indicate a character's mood if they are speaking from off-screen.

This is doable using overlays. If you'd like, I can whip up some sample code for you.

8. Ability to include scaled-down screen captures for display in the Load/Save screen. This allows for quick reference by the player when determining which game to load or overwrite.

This is being done. Are you using Ren'Py 4.7.1?

[PixelWrangler]

1. The ability to "kill"/stop a sound mid-play. This will allow for better voice acting control, as well as avoid lingering sounds during skip mode.

Not yet. Due in the next version.

Excellent. How about the ability to replay voice sounds (or any sounds, for that matter) during rollback? (via a button near the text box)

2. The ability to have rollback not include menus. Many commercial ren'ai games allow you to read back as far as you want, but not re-make choices. (That's what proper use of the "save" function is for )

There is the ability to limit how far the player can roll back. I have, while playing other games, accidentally clicked too fast and made the wrong choice, so I'd like to leave this in. Plus, readback would require a whole different set of code to support it.

I wouldn't want you to take it out, just let it be an option that the writer could set. A simple configuration boolean sort of thing.

"menusinrollback = false" or the like.

In that way, you could "fudge" readback functionality, without having to re-code for it.

4. The ability to remove the text box using a hot key or right mouse click. This is especially helpful during "special event" or "ending" sequences, where there are full-screen custom graphics. This will take the burden of displaying such graphics off of the scripter, and allow the player to view the full graphic at any time.

I believe most games have this bound to the center mouse button, so that's where Ren'Py has it.

Hm... most of the ones I've seen are right-clicks. I've played mostly commercial Japanese/translated RAGs, though...

I think I remember reading that you can re-map functionality... does that apply to this as well?

6. The ability to "zoom" a displayable in/out. Though a quick and dirty approach, it will allow for a neat effect without adding to file sizes. So if, for example, a character moves in for a quick peck on the cheek, the programmer just has to scale up the image, and possibly reposition it. If the character walks away, scale down, etc.

If relative positioning/layering of elements is used, all elements would scale and reposition appropriately. To limit issues with relative positioning, the following aspects should be more than adequate, and allow for accurate interpolation and repositioning of the graphics:

0.25X (quarter-size), 0.5X(half-size), 1X (normal), 2X (double-size), 4X (quadruple-size)

That's an idea. I'll see if I can make scaling fast and accurate enought to be useful.

Excellent. On a related note, how about a Marquee/Vignette option that would display part of a full image, possibly using a "masking" effect. For example, a phone conversation - all of the character's poses could be used, but it would be apparent that the character is not actually standing in front of the player.

Of course, this may be tricky from a graphical overhead perspective.

7. Thumbnail image next to dialog box. Though possible using the current version, it would be great to have the option to include simple "thumbnail" expression images next to the text box. This would be expecially helpful to indicate a character's mood if they are speaking from off-screen.

This is doable using overlays. If you'd like, I can whip up some sample code for you.

That would be cool, but I don't have an immediate use for it, so definitely at your leisure.

8. Ability to include scaled-down screen captures for display in the Load/Save screen. This allows for quick reference by the player when determining which game to load or overwrite.

This is being done. Are you using Ren'Py 4.7.1?

Yes. And I thought about not including that last one until I had a chance to double-check things. Sorry about that.

Once I've been using the program a little longer, I'll take stock and check back in with any other suggestions I've come up with.

P.W.

P.S. - Apologies for suggesting so many already-possible features.

[PyTom]

Excellent. How about the ability to replay voice sounds (or any sounds, for that matter) during rollback? (via a button near the text box)

I think you're misunderstanding how Ren'Py's rollback feature works. When Ren'Py performs a rollback, the entire state of the interpereter reverts to a prior state. So once a rollback is performed, the system has no knowledge of the future anymore.

So Ren'Py will not behave any differently on a rollback and a roll-forward. If voices play the first time through, they will play again when the statement executes again on a rollback.

This same thing applies to menus and the like. Without any knowlege of the future, it's impossible for Ren'Py to force a menu to have the "same" choice... what would that same choice be?

If I do ever get around to implementing readback, it will be without voice support, and quite ugly. (For various reasons. Rollback is just so much cleaner with this sort of thing.)

I think I remember reading that you can re-map functionality... does that apply to this as well?

Yes. Read about config.keymap. Please note you'd have to provide the user with an alternate way of hiding the game menu.

Excellent. On a related note, how about a Marquee/Vignette option that would display part of a full image, possibly using a "masking" effect. For example, a phone conversation - all of the character's poses could be used, but it would be apparent that the character is not actually standing in front of the player.

I don't know what you mean by this.

[Grey]

Incidentally, I don't seem to be able to hide the textbox on any RenPy games I've played (Moonlight Walks,Sango) with a press of the middle button...I'm running on XP.

Are there any keyboard controls to do it?

[Guest]

Excellent. On a related note, how about a Marquee/Vignette option that would display part of a full image, possibly using a "masking" effect. For example, a phone conversation - all of the character's poses could be used, but it would be apparent that the character is not actually standing in front of the player.

I don't know what you mean by this.

By "marquee", I was referring to the Photoshop term/tool to mean a crop of a master image (displayable). Instead of cutting separate head-and-shoulders graphics for characters, a writer could simply specify a region of the character graphic to be displayed, cutting down on file size overhead.

A "vignette" is like a "marquee", but it has feathered edges... that is, the opacity fades (usually) in an oval pattern from the outside of the specified area to the center of that area. The result is a soft fade from background to image (displayable).

Example of vignette

The vignette would most likely be more graphically demanding than the marquee/crop effect.

A "masking" effect refers to the implementation of either of those two effects as an overlay to the image (displayable) in question. It will look the same, but consist of two elements: the displayable, and the mask above it. The displayable would use the mask's transparency to determine which portions to display, and at what opacity. This would also allow movement of elements within the "masked" area and, potentially, multiple displayables in the same cropped or vignetted area.

Hope this helps clear things up a bit...

P.W.

[PixelWrangler]

...above post here...

Rats. Did it again. My mistake.

P.W.

[PyTom]

Incidentally, I don't seem to be able to hide the textbox on any RenPy games I've played (Moonlight Walks,Sango) with a press of the middle button...I'm running on XP.

Are there any keyboard controls to do it?

There was a bug fix with this around 4.5 or so. Amgine Park, which is based on 4.7, has the fix. I'm considering adding 'h' as a keybinding to hide windows, but that won't happen until at least 4.8.

[chronoluminaire]

I think you're misunderstanding how Ren'Py's rollback feature works. When Ren'Py performs a rollback, the entire state of the interpereter reverts to a prior state. So once a rollback is performed, the system has no knowledge of the future anymore.

So Ren'Py will not behave any differently on a rollback and a roll-forward. If voices play the first time through, they will play again when the statement executes again on a rollback.

This same thing applies to menus and the like. Without any knowlege of the future, it's impossible for Ren'Py to force a menu to have the "same" choice... what would that same choice be?

If I do ever get around to implementing readback, it will be without voice support, and quite ugly. (For various reasons. Rollback is just so much cleaner with this sort of thing.)

Just to add my voice to those who'd like this. I'm incredibly impressed with Ren'Py, astonished by how many features it has and how well you supported, and personally think you jump to implement new features quicker than necessary (i.e. when it's not clear anybody's even going to use it...)

The only feature it feels to me that Ren'Py is missing is readback support. Readback's not just an inferior version of rollback made popular by the vast majority of commercial ren'ai games, but an alternative that would be actively preferred by a number of people.

I have the config.hard_rollback_limit set to 10, but I'd love to have a hypothetical readback_limit set to 9999. Because mis-clicks are one thing, but I don't want people to "just try" an option feeling that they can back up and undo it at any time. I'm not taking away any functionality by denying them rollback, because people can always save when the menu is up. The difference is in how it feels. If a user chooses to save before a decision, that indicates that they think it might be important. It heightens the subjective significance of the player's choices. If they're able to just go "mmm... maybe not, let's just see the other options..." then that leaves the feeling that what choice they actually make doesn't really matter. It decreases the subjective significance of the player's choices.

In my opinion, one of the appeals of visual novels and ren'ai games is that they're like a fantasy life simulator. And the thing about life is, you don't have an undo button. The choices we make in our lives do really matter, and we can't go back and change them. A related aspect is the player's feeling that you've really got some control over the way these characters' lives go. Feeling like you're directing the choices of a character is a powerful involving and immersing factor, making it feel that they have genuine lives which could go either well or badly. Feeling that you can back up and change history reduces the involvement, makes it feel more like you're playing a game or reading a script and less that you're involved in the life of a "real" person.

Now, I'm not expecting to persuade you over to my point of view. I just want to explain it a little so you can see that at least subjectively it's a point of view that makes sense, even if you disagree with it. The thing is if you refuse to implement readback on subjective preference grounds, you force all users of Ren'Py to go along with your opinion on this. (If it's on the grounds of technical difficulty, then that's entirely different and fair enough.)

It's like the annoying_text_cps parameter. I happen to agree with you that it's annoying, and always turn it off in my preferences; but I know there are people writing Ren'Py games who like it switched on and want their games to appear with it. So I applaud you for implementing it.

Sorry, this post has got quite long, and may sound aggressive. I really don't mean it that way; and I am incredibly grateful to you for providing this amazing engine! This also isn't meant to be a suggestion that you should drop your NaNoRenO/IntRenAiMo game to implement it!