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.
