Ren'Py Help with building distribution

[DarkLoki]

So, I could really use some help if you please, maybe someone else has or will have the same issue.
I am building a standalone mod. I deleted the images.rpa, told the SDK to delete all persistent variables and went to town. My build runs just fine but when I build a distribution, and try to run the distribution on a clean PC, it tells me it can't find an image. I replaced that image with another and changed it in the code.
I've searched with multiple text editors including Notepad+ but cannot for the life of me find where the old image is referenced. The main difference is I changed it from a .png to a .webp
I could easily change it back to a png, but then I wouldn't learn anything and who knows what other images are messed up.

Like I said, the development version works fine, it's the new distribution that I make that has errors.

Another thing I was curious about, even though I worked on this this morning, the distribution says the executable was last modified in 2015. Just wondering about that, more concerned about what's going on with the images. Thank you in advance

 

[osanaiko]

image files can be referenced in various ways, including variable substitution, as well as the helpful but perhaps too magic "auto loading". Renpy docs are often obtuse and lack help examples, but do reward re-reading when you are stuck.

You must be registered to see the links

Does the place where the running game informs of the missing image not help track it down? what is the error message, if any? how about the log file?

Also consider searching for substrings of the full image name (dropping the extension at least) if you haven't tried that yet.
Other places to look could be screen definitions, or styles, or any of the more funky Displayables (layeredimage, conditonswitch, alphablend etc)

 

[DarkLoki]

image files can be referenced in various ways, including variable substitution, as well as the helpful but perhaps too magic "auto loading". Renpy docs are often obtuse and lack help examples, but do reward re-reading when you are stuck.

You must be registered to see the links

Does the place where the running game informs of the missing image not help track it down? what is the error message, if any? how about the log file?

Also consider searching for substrings of the full image name (dropping the extension at least) if you haven't tried that yet.
Other places to look could be screen definitions, or styles, or any of the more funky Displayables (layeredimage, conditonswitch, alphablend etc)

Thank you for the reply.

I will look into some of the things you suggested further, but in this case there is no substitution, object or class.
it is a straight statement.

I will post sample code etc when I get back to the machine.

 

[gojira667]

Have you run Lint in the SDK? It will catch simple cases of this.

 

