Hellclient 社区

jarlyyn

界面优化在关系地图中，会显示房间对应的Marker信息

jarlyyn

更新内容为加入脚本shared数据功能和相关api

shared为使用同一个脚本的游戏可以共享读取的数据。

相对于现有的数据：

脚本数据只读，共享。
Mod数据只读，共享，需要额外开启
用户数据读写，独立。
共享数据读写，共享。

jarlyyn

通过测试，将HMM编译为动态链接库，然后封装成lua库供lua调用，大概能在lua(非git)跑出45 ms的速度，也算可用了。

jarlyyn

经过实际业务的测试，很遗憾的放弃hmm.ts的lua版性能支持。

由于HellMapManager的功能日渐复杂，性能压力也越来越大。目前的HMM的性能测试数据如下

API模式，普通寻路，9ms,十分优秀。
TS转译js,node执行 20ms,基本可用。
TS转译lua,luajit执行，100ms,勉强可用。
TS转译lua,lua执行，500ms,完全不可用。

由于绝大部分客户端仅支持原生lua, 并不支持luajit，而且ts转译lua还是有不小的性能损失的。所以hmm.ts基本不可能在可见的技术情况下达到可用的程度。

因此，我们不得不遗憾的承认，没有能力让hmm.ts达到在各大客户端可用的程度。

hmm.ts的lua版本仅提供兼容性支持，提供可编程的数据转换。

如果lua机器需要使用hmm数据库，需要走api通道。

当然，如果有可能的话，我也希望能让支持lua的客户端能高效的使用全功能的hmm.ts功能。

jarlyyn

升级flutter版本
修正部分文字错误

jarlyyn

API版本更新到 1006
HellMapManger 变量页面显示优化

jarlyyn

对于整个移动模块来说，最核心的可能就是移动失败处理了。

本身对于大部分系统来说，失败/意外流程处理都是最复杂的。而移动模块的失败处理大部分面对的是wiz的恶意，所以更强调可扩展性和可维护性。

对于移动失败，本质来说，就是：

发出移动指令
2.预期会收到成功信号，或者各种失败信号
3.如果收到成功信号，则对当前移动的这一步进行核销。
4.如果受到的是失败信号，则根据具体的失败信号数据进行处理，重规划路线/重试/放弃失败。

因此，移动失败是一个很典型是预期管理

我做的预期管理模块有很大一部分目的就是为了移动失败处理设计的。如果是其他语言/客户端的机器，也能通过各种类库或者触发器分组的功能进行预期管理。

以newhelljs为例，代码地址

    App.Map.StepPlan = new App.Plan(
        App.Map.Position,
        function (task) {
            App.Move.RetryStep = false
            let tt = task.AddTimer(App.Map.StepTimeout, function (timer) {
                return App.Map.OnStepTimeout()
            }).WithName("timeout")
            task.AddCatcher("core.longtimestep", function () {
                tt.Reset(App.Move.LongtimeStepDelay)
                return true
            })

            task.AddCatcher("core.retrymove", function () {
                App.Move.RetryStep = true
                return true
            })
            task.AddCatcher("core.movereset").WithName("movereset")
            task.AddCatcher("core.wrongway").WithName("wrongway")
            task.AddCatcher("core.walkbusy").WithName("walkbusy")
            task.AddCatcher("core.walkresend").WithName("walkresend")
            task.AddCatcher("core.walkretry").WithName("walkretry")
            task.AddCatcher("core.walkfail").WithName("walkfail")
            task.AddCatcher("core.blocked2", (catcher, event) => {
                if (App.Core.Room.Current.ID == "") {
                    return true;
                }
            }).WithName("blocked2")
            task.AddCatcher("core.blocked", (catcher, event) => {
                catcher.WithData(event.Data)
            }).WithName("blocked")
            task.AddCatcher("core.needrest").WithName("needrest")
        },
        function (result) {
            switch (result.Type) {
                case "cancel":
                    break
                default:
                    switch (result.Name) {
                        case "timeout":
                            break
                        case "movereset":
                            App.Map.Room.ID = ""
                            App.Map.Retry()
                            break
                        case "wrongway":
                            if (App.Move.RetryStep) {
                                App.Map.Resend(0)
                                return
                            }
                            App.Map.Room.ID = ""
                            App.Sync(() => {
                                App.Map.Retry()
                            })
                            break
                        case "walkbusy":
                            App.Map.Resend()
                            break
                        case "walkresend":
                            App.Map.Resend(0)
                            break
                        case "walkretry":
                            App.Map.Retry()
                            break
                        case "blocked":
                            App.Move.OnBlocker(result.Data)
                            break
                        case "blocked2":
                            App.Core.Blocker.BlockStepRetry()
                            break
                        case "needrest":
                            App.Move.NeedRest()
                            break
                        case "walkfail":
                            App.Move.OnWalkFail()
                            break
                        default:
                    }
            }
        }
    )

