Mudlet: 使用函数使 commandSeparator 可设置

或者您可以使用正确的形式，即 sendAll("com1", "com2", "com3", "com4")
或者你可以使用 getCommandSeparator 然后使用它的输出来形成你的字符串，IE

local cs = getCommandSeparator
local commands = {
  "com1",
  "com2",
  "com3",
  "com4",
}
send(table.concat(commands, cs))

我不确定我们是否要鼓励脚本作者在他们的脚本中设置/重置命令分隔符。 我最终会遇到很多人问他们为什么不能再次使用分号，或者为什么冒号突然将事情分成两个命令，而只需要在重置之前你的函数出错一次。 特别是因为如果它是;并且现在玩家留下了一个意外损坏的设置，那么你不会对它做任何事情。

话虽如此， setCommandSeparator 可能只是拥有全套首选项 getter/setter 就很好，但这正是它不应该用于的。

很公平。 除了潜在的问题，能够从主控制台lua setCommandSeparator("somethingElseTemporarily")将是解决习惯于“;”的玩家问题的一步作为命令分隔符。 如果它实现了，它可能需要一个 >>>小心误用，你的脚本可能会中断。 <<< 在手册中。

我很困惑为什么命令分隔符的所有这些临时更改都在进行。 如果他们习惯了;为什么不像他们习惯的那样将其更改为; ？ 当他们可以进入设置并将其更改为他们实际想要的内容时，需要输入两次来来回更改它。

似乎您想要一个别名，该别名将按照恶魔的第一条评论的方式输入到 sendAll

人们究竟在你的其他客户端中输入什么来发送多个命令，但又不干扰闪烁的笑脸和服务器端的恶作剧？

我还认为，省略设置命令分隔符的函数是执行级别的有意识和深思熟虑的决定：grin：以避免一个脚本/包更改它而另一个（可能是异步的）从一个运行计时器！）处于活动状态。

据我所知，关于此的主要讨论在 #1866 中。

这听起来确实像是我们可能已经做过的事情，但我认为可访问性可能最终需要我们创建某种方式来至少从命令行设置它，即使它与 lua API 本身是分开的。

我很困惑为什么命令分隔符的所有这些临时更改都在进行。 如果他们习惯了;为什么不像他们习惯的那样将其更改为; ？ 当他们可以进入设置并将其更改为他们实际想要的内容时，需要输入两次来来回更改它。

问题在于 MUD 接受 ';' 作为输入，无法输入';' 如果 ';' 则没有菜单跳转是您的命令分隔符。 能够制作笑脸是一回事（可以创建一个 mudlet 别名，在使用聊天频道时将命令分隔符临时切换为无害的东西以避免这种情况）。 另一个是 MUD 可以存储服务器端别名，与客户端别名相比，它们通常处理速度更快，创建速度更快/更容易，但这些使用 ';' 也将命令分开。

在我看来，这些都是不使用;作为命令分隔符的理由。

不幸的是，当我们已经有数百个使用send("tens of commands separated by ;")的触发器和客户端别名在更改命令分隔符时全部中断时，这不是一个选项。 我认为这个习惯来自 ZMud，它使用;来分隔命令，尽管 ZMud 的解析器会发送;如果它被空格包围。 如果将命令分隔符加倍只是将其发送到 Mud 呢？ 就像如果您的命令分隔符（例如在我的情况下）是;然后发送;;将发送一个;到泥而不是例如键入say hello everyone;;)将发送say hello everyone;) 。 如果您使用;;作为命令分隔符，那么您将使用;;;;转义命令分隔符并发送;; 。 可以在首选项中有一个复选框，可以启用/禁用该选项，默认情况下禁用，以及避免破坏任何将命令分隔符加倍可能会破坏的功能，但我不认为会有什么危害。

如果你用过;; 作为命令分隔符，你会做 ;;;; 转义命令分隔符

你认为人们会很好地把分号打四次吗？ :thinking: 我不认为这是现实的。

你认为人们会很好地把分号打四次吗？ 🤔 我不认为这是现实的。

我不认为那些已经采用 2 字符命令分隔符的人会发现需要经常转义他们的命令分隔符。 您需要多久从已经设置为;;的命令分隔符中逃脱？ 另一种方法是永远无法以任何方式将;;发送到 MUD，对吗？ 我同意对于那些为其命令分隔符设置了 2 个或更多字符的人来说，转义会变得乏味，但在命令分隔符中设置 2 个或更多字符并不是要在发送到泥浆时遇到问题转义字符的单个字符？ 看看人们使用什么作为命令分隔符，以及他们是否采用了;;或其他一些双重字符的民意调查会很有趣。

