简介：《原始传奇》（UO）专属的 TUS 全站脚本是一套免费提供的 C/C++ 自动化扩展集合，面向追求高效操作的玩家与希望深入游戏脚本机制的开发者。它围绕移动、战斗、交易、任务等核心玩法提供自动化支持，并通过 ini 配置文件开放参数调节，用户可根据服务器版本 12.6.0.4 的实际环境灵活适配。压缩包内共 113 个文件，其中 scp 脚本构成主要逻辑框架，txt 说明文件辅助理解配置，htm 网页用于展示角色状态，log 日志记录运行过程，chm/help 文档提供参考帮助，整体体积仅 1.12MB，便于下载部署。除了常用的菜单、地图、物品、技能定义外，还附带了状态显示和聊天快捷功能，玩家能据此快速构建个人专属的操作界面。目前已有 5092 人学习/下载，对有 C/C++ 基础或希望自定义 UO 玩法的用户，这套脚本提供了扎实的参考资料和可直接运行的基础框架。
1. 为什么我会把这份TUS脚本从硬盘角落翻出来
某天凌晨两点，游戏角色在矿洞里挂着挖矿，我迷迷糊糊看了一眼屏幕，发现角色站在原地发呆，聊天框刷出一排同一条报错。那一瞬间我意识到，TUS脚本崩了。这套当年用C/C++写的TUS脚本，是给某款老牌网络游戏做自动化操作用的UO脚本集合，从角色移动、战斗、拾取到状态监控，全靠一个exe加一堆scp文本文件撑着。折腾到天亮我才修好，但也因此决定把整套资源的文件构成、启动方式、常见坑和二次开发思路完整整理一遍。如果你手上有这份TUS脚本但不知道从哪个文件开始看，或者跑起来之后总出幺蛾子，这篇笔记就是给你写的。
2. 看懂文件组成：TUS到底由哪几个部分协作
2.1 文件角色速查：哪一个是引擎、哪一个是配置
第一次拿到解压包的人最容易懵：里面既有exe又有chm、hlp、htm，还有一堆没有扩展名或者看起来像杂物的文件。但拆开看，这套TUS的职责分层非常清晰。我把输入里列出的文件逐个标了一下角色，方便你拿到手就能对号入座：
| 文件 | 角色 | 实际作用 |
|---|---|---|
| tusSvr.exe | 引擎主体 | 读取配置、加载脚本、与游戏客户端交互的入口程序 |
| tus.ini | 总配置入口 | 控制引擎启动参数、脚本加载路径、日志级别、热键绑定 |
| TUShelp.chm | 编译版帮助文档 | 离线手册，查函数和脚本语法用 |
| HOG.HLP | 辅助帮助文件 | 老式WinHelp格式，部分老玩家习惯看这个 |
| webpage1.htm | 状态页模板 | 状态页的HTML结构模板 |
| webpage2.htm | 状态页辅助页 | 状态页里的样式或附加信息页 |
| tusstatusbase.htm | 状态页成品壳 | 引擎把角色实时数据填充进去后展示用 |
| tusitem.scp | 物品交互脚本 | 处理拾取、使用、丢弃、识别物品ID等逻辑 |
| tus1140426.log | 运行日志 | 日期命名的日志文件，记录脚本执行轨迹与报错 |
这里有个容易忽略的点：日志文件名tus1140426.log和tus1140427.log，看名字就知道是带日期的滚动日志。也就是说，这份资源在归档之前是被人实际跑过的，而且至少跨了两天运行。日志不是单纯凑数的文件，后面排错时它就是第一手线索。至于tus.ini、tusitem.scp这类文件名的同类兄弟，比如菜单、地图、定义表之类的scp，可能因为打包时取舍没有全列在清单里，但只要有tusSvr.exe和tus.ini在，整套脚本的骨架就还在。
2.2 三层协作模型：exe读ini、ini调scp、scp写日志
TUS这套脚本你能改的部分，跟需要编译的部分是分开的，这是它最让人舒服的设计。我一般会把它理解成一个三层结构：
第一层是tusSvr.exe，一个可执行引擎，它负责跟游戏客户端通信，比如读取游戏窗口的内存数据、模拟键盘鼠标操作、拦截游戏发来的网络消息。这一层你改不了，也不需要你看懂C++源码，只要知道它是个黑匣子，输入是配置和脚本，输出是游戏内的行为和日志文件。
第二层是tus.ini，它是唯一让引擎知道“该干什么”的入口。ini里面写明了要加载哪些scp文件、延迟多少毫秒、日志写到什么级别、热键绑在哪个键上。引擎启动时先读ini，然后按ini里的指示去找对应的scp文件。
第三层是那些scp文本脚本，它们才是你真正能自由发挥的部分。scp里写的是类似宏命令的指令序列，引擎负责按行解析并执行。之所以把逻辑放在scp而不是编译进exe，就是让你改行为时不用重新编译——这个设计在当年脚本圈里是通用做法，好处是迭代快，坏处是语法错误得靠日志自己排查。
日志则是整个模型的闭环出口。引擎每执行一条关键指令，就往日志里写一行。挂机挂了几个小时出了问题，你打开最新那个日期的日志文件，拉到报错点附近，基本就能定位到是哪个scp哪一行出的事。
2.3 tus.ini参数速览与修改原则
tus.ini是整套脚本的钥匙。我不建议你上来就改一堆参数，先打开看一眼结构，确认几个关键项即可。典型的tus.ini内容大致长这样：
; TUS 主配置示例 [Client] Path=C:\Game\Client.exe Version=12.6.0.4 [Script] Menu=tusmenu.scp Defs=tusdefs2.scp Item=tusitem2.scp Map=tusmap.scp [Status] Port=8080 Page=tusstatusbase.htm [Log] Level=2 File=tus1140426.log上面这个示例综合了常见做法的配置项结构，具体文件名和字段请以你解压出的实际tus.ini为准。重点看几个地方：Path对应游戏客户端exe的完整路径，Version是适配的客户端版本号；Script段下面列出的每个scp文件会被引擎逐一加载；Status段里的Port是状态页服务的监听端口，Page指定填充数据用的HTML模板；Log段的Level控制日志详细程度，从0到3，数字越大越啰嗦。
改这个文件的原则就一条：一次只改一个参数，改完单独启动验证一次。千万别同时改路径、端口、日志级别，出了问题你根本不知道是哪一项导致的。另外，路径里尽量不要带中文和空格，虽然现代系统能容忍，但老脚本引擎经常在这上面翻车，后面避坑章节我会再强调。
3. 部署与首次启动：把文件放对位置再开引擎
3.1 目录结构与版本对应关系
拿到资源包之后，第一步不是双击tusSvr.exe，而是先检查目录完整性。常见做法是：在某个干净的目录下解压，比如D:\TUS，然后把压缩包里的文件按原结构释放出来。接着确认几个关键文件都在同一个根目录下：tusSvr.exe、tus.ini、webpage1.htm、webpage2.htm、tusstatusbase.htm、至少一个scp文件。如果缺了tus.ini，引擎会用内置默认值启动，大概率行为不可控；缺了htm文件，状态页功能就白搭。
版本对应关系是这个环节最容易踩的坑。资源描述里提到的游戏版本号，是脚本适配和测试过的目标版本；如果你本地的游戏客户端版本跟它对不上，引擎可能能启动，但读内存地址和识别消息包时会错位，表现出来就是角色乱跑、捡不起来东西、菜单弹不出。所以部署前先确认自己客户端的版本号，再决定是用这份脚本还是找匹配版本的资源。
我一般还会做一件事：把原始目录完整复制一份改名加后缀_bak，比如D:\TUS_bak。这不是多此一举，后面你改scp改坏了，或者ini改得启动不了，直接拿备份覆盖回去就是后悔药。有人说反正能重新解压，但实操中你会发现，原压缩包可能已经被你放到看不到的角落了，而且解压出来再手动改一遍配置更浪费时间。
3.2 修改tus.ini的五个关键位置
确认版本匹配之后，打开tus.ini，从一堆参数里挑这五个地方来改，其余的先不动。这是我在多次部署中总结出来的最小必改清单，覆盖了从路径到页面的闭环。
第一，[Client]段的Path，改成你本机游戏客户端的实际路径。这个最关键，路径错了引擎连客户端都找不到。第二，Version字段，确认跟你客户端版本一致，不确定就暂时不改，启动后看日志有没有版本不匹配的警告。第三，[Log]段的Level，第一次调试建议设成2或3，虽然日志写得勤，但你能看到脚本每一步在干什么；跑稳定了再调回0或1，减少磁盘写入。第四，[Status]段的Port，默认8080，如果你本机这个端口被其他程序占了，就改成8081或9080，记住改完的端口号，等下要访问状态页。第五，检查[Script]段里列出的scp文件是否都在根目录下，路径只写文件名即可，引擎会从exe所在目录找；如果scp放在子目录，这里要写相对路径。
这五处改完，保存，注意编码格式。老脚本引擎对ini的编码很敏感，最好保存成ANSI或GBK，别用带BOM的UTF-8，否则第一行注释可能直接把引擎带崩。这一点百分之九十的新手都不知道，等你在启动阶段遇到莫名其妙的“闪退”时，优先怀疑编码问题。
3.3 先开游戏还是先开引擎
启动顺序这块，TUS跟很多现代辅助工具不一样，它不是那种把脚本注入已运行进程的类型，而是引擎主动去连接游戏客户端。我实际操作下来，最稳妥的顺序是先手动启动游戏客户端，进到登录界面或者人物选择界面，然后再启动tusSvr.exe。如果先启动引擎再开游戏，引擎可能在等待连接时超时，日志里会留下一条连接失败记录；虽然有时它能自动重连，但我见过不少版本没有重连逻辑，挂久了就直接退出。
验证引擎是否跟客户端建立了联系，看两方面。第一，看tusSvr.exe的窗口标题或者控制台输出，正常时会显示类似“已连接”或“初始化完成”的状态；第二，看最新日期的日志文件，尾部应该有加载scp清单的记录。用命令行确认引擎在跑也很方便：
tasklist | findstr tusSvr这条命令会列出所有名字里带tusSvr的进程，如果有输出说明引擎还活着，没有输出说明它启动后立刻退出了。此时优先检查ini编码和路径配置。
状态页是另一个验证入口。浏览器打开http://127.0.0.1:8080（端口按你ini里填的实际值），如果能看到网页1或者网页2的内容，说明引擎的HTTP服务和状态页模板都正常。这里是玩家血条的实时回显，正常时角色站立不动，状态数值也会定期刷新；如果页面打开但数字一直不变，说明脚本逻辑没跑起来，问题多半在scp加载环节。
4. 核心SCP脚本解析：菜单、定义、物品与地图如何联动
4.1 tusmenu.scp：操作入口与界面挂接
菜单脚本是整套脚本里你最先接触到的东西。当你按下某个热键，弹出TUS的操作菜单，那些条目背后就是tusmenu.scp在响应。它做的事可以用一个伪代码逻辑概括：热键触发 -> 引擎读tusmenu.scp -> 查表找到对应功能 -> 执行功能名下挂的动作序列。
假设tusmenu.scp里有这样一段，用类似宏的语法描述：
MENU_BTN "挂机挖矿" ACTION "move" "x=1200,y=800" ACTION "mine" "count=50" ACTION "move" "back" END_MENU这段示意代码表示菜单里有个“挂机挖矿”按钮，点击后先移动到某个坐标，执行挖矿动作50次，再返回。修改时你要注意：菜单名跟动作条件之间是严格配对的，你改了显示名就要检查对应的动作块还在，不然菜单能弹出来但点下去没反应。这类脚本没有可视化调试器，确认菜单是否生效的唯一办法就是进游戏按热键，弹出来点了看日志。
4.2 tusdefs2.scp与tusitem2.scp：ID到行为的映射
定义文件和物品脚本是TUS里最绕也最实用的一对。grep一下旧脚本的写法，你会发现defs文件本质是张ID映射表，把游戏里的物品ID、技能ID、NPC类型ID翻译成脚本能识别的名字。而tusitem2.scp才是真正的逻辑处理者：它根据defs里的定义，决定遇到某个ID的物品时是捡、是跳过还是使用。
常见做法是，在defs2里给某类物品起一个可读名字，然后在item2脚本里用条件分支处理。比如逻辑上会是这样：
CHECK_ITEM "gold" IF "quantity" ">" "100" ACTION "pickup" ELSE ACTION "skip" ENDIF END_CHECK这段示意代码表达的是：检测到名为gold的物品时，数量大于100就捡起来，否则跳过。这里有个隐藏注意点：不同游戏服务端的物品ID可能不一样，这份脚本基于某个特定版本定义，换服之后ID对不上，脚本会识别不了物品。这时候你打开日志，里面会刷“unknown item id”之类的提示，你需要把目标服务器的实际ID替换进defs文件。查ID的方法通常是查看游戏客户端内的物品信息，或者抓一次正常拾取时的日志输出，里面有引擎识别到的原始ID。
4.3 tusmap.scp：坐标、区域与寻路
地图脚本负责的是移动逻辑，包括从A点到B点的路径点序列、挂机区域的范围划定、以及卡住后的绕过策略。如果tusmap.scp写得稀烂，表现就是角色走到墙角就不动了，或者在两个点之间反复横跳。
典型的地图脚本片段，思路是维护一个路径点列表，引擎按顺序执行移动指令：
ROUTE_START "矿区入口" WAYPOINT "x=1000, y=700" WAYPOINT "x=1050, y=720" WAYPOINT "x=1100, y=750" ROUTE_END这个示例里，WAYPOINT就是路径关键点的坐标。修改时要注意坐标的基准：TUS用的坐标是游戏内的世界坐标还是区块内偏移，直接决定你写的数字对不对。最简单的验证方式是人为走到目标位置，打开状态页或者用日志输出当前坐标，跟脚本里的点对比，差太多就说明基准选错了。另外，路径点之间要有合理的间距，间隔太密脚本走起来一顿一顿的，太疏则容易撞墙或者被地形卡住，要加中间过渡点。
4.4 日志与状态页：验证脚本是否按预期走
你手头的tus1140426.log、tus1140427.log是现成的滚动日志范本，说明这套脚本的日志机制是每天一个文件。调试时我习惯先查看今天日期的日志文件，确认脚本加载列表和初始化状态。如果发现某个scp文件名出现在日志的“加载失败”附近，那原因无非两个：文件不存在，或者文件内有语法错误。
状态页的作用则是把日志没法直观表达的信息可视化。tusstatusbase.htm是数据填充用的模板，引擎会把角色生命、法力、坐标、当前动作等动态数据填进去，刷新浏览器就能看到最新状态。我看状态页的习惯是：每隔十几秒刷新一次，观察数值是否随时间变化；如果数值一直冻结，说明脚本主循环已经停了，这时候回日志找最后的有效执行记录，十有八九是卡在某个等待条件上。
5. 常见问题与避坑：TUS跑不起来的五个细节
5.1 启动tusSvr.exe后窗口一闪而过
现象：双击引擎exe，窗口还没看清就消失了，进程列表里也没有它。原因：不是exe坏了，就是ini配置有问题读不下去，最常见的三个因素分别是ini保存成了UTF-8带BOM格式、[Client]路径写错导致引擎初始化失败、缺少关键依赖文件。解决：先把tus.ini用记事本另存为ANSI编码；检查Path指向的文件确实存在；确保TUShelp.chm和HOG.HLP还在目录里，某些老版本引擎启动时会加载帮助文件作为资源库，缺了就主动退。改完这三处再启动，问题基本消失。
5.2 状态页打不开或者只出空白页面
现象：浏览器访问http://127.0.0.1:端口，要么连接被拒绝，要么页面空白。原因：端口被其他程序占了，或者html模板跟引擎的填充规则对不上。解决：先换端口，把ini里的Port改成8081再重启引擎；空白页则注意访问的是不是webpage2.htm对应的地址，有些版本状态服务有两个页面入口，一个给你看状态，一个给你看配置。直接在浏览器里把webpage1.htm改成实际文件名访问，能打开就说明服务本身活着，问题在模板路径配置。
5.3 挂机挂到一半角色突然定住不动
现象：日志停在某条命令之后，角色就再没有新动作了。原因：最常见是地图脚本里当前路径点无法到达，比如被其他玩家放的障碍物挡住，或者目标点在墙体内；其次是脚本在等待一个条件，比如“等血量回满”但周围没有安全回血点。解决：先看日志最后几行，确认停在哪条action上。如果是移动卡住，给map脚本该路线加一个绕行中间点；如果是等待条件卡住，把等待超时参数从无限改成30秒，超时后执行备用动作或直接回城。这类问题没有一劳永逸的办法，只能定期扫日志。
5.4 改完ini或者scp后启动还是老行为
现象：你明明改了脚本，重启引擎后行为跟改之前一模一样。原因：引擎进程没退干净，旧实例还占着配置和脚本文件，新启动的进程可能因为端口冲突启动失败，你看到的还是旧实例在跑。解决：改完配置后，打开任务管理器确认所有tusSvr相关进程都结束了，再重新启动。从那次翻车之后，我养成了一个习惯：每次改配置前先杀进程，改完再启动，宁可多花十秒，不赌它自己干净退出。
5.5 日志文件增长快得吓人，磁盘空间被吃光
现象：logs目录下几天就积累了好几百MB日志，C盘空间告急。原因：日志级别设成了最高，而且脚本循环频率很高，每个动作都写一行，自然爆炸。解决：把ini里Log段的Level降下来，稳定运行时设成1，只记录错误和关键节点；同时定期归档或删除超过七天的旧日志。日志不是越多越好，它只是工具，出问题时能定位就行，平时让硬盘清净点比什么都强。
6. 进阶：用最小改动原则做自己的TUS功能扩展
想给TUS加一个自己的功能，最怕的就是大改。我摸索出来的稳妥路径是“最小改动、单点验证、随时回滚”。
第一步，改之前先把要动的scp复制一份，命名带上当天日期，比如tusmap.scp.bak_0428。这不是走形式，有一天我改map脚本时手滑删了一个逗号，整个路径表解析中断，角色在矿区入口原地发呆。当时没有备份，只能靠印象把删掉的那行补回来，前后折腾了半小时才恢复。从那以后，我每次改scp都先复制一份带日期的备份，成本十秒钟，省下的是半小时的返工。
第二步，一次只改一个功能块。比如想改“挖矿结束后回城补给”的逻辑，就只动tusmenu.scp里对应的动作块，其他菜单项一概不碰。改完保存，启动游戏和引擎，按热键触发一次，看日志确认这一步执行到位。然后再改下一个点。
第三步，维护一份自己的回归验证清单。每次改动之后，我按固定顺序过一遍：引擎能不能启动；状态页能不能打开且数值刷新；主菜单能不能弹出；某个核心动作能不能执行；日志接不接受新事件。这张表不用很复杂，五到六个检查点足够。它最大的价值不是功能测试，而是让你在改坏之后第一时间知道坏在哪一环，不用从零查起。
最后分享一个实用小技巧：在scp里加临时日志行。调试时，我会在关键的判断分支处插入一条类似“当前执行到XX分支”的日志语句，跑一轮看输出顺序，确认逻辑走向符合预期；验证完再把这些临时日志删掉。这种方法比盯状态页直观得多，尤其适合处理那种“看起来没反应但也不知道卡在哪”的情况。
希望这篇拆解能帮你把手上的TUS脚本真正跑起来。
本文还有配套的精品资源，点击获取
