多行触发，to be or not to be?
很多新人，在学习写机器的时候会听到要用多行触发解决一些问题，比如ask,比如图形等。然后打出了一串问号。
我开个帖子，解释下触发，多行触发，多行触发的优点，以及为什么我不建议用多行触发，以及我建议的方案。
先丢个我发过的相关帖子
https://www.pkuxkx.net/forum/thread-47122-1-1.html 首先，让我们搞清楚什么叫触发
Mud本质是一个通过telnet连接服务器交互文本的模式。
客户端和服务器的交互是一串2进制流(可以认为是无限长不分行一直持续变化的文字)
在实际应用上，mud大体是由历史信息(以回车分割行，一行串字符，理论上不该有变化，重绘除外)和提示行(未回车的信息，可以输入文字继续，典型就是打开dos窗口的c:\开头的位置)
很明显，大部分的交互内容就是以行为单位的文本信息。
触发就是在 提示行变成历史信息这个时间点，对最新的这个行做判断，确定是否要执行代码的一个工具。
终端的文字数据支持通过ansi控制符进行控制，生成颜色/擦除文字等。
触发 一般 是对处理后的渲染文字进行匹配。
由于 Mud的初始目的是与人眼进行交互，所以触发一般是通过最匹配人眼/人脑模式的通配符和正则表达式来进行工作的。
本帖最后由 jarlyyn 于 2024-4-18 02:27 PM 编辑
然后，是正则表达式
引用wiki:https://zh.wikipedia.org/wiki/%E ... 8%E8%BE%BE%E5%BC%8F
正则表达式（英语：Regular expression，常简写为regex、regexp或RE），又称规律表达式、正则表示式、正则表示法、规则表达式、常规表示法，是计算机科学概念，用简单字符串来描述、匹配文中全部匹配指定格式的字符串，现在很多文本编辑器都支持用正则表达式搜索、取代匹配指定格式的字符串。
总的来说，正则表达式表达的是一种文字上的规律(而非代码）,所以正则表达式本身不包含也不应包含逻辑，只是对文本形状的一种描述
很明显
正则表达式最大的优点是直观，人眼脑可直接处理
正则表达式最大的缺点是功能弱，表达力有限。
在真正写代码时，看到文字就直接丢出正则处理是一种常见的被鄙视的行为。
对于我的认知来说，正则表达式最大的以一就是提示程序：“这个代码属于疑似病例，需要处理判断下”。
好，接下来解释下多行触发。
多行触发解决的不是正则/触发的问题。
像我上面所说，触发是用来匹配当前行的。按程序员的说法，触发是stateless的协议，和网页的HTTP一样（参考 https://stackoverflow.com/questi ... -stateless-protocol）
也就所，两次匹配之间是独立的，没有上下文(Content)来提供背景进行复杂判断。
常见场景就是你见到了韩式忠说的任务地点，但是由于没有上下文(相关的行)，你不知道老韩是否是回答你。
所以，为了把上下文引入触发，才有了要多行(匹配多行)的说法，让你确定韩世忠是针对你提问说的地点。
但是，顶真的读者会记得,我之前说了，正则表达式只是对文本形状的一种描述，和上下文(相关文字行)没有关系啊，是不是有点不太对？ 为什么我说不应该用多行匹配？
在回答问题前，我先要问一个问题，为什么触发会需要上下文？
如果回答只有对应玩家能看到，或者回复很明确(玩家 xxxx的npc出现在 西安 东大街)，需要上下文么？
不需要。
本质上来说，需要上下文的回答，就是WIZ是不惜增加服务器负担试图用来限制机器人的。
所以，如果多行匹配一下，简单形状判断就能绕过去，你真的觉得wiz都是大聪明么？
wiz会给你只固定形状的干扰么？
当然不会。
用形状匹配来解决上下文，在我眼里，就是头痛医脚的方案。头痛了，泡泡脚，或许能缓解头痛，但他不治本啊。
既然我们知道这题的目标是上下文，上下文就是相关的文本行。
那很明显，我们治本的方案，就是收集相关上下文吧？
jarlyyn 发表于 2024-4-18 02:15 PM
为什么我说不应该用多行匹配？
在回答问题前，我先要问一个问题，为什么触发会需要上下文？
很好，我们的方案来了。收集相关上下文。
我之前说了，相关上下文就是 文本行，有顺序的文本行。
那很明显，我们维护一组文本行就行了。当然，最好不光维护文本行，还要维护色彩这些额外信息，那我们就能解决接任务时的99%的问题了。
具体来说，我们只需要知道 什么时候可以开始 收集，什么时候可以结束 收集，什么时候可以过滤，就行了。
以ask来说
很简单，以"你向xxxx打听关于xxx的事"开始，ask后发一个response或者checkbusy,作为结束(偷学之类可以用计时器)，过滤不需要 的文字，就是完整的任务信息了。
同样的，地图信息可以以(区域名）为触发开始，破阵可以以"^[竹|八卦]$"为触发开始，以response或者checkbusy作为结束，获取上下文。
这样，我们就可以抽象出一个功能。
指定开始记录，记录从当前行开始行信息，在指定触发后结束记录，获取到期间所有的文本信息，判断指定行的内容或者循环处理所有行的问题。至于色彩触发之类在这个模式里更是简单的一笔。
做成一个能复用的功能，不必绞尽脑汁写几十个几百个多行触发强？
写代码，不要写呆子代码么。
当然，多行触发也不是一无是处。
有时候有些东西不是为了解密，只是单纯的判断形状，那多行触发也未必不能以用。
比如典型的，出口过多分多行时，用多行触发就很不错。
毕竟，多行触发，就像我之前说的，还是有优点的
直观，人眼脑可直接处理
维护真的很省力。
解释完原理，相应的代码方案，会与下一个帖子相关。
现在要去开会了，溜了溜了。 这期比较水啊。没什么干货，全是牢骚话。
页:
[1]
2