Plugin API: hooking/customizing SPADS commands

[Nemo]

Hi bibim,

I'm doing something a little roundabout in my plugin, and wanted to ask if you thought it should become part of the normal API.

What I'm doing:

Code: Select all

    my $builtin_start = $::spadsHandlers{start};

    addSpadsCommandHandler({start => sub ($source, $username, $params, $checkOnly) {
        my $backend_says_ok_start = 1; # <API call>
        if ($backend_says_ok_start) {
            $builtin_start->(@_);
        } else {
            sayBattle("NOT OK");
        }
    }}, 1);

I'm comfortable with this because I <3 perl and hack it for a living, but not everyone is in the same boat :)

Do you think there should be a more straightforward way of hooking !start? Either by exposing launchGame directly, or by some sort of command-chain-fallback thingy, where one !start hook could work and then yield to the next with a successful return val (or something). In either case (or some other one), let me know, I'd be happy to see about a pull request once I get this S44 zombies thing off the ground.

[bibim]

Do you think there should be a more straightforward way of hooking !start? Either by exposing launchGame directly, or by some sort of command-chain-fallback thingy, where one !start hook could work and then yield to the next with a successful return val (or something).

Did you take a look at the preSpadsCommand callback? I think it does exactly what you are describing here, in a generic way for any SPADS command.

For more complex cases where one needs to alter the logic of an existing command (and not just filter its execution or execute some code before/after the command), then indeed it is required to do something as you did. You also need to restore the original command handler when the plugin is unloaded. There is an example of this in the KickBanNextGame plugin, which alters the !kickBan command logic. Here is the relevant code:

In the plugin constructor:

Code: Select all

# save default kickBan command handler
my $self = {previousKickBanHandler => $::spadsHandlers{kickban}};

[...]

# replace default kickBan command handler
addSpadsCommandHandler({kickban => \&hSpadsKickBan},1);

In the plugin unload callback:

Code: Select all

# restore default kickBan command handler
addSpadsCommandHandler({kickban => $self->{previousKickBanHandler}},1);

Tbh it seems ok for me like that, I'm not sure this specific use case requires additional dedicated API functions?

[Nemo]

Argh! No, I missed preSpadsCommand. Perfect, I will use that :). Totally agree that there's no need for additional API surface area for this case.