我认为民意调查不会有帮助，因为那是在说“让我们搞砸少数”，无论少数最终是谁。

原始脚本：

local x = getCommandSeparator()
if x ~= ";" then setCommandSeparator(";")
send("com1;com2;com3;com4")
setCommandSeparator(x)
else
send("com1;com2;com3;com4")
end

这是一个疯狂的工作量，为什么要把事情弄得这么复杂？ 如果您有几件事情要发送，请使用sendAll() ?

我认为民意调查不会有帮助，因为那是在说“让我们搞砸少数”，无论少数最终是谁。

我看不出任何人会如何被一种逃避命令分隔符的方法所迷惑。 新的首选项选项或功能不应破坏任何当前功能。 我很好奇人们实际使用什么作为他们的命令分隔符，如果人们采用了 2 个字符的命令分隔符，以便他们可以将该字符发送到 MUD 或不发送。 如果您的命令分隔符是单个; ，则;;)将发送;)并绕过命令分隔符。 如果您的命令分隔符是双;;则;)仍将发送;)而不激活命令分隔符。 如果您出于某种原因想发送;; ，例如gossip Hey guys, I use Mudlet and my command separator is ;; ，那么您可以输入;;;;将;;发送到 MUD前面的例子。

这是一个疯狂的工作量，为什么要把事情弄得这么复杂？ 如果您有几件事情要发送，请使用sendAll() ?

如果我们为那些喜欢使用;作为命令分隔符但有时仍需要实际发送;到他们的 MUD 的人提供setCommandSeparator()函数，那将是一种解决方法。 sendAll()如果只有 2 或 3 个命令，效果很好，但是当您连续执行 30 或 40 个命令时，与使用现有的;命令分隔命令相比，快速编写这些命令会变得乏味分隔器。

我想这已经变成了 2 个建议，一个用于setCommandSeparator()函数，另一个是Double command separator to bypass the command separator的首选项复选框选项。 在这种情况下不确定 Github 的礼仪，所以我很抱歉！

当您告诉某人他们必须输入;;;;时，我认为您不现实……对不起！ 你可能得到的回应是“你在开玩笑吗？”

出于特定原因，我们一开始没有包含该功能 - 它会导致不良习惯。 我了解您游戏中的玩家对这个坏习惯的摩擦以及它的难度，他们希望通过放入非常大的脚本别名来做更多的工作，这些别名会更改、编辑等与分隔符混淆，而不是更改习惯......但也许最好将习惯改成更好的东西？

如果您想发送多个内容，请不要将send()与命令分隔符一起使用。 这是不好的做法。 出于这个原因，我们有sendAll()可以完全避免这些混乱。 请参阅前面粘贴的代码恶魔。

我完全明白您希望更顺畅地过渡到 Mudlet。 但是养成坏习惯可能不是一个好方法，因为最终 Mudlet 会变得和其他客户端一样糟糕，不是吗？

当您告诉某人他们必须输入;;;;时，我认为您不现实……对不起！ 你可能得到的回应是“你在开玩笑吗？”

他们当然不必这样做，只要他们想出于任何目的逃避命令分隔符。 如果他们使用单个;作为命令分隔符，他们只需键入两次即可转义并发送单个; 。 ;)

如果您想发送多个内容，请不要将send()与命令分隔符一起使用。 这是不好的做法。 出于这个原因，我们有sendAll()可以完全避免这些混乱。 请参阅前面粘贴的代码恶魔。

不幸的是，当我编写了很多别名和触发器时，我没有意识到sendAll()是首选选项，我也不知道用于输入大量方向的speedwalk() 。
所以我最终得到了很多看起来像这样的别名"brief;compact;s;s;w;w;w;w;w;w;w;w;w;w;w;w;w;w;w;w;s;w;w;s;s;w;s;s;s;s;s;e;s;s;e;e;s;e;e;n;e;e;n;e;n;d;d;n;n;n;d;e;e;s;s;s;u;u;u;n;u;u;n;n;w;n;n;u;u;u;n;n;enter lift;u;s;s;s;s;s;s;s;d;d;d;e;e;e;s;s;s;e;e;e;s;s;e;s;e;s;e;e;s;u;u;u;u;u;e;n;n;n;e;n;n;n;e;n;n;n;n;e;e;s;e;s;e;n;n;e;n;e;n;e;s;e;s;e;e;s;s;s;e;e;e;s;brief;compact"

