Server command line API

[ArthurCose]

There's a need for two command interfaces, one from the client, and one from stdin. A command from the server would not have a player_id.

Net:on("command", function(event)
  -- { player_id: string?, command: string }
  print(event.player_id, event.command)
end)

Responding to the client would require a new function or a set of new functions. We have print, warn, and printerr for stdout, it may make sense to have Net equivalents such as Net.print(player_id, ...) with nil player_id resolving to stdout instead of sending a packet.

Net:on("command", function(event)
  if not event.command:find("^/echo ") then
    return
  end

  local message = event.command:sub(7)
  Net.print(event.player_id, message)
end)

The command listener above would respond to /echo hello with hello to the player or cli depending on where the command was entered. A simple chat could be implemented by running Net.print over every player if the message does not start with a /. The scripter could decide if the chat would be per area or server wide as well.

[TheMaverickProgrammer]

I greatly dislike the idea of a chat. Since commands should always return the status of the command, I imagined a callback that returned a string or an object that encodes the status in the string.

Net:on("command", function(event)
  if not event.command:find("^/echo ") then
    return Net.Results.Error("Use /help for a list of commands.")
  end

  local message = event.command:sub(7)
  return Net.Results.Ok(message)
end)

This assumes nil returned is a special case that would print nothing or perhaps something helpful like "No response".

I like the idea of event containing the player_id of who used the command. But with this pipeline, we'd already know who to return the value to. We can still use player_id to perform some actions on their behalf such as warping around the map for debugging.

Also, forcing a return like this instead of exposing something like Net.print(...) avoids creating the possibility of chat since it will only return and feed to the person who ran the command.

[ArthurCose]

I'm not too against this, I'm wary of Net.Results since it's another API feature that may require more thought.

As for I greatly dislike the idea of a chat and avoiding creating the possibility of chat, we should really focus on letting scripters achieve more and not less, a chat was an example of how we can achieve more with a console feature without it being the intended use.

There are other uses people could come up with that are more in line with intended use cases, such as displaying the result of a command that may finish after some delay or broadcasting the use of a command to other privileged users to inform malicious use.

These use cases were not something I thought of when I originally came up with Net.print(...), but since it's more flexible these are achievable.

[TheMaverickProgrammer]

Chat will open up a toxic problem to deal with. It's better we don't supply creativity on this one issue.

[ArthurCose]

That's something for server owners to decide. I'll agree to not make it a goal if you don't want it still, but we shouldn't block ideas just because it opens up others is what I'm getting at.

[ArthurCose]

We also already have BBS, so it's an odd thing to be against when server owners can already implement a chat through it.

[TheMaverickProgrammer]

BBS is easier to regulate and stores every conversation locally for auditing if need be. Dynamic chats are harder to regulate. I am very much in favor to discourage and prevent a real-time chat feature in OW.

[ArthurCose]

A dynamic / real time chat can be implemented through the BBS UI is what I mean. (Press L to open BBS from anywhere, leave a message and view them)

It isn't necessary to store every conversation outside of RAM either with the BBS API.