Currently unsupported ren'py features

[CensoredUsername]

Going through the changelogs since I've worked on this, the following things might need additional unrpyc support:

7.4.0:

• [x] define statement can use += or |= update operators.
• [x] audio statements got a new volume clause?

7.4.1

• [x] say statement gained ID clause

7.4.6

• [x] camera statement

7.5

• [x] a block can be included as part of an ATL interpolation
• [x] show/hide/call screen take an expression modifier
• [x] add takes an alt property

7.6 / 8.1

• [x] _ren.py files
• [x] show screen/hide screen/call screen can now take expression, as, onlayer, zorder and with clauses.
• [x] screen for loop now supports continue/break
• [x] rpy monologue none statement
• [x] triple quoted strings can be used in screen language
• [x] screen language can have both an at property and at transform statement

7.7 / 8.2

• [x] rpy python [future]

[CensoredUsername]

Implemented define operators. audio statements are UserStatements, so those didn't require any special handling. The rpy python statement was a simple one so just added that as well right now.

[madeddy]

7.4.6

* [x]  camera statement

7.6 / 8.1

* [x]  screen for loop now supports continue/break

Don't forget i have them in my forks statements branch. Easy stuff i'd say and the camera i could even verify in @Gouvernators fork. He has also other useful code snippeds. Oh. Are they py3 renpy only? Then it's just for later.

[CensoredUsername]

Both are still needed for 7.x support, but yeah, low-hanging fruit. Added camera, and show/hide/call screen are UserStatements so no work needed there. I'm just going through the changelog and other branches systematically to try to get everything and the cleanest decompile. For instance, that's why my Camera impl has the layer name as optional.

[CensoredUsername]

add is a sl2 keyword and uses the default parsing logic for that, so no change needed to support extra properties there.

at transform: going on the same line seems to be cosmetic. But it's likely to interact with the already existing at transform: bug, so let's just handle that there. Triple quoted strings in screen language also shouldn't affect anything, seems to just be lexer work that was needed for that, and we'll just get it as a PyExpr anyway, and we keep track of emitted newlines through those.

[CensoredUsername]

rpy monologue none is a doozy. Adding that to #99 . Issue is that this directive doesn't make it into the AST, but it does influence how things after it get parsed. So if it is used, and after that a say statement is used that normally would be interpreted as monologue mode, that wouldn't be the case. But in our decompiled file, it now would be interpreted as monologue mode, because we lack the parser directive. To work around that, we'd likely have to make it so that we always emit a rpy monologue none statement, unless we're sure it hasn't been used.

[CensoredUsername]

_ren.py files likely don't require any special handling, as the engine transforms them in memory to equivalent .rpy file with supposedly identical line numbers. This means there's no way to know which it was at the start, but we'll at least be able to decompile it to an equivalent .rpy file that will generate the same .rpyc file.

[madeddy]

_ren.py files likely don't require any special handling

Yeah. The docs sound like it. Gives me the vibe it's more a fancy thing for some people with just a little bit usefulness.

rpy monologue none is a doozy.

While i see the usefulness for game devs, does it sound really annoying to decompile. Or? The docs make it sound as if it's more a writer's helper and the engine makes multiple single line statements out of it.

...it's likely to interact with the already existing at transform: bug...

Thought also this crazy thing could maybe be related. I'm really curious to see what you find out about it.

[CensoredUsername]

While i see the usefulness for game devs, does it sound really annoying to decompile.

It is confusing to decompile, because you don't know if it has been used, and the default is double.

So imagine a file like

rpy monologue none

character """This might seem like multiple sentences

but it actually ends up in a single textbox"""

if we'd simply just dump what we see back, the decompiled result would be:

character """This might seem like multiple sentences

but it actually ends up in a single textbox"""

As you can see, the monologue directive is lost now (because it is purely a parser directive, that doesn't generate an AST node). As the default mode is double, This now gets split by monologue processing into two different say statements by ren'py, which is incorrect.

[CensoredUsername]

Say statement ID clause support added as well. With a bonus that such a new feature already has two different ways of handling it to be backwards compatible.

[CensoredUsername]

ATL simple statements being able to have a block instead of putting everything on the same line seems to be a cosmetic feature as well. Nothing due to it remains available in the AST except for the occasional line number for some (but not all) properties.

[CensoredUsername]

Moved the cosmetic issues to #178, moved cosmetic things to another tasklist issue, and rpy monologue none has its own issue.

[madeddy]

As you can see, the monologue directive is lost now ...processing into two different say statements by ren'py

So if i get this right do the files have no sign it was a monologue in multiline, or?

• How does Ren'Py knows then if the engine also just reads the rpyc?
• The only possible way i see is, if you have more as one line with say stmt from the same char following each other. Could this be used as indicator? It could also be a mistake if this say stmt where never a monologue...

ATL simple statements ... have a block...seems to be a cosmetic feature as well.

Agreed. By chance i read this in the docs just a few hours ago and thought it's just what i call a writers help. Means a alternative for devs. In this case for people who like the block way.

[CensoredUsername]

How does Ren'Py knows then if the engine also just reads the rpyc?

It doesn't need to know. The RPYC contains the statements post-splitting by monologue processing.

The only possible way i see is, if you have more as one line with say stmt from the same char following each other. Could this be used as indicator? It could also be a mistake if this say stmt where never a monologue...

I'll have to check how ren'py encodes the strings in the say statement again. If we're lucky, we can distinguish between stuff like "this is the first line \n\n and this is the third" and

"""this is the first line

and this is the third"""

Presence of the latter one in a single say statement indicates monologue mode needs to be disabled.

In this case for people who like the block way.

Or those who don't want a 300-long line due to a lot of spline knots ;)

[madeddy]

Or those who don't want a 300-long line due to a lot of spline knots ;)

LOL. Nice point. I happen to be one of these where the code line should end with a 100 chars. And segmenting this in a multiline block looks nicer and more usable to me.