很明显，是对于整个移动做了预期。

首先这个预期是基于App.Map.Position的

Map库中有两个Position

App.Map.Position 当前房间范围
App.Map.MovePosition 当前移动的范围

所以，当成功移动时，整个移动处理会因为离开范围而被"cancel"

当没有Cacnel时，说明意外出现了。

不同的信号(事件)会根据在switch里做分支判断，调用各种异常。

这也就是整个失败处理的底层逻辑

在完全基于hmm开发的hongchengjs中，我为了可维护性，做了些调整，将常见的移动失败作为一个文本保存，启动时调入内存放在一个Hash表里，直接做表匹配模拟事件，算是一个小的结构优化。

代码地址

在失败处理中，有四个处理是最为典型的

第一个是路线错误

也就是"core.wrongway"事件。

触发后会清空当前房间信息，调用当前移动的Retry方法进行重新规划和移动。

第二中是路线禁用

也就是"core.blocked2"事件。

出发该事件后，说明被拦截，而且不该击杀然路Npc，会把当前房间和目标房间的出口临时禁用，然后重新规划路线。

第三种是插入战斗

"core.blocked"事件

会把当前移动进行快照，然后击杀拦路npc,再对快照进行还原，继续移动。也是很经典的形式。

最后是重新规划

"walkretry"事件

这个事件和路线错误一样都是直接调用重新规划。

区别是这个事件本质是一个衍生事件，在我的事件系统中，一般会调用Filter进行处理，一般是调整当前Move的上下文标签。然后再根据最新上下文标签进行重新规划。

这四种基本就是主要的移动失败处理的内容。当然，不同的Mud可能还会有一些细节上的调整。

移动失败处理的主要处理方式就是

重试。
调整上下文，重新规划，避免失败出口。
挂起移动，解决意外，还原移动并继续，

jarlyyn

选项(Option)模式是一种新近流行的设计模式，用于配置类，主要流行于于Go语言(golang)。

每个设计模式本质上就是正对一个场景的一个常见小招式。

选项模式也不例外。它解决的主要问题是：

复杂系统的可复用编码配置。

典型的选项模式的形式是

 var system=Systm.New(opt1,opt2,opt3...)

通过opt1,opt2,opt3来对系统进行初始化。

复杂系统

选项模式正常情况下一定是解决复杂系统的问题的。

甚至可以简单粗暴的认为选项模式是一个改良的构建者(builder)模式，即配置器列表。

不复杂的系统没有使用选项模式的必要。

对于选项模式，最典型的就是和Builder模式一样，用来处理一个封装类，类里封装了大量的函数/接口，可以根据需要去把这些函数进行替换。

默认可用及扩展性

选项模式的优势其实很大一部分体现在可扩展性上。

由于选项模式的选项都是可选的，而且不可能在代码写完后自动扩展。

所以，选项模式中可以认为一定有部分选项没有被配置过。新建的封装类一定在所有选项中可以运行的默认值。

同样，因为有这个默契，大部分采用了选项模式架构的代码一定有很好的兼容行。因为添加的新的功能和实现必须与原有的行为表现一致。

可以认为这是对代码结构的一种架构上的约束。

基于功能/模块配置

选项模式的主要价值，就是体现在可以分块的，可选的进行配置。

因此，从逻辑上来说，每个选项代表了一种功能，或者模块。

具体来说，举个自理，我的go语言http请求库，默认情况下会生成一个标准请求。比如：

