Tutorial Automating Ren'py Builds

[apologetik]

EDIT (2023-12-04): Added link to "warpa" RPA tool

EDIT: I'd like to note that this is primarily aimed at introducing tools that allow you to automate builds. It isn't a fully fledged template for doing so. Figured I'd edit this in now before some silly goose misunderstands the point

The default workflow for Ren'py developers is to use the actual Ren'py app to run, test and build their projects. I personally find this to be very frustrating.

There are several tools at our disposal for automating the process of building a Ren'py project - and I'll go over the ones I currently use.

Quick caveat: I primarily develop in a *nix environment and test on Windows. Most of this can be easily translated to Windows - which I presume most Ren'py devs are using. I'll write a follow-up article at some point when I have time to test this process there.

Let's talk about what the normal process is and we'll examine what we can automate away for each step.

Ren'py UI

The standard way of building things in Ren'py looks like this:



There are several options here, the most important being:

- check script/lint
- force recompile
- building archives (part of building distros, but we'll ignore that)
- build distributions

Each one of these steps can be automated away.


Linting

Linting a Ren'py project from the command line is incredibly easy. If you're writing raw .rpy files, all that is needed is:

$ /usr/share/renpy/renpy.sh path-to-game/ lint

Replace the path to your game (and possibly your Ren'py install). You may get a number of errors from the "standard" Ren'py files that fail to compile, which you can ignore. I know ignoring stuff is silly, but the tool will hard-fail if you have errors in your actual code.


Recompilation

Compiling the .rpy files to .rpyc is similarly easy, using the same command line:

$ /usr/share/renpy/renpy.sh --save-dir /tmp/ignore --compile path-to-game/ compile

Similar to the previous part, you will probably get errors based on where Ren'py is installed. I ignore those. I know ignoring stuff is silly, but the tool will hard-fail if you have errors in your actual code.


Building Archives

Now, linting and recompiling is easy and really not all that interesting. Making your project less of a mess for yourself and users, however, is awesome. Content updates and patches can be handled in a much easier way with archives, diffing a large number of files (I'm looking at you, LiL!) would be incredibly annoying. Games that require a full re-download drive me up the wall, even if I'm willing to do it.

Tools that are usable for this purpose that work well:

-

You must be registered to see the links

- a Python-based RPA packer and unpacker
-

You must be registered to see the links

- Go RPA packer and unpacker
-

You must be registered to see the links

- Rust RPA packer and unpacker

The standard way requires some changes to "options.rpy" - we'll talk about that quickly and move on to the easily automated tools.

Archives: The Standard Way

The normal way of building archives in Ren'py is to update the build section in "options.rpy".

init python:
  build.classify('**~', None)
  build.classify('**.bak', None)
  build.classify('**/.**', None)
  build.classify('**/#**', None)
  build.classify('**/thumbs.db', None)
  build.classify('game/**.png', 'archive')
  build.classify('game/**.jpg', 'archive')
  build.documentation('*.html')
  build.documentation('*.txt')

Specifying "None" means that Ren'py will ignore files of that type. Specifying a name afterwards means that files matching a glob will go into an archive with that name.

The line "build.classify('game/**.png', 'archive')" will ensure that any PNG files dropped into the "game" directory will be packed into an file called "archive.rpa".

In my opinion, this leads to a very messy "game" directory for the developer.

rpatool

rpatool is fairly easy to use. My problem with it is just that I have to install Python.
(edit: unfortunately, some people lack humor, so I must specify that this is a joke.)

Let's say you want to pack images from a "chapter 1" into "chapter1.rpa".

$ rpatool -c game/chapter1.rpa path-to-chapter1-images/

Note that "path-to-chapter1-images" will be included in the file path inside of the archive itself, so if you're working on your game with an organized structure, eg:

/
  game/
    chapter1/
      chapter1.rpy
      images/
        something.png

You may want to, instead, "cd game/chapter1" and then "rpatool -c ../chapter1.rpa images/".

Totally up to you and how you organize your project.


arpy

arpy is written in Go and has prebuilt releases you can download for Linux, Mac or Windows.

Similar to rpatool, if you want to pack up an image-only "chapter1.rpa", you can run something like:

$ cd game/chapter1

$ arpy -o ../chapter1.rpa -g '.+\.png' .

That ".+\.png" part is a regular expression (regexp), similar to "options.rpy", allows you to specify files by a pattern and skip others.


Building Distributions

For building the project and making a zip you can ship, look no further than

You must be registered to see the links

.

Renkit provides a way to download and use various versions of Ren'py, build your project, and notarize that project for use on MacOS - which is pretty awesome.

We're only interested in `renconstruct` right now, though.

The command to run should look like this:

$ renconstruct build -i=path-to-project -o=path-to-output/ -c=renconstruct.toml

As you can see, you'll want a "renconstruct.toml" file. This allows you to skip some of the command-line options.

Mine looks like this:

[build]
pc = true
mac = true
steam = false

[options]
clear_output_dir = true

[renutil]
version = "8.0.0"

This takes care of building the zip archives of your release.


Tying These Together

Again, as mentioned, I develop on *nix and have CI/CD set up that runs this stuff for me every time I push to my repository. How my CI/CD does this is by running commands I've specified in a configuration file - in this case, we'll look at Make.

A simple one could look like:

# Makefile example

lint:
    /usr/share/renpy/renpy.sh path-to-game/ lint

recompile:
    /usr/share/renpy/renpy.sh --save-dir /tmp/ignore --compile path-to-game/ compile

build-debug:
    @mkdir -p build/game
    @cd game/chapter1 && \
        arpy -o ../build/game/chapter1.rpa -g '.+\.png' .

distribute:
    @renconstruct build -i=build/game -o=build/distrib -v=8.0.0 -c=renconstruct.toml

Running "make lint" will detect issues in your game via Ren'py's lint, "make build-debug" will handle archives, "make distribute" will handle building a zip that you can give to users.

Again, I want to stress that this post serves as an example. There are more pieces to the puzzle to be figured out, but if this is something that interests you, it's a decent starting point.


Wrapup

Thanks for reading, and I hope that you found something useful here. Happy to answer questions and help in any way I can.

 

[anne O'nymous]

I'm a software engineer by trade and I don't like to run anything more than three
times manually, and I prefer to have CI/CD yell at me when something easily detectable
breaks.
[...]
Running `make lint` will detect issues in your game via Ren'py's lint, `make build-debug`
will handle archives, `make distribute` will handle building a zip that you can give to users.

Ok, take a seat, preferably comfortable, breath, and think seriously about what you just did...

No, don't stop now, you haven't thought seriously enough yet...


In one hand, you have Ren'Py's SDK:

• It can be launched automatically when KDE/Gnome/whateverYouPrefer starts ;
• It have a visual interface full of buttons to press ;
• The compilation is automatically done when you starts a project ;
• If the compilation trigger an error, all the information will pop-up in front of you ;
• You need to starts a project to test it, therefore it will always be fully compiled when you'll know that it's bug free ;
• You don't lint before you've tested your code, therefore the SDK is in front of you, with your project selected ;
• The lint result will pop-up in front of you ;
• You don't build the distribution before the lint file is clean, therefore the SDK is still in front of you, with your project selected.

In the other hand, you have:

• A make file that you have to manually invoke from the console ;
• A result that either you'll have to browse from the console, or that is in a file that you'll have to manually open.

And you are saying that what you have on this other hand is better and less manual ?


If at least you had designed your make file for it to clean before it proceed, and to automatically pop-up the result file if it exist, redirecting the outputs to it if needed, it would be debatable. You could then make this more automatic and relying on just few clicks (opening the right menu, then click on the right entry)... Therefore, like it already happen with the SDK, but with more clicks.

But no, you haven't did this. And, of course, putting the commands in the cron tab would mean that you've to manually search for the result files and to manually open them. This without being sure that the information effectively regard the last compilation, unless you also manually delete the files once you don't need them anymore.


I can be wrong, but it really looks like you need a hobby that don't imply codding, because you gone way to far.
The worse being that you seem truly convinced that your life is better now that you are living in hell.

 

[apologetik]

Ok, take a seat, preferably comfortable, breath, and think seriously about what you just did...

No, don't stop now, you haven't thought seriously enough yet...

This seems a bit unnecessarily adversarial, but sure, I'll bite.

I'm not sure if you understand the point of _automation_. The entire point of this post is to look at tools that allow you script interactions rather than perform them by hand. For example, there are two Github actions you can use (if you're on Github) which will build and lint every commit|release:

-

You must be registered to see the links

-

You must be registered to see the links

How does that lint work? Well, it downloads the SDK and runs `renpy.sh lint`.

...

• The compilation is automatically done when you starts a project ;
• If the compilation trigger an error, all the information will pop-up in front of you ;
• You need to starts a project to test it, therefore it will always be fully compiled when you'll know that it's bug free ;
• You don't lint before you've tested your code, therefore the SDK is in front of you, with your project selected ;
• The lint result will pop-up in front of you ;
• You don't build the distribution before the lint file is clean, therefore the SDK is still in front

Bug free and compiles are not the same thing. You can lint and test at the same time. I write software for a living. We lint, test and build on every commit or just while something is WIP. Most of the industry does. The thought of running all of this manually every single time and trusting someone "yeah I tested" is hilarious. That's how you end up with bad code.

In the other hand, you have:

• A make file that you have to manually invoke from the console ;
• A result that either you'll have to browse from the console, or that is in a file that you'll have to manually open.

And you are saying that what you have on this other hand is better and less manual ?

Yes. If you're developing a project and using VCS (whether it's git, perforce, whatever) you commit, push, and CI/CD handles these actions for you.

If at least you had designed your make file for it to clean before it proceed, and to automatically pop-up the result file if it exist, redirecting the outputs to it if needed, it would be debatable. You could then make this more automatic and relying on just few clicks (opening the right menu, then click on the right entry)... Therefore, like it already happen with the SDK, but with more clicks.

Perhaps you missed the "a simple one could look like...". You're thinking of "automatic" from a point-and-click GUI worldview. I am thinking of "automatic" from an actual software view.

But no, you haven't did this. And, of course, putting the commands in the cron tab would mean that you've to manually search for the result files and to manually open them. This without being sure that the information effectively regard the last compilation, unless you also manually delete the files once you don't need them anymore.

I'm pretty sure you have no idea what you're talking about. Why would I put this in crontab? I'm guessing you have no software development experience outside of Ren'py because a lot of what you said here simply doesn't make sense.

I can be wrong, but it really looks like you need a hobby that don't imply codding, because you gone way to far.
The worse being that you seem truly convinced that your life is better now that you are living in hell.

While I'd like to thank you for the very clearly well intentioned thought and post (big /s), I very much enjoy programming and what I'm doing. Merging my experience as a software dev and this journey into VNs is not "hell", it's allowed me to focus on the game and not doing a bunch of things by hand. This is much easier from my PoV, and if someone else finds tools or thoughts listed here useful, I will continue to share them.

Thanks for your reply!

 

[anne O'nymous]

The entire point of this post is to look at tools that allow you script interactions rather than perform them by hand.

And my post is here to remind you, or teach you, I don't know which one apply, that automation isn't always the answer.
Of course, when you are young and enthusiastic, you make scripts for everything. I know it, I've been young and, since I've been admin, mostly network and security, for years, I wrote thousands of them. But it doesn't mean that it's always the right answer, especially when it answer to a wrong problem.

You can lint and test at the same time.

If you have time to loose, yes, you can. But there's no interest, nor advantage, in doing this.

Until you know that your code works as expected, and pass both your unitary tests and practical ones, your code is not frozen. What is the interest to ensure the rightness of an unfrozen code ? You'll pass time fixing a warning that will possibly don't exist in two hours, because you'll refactor the piece of code where it happened due to a bug.
Lint should be your last touch. Now that your code is working, it's time to care about its aestheticism and the none breaking issues you missed.
Doing otherwise is nothing more than fixing the compilation warnings before fixing the errors in your code. You don't do that, right ?

I write software for a living. We lint, test and build on every commit or just while something is WIP. Most of the industry does.

Wait... "on every commit", not "before every commit" ?
It's just a wrong phrasing, right ? You don't commit, crossing your fingers that everything is correct, right ?

Perhaps you missed the "a simple one could look like...". You're thinking of "automatic" from a point-and-click GUI worldview. I am thinking of "automatic" from an actual software view.

I don't know what I missed, nor if I missed something, but you clearly missed the whole development process.

1. Write the code ;
2. Test the code ;
3. Correct the code ;
4. Loop to 2 until there's no mode bug ;
5. Polish the code ;
6. Commit.

You also missed the effective point: You don't compile (because it's not needed), nor lint, randomly.

I'm pretty sure you have no idea what you're talking about. Why would I put this in crontab?

Because a nightly built is the unique case where your automation make sense.
Since you don't need to compile, and don't lint without having changed your code, nor two hours after you did it, the only other possibilities is that you develop your game without the SDK. But it would be stupid, because the SDK is an automation interface.

I'm guessing you have no software development experience outside of Ren'py

Please, don't tell this to my boss. He must be a childhood friend, he would be very angry to discover that his senior programmer, team manager, tests writer, and I guess that I have few others titles due to what I do, know absolutely nothing regarding software development.

[...] because a lot of what you said here simply doesn't make sense.

And of course, if it don't make sense to you, it's because I know nothing. Not because you have less experience than me, and felt offended by my answer.
Seen the versioning software you named, I'll go for the second option. I'll probably feel old again, but I'm not sure that you were born when I wrote my first line of code. Where you born in the early 80's ?

While I'd like to thank you for the very clearly well intentioned thought and post (big /s),

Am I contagious ?

I very much enjoy programming and what I'm doing.

The opposite would be depressing.

Merging my experience as a software dev and this journey into VNs is not "hell", it's allowed me to focus on the game and not doing a bunch of things by hand.

The "bunch of things by hand" being "clicking on the 'check script' button" every now and then, and on the "build distribution" once in a while.

You know, you are far to be the only "software engineer" who is working on a Ren'Py game. But you are the first one I see who believe that this part of the process need automation.

Thanks for your reply!

There's really no need. I would like to say that the pleasure was all mine, but you made me feel old, and I don't like this.



All this being said, I know that you haven't thought your automation beforehand. I'm not a fortune teller, but I don't need to be one to know it, and you can deny it all you want, it will change nothing to the truth. And the truth is that you wrote those two sentences:

`rpatool` is fairly easy to use. My problem with it is just that I have to install
Python.

Would you have thought seriously about this for more than two seconds, something really obvious would have jumped to your face like a facehugger freshly hatched: Ren'Py is a game engine wrote in Python, and Python is a script language that need an interpreter.

You don't need to install Python to use rpatool, you already have Python...

 

[apologetik]

And my post is here to remind you, or teach you, I don't know which one apply, that automation isn't always the answer.
Of course, when you are young and enthusiastic, you make scripts for everything. I know it, I've been young and, since I've been admin, mostly network and security, for years, I wrote thousands of them. But it doesn't mean that it's always the right answer, especially when it answer to a wrong problem.

I find this highly unlikely. At any rate, I'm getting on in years. If you've given up or don't find joy in it, that's OK.

If you have time to loose, yes, you can. But there's no interest, nor advantage, in doing this.

Until you know that your code works as expected, and pass both your unitary tests and practical ones, your code is not frozen. What is the interest to ensure the rightness of an unfrozen code ? You'll pass time fixing a warning that will possibly don't exist in two hours, because you'll refactor the piece of code where it happened due to a bug.
Lint should be your last touch. Now that your code is working, it's time to care about its aestheticism and the none breaking issues you missed.
Doing otherwise is nothing more than fixing the compilation warnings before fixing the errors in your code. You don't do that, right ?

I'm not sure what you mean by code being "frozen" here, but you should be doing all of the above as you go throughout the development cycle.

Wait... "on every commit", not "before every commit" ?
It's just a wrong phrasing, right ? You don't commit, crossing your fingers that everything is correct, right ?

You quoted the "...something is WIP..." part without reading it. Even if I hadn't said that, committing early and often is easier than waiting until significant checkpoints. Just rebase/cleanup your commits.

I don't know what I missed, nor if I missed something, but you clearly missed the whole development process.

1. Write the code ;
2. Test the code ;
3. Correct the code ;
4. Loop to 2 until there's no mode bug ;
5. Polish the code ;
6. Commit.

You also missed the effective point: You don't compile (because it's not needed), nor lint, randomly.

You should write, test, lint and compile throughout the development process. If you aren't doing that, you are doing it wrong. There's really not much to say about it other than that. Almost every editor supports post-write hooks or has lint, test or compiler tooling that allows you to check stuff as you write it. If you have them, take advantage and catch issues early. I don't know why you are against that.

You're taking this "run `make lint`" as if it means you have to physically type it out every single time. No - hook it up in CI/CD. Hook it up to a postwrite in your editor. Whatever floats your boat. Get feedback quickly.

Please, don't tell this to my boss. He must be a childhood friend, he would be very angry to discover that his senior programmer, team manager, tests writer, and I guess that I have few others titles due to what I do, know absolutely nothing regarding software development.

...

And of course, if it don't make sense to you, it's because I know nothing. Not because you have less experience than me, and felt offended by my answer.
Seen the versioning software you named, I'll go for the second option. I'll probably feel old again, but I'm not sure that you were born when I wrote my first line of code. Where you born in the early 80's ?

I don't particularly care how long you've been in the industry. If you find all of this tedious, you don't enjoy it. And that's OK. You're free to continue manually running things through a GUI.

Direct note, though: your statement re: crontab. If you are being serious, then yes, I would think the former. If you're trolling, then you're just being a jerk as mentioned elsewhere. I am now leaning towards the latter, but you're the only one who can know the answer for certain.

You know, you are far to be the only "software engineer" who is working on a Ren'Py game. But you are the first one I see who believe that this part of the process need automation.

I'm definitely not the first - otherwise none of these tools would exist. But that's OK - I'm not forcing the platform to change. I was just posting about some tools.

All this being said, I know that you haven't thought your automation beforehand. I'm not a fortune teller, but I don't need to be one to know it, and you can deny it all you want, it will change nothing to the truth. And the truth is that you wrote those two sentences:


Would you have thought seriously about this for more than two seconds, something really obvious would have jumped to your face like a facehugger freshly hatched: Ren'Py is a game engine wrote in Python, and Python is a script language that need an interpreter.

You don't need to install Python to use rpatool, you already have Python...

I don't use rpatool. I did use it initially. The point of the post is that you don't need to do things through the standard GUI just to build your game. There are opportunities to do things in a less annoying way, depending on your perspective. Is the fun part linting? Cool, do it! Or cut it out and have it run for you.

Rather than this being some "slam dunk", the phrasing and argumentation here just shows that you're looking to be a jerk for no reason. It's actually pretty pathetic. I've tried fairly hard to not be a dick here, but frankly you've made it rather difficult. If you want to actually talk constructively, perhaps show some of your workflows, that'd actually be a useful contribution. So far, nothing you have said is helpful to anyone. If you want to engage further, I would love for you to detail your process and perhaps I or others can learn from that.

 

[anne O'nymous]

You quoted the "...something is WIP..." part without reading it. Even if I hadn't said that, committing early and often is easier than waiting until significant checkpoints. Just rebase/cleanup your commits.

And you are answering without thinking.
You said that "[you] lint, test and build on every commit or just while something is WIP". It's logical that I wonder if the "on every commit" is a typo. But at no time this imply, in a way or another, that I missed the second occasion where you lint/test.
And yes, it's logical to question your phrasing, because committing untested code is purely useless. Worse, when you are part of a team it's dangerous. Your teammates will assume that your code is good to go, and base their own code on what it produce. If there's a bug in your function (by example) that make it return a wrong result, every code relying on your function will spread this bug, because it will be based on a wrong assertion.

This being said, I really like the logic. You put automation because having to click is so annoying, but you don't care if you need to cleanup your commits time to time. And rebasing, seriously ? It's not because it's possible that it should be done.

You should write, test, lint and compile throughout the development process. If you aren't doing that, you are doing it wrong.

And you should think before answering. It's you, and only you, who decided that "code = project".
Were you a bit more humble, and therefore less convinced to be the only custodian of a truth that can't be nothing else than universal, you would have remembered that even BASIC isn't purely linear since decades.
It's obvious that you test during the development process... each time you finished a function, method, class, etc. The fact that I mentioned unitary tests should have been a hint, since it's what they are for.

I don't know why you are against that.

Given that there's nothing in what I said that could at least imply this, while there's many things that explicitly tell the opposite, what you should ask yourself isn't why I'm against it, but why you invent what you are reading.
A guy who say that he's payed to, among other things, write unitary test suits, that would be against testing during the development process... In what world did this seem coherent exactly ? Yet it's the conclusion you came to...

You're taking this "run `make lint`" as if it means you have to physically type it out every single time. No - hook it up in CI/CD. Hook it up to a postwrite in your editor. Whatever floats your boat. Get feedback quickly.

No, I'm not taking it strictly like this, read again. But yes, I don't take it as a hook, because it's even more absurd.

You want to have your feedback as quickly as possible, good, it's why the "Check Script" button exist, is as easily available, and it's implementation designed to pop-up the result.
You find that it's not fast enough ? Well, the SDK is open source, nothing prevent you to hook it to the "launch project" button, and have it proceeded in background while you test your code.
You need to know the result before you test your code ? Well, what can I say, except that if you have so few trust in your own code, it's probably not the right job for you.

You lint to confirm that you did everything correctly, and you need to do it because you are just human, and so make an error time to time.
But, as I said, there's no interest to do it before you frozen this part of your code (since it need to be explicitly said). This because, before the moment this part of your code is completed and works as expected, and therefore before the moment it's time to pass to another part of your code (since here again it need to be explicitly said), most warnings will just tell you that you haven't done "this" yet.
A purely useless information, because you are supposed to know what you haven't done yet, and a waste of time, since you'll have to proceed information that you already know.

I don't particularly care how long you've been in the industry.

You said that I wasn't in it, I answered that you are wrong, nothing more.

You clearly felt deeply offended by the fact that I found your marvelous automation purely useless. And you discarded my opinion because, unable to question yourself, you decided that I know nothing. I just corrected you on this point. No, it's not by ignorance that I find your idea useless.
After, that you question yourself or not, it only regard yourself, personally I don't care. While my first answer was addressed to you, this one is addressed to the readers, because parts of what you say is a waste of time, while a parts of it is even dangerous.

If you find all of this tedious, you don't enjoy it.

It really starts to be annoying all those thoughts that you force into my mind.
Would have I wrote all those tools, how-to and mods, all this on my free time, if I were finding all this tedious ? And it's not because I find one particular automation purely useless, that I don't have hundreds automation on my own LAN.

If there's someone who find something tedious here, isn't it the person who said that he don't like to do things manually more than three times ?
I'll not say that it's the best time, but those two seconds you pass moving your mouse to click on a button are a break you give to your brain. And, as short as it is, it's something that matters. It will make you gain more time than codding with a brain so saturated that you miss the most obvious things and need an hour to debug your code.

I'm definitely not the first - otherwise none of these tools would exist.

Since when software engineers write tools only because they are needed ?
Above, you were talking about enjoyment. Well, when you are a software engineer, is there something more enjoyable than a challenge ? And once the tool exist, you release it, in case someone need it.
At no time the sole existence of a tool is a proof that there's a need.

I don't use rpatool. I did use it initially.

You totally missed the point, right ?

I don't care if you use rpatool or not. The issue is that, if you have Ren'Py, whatever the SDK or a simple game, installed on your computer, then Python is available. Yet, you explicitly wrote that using rpatool is an issue because it require that you install Python.

If you want to actually talk constructively, perhaps show some of your workflows,

Don't worry about this, I'm doing it regularly, and not just for my coding workflow, or even my workflow.
But the fact is that I'm doing it where, and when, it make sense to do it. Like by example in my previous answer in this thread... Strange that you commented it, and yet suddenly what, boom it disappeared from your mind ?

If you want to engage further, I would love for you to detail your process and perhaps I or others can learn from that.

Engaging further ? What would be the interest exactly, since you don't want to hear what I have to say ?
When you aren't purely inventing what you read, you prefer to discard it because it don't match your vision. Well, sorry to be human and not a machine. Sorry if it really disturb you that I prefer to take my time, while not wasting it uselessly, to paradigms that are far to make unanimity and are more buzz words than effective improvements.

And if it make you think that I'm a troll, a jerk, or whatever, who care ?
I'm grumpy, sarcastic, and sometimes I can be really harsh. But it never prevented me to be both useful and helpful. Exactly like my "none classical accordingly to your criteria" workflow never prevented me to do a good job and be appreciated for this by my co-workers, superiors, and also my clients when I was freelancer. And you see, this matters way more than what one guy on internet can think about me.

 

[apologetik]

Thanks for your reply! It was a pleasure.

 

[Deleted member 5650140]

thank you

 

[TDoddery]

What the fuck is "lint" anyway ?

OK I Googled it - I didn't even know it was a thing.

Maybe now I can find all those bugs that never caused any problem.

 

[apologetik]

What the fuck is "lint" anyway ?

OK I Googled it - I didn't even know it was a thing.

Maybe now I can find all those bugs that never caused any problem.

Linting's first target is usually stylistic (to keep things consistent), but most linters nowadays can catch basic bugs as well. The Ren'py linter is useful for finding syntax errors and missing content. I haven't found anything particularly useful aside from theirs, perhaps because it isn't a general purpose language.

 

[TDoddery]

Missing content? You mean if the code is pointing at empty space or something?

 

[apologetik]

Missing content? You mean if the code is pointing at empty space or something?

It will find references to images that are missing, style issues, possibly more that I haven't run in to.

 

[TDoddery]

It will find references to images that are missing, style issues, possibly more that I haven't run in to.

I'll try it