Pajbot structure

Make it run!

First step of every new repo - make it work in your environment. I was suggested to not bother with windows and use a VM or some cloud. I knew my Windows version would have problems running WSL, I tried that before.

I followed repo's instructions.

The reason to choose cloud over other solutions is how problematic it would be to run nginx through localhost. Having a domain solves those issues.

There were some details to set up properly, but luckily I wasn't the first with the issue.

As soon as I ran the command to start the bot, the bot would say up in my channel chat.

I stop it and it says down.
Cool, cool. So it works.

About Pajbot structure

I will not explain every step, but some examples of the main steps I did.

We start from here:
pajbot/ folder.

pajbot/web handles the web controller of the bot. You can find stuff like the list of all existing commands and their descriptions in here.

pajbot/web/routes/api/commands.py is where we put data to display on that website.

A description that I add here will later be displayed on that web version like so:

Important files

pajbot/managers/command.py
This file is the main one for commands. Here is where they are stored and they have their description.

In here you can see all the arguments. This is the place where I would have to put mine.

pajbot/models/command.py
Is the file with command classes.

I started with adding my command to various places I noticed other commands go into.

Such as to this class of base commands,

To this list of options,

To the argument list...

I have had a problem with that one, actually. The bot would not parse the command properly. Guess why? Because a chat reply is a string! Not a boolean. So I had to parse it to a boolean before putting it in options. That's what this piece of code does. Or just look at it here:

        if "command_state" in options:
            state = options["command_state"].lower()
            if state == "true":
                options["command_state"] = True
            elif state == "false":
                options["command_state"] = False
            else:
                options["command_state"] = None

Another thing that was also mentioned in a different issue. The problem is that disabling a command actually deleted the command from the database. That hardcoded solution obviously created problems when you wanted to toggle those commands. To solve this, I added a new chat_enabled property to the database. In here.

That was probably the most complex part of all this. Solution to that issue took more than that. I also needed to connect the logic of the command. It took some time fo find all places to connect my logic into (including the things I already mentioned above).