I’ve been politely asked to make another tool that will allow to edit the rooms a bit faster and with less clicks so cheer everyone because I hacked together a horrible abomination of async code, the MRM.
Now you can define your areas in a single text file that looks like this:
messages:
common_exit: &common
leave: leaves to $SHORT
arrive: arrives from $NAME.
travel: goes to $SHORT.
rooms:
- tid: entrance
id: cb3c1cm9gbrmb43nluu0
name: the entrance
description: >
The entrance is nice.
exits:
- to: other
messages: *common
- to: house
messages: *common
- tid: house
id: cb3c9a69gbrmb43nm53g
name: The House
exitName: house
description: >
the house is tall
exits:
- back: entrance
messages:
<<: *common
leave: leaves.
- tid: other
id: cb3d5v69gbrmb43nmntg
name: The Other
description: >
Meh.
exits:
- back: entrance
messages:
<<: *common
leave: leaves.
And then do two things.
First, it allows you to do a quick style check:
And second, it allows you to sync that to Wolfery:
Hopefully this solves the pain of, and I quote here, “checking every single goddamned exit in this mansion”.
The app is available as a no strings attached thing, meaning you need to clone the repo and dart run ./bin/mrm.dart. I’ll come up with some builds for some OSes later. Probably.
You write a file like the example, then run the tool sync -s file.yaml and it will tell you what needs to be updated in the world and will do it if you tell it to continue. It’s a command line tool only and it works somewhat like this:
There wasn’t much interest based on this thread so I didn’t bother with a proper manual because Shin’s close enough for me to teach her how to use it hands-on.
So this is a 3rd party client essentially, specifically without anything information except the status feedback regarding the submitted file. Making assumptions based on what I see in the file - It logs in as you (in tandem with any other sessions you have logged in) and will send all of the required commands which would be sent by button clicks on the interface if told to do so but otherwise just checks information in rooms that it sees while you’re roaming around?
Exactly. It will check the info on its own, it teleports the character around every room to sync the state. And you need to specify the char name because of the sessions craziness. It doesn’t work in the background. Just runs when you call it, does its thing, and dies.
Makes sense.
Seems like a neat and useful project at least.
Having a mode capable of telling it to fetch data values from any provided list of room/area ids in order to establish a base line text file could also prove useful as well.
Basically creating the file based on what it sees so it that output can be edited and fed back in to make bulk changes.
–
Hopefully someone on staff will have time to review the project and give an all-clear. Seems useful for doing large jobs in a tidy way, but I’ve got no coding/programming chops to speak of myself, so I have to play from the position of keeping staff perms safe until then.
Yeah, area management and info-fetching is definitely the next logical jump after that and probably not much further after until we have further functionality developed down the road for handling access restriction functionality, but that might be a while.
I’d want @Accipiter’s input on this if it to become something more tbh. The code is a mess and it’s no fun to keep expanding it in dart for it has some awful infrastructure to support these kind of things. I’d rather re-write it from scratch in something else but then it loses the point of being the api playground for the mobile app. That said, the mobile app is self-sufficient by now so it’s not like that matters much.
What was the plan with the bot tokens / oauth? I’m not really happy about maintaining a tool that wants to store your passwords plaintext and I’m really using it as a last resort option.
While you could store the HMACSHA256 version of the password instead, to prevent the plain-text password to be stored, that hash is still the ‘password’ for Wolfery, thus a security issue.
The ideas are still rather loose, but would be something like this:
Provide an interface/commands to manage bot-tokens. E.g. log in with the client and wake up the intended bot. Type things like:
list tokens
create token
delete token XXX
Bot tokens are strings that can be used as credentials to the API
Character’s with bot tokens will be marked with a bot tag.
Using a bot token as credentials when accessing the API will differ in the following ways:
Only able to wake up the character the token is created for
Limited to a subset of the commands, relevant for bots. E.g. not able to create/delete characters.
Different restrictions on command flooding, where bots may issue more of certain commands (such as build commands), but may be more restricted on others (such as room communication).
Deletion of bot tokens will instantly revoke access to any bot using it.