Ren'Py (solved) ScriptError: could not find label 'start'.

[plentyfucksgiven]

I'm running linux, which might possibly matter.

In irregular intervals, I stumble upon games (straight from the dev, no compressed versions/repacks) which fail to start using the shell script with the bundled renpy. I assume the latter being different/the culprit. I have a renpy sdk for 7.x and 8.x and using the matching one, the games start fine.

Today, it's Eternum - doubt the game doesn't start for other people (this holds true for at least for the windows players, otherwise there would be posts about it).

I'd like to stop using the workaround and understand the issues. Of course, the label exists - I can also unpack the rpa.

The traceback:

I'm sorry, but an uncaught exception occurred.

While running game code:
  File "renpy/common/00start.rpy", line 283, in script
    python:
ScriptError: could not find label 'start'.

-- Full Traceback ------------------------------------------------------------

Full traceback:
  File "/home/user/games/Eternum-0.7.5-pc/renpy/bootstrap.py", line 326, in bootstrap
    renpy.main.main()
  File "/home/user/games/Eternum-0.7.5-pc/renpy/main.py", line 617, in main
    run(restart)
  File "/home/user/games/Eternum-0.7.5-pc/renpy/main.py", line 148, in run
    renpy.execution.run_context(True)
  File "/home/user/games/Eternum-0.7.5-pc/renpy/execution.py", line 922, in run_context
    context.run()
  File "renpy/common/00start.rpy", line 283, in script
    python:
  File "/home/user/games/Eternum-0.7.5-pc/renpy/script.py", line 918, in lookup
    raise ScriptError("could not find label '%s'." % str(original))
ScriptError: could not find label 'start'.

Linux-6.9.2-arch1-1-x86_64-with-glibc2.2.5
Ren'Py 7.4.6.1693

 

[guest1492]

I have no idea why, but I find the file path suspicious: "renpy/common/00start.rpy"

All the other paths specify the renpy folder inside the Eternum folder.

 

[GNVE]

Well the game starts with the start label. It seems you have deleted it. Put label start: at the beginning of your script. (and end with return).
If you are unsure make a new test game and look at how it is done there in the script file.

 

[plentyfucksgiven]

Well the game starts with the start label. It seems you have deleted it.

No. I did not modify the game files. Mentioned label is at line 599 in game/script.rpy.

You did read that a) the game starts fine using the sdk and b) that I did not write a game on my own?

 

[peterppp]

have you compared the .sh files of games that work with games that don't work? are they exactly the same? i doubt the devs change them but perhaps there is some difference due to renpy versions or something

 

[plentyfucksgiven]

Not yet. I'll have to find two comparable games, though (means at least another game with the same renpy version - I already know which file to check, but I need to unzip them).

 

[osanaiko]

almost certainly nothing to do with linux.

if the dates on the RPYC files are newer than their RPYs, then it might be running "complied" code that is different to what you see in the rpy files.

Otherwise, something is seriously wrong with your installation of the game. try downloading the archive again.

maybe also check that nothing (antivirus?) is quarantining anything.

 

[plentyfucksgiven]

tl;dr: Yes, it was me. Though I'm not sure why it didn't always hit me. I create a symlink to where I store the game's archives (for easier access and installation of wtmods and stuff), scripted (yes, I've written scripts to extract games).

This symlink, with the same name as the game (derived from the file name semantics here), seems to break game file discovery in some cases. Sad part is: I already found that out once, but did nothing (wtf, me) about it, and then forgot about it. And now I look a little stupid, but that's okay.

And I already typed some responses, so there they are.

almost certainly nothing to do with linux.

I already had game devs which had no clue of linux specifics (not to blame them, we're a niche) and packing games in an incompatible way. Most errors get detected quite early (upper/lower case mismatch between files and code) or left uncommented but fixed on their own (execution bit), so although it's a small player base, I thought others would write something about the game "not running".

if the dates on the RPYC files are newer than their RPYs, then it might be running "complied" code that is different to what you see in the rpy files.

That's what I already assumed once, but I had a) fully rpa-packed games (like Eternum) and b) removed those compiled files (earlier attempt to fix it, a while ago). I just listed the contents of the zip to verify that first claim and found some files in game/cache (*.rpyb), which weren't the cause either (was already happy for another clue...).

Otherwise, something is seriously wrong with your installation of the game. try downloading the archive again.

No, I don't think so. There must be some systematic error in a situation most people don't create. I had a bunch of those "broken" games which work just fine when run with the SDK - and broken zips usually cannot be fully extracted. Creating the same error with some misplaced bits within the usual game sizes is way beyond realistic - I should play some lotto then.

maybe also check that nothing (antivirus?) is quarantining anything.

No such thing here.

Just had a deeper look at the renpy files and printed the labels from the namespace. Doing this in the SDK leads to game/script.rpy keys, while the "corrupted" renpy doesn't have those. So basically it can't resolve the game files.... [and then I started to debug renpys script.py; cont at top]

 

[79flavors]

[...] and b) removed those compiled files (earlier attempt to fix it, a while ago).

I would highly recommend NEVER deleting .rpyc files, if those are the ones you mean.

Basically - as soon as you delete .rpyc files, you massively increase the chances that your save files from previous playthroughs won't work. It's possible to fix things, but it's easy to make things worse with well intentioned advice.
(a little more info from a previous post of mine).

Removing the .rpa files after you unpack them is a good idea (not least, because of the amount of disk space usually freed). They aren't needed once they're unpacked.

 

[plentyfucksgiven]

yep, I caused such a problem - although not on the rpyc files, but on the (pickled) save files. I loaded (and stored) savegames using my SDK@7.6.2, and going back to 7.6.1 (I believe this was the bundled renpy) didn't work, and caused further issues along the way. I was able to go back, but I wouldn't recommend that switch

 

[Furiousrawrr]

yep, I caused such a problem - although not on the rpyc files, but on the (pickled) save files. I loaded (and stored) savegames using my SDK@7.6.2, and going back to 7.6.1 (I believe this was the bundled renpy) didn't work, and caused further issues along the way. I was able to go back, but I wouldn't recommend that switch

I have same problem how to fix this?

 

[plentyfucksgiven]

What exactly did you do? I can't run you through a possible solution without knowing what you changed/did (I did several things back then, see above).

 

[peterppp]

What exactly did you do? I can't run you through a possible solution without knowing what you changed/did (I did several things back then, see above).

i dont think it's related to your problem.
https://f95zone.to/threads/when-i-s...cripterror-could-not-find-label-start.240551/

 

[plentyfucksgiven]

Oh, I know the start label problem and it lead me to using a different renpy installation (Furiousrawrr - read the thread, before doing the same) - I might have misinterpreted the "I have the same problem" stage, but we had the same root cause to start with (though I found mine above - which should be highly specific). If he for whatever reason overwrote the renpy folder with another renpy installation, that puts him in the same place as me after doing similar things - a bad place to be (savegame incompatibility and the neccessity to retrace steps).