var myreq=preset.New(Host("http://www.baidu.com/)

如果我这是一个Post请求，需要带一个纯文字body，代码就变成了

var myreq=preset.New(preset.Host("http://www.baidu.com/,preset.POST,preset.StringBody("12345"))

而这个请求如果还需要带上一个特定的请求头，那么就是

var mreq=preset.New(preset.Host("http://www.baidu.com/,preset.POST,preset.StringBody("12345"),preset.Header("auth","abc"))

从这个例子应该能喊好的看出选项模式的主要用法了。

在构建复杂系统时，按功能和模块来进行配置，同时提供很多预制件，可以直接初始化为需要的功能。

在系统进行升级扩展时，由于保持默认行为的一致性，也会有很好的兼容性。

在Mud机器人中的应用

从选项模式的特点来看

系统复杂
高扩展性
功能化，模块化

也只有移动模块这个复杂系统需要用得上选项模式。

我在newhelljs的移动模块就是使用了选项模式的架构，具体可以看相关的内容。

jarlyyn

数模转换其实是一个很古早的概念了。

就是将原始的模拟信号，转换成数字信号，然后数字化的系统才能根据数字信号进行操作。

首先，从严格意义上说，服务器返回的文字信息本质是ansi控制文本，是一种带显示控制的控制，目的是进行一种美观的带格式的外观描述，这的确是一种数字化程度很高的模拟信号。

其次，对于实际的复杂业务来说，把数据抽象成业务数据，将代码隔离为业务层和交互层也是很通用的一种处理技巧，在实际需求上，的确有分割交互层(模拟信号)和业务层(数字信号)的意义。

所以，进行数模转换是一种我很推荐的架构形式。

数据标准化

数模转换而第一步是信息标准化。

也就是，将所有的信号，转为一种有约定格式和共性的基础信号。

很多时候，处理程序还需要对信号做一个2次处理，抽取和判断后生成原生信号的衍生信号。

在这个背景下，处理业务数据的代码才能做到信号形式的无关性。

具体到代码的例子。我在newhelljs里引入了

            App.LineEvent = function (name) {
                return App.Engine.LineEvent(name)
            }
            App.FilterLineEvent = function (filtername, eventname) {
                return App.Engine.FilterLineEvent(filtername, eventname)
            }

两个方法。

App.LineEvent是直接将一个mud行的出发，抛出为一个制定name的event
App.FilterLineEvent是定义一个处理器，在处理器里做预处理和判断，然后确定没问题的话再以eventname抛出事件

App.FilterLineEvent的应用范例:

    //处理房间名
    App.Engine.SetFilter("core.normalroomname", function (event) {
        let words = App.History.CurrentOutput.Words
        if (words.length == 1 && words[0].Color != "" && words[0].Bold == true) {
            App.RaiseEvent(event)
        }
    })

接到可能是房间名的信号后，判断是否符合条件，符合条件再抛出事件。

信号数据采样

在mud中，除了根据行进行分析的时间外，还有很多直接的数据信号取的护理。比如hp,score,skills,i等指令。

这时候需要将传输来的模拟信号(一般是固定格式的表格列表)转换为合适的数据模型，再加以保存。

对于能够主动触发的数据，也要做好缓存的处理。

工作重点

对于根据数模转换对代码进行分层，我们要明白主要的工作重点，这样能更好的根据实际情况进行合理规划。

我们的数模转换的核心目的是

让代码更清晰，易于维护，代码出现问题时能快速定位到相应模块
将业务与实际表现剥离，这样在Mud进行更新/更改界面时，不会需要对业务层进行调整。比较表现层比业务层测试快的多。

jarlyyn

在Mud机器人中遍历其实有两种含义。

第一，依次经过所有给到的房间。

第二，依次经过给到的路径，在需要停止时暂停。

这里主要讨论第二种。

之前说过，每个移动是一堆和移动相关的判断函数的集合。

这里就是要实现继续移动或中止的判断。

参考我的core/zone.js,遍历而实现代码是

    App.Zone.Finder = function (move, map) {
        wanted = App.Zone.Wanted
        move.Option.MultipleStep = wanted.SingleStep != true
        move.OnRoom = function (move, map, step) {
            let item = wanted.Checker(wanted)
            if (item) {
                wanted.Name = item.GetData().Name
                wanted.ID = item.IDLower
                if (map.Room.ID) {
                    wanted.Loc = App.Map.Room.ID
                    Note(wanted.Target + " @ " + wanted.Loc)
                }
            }
        }
        move.OnArrive = function (move, map) {
            if (wanted.Loc) {
                App.Map.FinishMove()
                return
            }
            wanted.Next(map, move, wanted)
        }
    }

很明显，这个Finder是用App.Zone.Wanted作为选项，对move进行了初始化。

这里覆盖了两个方法

move.OnRoom 经过房间(房间信息结束)的触发
move.OnArrive 移动结束的触发。

主要是因为可以多步移动。

代码使用 App.Zone.Wanted.Checker来判断房间中是否有遍历目标。

如果找到目标，则遍历结束(App.Map.FinishMove)。

是一个很标准的任务遍历模型。