Another Snoot Modding Guide

This is an old guide from the /snoot/ Mega archive with some minor updates and corrections for Snoot/Wani's newer versions. This old guide is my favorite since it just goes over the Snoot specific basics, then directs you toward proper documentation, which imo promotes a better understanding than most newer modding guides. This method is not ideal for everyone though, if you want to check out other guides I recommend SoulSound's video guide (ignore its claim that the Snoot modloader doesn't work) and Blacky's mod.
As of writing Snoot is on patch 12.1 and Wani is on 1.7.1. Everything in here should work for both games' latest versions.

  1. Another Snoot Modding Guide
    1. Snootgame specific stuff:
    2. The bare Ren'py basics you won't get anywhere without (or you can also just skip to the quickstart guide):
    3. Essential Ren'py syntax you should learn (not all of it, just the general concepts):
    4. Semi-advanced Ren'py concepts that often come handy (again, just the concepts):
    5. Advanced Ren'py concepts that you probably won't need (you need a solid understanding of most previous topics):
    6. REALLY advanced Ren'py stuff you won't need 99% of the time (you pretty much need programming experience for these):
    7. Important references:
    8. Some editors to consider:
    9. Protips/QoL shit:

You want to make a mod for snoot game? Well that's just fucking dandy.

What the fuck IS a mod you ask? It's a change to the game, essentially.

How big does it need to be?
As big as you want it to be.

It can be a single changed up word or a new sprite for a character.
OR
It can be an entirely new storyline with choices, CGs, and whatever the fuck else (YOU) want!

Oh but I can't use Ren'py! Well toughen the fuck up. If a bunch of homophobic puerto ricans from a vietnamese secondhand fleshlight manufacture network could do it, so can you. In fact, these caveman script kiddies made up an entire modding system for YOUR convenience.

WOW shitting dicknipples what do I do?

Right now the modding system is kinda fickle for mods that change up the main story scenes, first let's assume that you want to add new stuff.

1, Download the game and run it (so you know it works, and so Ren'py can set up the cache and store and all that shit).
2, As per the readme our monkey gods provided, create a directory in the mods folder.

This folder will house ALL of the files related to your mod. Scripts, images, music, everything.
Not only do you NOT want to spread files all around, but people won't put up with your retarded ass shit if you can't compress the entire mod into a single zip file. Are you gay or something?

Okay, so how does it work?

Ren'py has these things called LABELS. What are LABELS? You can think of a label like a chapter in a book. Sentences of a story are compiled under one label. In case of a visual novel, these are the dialogues and all the commands you give to make character sprites appear and move around on the screen. You'll read documentation on them soon, but for a mod you will be putting these in .rpym files instead of .rpy if you wanna take full advantage of the modloader.

When you press the start button in the menu, Ren'py moves to the "start" label. Then you can tell it to move to the "chapter 1" label or "day 1", and so on. This is entirely up to the developer to decide, cavemanon devs just so happened to go with this chapter-like structuring.

So what's your mod gonna do? It's gonna reroute the game to a label you create. The modding system has this prepared for you, as seen in the readme. As the readme says, you'll make a metadata.json file. Some tutorials will tell you the metadata system doesn't work, but the only reports I've seen have just been folk not enabling the mods after install.

Now there's an opportunity for a sneaky fucking retarded bug to occur: If the labels your script files use just so happen to also exist in other script files, then it will wreck chaos upon your ass like you've never seen before. Don't fucking do it. How to guard against this? Prefix your labels with some unique identifier related to your mod (then email cavemanon and complain about global namespace pollution).

For example: "the_mod_to_take_your_virginity__chapter1_scene1"

The official modding README gives a good example of how your mod should be formatted. You will generally have the metadata.json file that tells the modloader what to load, at least one .rpym file with your mod's story labels.

BASICALLY, you add your mod to "label" section of your metadata, in the readme example it's "test_mod_label". Whenever a player runs your mod (from the mod menu), this label will be jumped to.

And that's it.

How do you add dialogue lines and show characters on the screen and shit? Either read the Ren'py docs or watch a tutorial (you can learn the basics in like 5 hours unless you're clinically retarded). Or look at how shit's done in the main script files. Fair warning, cavemanon devs have literal hack solutions to some stuff, it can be hard to understand at spots.

Now what if you want to alter scenes in the game? Well tough fucking luck with that one cause you're a greedy geezer and the developers hate you.

The current modding system does not provide a way to do this. Instead you open the game script and edit whatever the fuck you want. But you cannot use the mod folder then. It's gay. Alternatively you can try redefining labels the game uses, but due to how the Ren'py parser iterates through the folder structure it's not guaranteed to work. Also alternatively you can copy the main story files over to your mod folder, but then you need to prefix every single label to prevent the aformentioned routing bug. Hope your editor can do mass replace (be careful with it tho).

Below are some resources to get you going, no matter how big and complex your mod might be.

Snootgame specific stuff:

All of these files except for the old storyline are included in your game folder.

The bare Ren'py basics you won't get anywhere without (or you can also just skip to the quickstart guide):

Essential Ren'py syntax you should learn (not all of it, just the general concepts):

Semi-advanced Ren'py concepts that often come handy (again, just the concepts):

Advanced Ren'py concepts that you probably won't need (you need a solid understanding of most previous topics):

REALLY advanced Ren'py stuff you won't need 99% of the time (you pretty much need programming experience for these):

Important references:

A general quickstart guide (it's kinda shitty but touches on the most important topics):
https://www.renpy.org/doc/html/quickstart.html

Same but more detailed (could be harder to understand for non-programmers):
https://www.renpy.org/dl/4.1/tutorial.html

Beginner tutorial series (it's more practical examples than a general overview so it's very limiting, but it can help):
https://www.youtube.com/watch?v=CjJ2R22U11Q

Another okay-ish guide (has a hard time explaining stuff, but it has lots of image examples):
https://videlais.com/2018/06/28/working-with-renpy-part-1-downloading-and-configuring/

Some editors to consider:

  • Notepad++ or Sublime Text - Easy to use, doesn't support Ren'py by default (does support python)
  • Editra or jEdit or Atom - Endorsed/Recommended by Ren'py, I've never heard of them otherwise
  • VSCode - More features than Notepad++, might be overkill for a Ren'py project
  • PyCharm - Definitely overkill for a Ren'py project, has industry standard features though (if you can setup your own syntax highlight/code completion, I definitely recommend this one)
  • Kate Editor - My editor of choice. Easy to use, supports Ren'py by default, has a Linux version.
  • notepad, emacs or vim and the likes - Not unless you know what you're doing, I seriously do not recommend these
  • Word or Google docs - No.

Protips/QoL shit:

  • Integrals and fractionals matter a LOT in Ren'py. Learn the difference.
  • Align, position, and anchor properties are not the same, but they affect eachother. Always keep track of them.
  • It's entirely valid to have your entire script in one .rpym file, especially if it's linear and/or not too long.
  • If your story has multiple chapters however, store each chapter in a separate label and call those labels in a "storyline" label similar to the one found in old versions of Snoot Game. Use this label in your metadata.
  • Use renpy.error() to make sure a specific line is actually reached, and to get information about variables and stuff (you can still press ignore to continue the run). The last error is saved to the log files, which is handy for when you log large JSON-like data (and if you're a retard like me who keeps closing the window).
  • Combine renpy.error() with dir() to get even more info, as Ren'py likes to cast stuff as strings. For example: renpy.error(dir(my_character))
  • Run the game from the command line using "/path/to/renpy.exe ." from your folder, and tell the big bulky Ren'py window to go fuck itself.
  • If you're using an editor that utilizes bookmarks, drop one where you define your transforms/characters/images, at the start of important labels, and near the last lines you've added.
  • Use/add hotkeys for quickly commenting/uncommenting a line, and drop a few labels so you can easily start the story from a certain scene (or use the warp command, but it's harder to do while debugging).
  • Before you distribute your mod, install it over an untouched (=never ran) version of the game, to make extra sure it will work. This should never be a problem, but with the variable store, persistent data, and cache, stuff can potentially break on a "new install". The infamous "works on my machine" type of bugs can stem from this.
  • Using git can be a lifesaver, but you probably should consider a way to automatically backup your files in any case.
  • Snoot's sprites use yalign 0.1 or ycenter .655, Wani's usually just sit around default y position
  • For Snoot you should generally use xcenter instead of xalign or xpos. It sets the anchor point in the center of the image rather than the edge, which makes it a bit easier to put characters near the edge of the screen. For Wani you can just use xpos since most of the sprites have xanchor 0.5 in their defines, but you still usually shouldn't use xalign.
  • Don't put a colon after a show statement if you aren't doing anything with it, it will cause fatal errors

Warning

LINK

You are about to visit a link which has been flagged with the above content warnings. Do you wish to continue?

Cancel
Edit
Raw PDF PNG

Pub: 04 Mar 2025 21:33 UTC

Edit: 11 Apr 2025 00:08 UTC

Views: 76

new·what·how·langs·contacts