Simple scripting implementation idea

I’m chatting with the local wolf and I think I have an idea on how to make the scripting work in the least painful manner.

Why not have scripts behave like bots? It already opens a lot of possibilities for those who wish to add some interactivity. Here’s an MVP:

There’s a new syntax for bot commands: !bot stuff goes here. The bang is a required prefix, bot is the name of the bot, and everything past it is passed onto the bot verbatim. It would be pretty easy on the client side as it’s just a glorified message.

The users will be able to register the bot name for their bot characters. I’d envision this to be gated initially, just like creating puppets is gated. It’s a realm-wide thing so it’s reasonable to have an admin command to assign bot names.

Functionality wise, when the user has a command e.g. inv registered to a bot, whenever someone does !inv look Alice the bot character in question receives a botrequestmessage that includes:

  • command name (inv)
  • command args (look Alice)
  • sender character id
  • sender character’s originating room

The bot then should be able to reply to the user with a botreplymessage. It will be displayed in the UI just like messages do but without the username writes prefix, distinguising them as bot messages in the chrome title instead.

This already allows for interactivity within a room, as users will be able to see customized actions based on what they do. But to make it better, the botreplymessage could be also sent to the room. Privacy-wise, it must be the room of the character the request came from, and it could expire just like the summons expire. It would still display with a similar chrome to distinguish it as a bot-generated message but it will allow publicly-visible actions. It pretty much covers 70% of what people would care about.

To get to 90%, the bot should be able to force-teleport requesters. With instance rooms that allows for endless flexibility.

All that is generally much easier done than the full-brown scripting as it leaves the complex bits to the bot owners. Mucklet side it’s just a couple new commands that don’t differ much from messages.

edit: but far, what if there’s a dozen bots wanting to use a look or use or pay command?

Yeah, bummer, is it first come first served? Without knowing how to distinguish on the rest of the arguments it’d be extremely hard to make it work.

Luckily, there’s a solution – delegate! If you give out a very broad bot verb (like use), the bot author must do their best to accommodate its widest use (not unlike builders deciding which areas get the top level treatment). For that to work, you’ll need a botforwardmessage that one bot (registered for the use command) will send to another bot (that knows how to handle the use that lever command specifically. By sending it via a dedicated command you transfer all the permissions to get the room details / reply along.

1 Like

I think that having the ![bot name] work globally would be useful for if you want to do certain commands from other rooms, for example if there was a bot that held an inventory system and allowed you to buy from certain locations by specifying what you want to buy at the room your in?

Perhaps if the ![bot name] had a limit of 1 per player and it was registered as the name of the bot then everyone could instead pass their command after ![bot name] like !Banker pay Ico Twilight 10Sb. Rather than !pay Ico Twilight 10Sb

1 Like

!Banker pay Ico Twilight 10Sb isn’t much different from m Banker=pay Ico Twilight 10Sb tho. The point was to make it feel you are not interacting with the bots, rather you interact with the environment. The fact that it’s backed by the bots is just an implementation detail – we’re running microservices over the res fabric because that’s what would be easy to do.

1 Like

Oh, so it’s like being able to implement commands for specific rooms?

More like custom commands. I have a hunch that making scripting will take a long while, and this could be a good way to kickstart useful interactions while @Accipiter figures the proper way of doing it.

The way it can be done with this proposal is pretty much piggybacking over the existing message infrastructure (with some elevated permissions for bots to subscribe to origin rooms, yeah, but also the rooms can be just passed inline). With bots limited to supporters and commands requiring manual approval this very much allows interested parties to start doing useful stuff now without it all becoming a wild scripting west.

1 Like

Hmm, I’m interested in how bot developers are going to keep track of what command + attributes belong to which bot, will there be a command built in to view who owns what commands?

It will be up to developers themselves, it just needs to be simple Mucklet side so that @Accipiter could roll it fast-er. So for mucklet it will be something like 'command pay goes to Paybot Smith'. Now, whoever runs Paybot Smith says: it will process messages of format !pay $AMOUNT $CURRENCY to $CHARACTER. Paybot will parse the arguments and if currency is sinderbucks it forwards the request to Banker Badger. If it’s scam it forwards it to scam dracones.

This makes the Paybot Smith a bit all too powerful, but if there’s any notion of abuse it’s easy to revoke the privileges. In the meantime it allows to iterate fast and make useful things without waiting on Mucklet to settle down on a better API (and once there is a better API it would be easy to migrate to it because all the interactions will be well known by then).

1 Like