Really? Use any base testing RenPy code you have (heck, use one of the demos that come in each SDK such as "The Question"), make a new rpy file with a simple function that includes the operator(s) in it such as (any use of the wildcard operator will do):
def testUltraHack(*args):
return sum(args)
No there is no limitation this small AFAIK. I get also a few more lines(last is 336) with
...
label evening_multi_choice:
scene night_choice
with dissolve
ndpt "{i}It's the night... What am I going to do?{/i}"
if day == 7:
jump day_7party
elif True:
scene night_choice
with dissolve
menu:
"Go to sleep" if True:
ndpt "{i}I'm out, I need to sleep!{/i}"
jump day_select
"Go to the Private Club" if True:
ndpt "{i}I want to hang out a little at the Private Club...{/i}"
jump intro_private_club
label day_select:
if day == 3:
jump day_4
elif day == 4:
jump day_5
elif day == 5:
jump day_6
elif day == 6:
jump day_7
elif day == 7:
jump day_7party
elif day == 8:
jump day_9
elif day == 9:
jump day_10
elif day == 11:
jump day_12
elif day == 12:
jump end_update
label end_game:
return
# Decompiled by unrpyc_1.2.0-alpha: https://github.com/CensoredUsername/unrpycYes. Its based on the last official version 1.1.8, but with the changes in Renpys this years new py3 versions it doesn't work anymore. Its not officially updated since 1. April by the dev.
Why "label day_select:" appears twice?
I solved the problem (at least this time). For some reason, it is on Windows that the writing of a large file can stop before it ends. It has something to do with the buffer. On linux, everything works fine without changes.
Well, I checked this piece of code. Nothing is deleted. the operator both was and remained after decompilation. At the expense of "has" - I'm still deciding.
My fault.
A copy and paste mistake. Original its just one time there.So i was wrong, as there is a limit of sorts. At least on Win. But why? And can we increase the buffersize with python somehow...I solved the problem (at least this time). For some reason, it is on Windows that the writing of a large file can stop before it ends. It has something to do with the buffer. On linux, everything works fine without changes.
Strange. I did also check multiple files if there the asterisk sometimes missing is, but no.
I did try to understand the unrpyc code for this, but was too dumb so far.
Well, I just set the value to 0. if set any other value, then the number of rows will either be the same or even less. Another question is why the dump comes out all if the file is opened for it the same... Illogical...
It is written in the unrpyc itself and the author decided to use it wherever possible.
The buffering arg shouldn't do anything against this error. Its just the chunksize for reading and not for the filesize AFAIK:
By the way: in this is the codecs module not needed i think. Another import less we need.("codecs" is fairly large) UsingTaken from: https://docs.python.org/3.10/library/functions.html#open said:
with open(out_filename, 'w', encoding='utf-8') as out_file: should be enough. In my newest expermental version i use now evn the pathlib variant: with out_filename.open('w', encoding='utf-8') as out_file:Why illogical? Its different functionality which outputs the content. For dump its
astdump.pprint() which goes in astdump.py and the other is decompiler.pprint() which goes in the init.py. In there should be your difference to find.
But it does. Why? It's a difficult question that I don't have an answer to.
Because I was expecting a cropped file in both modes. It is quite strange to see when a smaller file cannot be fully printed, but a larger one can.
Yes, I already know about this problem, but I haven't posted a fix yet, it will be later, along with others.
Something strange is going on with this bug. I feel the problem comes from something else, but is somehow accidentally affected if you switch the buffer of.
Maybe the AST needs to be cast to dict state, before you access it as dict...? Just thinking.
I just put an attribute check. This piece of code is needed only if not recompiled files in 8 engine with py3.
But just why is it not there when running on linux? This moment is even more embarrassing.
I found a more accurate place that puts a stick in the wheels. I even found a place where I need to fix it (I hope I did it right. I haven't tested it on earlier engines yet). If you're interested, everything is already in the dev branch.