Regarding un.rpyc problem :
[...] But well, the more I look at what's uncompiled, the more I assume that un.rpyc isn't really in fault here. They used a really dirty way to do things, and it seem logical that un.rpyc isn't really able to understand every lines.
I change my affirmation, it's un.rpyc fault. I used it on a game (
You must be registered to see the links
) using my string patching extension to Ren'py ; so a game using user defined statements.
un.rpyc was able to uncompile the line opening the block, but not the content of the block. And, after taking a closer look at what it return with the previous game which take it at fault, the problem is the same. There's user defined statements opening a block, which are correctly recognized by un.rpyc, but they are followed by an empty block, because un.rpyc failed to recognize its content.
Can't say for the other game, but for my extension, it's probably because the said content isn't statements (like it's for Ren'py blocks like "menu" by example), nor properties (like it's for Ren'py blocks in screens). un.rpyc seem to hook itself to Ren'py AST, and like these lines aren't part of the AST, they don't trigger un.rpyc which end with nothing to fill the lines.
It will happen with few games only, since user defined statements (whatever they are done right or not) are an exception, but I think that it need to be know.