checking commands list before exits

[adamkittelson]

When entering 's' instead of going south you save, 'w' does 'where' instead of 'west' etc.

That seems to violate the principle of least surprise for users.

I'm not sure if the order should just be switched, or if directions should get precedence if the command entered is 2 characters or less, or something else.

Hypothetically, lets say a mud creator wanted to change how this works without editing src/commands.js since that's considered part of the engine. Is that something that the plugin system could address, and how would that look?

[shawncplus]

My plan was implementing configurable BASH-like disambiguation. So s would go south, but \s would save (much like \command overrides any local aliases in BASH.) The implementer could configure which took precedence in the skill/exit/command pool

[adamkittelson]

Cool. So question on plugin usage.

I gather that my hypothetical plugin to override the command / exit precedence order would reside in plugins/plugin-name/plugin.js and the shell of it would roughly be:

module.exports = {
  init: function(config) {
    //stuff here
  }
}

How would I get at the Commands scope to override or add functions from within the plugin? Is that even a valid question or would that be fundamentally doing it wrong?

[shawncplus]

That would be pretty fundamentally wrong. Plugins, in the way they're designed now, don't alter core functionality. They could be hammered into place to do such a thing given that it's javascript but my original intention was for plugins to attach themselves to events that the core would emit, such as the Web Builder plugin attaching itself to the 'startup' event of the server to launch a server of its own, or someone could write a plugin that made it so on player save it also wrote to a MySQL database or something along those lines.

Does that answer your question? Or do you have a suggestion for something that would be more flexible?

[adamkittelson]

Yep, that answers my question. I'm a Ruby programmer by day so it's in my nature to want to edit core functionality without editing core functionality. ;)

I'm not sure of a more flexible way to handle it. I definitely agree with your goal of having things in /src be core so implementers can update that code as you release new versions, and with that in mind I'm hesitant to make changes to core in the branch I'm creating my mud in beyond bugfixes that I send back upstream.

I'm not sure if the fact that I keep bumping into things that would be easier to do if I just changed core are a lack of creativity / knowledge of the codebase on my part, or an indication that core is trying to do too much.

Maybe some things that are more mud specific details should be moved out of /src and into some other folder? One of the hard parts there is really distinguishing what can stay and what can go. Skills obviously would need to be edited by a mud implementer, but even stuff like the room_exits function would be nice if it just emitted an event somewhere that said 'hey, i don't know what to do with this command, help me out here' and left the implementation up the mud developer. But include a default handling of that scenario outside of core to catch it and show how one way to handle it.

It could be cool if core was something like a git submodule so we could just pull in updates and treat it like a dependency, developing our muds in our own repositories instead of in forks of ranviermud.

Anyway just tossing things out there, I haven't fully thought any of this through by any means.

[shawncplus]

Hmm, that's actually a really good idea. I'll have to do some deeper research into the asynchronicity of events. Because doing something like emit('blah') at the top of core functionality and letting that act as an override if they provide events might work and keep it separate.

[timmcd]

Would a plugin to create "aliases" that are checked first on player input work to solve this problem? Or would I have to hack on the engine src to make this happen?

[shawncplus]

@timmcd well like in my previous comment, a good solution to this, as @adamkittelson suggested, is to implement events at the top of any null state input (that is, any time what the player would type is sent to the command parser instead of state-specific stuff that traps input). For example: at the top of commands event I could emit an event called 'onCommand' or something that plugins could hook into. So they could trap it and force the player into a new state bypassing the core command parsing. This will, like any plugin, be vulnerable to poorly written plugins or ignorance of the principle of least astonishment but I guess that's the risk one takes.

[lucascube]

I too would also like to see this. When pressing s and saving seems unnatural from a players perspective. I don't want to do a hack job, so what is the best way to modify the core to handle this issue? Does it reside with in the command.js or is there more to it?