Ren'Py Ren'py 'screen is not known' error persistently crashing my game.

[Deleted member 107261]

delete.

 

[79flavors]

It's almost certainly a

You must be registered to see the links

issue.

Last time I saw this, it was because the author had used variant "large" and variant "small" without also having a variant "medium". It worked fine on some android devices, but not others (basically, dependant on screen size).

A better solution is to have two versions of the screen. One with any variant "small" and one without a variant parameter at all. That way, "small" will be used on a small hand held device like a phone of small tablet and the full sized/default version will be used everywhere else (like desktop PC's, larger tablets, etc).

Obviously, it you really do want to create separate variations of the screen for "small", "medium" and "large"... you can. But in that case, I'd still argue it would be better to omit the variant "large" parameter, since large tends to be the version most games are designed for anyway and "no variant defined" version will be used as the default if no better match is identified.

 

[79flavors]

I read over that, however I haven't used "variant" in my code. (Anywhere).
I actually had no clue it existed until a few minutes ago.

Do you think that still applies? As in, should I try adding it to see if if fixes an error?

Sec... Just downloading v0.0.22.2 v0.0.25 of your game.

I did say "almost certainly" because I was half-arsing it and going with the educated guess. Let me look at the code.

 

[79flavors]

As far as the code, ....I could just paste it here for you.

Invariably, something like this, it tends to turn out to be something you're taking for granted.
The number of times I see people reposting "versions" of their code on here... for it only to turn out to be something they didn't post (or more commonly removed, "to simplify the example") is beyond number. Since you've released the game, may as well look at the whole thing.

As for the variant thing... it's more like this:

screen pichi_sit_npc():
    imagebutton:# the rest has not been changed or altered for some time.
        xalign 0.4
        yalign 0.28
        idle "pichichar/pichi_sit_1.png"
        hover "pichichar/pichi_sit_1_hov.png"
        action [Hide("pichi_sit_npc"),Call("pichi_events_storypoint_3")]

screen pichi_sit_npc():
    variant "small"
    imagebutton:# the rest has not been changed or altered for some time.
        xalign 0.4
        yalign 0.28
        idle "pichichar/pichi_sit_1.png"
        hover "pichichar/pichi_sit_1_hov.png"
        action [Hide("pichi_sit_npc"),Call("pichi_events_storypoint_3")]

Where somehow the "small" version of the screen is different from the normal version of it.

 

[79flavors]

Do you have a save file, just before this error occurs?

Because.. yeah... at first glance, it looks fine.

 

[79flavors]

[...] I've tried deleting .rpyc files.

As a side note to all of this, deleting your .rpyc files is a BAD, BAD idea.
The RPYC files contain a cross reference of every single line of code in your game and where to find each line.
It's how the game continues to work, even if you add, edit or delete lines.
If you delete the RPYC files, there's a really good chance your save game files will cause your game to crash when it can't figure out where it's supposed to be continuing from.
RenPy is pretty good at figuring this sort of stuff out... but if you ever end up with players saying "My save files don't work any more"... it'll be because you deleted some RPYC file(s).

As for the basic problem, I don't see why screen pichi_sit_npc() would never be found.
I did wonder briefly if you had some other screen component (like the quick_menu) that was failing on android, but that doesn't seem like the case.

I tried small, medium and large variant tests... all fine with vers 0.25 of the game.

You're coding your screen usage as (sort of):

    show screen whatever
    $ renpy.pause(hard=True)

... which will cause issues when people use the [SKIP] key. But I don't see how that would cause the "screen not found" error.

Normally you should code:

    call screen whatever

... which is pretty much "show this screen and wait until the player does something that triggers an action". Usually a screen coded to do this would also include modal True to force RenPy to only allow the player to interact with THIS screen and no overlapping screens. Though it's not clear to me if recoding would work here, as you seem to have places in the code where you show multiple screens before the player interacts with them.

The problem with the renpy.pause(hard=True) is that it doesn't stop the game continuing. The game will be fine as long as the player clicks on something which has an action - but other elements (like SKIP) will just cause the game to carry on... the game will just continue to the next line of code, and you'll get all sort of unexpected things happening (like seeing the same scene/dialogue over and over again or something seemingly happening out of sequence).

Meanwhile, I'm not making any obvious inroads on your original problem - so I'll see if a night's sleep clarifies things.

 

[anne O'nymous]

You're coding your screen usage as (sort of):

    show screen whatever
    $ renpy.pause(hard=True)

... which will cause issues when people use the [SKIP] key. But I don't see how that would cause the "screen not found" error.

I also don't see why it can be the cause, but isn't to what the traceback is pointing ?

If you look at it, it say that the error happen after this chain of event:

code/events/get_magun.rpy:29
code/recaps/ryoko_recap.rpy:29
code/zones/tower.rpy:397
code/zones/lull_forest.rpy:69 (8 times)
code/zones/tower.rpy:397
code/zones/tower.rpy:388

Then if you put those lines in regard with the code, you found this:
code/events/get_magun.rpy:29
code/recaps/ryoko_recap.rpy:29
code/zones/lull_forest.rpy:69
code/zones/tower.rpy:397

    $renpy.pause(hard=True)

All following a "faked call screen".

Then finally the faulty line,
code/zones/tower.rpy:388

            show screen pichi_sit_npc

If you look at how the code access to "the_tower2", that is the label where the fault appear, a grep tell me that there's 22 access from a label (jump the_tower2) against 4 from a screen (Jump( "the_tower2" ) ).
If the problem was directly linked to the screen (something that would make it invisible to Ren'py for some reason), the error should be triggered every single time. If it was something that would force Ren'py to loose its memory (making him forget that the screen exist), the error should be triggered under whatever circumstance after a given number of times or actions.
Yet apparently it happen only in a particular circumstance that imply a (too big ?) stack of pause.

It don't tell why the error happen, but from my point of view, it say that it happen because of the way screens are handled.


AgentH since you seem able to reproduce the error, try to simply change the following lines:
code/zones/tower.rpy:388
from show screen pichi_sit_npc to call screen pichi_sit_npc.
code/recaps/ryoko_recap.rpy:28
from show screen ryoko_replay_scenes1 with dissolve to call screen ryoko_replay_scenes1 with dissolve.
code/events/get_magun.rpy:29
from show screen grimmlying with dissolve to call screen grimmlying with dissolve.

Then follow the path to the error, to see if it still happen.

 

[79flavors]

Something else... and again, I can't say it's related to the crash... but it doesn't look right.

Your actions for screens like pichi_sit_npc are using action Call().

screen pichi_sit_npc():
    imagebutton:
        xalign 0.4
        yalign 0.28
        idle "pichichar/pichi_sit_1.png"
        hover "pichichar/pichi_sit_1_hov.png"
        action [Hide("pichi_sit_npc"),Call("pichi_events_storypoint_3")]

But then when things pass control to label pichi_events_storypoint_3, the code there doesn't behave like a "called" label.

Instead, depending on the story progress, it shows new screens and/or jumps to label the_tower2.
... and it's the jump back to label the_tower2 that makes me say "doesn't behave like a 'called' label".

Once back to label the_tower2, the various conditions will result in screen pichi_sit_npc being shown again... leading to another Call... and so the looping continues.

I don't think you meant action [Hide("pichi_sit_npc"),Call("pichi_events_storypoint_3")]
I think you wanted Jump instead.

So action [Hide("pichi_sit_npc"),Jump("pichi_events_storypoint_3")].

Call and call label are "jump to label and then when you encounter a return statement, return to where the call was made from.

To track things, programming languages (like Python and RenPy) use something called a "call stack". Each time a call statement is run, the line identifier (where the call statement was run from) is added to the call stack. Each time a return statement is encountered, the latest entry of the call stack is removed and program control is passed back to that calling line.

And before it becomes too confusing, I'll quickly say call and call screen are COMPLETELY different things.

What MIGHT be happening to your game on android is that long term players who've been in and out of the tower A LOT (or similar situations) have put so many entries onto the call stack that the memory used by the game is being somehow corrupted. PC's with a lot more memory and better memory management would take much longer to get into a pickle like this (assuming I'm right).

The error log seems to point to this, with both lull_forest.rpyc line 69 and tower.rpyc lines 397 and 388 appearing multiple times - strongly hinting that there is some sort of inadvertent uncontrolled looping going on.

I've only played your game for about 10 minutes and the call stack already looks like this:

Spoiler: My current call stack for your game

You don't have permission to view the spoiler content. Log in or register now.

My temptation is to say swap those action Call() to action Jump(). Except, you genuinely have labels which are called (label switch_battle_mode: for example). So since you have a mix of usage, each action would need to be reviewed independently, in it's own right. Simply put... if it's supposed be "go and come back"... then it's call (or Call()). But if it's supposed to be "go and never come back", then it's jump (or Jump()).

Plus IF it is all a result of a overwhelmed call stack... then you'll have players out there with save files that include that corrupted data. Just fixing the code won't repair that - it'll just stop it getting worse.

 

[anne O'nymous]

The error log seems to point to this, with both lull_forest.rpyc line 69 and tower.rpyc lines 397 and 388 appearing multiple times - strongly hinting that there is some sort of inadvertent uncontrolled looping going on.

It's the line 69 that puzzle me, especially put in perspective with what you said about the called labels.
lull_forest.rpy:68-70

    label lull_f_1:
    $ renpy.pause(hard=True)
    return

But this label is only jumped to, and as far as I saw, never from one of the many called labels.
And why is this particular pause 8 times in a row the last line where Ren'py was before it branched to another label ? That what the traceback show, but looking at the code I failed to see some logical reason for that.

For anyone who's interested, I got the list by using the following command in the developer console:
for i in renpy.game.context().return_stack: print i

You can also keep a quick look on the stack from the console with:
watch renpy.call_stack_depth()
At anytime you'll see the number of entries in the stack, what will tell you if you broke a call chain somewhere.

 

[Deleted member 107261]

Rar necro-post!

So after much toil and tribulation, it's still fucking broken.

I have narrowed it down a bit though.
1) Android Emulation works fine. This leads me to believe that the issue is with the way Ren'py is handling the process of building to Android. This is supported by some messages I see occasionally when building.

2) I have also removed the possibility that it's related to my code entirely. (Seriously, I deleted the entire segment of code where this issue occurs, and the game still crashed entirely (no errors this time), however it's always during the same exact issue.

3) This does not seem to be a problem in any other Ren'py games I've coded / created however. So that makes things less clear.


Honestly... I'm seriously considering just not even using Android.

The Ren'py help channel has not been so helpful, in fact no one there seems to have any insight as to why this is happening either.

Therefore, I have resurrected this post in one final attempt to fix this phantom error (if possible).

Is there anyway to fix the rapt/ gradle version that Ren'py is packaged with?

That's the last thing I'm interested / willing to try before I just say fuck it entirely.

 

[renarai]

anyone know?how to solve it

 

[anne O'nymous]

anyone know?how to solve it

Update your GPU/Video card drivers.

If the problem persist, when launching the game, keep SHIFT pressed until you see the renderers selection screen, and choose "Angle".