Conversion of specific TWBot modules into MultiBot modules

I'm noting some quite paltry feature sets on some of these modules, which I would like to improve (a note to self):

Killrace — Presently it's odd vs. even freqs. Allow it to be any number of freqs. Just needs a HashMap.

Marco — rather than setting up an elaborate word list before the game starts, the host should be given the option to be spontaneous and specify a word. Very easy to modify. This seems like it would be a lot more fun than an automated word list where the bot basically runs the whole show. Zzzz.

Another note to self:

Get someone to finish the Commander map, and finish up the bot.

All of these were converted, except for wipeout, and all need testing. Additionally, the marco and killrace modules were given the above additions.

The following modules now need testing on MultiBot:

* ballspec * bountyhunter * conquer * killrace * marco * payback * platoon * raceelim * revenge * stepelim * tugawar

Tested successfully: - golden

Everything from TWBot that was even vaguely useful is now in MultiBot. Awaiting testing.

If we really want to replace TWBot by Multibot we also need to work on getting multibot more user friendly:

• Put !host on multibot which returns the name who did !lock and a way for a staffmember to claim the bot once it has been already locked
• The !modhelp isn't really sufficient. It's a command which staff has to get used to again and doesn't allow to differentiate between a staff-only !help and a public !help. That the staff has to get used to it again is unavoidable but that !modhelp doesn't allow to differentiate between staff/public !help is more disturbing.
• There isn't much need for !follow which also is RoboBot6> Not Implemented Yet.

---

My suggestion for !help is using the !help interface from Mervbot which is something like this:

   MMaverick> !help
    RoboBot6> Multibot Sysop commandlist (Send ::!help <command> for more info)
    RoboBot6> Sysop: !die
    RoboBot6> ER:    !go !listgames !listutils !lock !load !unload !unloadall !loaded !home !gtfo

   MMaverick> !help lock
    RoboBot6> !Lock <game>    (Locks the bot and loads game <game>)

   MMaverick> !help !load
    RoboBot6> !Load <Utility> (Loads utility <Utility>)
    RoboBot6> !load           (Loads standard, warp and spec modules)

This keeps the !help clean and specifies exactly what rank you have on the bots by returning your rank and the commands that are associated with your rank. The staff also remembers the command syntax more easily because they have to do !help <command> for specific command syntax information.

Another benefit is that the modules can hook in on !help just like normal but should only return a single line for a clean !help:

   MMaverick> !help
    RoboBot6> Multibot Sysop commandlist (Send ::!help <command> for more info)
    RoboBot6> Sysop: !die
    RoboBot6> ER:    !go !listgames !listutils !lock !load !unload !unloadall !loaded !home !gtfo
    RoboBot6> PRODEM: !prodem !prolag

What do you think, dugwyler? If you agree maybe we can try this on the multibot(s).

Sounds like a very good idea. The !modhelp addition was really just to eliminate the spam you receive for sending !help while an event module is loaded… previously it was not a problem, because the bot didn't have many commands available when it was locked/module was loaded, but now the spam is ridiculous. I think what you mention as far as command-specific help would make a lot more sense considering the number of commands now available.

Per module it might be a little more tricky: we'd have to implement a way to standardize command handling and associated helps, and the commands are probably not nearly as well-known, so it might become more of an irritant than it would help. Not sure, though. Definitely all for doing it on the Multibot interface itself; this means we could easily recombine the !help again.

- Will comment out references to follow for now. - !host should be pretty easy to implement. Once a host has done !lock, are other hosts not able to unlock and move it?

Also, is it looking still like King MultiBot is running as it should, and Queen still giving all sorts of strange errors?

yea agreed. At first it will be quite annoying for the staffers who use it, but once used to it I think they will see it's quite good. The bulk of the work is getting each multibot module to work with this new !help interface. It's possible to standarize this interface like the CommandInterpreter but that would be another dependency a programmer would have to use. It's probably the best way though.

About !host; yea another host can !unlock it and !lock it again but that would kill the current game. What if a host has to go and another one wants to take over but he wants to make sure everyone who PM !host to the bot gets the correct answer.

Maybe make it so that if the !lock command is used again by a different host and the bot is already locked, it only changes the !host value?

lnx completely updated RoboQueen last night to the most recent version so everything should be good. When one of us gets around to bugfixing those multibot modules we should test first if the bug is still there. Also updated Roboking last night btw.

1:Nycle> if you have time can you port the deathmessage module as well

More offtopic stuff: (Stargazer <ER>)>so robo actuallt keeps all utils in loaded status when you move from arena to arena. did you know that :O Is that normal behaviour or a bug?

Er, what was it that deathmessage did again? Can't remember that one… it may have been put into the etc module?

I think it's normal for modules to stay loaded between arena moves, or at least this is how TWBot used to handle them. We can have it auto-unload them all, though, if that seems smarter.

I don't know about the deathmessage module, do a search for the etc module changeset

It seems logical to leave modules loaded during a arena move since there is a seperate command to unload the utility modules. I thought TWBot unloaded them though (however, TWBot was different - you couldn't move the bot without unlocking it first which would unload all the modules, right?).

On TWBot, !unlock would basically just free it up to move (!off would shut off the modules). We could change it to unload them automatically if hosts prefer it, but it doesn't seem too big a deal to me. We might not have an equivalent of !off on MultiBot yet, though? I can't recall. Maybe an !unloadall or !unload all

Looks like deathmessage was not converted. This would probably be a good addition to the current "messages" util.

soo what's the status on all of these?

Dugwyler should know the most recent status on this, please ask him.

I think everything was done except for DeathMessage, which I didn't quite finish up adding to the messages module. I'll try to finish this. Could someone with a little freetime in the meantime verify nothing was missed being converted from TWBot to MultiBot, either as a MultiModule or MultiUtil? I think a couple of things were left intentionally. But it would be nice to know for certain before we stop making TWBot spawnable and switch over completely to MultiBot.

medorP (Prodem backwards) still needs to be converted to multibot

Wipeout has been converted.

Ok, that's set. Should be the last.

All TWBot modules converted to MultiBot.