[anne O'nymous]

I am building a standalone mod. [...] but when I build a distribution, [...]

Things don't add up here. Either it's a standalone mod, or you build a distribution because it's a game, but it can't be both at once.

[...] it tells me it can't find an image. I replaced that image with another and changed it in the code. [...)

How replacing the image will make Ren'Py suddenly find it ? Or have you replaced the image before the error happen ?

[...] cannot for the life of me find where the old image is referenced. [...]

As Osanaiko said, it's because there's probably none.

The main difference is I changed it from a .png to a .webp

Ren'Py don't care about the file extension. You can perfectly have an image using the WEBP format while having the "png" extension.

This being said, with an exe from 2015 you're at most with a 6.99.8 version of Ren'Py, therefore it do not support the WEBP format.

Like I said, the development version works fine, it's the new distribution that I make that has errors.

What you want to do really confuse me.
Once again the main issue I have is that you qualify your project as being a mod, more over a standalone one, but everything you talk about point to it being a game.

Just wondering about that, more concerned about what's going on with the images.

[A guess, with 75% certitude]
Ren'Py do not find the image, because the, near to 10 years old, version used do not know about the WEBP format. Therefore, while there's a file with the right name, Ren'Py discard it, because it don't have a valid format.

[Another guess, with 20% certitude]
The file have uppercase characters, or an underscore, and you try to address it as it in the code. The auto-referencing translate the name in lowercase and replace the underscores by spaces.

 

[DarkLoki]

Have you run Lint in the SDK? It will catch simple cases of this.

Thank you. I have no idea what LINT is. As I mentioned, my working project runs just fine. It's just a distribution

 

[DarkLoki]

Things don't add up here. Either it's a standalone mod, or you build a distribution because it's a game, but it can't be both at once.




How replacing the image will make Ren'Py suddenly find it ? Or have you replaced the image before the error happen ?




As Osanaiko said, it's because there's probably none.




Ren'Py don't care about the file extension. You can perfectly have an image using the WEBP format while having the "png" extension.

This being said, with an exe from 2015 you're at most with a 6.99.8 version of Ren'Py, therefore it do not support the WEBP format.




What you want to do really confuse me.
Once again the main issue I have is that you qualify your project as being a mod, more over a standalone one, but everything you talk about point to it being a game.




[A guess, with 75% certitude]
Ren'Py do not find the image, because the, near to 10 years old, version used do not know about the WEBP format. Therefore, while there's a file with the right name, Ren'Py discard it, because it don't have a valid format.

[Another guess, with 20% certitude]
The file have uppercase characters, or an underscore, and you try to address it as it in the code. The auto-referencing translate the name in lowercase and replace the underscores by spaces.

Thank you for the reply.

It's a mod because I'm basing it on the original games code. As for the other reasons you suggested, it's specifically states it's looking for the PNG image when I changed it in the code to the WEBP image. I always observe case sensitivity having learned HTML on a Linux box. And there are dozens of other images that I converted that work just fine. And once again, My working files have no problem, it's the distribution that I try to install on a different machine that doesn't run

 

[gojira667]

Thank you. I have no idea what LINT is. As I mentioned, my working project runs just fine. It's just a distribution

Backing up, you have the original game in the SDK? Assuming yes, you do your mod work. The modded files when distributed are added to what exactly? Loose, packed into RPA file(s) or what?

Your mod distribution may be missing a script file or based on the load order, it's preferring the game's un-modded script(s) to yours.

 

[peterppp]

link to the distribution that doesn't work?

 

[anne O'nymous]

It's a mod because I'm basing it on the original games code.

So a not standalone alteration. But well, I'll not starts talking about semantic...

As for the other reasons you suggested, it's specifically states it's looking for the PNG image when I changed it in the code to the WEBP image.

There's only one case where Ren'Py will include the file name when it throw an error (that we still haven't seen despite Osanaiko having explicitly asked for it), and it's when the said file name is explicitly addressed in the code.
But you said that you searched everywhere, using many different tools, and didn't found it. So, where's the truth exactly ?

I always observe case sensitivity having learned HTML on a Linux box.

Good for you that you learned HTML on a Linux box. But well, flexing will lead you nowhere here, especially when answering to someone who learned to code before Linus released the first version of his *nix derived OS.

This being said, what was needed in this particular case was reading abilities. I precisely, and explicitly, said that you must not follow case sensitivity when it come to auto-referenced images.

And there are dozens of other images that I converted that work just fine.

Then the exe timestamp isn't dated from 2015 ; WEBP support appeared with the version 6.99.12, that was released in December 2016. Or you seriously messed somewhere.

 

[79flavors]

I am building a standalone mod.

Based on other replies in this thread, I'd probably categorize your work as a "fan remake".
It sounds like you've taken the original game, removed parts of it and reworked those missing pieces to create something new.

A "mod" is more "leave the original game alone, but use code to override what it does".
The main feature of a mod is that if you remove it, the original game still works as originally intended. (Although save files wouldn't work).
None of which is really important, beyond that if you say "I am build a standalone mod", it creates certain expectations for those of us trying to help.

I deleted the images.rpa, told the SDK to delete all persistent variables and went to town.

A few things to talk about here.
You don't need to worry about persistent variables. When you build a new distribution from the RenPy Launcher/SDK, it is built without persistent files. Each distribution is a brand new start.
Persistent data will still exist on a player's computer once they've played the game, but that will be within the /saves/ folder (and the copy stored in C:\Users\{user}\AppData\Roaming\RenPy\{gameid} for Windows users).

I personally would not have deleted the images.rpa file until you'd unpacked it. In fact, that's true of all the .rpa files.

To convert a fully running, existing game into a version that can be worked on with the SDK, I would do this:

• Unzip the original game to your normal "RenPy games" folder.
• Use UnRen to unpack the game. (Works most of the time).
• If the unpacked version of the game only has .rpyc files, use UnRen again to decompile them into .rpy files. (Again, works most of the time).
• Delete all the .rpa files, now that UnRen has unpacked them.
• Create a new project within the RenPy launcher, to match your game's name. (If the original game was "Brave New World", then call it something like "Brave New World Fan Remake").
• Exit the RenPy Launcher (and any editor you are using).
• Delete the /game/ folder in the SDK's development folder (wherever you created the project).
• Copy the /game/ folder from the installed game into the SDK's folder (effectively replacing the /game/ folder you just deleted).
• Delete the script_version.txt file from the newly copied /game/ folder. (RenPy SDK doesn't like this file being there).
• Edit at least the build.name within the options.rpy. Probably the config.version too.
• Maybe do a LINT check now. You'll at least learn about all the problems that aren't your fault (but you probably should fix anyway).
• Take a copy of the SDK's folder in this state. That way, if you screw up - you won't need to do all this again to start again.

That's it.
You now have a full copy of the game, with all the game files unpacked in a folder the SDK can recognize. You can work on game to your heart's content. Delete images, rename files, rewrite code. Whatever it is you want to do.

My build runs just fine but when I build a distribution, and try to run the distribution on a clean PC, it tells me it can't find an image.

As other have already talked about, this is where LINT comes in.
LINT is a code checker. It will go through your code and show warnings and errors about anything wrong with your code (like image files being missing).
LINT is available on the main RenPy Launcher screen under [Actions] as Check Script (Lint).

Generally speak, every developer should probably do a LINT check before building a distribution.

I replaced that image with another and changed it in the code.

This sets off alarm bells for me.
A well written RenPy game shouldn't need the images defining within the game itself. RenPy does all of that automatically.
The exception is video and sound files, which need to be named explicitly. But you've been talking about .PNG and .webp files, not video/audio.

RenPy auto-imports all references to images files stored in the game upon startup. It calls them "displayables". An image called ./game/images/testing/thisismyhouse.png will automatically be accessible within the game as thisismyhouse.
The thing that trips up a lot of new developers is that all auto-imported displayables are lower case. So ./game/images/testing/ThisIsNOTMyHOUSE.webp would be known as thisisnotmyhouse. It's why I would usually advise that all filenames (in fact most things in RenPy) be lowercase - since it means you never need to think about it.

Anyway, you're dealing with an existing game, so you're stuck with the original developer's faults and fuckups.

I've searched with multiple text editors including Notepad+ but cannot for the life of me find where the old image is referenced. The main difference is I changed it from a .png to a .webp

My guess is that this is something to do with you deleting the original images.rpy file.
I'm guessing of course, so its likely something else.
LINT will probably point you in the right direction.

I could easily change it back to a png, but then I wouldn't learn anything and who knows what other images are messed up.

You shouldn't need to change them back.

I risk making things worse here... but RenPy doesn't care what the file is called.
You could rename testb.webp to testb.jpg and RenPy will still process scene testb with fade normally (as long as you let RenPy auto-create the displayable name).
RenPy either uses a standard image library that doesn't care, or checks the image file's header.
Which doesn't mean doing that is a good idea. It's just why the "compressed" or "crunched" versions of games work, despite the images being converted to another format.
If it isn't already obvious... Don't do things like this.

Like I said, the development version works fine, it's the new distribution that I make that has errors.

A very unlikely cause is the build.classify sections within the options.rpy file.
If there's something weird going on there, you should notice it very quickly.
(I'm thinking something like there being a line like build.classify('**.webp', None))

Another thing I was curious about, even though I worked on this this morning, the distribution says the executable was last modified in 2015. Just wondering about that, more concerned about what's going on with the images. Thank you in advance

No clue.
It implies that the distribution file you are looking at isn't the the one the SDK generated. But that's a whole new rabbit hole, and somewhat unlikely.
I just built a distribution of an old game I worked on, the .exe file is dated today.

Most of the time, a game written in RenPy an old version of RenPy (for example, 6.7.1) can be rebuilt in the latest version of RenPy (currently 8.2.3). Again, that's not universally true. But "most" of the time. I would generally start work using the latest version of RenPy, regardless of which version the original game used - until something breaks, then I might go back to the original version (or at least the latest version that doesn't break).

What I will ask is....
What game are you reworking?
While we can't see your code. It might help to see how well (or badly) the original game was written.
At the very least, we can see how the original game accesses it's image files.

If I were you, I'd go back and follow my instructions about unpacking the original game into a new SDK folder. Then copy all your current code/images over the top of it. That way, any missing files included in the original game will be there again. Of course, that will then mean a lot of effort to go remove all those .png files again. It would give you a safe/stable starting point though.

 

[anne O'nymous]

It implies that the distribution file you are looking at isn't the the one the SDK generated. But that's a whole new rabbit hole, and somewhat unlikely.
I just built a distribution of an old game I worked on, the .exe file is dated today.

Historically, Window distributions had two executable ; one in the main directory, and one in the lib directory. The one in the main directory had a timestamp at the date of the SDK built, while the one in the lib directory was created when the distribution file was built.
From memory it changed with the 7.3.x branch, the distribution now having only one executable, built with the distribution. Therefore, as I said, if the exe is dated from 2015, it's an old version of Ren'Py, between 6.99.0 and 6.99.8.

But this don't match with everything else he said.
There's no reason to use a so old SDK, even when making a fan version of an old game. As long as it's still one the 7.x branch, Ren'Py backward compatibility imply that any new version of the SDK would works. But building a distribution with such SDK wouldn't lead to an exe dated from 2015.
This while a distribution built through a SDK from 2015 would actually include an exe dated from 2015, but it wouldn't handle WEBP images ;

You must be registered to see the links

, released the 23 December 2016.

Most of the time, a game written in RenPy an old version of RenPy (for example, 6.7.1) can be rebuilt in the latest version of RenPy (currently 8.2.3).

The last release is the 7.8.0/8.3.0 (since few days), and the 8.x branch is to avoid when working on an older game due to Python 2.x/3.x compatibility issues.


By the way, a world will end soon, with

You must be registered to see the links

probably before the end of the year.

 

[DarkLoki]

Based on other replies in this thread, I'd probably categorize your work as a "fan remake".
It sounds like you've taken the original game, removed parts of it and reworked those missing pieces to create something new.

A "mod" is more "leave the original game alone, but use code to override what it does".
The main feature of a mod is that if you remove it, the original game still works as originally intended. (Although save files wouldn't work).
None of which is really important, beyond that if you say "I am build a standalone mod", it creates certain expectations for those of us trying to help.




A few things to talk about here.
You don't need to worry about persistent variables. When you build a new distribution from the RenPy Launcher/SDK, it is built without persistent files. Each distribution is a brand new start.
Persistent data will still exist on a player's computer once they've played the game, but that will be within the /saves/ folder (and the copy stored in C:\Users\{user}\AppData\Roaming\RenPy\{gameid} for Windows users).

I personally would not have deleted the images.rpa file until you'd unpacked it. In fact, that's true of all the .rpa files.

To convert a fully running, existing game into a version that can be worked on with the SDK, I would do this:

• Unzip the original game to your normal "RenPy games" folder.
• Use UnRen to unpack the game. (Works most of the time).
• If the unpacked version of the game only has .rpyc files, use UnRen again to decompile them into .rpy files. (Again, works most of the time).
• Delete all the .rpa files, now that UnRen has unpacked them.
• Create a new project within the RenPy launcher, to match your game's name. (If the original game was "Brave New World", then call it something like "Brave New World Fan Remake").
• Exit the RenPy Launcher (and any editor you are using).
• Delete the /game/ folder in the SDK's development folder (wherever you created the project).
• Copy the /game/ folder from the installed game into the SDK's folder (effectively replacing the /game/ folder you just deleted).
• Delete the script_version.txt file from the newly copied /game/ folder. (RenPy SDK doesn't like this file being there).
• Edit at least the build.name within the options.rpy. Probably the config.version too.
• Maybe do a LINT check now. You'll at least learn about all the problems that aren't your fault (but you probably should fix anyway).
• Take a copy of the SDK's folder in this state. That way, if you screw up - you won't need to do all this again to start again.

That's it.
You now have a full copy of the game, with all the game files unpacked in a folder the SDK can recognize. You can work on game to your heart's content. Delete images, rename files, rewrite code. Whatever it is you want to do.




As other have already talked about, this is where LINT comes in.
LINT is a code checker. It will go through your code and show warnings and errors about anything wrong with your code (like image files being missing).
LINT is available on the main RenPy Launcher screen under [Actions] as Check Script (Lint).

Generally speak, every developer should probably do a LINT check before building a distribution.




This sets off alarm bells for me.
A well written RenPy game shouldn't need the images defining within the game itself. RenPy does all of that automatically.
The exception is videoand sound files, which need to be named explicitly. But you've been talking about .PNG and .webp files, not video/audio.

RenPy auto-imports all references to images files stored in the game upon startup. It calls them "displayables". An image called ./game/images/testing/thisismyhouse.png will automatically be accessible within the game as thisismyhouse.
The thing that trips up a lot of new developers is that all auto-imported displayables are lower case. So ./game/images/testing/ThisIsNOTMyHOUSE.webp would be known as thisisnotmyhouse. It's why I would usually advise that all filenames (in fact most things in RenPy) be lowercase - since it means you never need to think about it.
Anyway, you're dealing with an existing game, so you're stuck with the original developer's faults and fuckups.





My guess is that this is something to do with you deleting the original images.rpy file.
I'm guessing of course, so its likely something else.
LINT will probably point you in the right direction.




You shouldn't need to change them back.

I risk making things worse here... but RenPy doesn't care what the file is called.
You could rename testb.webp to testb.jpg and RenPy will still process scene testb with fade normally (as long as you let RenPy auto-create the displayable name).
RenPy either uses a standard image library that doesn't care, or checks the image file's header.
Which doesn't mean doing that is a good idea. It's just why the "compressed" or "crunched" versions of games work, despite the images being converted to another format.
If it isn't already obvious... Don't do things like this.




A very unlikely cause is the build.classify sections within the options.rpy file.
If there's something weird going on there, you should notice it very quickly.
(I'm thinking something like there being a line like build.classify('**.webp', None))





No clue.
It implies that the distribution file you are looking at isn't the the one the SDK generated. But that's a whole new rabbit hole, and somewhat unlikely.
I just built a distribution of an old game I worked on, the .exe file is dated today.

Most of the time, a game written in RenPy an old version of RenPy (for example, 6.7.1) can be rebuilt in the latest version of RenPy (currently 8.2.3). Again, that's not universally true. But "most" of the time. I would generally start work using the latest version of RenPy, regardless of which version the original game used - until something breaks, then I might go back to the original version (or at least the latest version that doesn't break).

What I will ask is....
What game are you reworking?
While we can't see your code. It might help to see how well (or badly) the original game was written.
At the very least, we can see how the original game accesses it's image files.

If I were you, I'd go back and follow my instructions about unpacking the original game into a new SDK folder. Then copy all your current code/images over the top of it. That way, any missing files included in the original game will be there again. Of course, that will then mean a lot of effort to go remove all those .png files again. It would give you a safe/stable starting point though.

Wow! Thanks so much for all the info. You've given me a ton of stuff to look into. I'm traveling this week but will work on it as I am able and will let you know. Thanks again

 

[DarkLoki]

So a not standalone alteration. But well, I'll not starts talking about semantic...




There's only one case where Ren'Py will include the file name when it throw an error (that we still haven't seen despite Osanaiko having explicitly asked for it), and it's when the said file name is explicitly addressed in the code.
But you said that you searched everywhere, using many different tools, and didn't found it. So, where's the truth exactly ?




Good for you that you learned HTML on a Linux box. But well, flexing will lead you nowhere here, especially when answering to someone who learned to code before Linus released the first version of his *nix derived OS.

This being said, what was needed in this particular case was reading abilities. I precisely, and explicitly, said that you must not follow case sensitivity when it come to auto-referenced images.




Then the exe timestamp isn't dated from 2015 ; WEBP support appeared with the version 6.99.12, that was released in December 2016. Or you seriously messed somewhere.

Any gratitude I may have for your encompassing response is kind of negated by your incorrect assumption I was "flexing". I simply pointed that out to help you understand where I was coming from. I actually started programming in BASIC on my Atari 400. I've been programming VB, ASP, C# .Net for 20 years. Did not include that because none of it seemed relevant to the conversation. I suppose I should just say "thank you" for responding and leave it at that.

 

[DarkLoki]

Based on other replies in this thread, I'd probably categorize your work as a "fan remake".
It sounds like you've taken the original game, removed parts of it and reworked those missing pieces to create something new.

A "mod" is more "leave the original game alone, but use code to override what it does".
The main feature of a mod is that if you remove it, the original game still works as originally intended. (Although save files wouldn't work).
None of which is really important, beyond that if you say "I am build a standalone mod", it creates certain expectations for those of us trying to help.




A few things to talk about here.
You don't need to worry about persistent variables. When you build a new distribution from the RenPy Launcher/SDK, it is built without persistent files. Each distribution is a brand new start.
Persistent data will still exist on a player's computer once they've played the game, but that will be within the /saves/ folder (and the copy stored in C:\Users\{user}\AppData\Roaming\RenPy\{gameid} for Windows users).

I personally would not have deleted the images.rpa file until you'd unpacked it. In fact, that's true of all the .rpa files.

To convert a fully running, existing game into a version that can be worked on with the SDK, I would do this:

• Unzip the original game to your normal "RenPy games" folder.
• Use UnRen to unpack the game. (Works most of the time).
• If the unpacked version of the game only has .rpyc files, use UnRen again to decompile them into .rpy files. (Again, works most of the time).
• Delete all the .rpa files, now that UnRen has unpacked them.
• Create a new project within the RenPy launcher, to match your game's name. (If the original game was "Brave New World", then call it something like "Brave New World Fan Remake").
• Exit the RenPy Launcher (and any editor you are using).
• Delete the /game/ folder in the SDK's development folder (wherever you created the project).
• Copy the /game/ folder from the installed game into the SDK's folder (effectively replacing the /game/ folder you just deleted).
• Delete the script_version.txt file from the newly copied /game/ folder. (RenPy SDK doesn't like this file being there).
• Edit at least the build.name within the options.rpy. Probably the config.version too.
• Maybe do a LINT check now. You'll at least learn about all the problems that aren't your fault (but you probably should fix anyway).
• Take a copy of the SDK's folder in this state. That way, if you screw up - you won't need to do all this again to start again.

That's it.
You now have a full copy of the game, with all the game files unpacked in a folder the SDK can recognize. You can work on game to your heart's content. Delete images, rename files, rewrite code. Whatever it is you want to do.




As other have already talked about, this is where LINT comes in.
LINT is a code checker. It will go through your code and show warnings and errors about anything wrong with your code (like image files being missing).
LINT is available on the main RenPy Launcher screen under [Actions] as Check Script (Lint).

Generally speak, every developer should probably do a LINT check before building a distribution.




This sets off alarm bells for me.
A well written RenPy game shouldn't need the images defining within the game itself. RenPy does all of that automatically.
The exception is video and sound files, which need to be named explicitly. But you've been talking about .PNG and .webp files, not video/audio.

RenPy auto-imports all references to images files stored in the game upon startup. It calls them "displayables". An image called ./game/images/testing/thisismyhouse.png will automatically be accessible within the game as thisismyhouse.
The thing that trips up a lot of new developers is that all auto-imported displayables are lower case. So ./game/images/testing/ThisIsNOTMyHOUSE.webp would be known as thisisnotmyhouse. It's why I would usually advise that all filenames (in fact most things in RenPy) be lowercase - since it means you never need to think about it.

Anyway, you're dealing with an existing game, so you're stuck with the original developer's faults and fuckups.





My guess is that this is something to do with you deleting the original images.rpy file.
I'm guessing of course, so its likely something else.
LINT will probably point you in the right direction.




You shouldn't need to change them back.

I risk making things worse here... but RenPy doesn't care what the file is called.
You could rename testb.webp to testb.jpg and RenPy will still process scene testb with fade normally (as long as you let RenPy auto-create the displayable name).
RenPy either uses a standard image library that doesn't care, or checks the image file's header.
Which doesn't mean doing that is a good idea. It's just why the "compressed" or "crunched" versions of games work, despite the images being converted to another format.
If it isn't already obvious... Don't do things like this.




A very unlikely cause is the build.classify sections within the options.rpy file.
If there's something weird going on there, you should notice it very quickly.
(I'm thinking something like there being a line like build.classify('**.webp', None))





No clue.
It implies that the distribution file you are looking at isn't the the one the SDK generated. But that's a whole new rabbit hole, and somewhat unlikely.
I just built a distribution of an old game I worked on, the .exe file is dated today.

Most of the time, a game written in RenPy an old version of RenPy (for example, 6.7.1) can be rebuilt in the latest version of RenPy (currently 8.2.3). Again, that's not universally true. But "most" of the time. I would generally start work using the latest version of RenPy, regardless of which version the original game used - until something breaks, then I might go back to the original version (or at least the latest version that doesn't break).

What I will ask is....
What game are you reworking?
While we can't see your code. It might help to see how well (or badly) the original game was written.
At the very least, we can see how the original game accesses it's image files.

If I were you, I'd go back and follow my instructions about unpacking the original game into a new SDK folder. Then copy all your current code/images over the top of it. That way, any missing files included in the original game will be there again. Of course, that will then mean a lot of effort to go remove all those .png files again. It would give you a safe/stable starting point though.

Apparently the main issue was I unzipped everything but kept working within the original directory, never creating a new project. Of course, there are other things I found based on your comprehensive response. I thank you very much for your assistance.

One new question I have is there are no "options.rpy" or "config.version". Without screwing up my now-working project, how can I create/recreate these files? Do I care to?

 

[osanaiko]

The filename "options.rpy" is arbitrary - it's just the name of a specific default file that is created by the Renpy SDK launcher when you make a new project.

The contents of the file are the important part. It basically contains a number of configuration options to customize your project. You don't *need* it, but a few settings make some aspects of your "dev life" easier (like setting a version number you can update each release).

The easiest way to see what is in there and if there is anything you want to use in your specific project is to just make a new Renpy project with the SDK Launcher and take a look at the generated file. It has a lot of comments.

 

[79flavors]

One new question I have is there are no "options.rpy"

It depends on the game you are copying.
options.rpy isn't mandatory. The developer could have put all the commands that would normally go in there into any file of any name. Given it's coded into the SDK user interface - I'm no idea why some developers think they need to change it.

You don't need to recreate it, because if the game already runs - it doesn't need it. (or at least, it doesn't need it to be named that).

or "config.version".

Did you mean script_version.txt?

And no, you don't need to recreate that either. It is automatically generated when you use the [BUILD] option in the RenPy SDK.

 

[anne O'nymous]

You don't need to recreate it, because if the game already runs - it doesn't need it.

More precisely, the values found in the file are the default values. Therefore, the game can perfectly works without options.rpy file. At worse you can still define the few options you change into one of your project file, script.rpy by example. But strictly speaking, unless you have specific needs, the default values works well.

The only thing that can have to be changed concern the game itself: config.name, config.version, config.save_directory and build.name.
Yet, only config.version really matters, the three others being filled by Ren'Py when you create the project in the SDK. It can be interesting to change the save directory and build name, but it will works even if you don't.

 

[DarkLoki]

Based on other replies in this thread, I'd probably categorize your work as a "fan remake".
It sounds like you've taken the original game, removed parts of it and reworked those missing pieces to create something new.

A "mod" is more "leave the original game alone, but use code to override what it does".
The main feature of a mod is that if you remove it, the original game still works as originally intended. (Although save files wouldn't work).
None of which is really important, beyond that if you say "I am build a standalone mod", it creates certain expectations for those of us trying to help.




A few things to talk about here.
You don't need to worry about persistent variables. When you build a new distribution from the RenPy Launcher/SDK, it is built without persistent files. Each distribution is a brand new start.
Persistent data will still exist on a player's computer once they've played the game, but that will be within the /saves/ folder (and the copy stored in C:\Users\{user}\AppData\Roaming\RenPy\{gameid} for Windows users).

I personally would not have deleted the images.rpa file until you'd unpacked it. In fact, that's true of all the .rpa files.

To convert a fully running, existing game into a version that can be worked on with the SDK, I would do this:

• Unzip the original game to your normal "RenPy games" folder.
• Use UnRen to unpack the game. (Works most of the time).
• If the unpacked version of the game only has .rpyc files, use UnRen again to decompile them into .rpy files. (Again, works most of the time).
• Delete all the .rpa files, now that UnRen has unpacked them.
• Create a new project within the RenPy launcher, to match your game's name. (If the original game was "Brave New World", then call it something like "Brave New World Fan Remake").
• Exit the RenPy Launcher (and any editor you are using).
• Delete the /game/ folder in the SDK's development folder (wherever you created the project).
• Copy the /game/ folder from the installed game into the SDK's folder (effectively replacing the /game/ folder you just deleted).
• Delete the script_version.txt file from the newly copied /game/ folder. (RenPy SDK doesn't like this file being there).
• Edit at least the build.name within the options.rpy. Probably the config.version too.
• Maybe do a LINT check now. You'll at least learn about all the problems that aren't your fault (but you probably should fix anyway).
• Take a copy of the SDK's folder in this state. That way, if you screw up - you won't need to do all this again to start again.

That's it.
You now have a full copy of the game, with all the game files unpacked in a folder the SDK can recognize. You can work on game to your heart's content. Delete images, rename files, rewrite code. Whatever it is you want to do.




As other have already talked about, this is where LINT comes in.
LINT is a code checker. It will go through your code and show warnings and errors about anything wrong with your code (like image files being missing).
LINT is available on the main RenPy Launcher screen under [Actions] as Check Script (Lint).

Generally speak, every developer should probably do a LINT check before building a distribution.




This sets off alarm bells for me.
A well written RenPy game shouldn't need the images defining within the game itself. RenPy does all of that automatically.
The exception is video and sound files, which need to be named explicitly. But you've been talking about .PNG and .webp files, not video/audio.

RenPy auto-imports all references to images files stored in the game upon startup. It calls them "displayables". An image called ./game/images/testing/thisismyhouse.png will automatically be accessible within the game as thisismyhouse.
The thing that trips up a lot of new developers is that all auto-imported displayables are lower case. So ./game/images/testing/ThisIsNOTMyHOUSE.webp would be known as thisisnotmyhouse. It's why I would usually advise that all filenames (in fact most things in RenPy) be lowercase - since it means you never need to think about it.

Anyway, you're dealing with an existing game, so you're stuck with the original developer's faults and fuckups.





My guess is that this is something to do with you deleting the original images.rpy file.
I'm guessing of course, so its likely something else.
LINT will probably point you in the right direction.




You shouldn't need to change them back.

I risk making things worse here... but RenPy doesn't care what the file is called.
You could rename testb.webp to testb.jpg and RenPy will still process scene testb with fade normally (as long as you let RenPy auto-create the displayable name).
RenPy either uses a standard image library that doesn't care, or checks the image file's header.
Which doesn't mean doing that is a good idea. It's just why the "compressed" or "crunched" versions of games work, despite the images being converted to another format.
If it isn't already obvious... Don't do things like this.




A very unlikely cause is the build.classify sections within the options.rpy file.
If there's something weird going on there, you should notice it very quickly.
(I'm thinking something like there being a line like build.classify('**.webp', None))





No clue.
It implies that the distribution file you are looking at isn't the the one the SDK generated. But that's a whole new rabbit hole, and somewhat unlikely.
I just built a distribution of an old game I worked on, the .exe file is dated today.

Most of the time, a game written in RenPy an old version of RenPy (for example, 6.7.1) can be rebuilt in the latest version of RenPy (currently 8.2.3). Again, that's not universally true. But "most" of the time. I would generally start work using the latest version of RenPy, regardless of which version the original game used - until something breaks, then I might go back to the original version (or at least the latest version that doesn't break).

What I will ask is....
What game are you reworking?
While we can't see your code. It might help to see how well (or badly) the original game was written.
At the very least, we can see how the original game accesses it's image files.

If I were you, I'd go back and follow my instructions about unpacking the original game into a new SDK folder. Then copy all your current code/images over the top of it. That way, any missing files included in the original game will be there again. Of course, that will then mean a lot of effort to go remove all those .png files again. It would give you a safe/stable starting point though.

Thank you again for all the responses. After an intense week of coding, I DID solve an awful lot of other issues by following everyone's suggestions that apply.

However, the original issue still exists. Not only did I follow all applicable suggestions, when it didn't work I even went to a clean machine, downloaded the SDK, created a new project, etc. and STILL have the same issue.

When I LAUNCH the project from the SDK, I get this:



When I build the distribution (after running LINT etc.) and run the new build, I get this:



which was the name of the original project I dl from f95, and the newly created distribution calls for files that have been long since removed from the project and the code.

I have used 3 editors searching *.* for the word "enhanced", it appears exactly ZERO x in the whole codebase. I would share code but don't even know where to start.

I'm totally at my wits end. Please, any suggestions would be greatly appreciated.

 

[osanaiko]

The docs state that the "config.name" param is used as the Window Title.

You must be registered to see the links

Setting that variable value is not limited to just the options.rpy file however, it could be in any code file.

Given that you are pulling in at least some code from another project, you should be careful if you are re-using previously compiled RPYC or RPYM files, as the value you are seeing might be in there. But I really don't know.