回到主题，我不相信当需要将用户选择的任何字符作为命令分隔符发送到 MUD 时，必须通过菜单跳转来交换命令分隔符，然后再次跳转菜单以将其切换回来，这是一个在这方面对其他客户端的设计改进，我认为 Mudlet 可以做得更好。

打开一个可以进行正则表达式搜索和替换的编辑器，将这个模式放入： (.+?);并替换为"\1", ，这样就可以为每个别名提供 95% 的路径。

不幸的是，当我编写了很多别名和触发器时，我没有意识到 sendAll() 是首选选项，我也不知道用于输入大量方向的 speedwalk()。

好的，我们将在这里改进文档，以便对未来有所帮助。

编辑：这是在所有相关的地方完成的。

我的问题仍然没有答案：

人们究竟在你的其他客户端中输入什么来发送多个命令，但又不干扰闪烁的笑脸和服务器端的恶作剧？

例如，我可以假设大多数玩家甚至不想深入研究别名脚本，他们只想输入诸如speedy s;s;w;w;w;s;s;s;e;s;s;e;e;u;u;u;n;n;enter lift;u;s;s;d;e;e之类的东西。

如果是这样，您可以轻松构建和分发一个别名，该别名将识别speedy命令并将其余部分拆分为单独的项目，然后可以使用 sendAll 单独发送，如上所述。

瞧，玩家很高兴，根本不需要使用或更改任何分隔符。

我绝不建议使用菜单跳转来继续设置和重置您最喜欢的命令分隔符与某人在他们的脚本中使用的分隔符（请记住，也可能存在冲突的作者）。
我也不会容忍一位作者在没有玩家通知的情况下更改分隔符，并且所有其他脚本的作者和玩家本人都会受到它的影响。

我的问题仍然没有答案：

人们究竟在你的其他客户端中输入什么来发送多个命令，但又不干扰闪烁的笑脸和服务器端的恶作剧？

从我问过的玩家那里，我听说了四种不同的方法来禁用/绕过菜单跳跃之外的命令分隔符。

1. ~在命令分隔符之前，所以~;会发送;
2. 将命令分隔符加倍，这样;;将发送;
3. 热键 ctrl+r 禁用命令分隔符等
4. 控制台输入栏末尾的图标，用于禁用命令分隔符

据我所知，在我们的用户中，首选的命令分隔符是; ，但其他客户端提供了多种方式来逃避命令分隔符，因此发送笑脸或向需要;的泥浆发出命令

逃避它对我来说听起来不错 - 有人知道 zmud/mush 做什么吗？

ZMUD 说：

文本被解析为由命令分隔符分隔的一系列命令（默认为 ;）。 每个命令都包含命令名称作为第一个单词，前面是命令字符（默认为 #）。 引号（“”或 ''）或方括号（[] <> 或 {}）中使用的命令分隔符在分解单个命令时会被忽略。 例如
#SAY {a;b}
是单个命令，其中
#SAY a;b
是两个命令。

MUSHCLIENT 社区提示：

在 MUSHclient 中，如果您以分号开始一行，则后续的分号不再被视为行分隔符。

Mushclient 的方法似乎更合理......但仍然想帮助宽恕不良行为吗？ 修复现有别名并不难，请参阅https://github.com/Mudlet/Mudlet/issues/3677#issuecomment -620511178，并且有了更好的文档，更少的人会开始犯错误。

@KitchenMUD你能用它修复你的别名吗？

@KitchenMUD你能用它修复你的别名吗？

这很乏味，但我可以使用您建议的方法将使用send的那些转换为sendAll 。

希望没有比嵌入setCommandSeparator()更多的工作

希望没有比嵌入setCommandSeparator()更多的工作

@vadi2也许这对我来说是一个糟糕的例子。 我想既然我们已经有了getCommandSeparator() ，那么对应的setCommandSeparator()函数将是一个简单的修复。 我认为，主要问题是 Mudlet 应该有一种方法可以在不要求用户跳转菜单的情况下转义所选命令分隔符。

也许更好的功能是一个新功能，它完全忽略命令分隔符的解析并直接发送代码中的输入内容？ 这样可以更安全地防止最终用户在 UI 解决方案之外搞砸一些东西。

也许更好的功能是一个新功能，它完全忽略命令分隔符的解析并直接发送代码中的输入内容？

我喜欢这个主意。 它会为你解决吗？

@Mudlet/lua-interface 中的其他人怎么看？