Plugin API: hooking/customizing SPADS commands

Plugin API: hooking/customizing SPADS commands

SpringRTS Perl Autohost for Dedicated Server

Moderators: Moderators, Lobby Developers, SPADS AutoHost

Post Reply
User avatar
Nemo
Spring 1944 Developer
Posts: 1376
Joined: 30 Jan 2005, 19:44

Plugin API: hooking/customizing SPADS commands

Post by Nemo » 09 Feb 2015, 00:59

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.
0 x

User avatar
bibim
Lobby Developer
Posts: 901
Joined: 06 Dec 2007, 11:12

Re: SPADS AutoHost

Post by bibim » 09 Feb 2015, 13:22

Nemo wrote: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?
0 x

User avatar
Nemo
Spring 1944 Developer
Posts: 1376
Joined: 30 Jan 2005, 19:44

Re: SPADS AutoHost

Post by Nemo » 09 Feb 2015, 15:12

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.
0 x

Post Reply

Return to “SPADS AutoHost”