Ren'Py Gripes

[Kia]

As a workaround, you may use a version manager and tell the version manager to ignore the .rpyc files.

I do that on whole projects, but often I work on small scripts that don't warrant a repo, or the receiving party doesn't use one. Zipping a folder to send sometimes is the easiest way.
Although, it's not always when I send something that .rpyc files are in the way, when a project has tons of script parts, those rpyc files are always in the way too.

[PyTom]

Another possibility to streamline it just a step further, if it's not already in use, might be {{double braces}}?

Code: Select all

{{日本語|にほんご}}

Hm.. would it make sense to use one of the full-width braces for this? Like ［日本語|にほんご］, or something like that? Ren'Py doesn't use any of the fullwidth character space, and for this one use, it might make sense - if it's easy to type and not confusing.

[Kaji]

Another possibility to streamline it just a step further, if it's not already in use, might be {{double braces}}?

Code: Select all

{{日本語|にほんご}}

Hm.. would it make sense to use one of the full-width braces for this? Like ［日本語|にほんご］, or something like that? Ren'Py doesn't use any of the fullwidth character space, and for this one use, it might make sense - if it's easy to type and not confusing.

If possible, that would be ideal! I'd assumed it was out because of variable substitution, but if it can make exceptions when it detects fullwidth characters, that really would be the most natural (and simple) way to represent it, possible

[Kaji]

On that note, just thinking about other possible use cases where it might come up...

Korean: [한글|hangul]
Chinese: [我|wo3]
Japanese: [東京|Tokyo] <- Taking an example from the documentation page on Ruby text

So we may want to have it check for an initial fullwidth character (or fullwidth up to the |pipe|) and then just assume anything after the pipe is the annotation, regardless of its encoding.

Sorry if stating the obvious here, just want to help ensure this isn't going to cause problems for other projects down the line.

[PyTom]

Fullwidth square brackets are different than half-width ones, so that's not a problem. I'd probably just use full-width left square bracket to enable ruby mode, and full-width right square bracket to end it.

I'm just wondering if there are any brackets that might work better. "【東京|Tokyo】", for example. I don't have a good feel for how easy or hard these are to type compared to the usual full width forms. "［東京|Tokyo］" Since this is something that might show up a lot, I want to make sure it's typeable.

Full-width braces could also work, and might be the best choice.

"｛ 東京｜Tokyo ｝"

[Kaji]

Ah, yeah, if we're using full-width brackets then that will certainly help to keep things separated. Might want to also allow the full-width pipe character ｜ as a divider as well then. That'll allow someone typing things up to not have to switch between keyboard layouts when they're typing.

Stylistically, I personally have always preferred the heavier brackets that Japanese has available: 【東京｜とうきょう】. Their weight really helps with readability because of how they visibly isolate things from the text. It's also what Japanese dictionaries typically use when putting the reading after a kanji headword (e.g. 東京【とうきょう】). So there's a nice consistency in that regard as well.

Testing Chinese and Korean keyboard layouts, it seems that (at least, based on OS X's keyboard layouts) Chinese has them 【中文｜zhong wen】, while Korean doesn't even seem to do full-width punctuation. But then, modern Korean virtually never uses Hanja, so that likely won't be much of an issue.

Based on that, my vote would be for 【東京｜とうきょう】as the format.

[PyTom]

Okay, go with 【東京｜とうきょう】 as the syntax, unless there is some sort of implementation problem.

[Gouvernathor]

+1 for bold-looking punctuation rather than characters which could get visually confused with others.

[dragondatingsim]

I'd like to propose to change the way image alignment in text works. Being able to customize how and where images are aligned in text (such as middle or bottom of text line instead of top) would make this feature much more flexible to use.

Relevant thread: viewtopic.php?f=8&t=66067

[m_from_space]

@Pytom:

In Ren'Py 8.0.3 the difference between using "blur" as an ATL transform property and using im.Blur() is huge. The latter is way better in achieving an excellent result, while "blur" makes images semi-transparent on the edges and creates artifacts. Will this change in the upcoming release? The documentation states:

Code: Select all

im.Blur(im, xrad, yrad=None, **properties)
    ...
    The same effect can now be achieved with the blur transform property.

That's not the same effect at all, even with similar blur levels (as far as my eye can compare it).

[Kaji]

Hi, Tom! Getting ready to work on another new batch of Japanese scripts, so I was just wondering if there was an ETA for an update including the furigana syntax we discussed back in December so that I can plan accordingly.

Thanks!

[PyTom]

Hi, Tom! Getting ready to work on another new batch of Japanese scripts, so I was just wondering if there was an ETA for an update including the furigana syntax we discussed back in December so that I can plan accordingly.

Thanks!

Real soon now.

[Kaji]

Hi, Tom! Getting ready to work on another new batch of Japanese scripts, so I was just wondering if there was an ETA for an update including the furigana syntax we discussed back in December so that I can plan accordingly.

Thanks!

Real soon now.

Looking forward to it! From the practical tests I've done with it, it really does a lot to improve the overall readability of the code files for those scripts.

[Kia]

A children_align for screen elements would be nice, specially for boxes and grids. I often put a handful of buttons in a box and wish for an easier way to align them than adding align to each individually or creating a new style for them.
By the way, the new changes are awesome, I've read the changelog and will be trying them soon.

[trailsiderice]

the lack of an "on click" function for ATL, or a "pressed" button state.

this frequently annoys me. It feels like a very basic feature that's missing. it makes animating a text or image button on click nigh impossible.