Skip to content

Infernus 是什么

Infernus 的名字来源于游戏中 id411 的载具(特指 sa 中)。

Infernus 是一个基于 samp-node 打造的库,用于在 JavaScript 层调用游戏的 sdk

WARNING

Infernus项目已进入维护阶段并将逐步归档,后续生态建设将由omp-node社区主导推进,诚邀感兴趣的开发者共同参与。

🚧 施工中

  • omp-node 目前正在积极开发中,未来它会取代Infernus
  • 如果您想尝鲜omp-node,或更喜欢原生语法而没有过多封装,请关注 @open.mp/node

差异

/Infernus + samp-nodeomp-node
运行环境Windows/Linux: Node.js 22.17+Windows/Linux: Node.js 18+
模块规范CommonJS/ESModule(实验性)ESModule
架构支持仅x86x86/x64
底层实现通过sampgdk→fakeamx→原生调用直接调用omp-gdk/omp-sdk
执行效率
兼容性策略通过兼容层polyfill支持三方插件插件需适配sdk并使用特定版本
设计理念1. 提倡完全使用Infernus重构,避免Pawn代码开发
2. 强制采用Steamer替代原生接口
详见官方文档

缺陷

DANGER

是的,一切的开始前您需要了解缺陷。

一些缺陷极大影响了开发体验,建议您以实验性的心态尝试使用 samp-node 生态开发。

总的来说目前生态并不稳定,这是多方面因素导致的。

生态系统

INFO

点击查看已实现的生态包,不保证和原型库执行结果相同,且一定存在BUG。

原有的以 pawn 开发的库,如果您的项目必须依赖这些,那么目前而言会出现两种情况:无人开发或是不兼容。

由于 samp-node 的插件开发是基于 samp 而不是基于 omp,所以对于 omp 而言,一些插件生态基本无法兼容,比如无法访问到一些插件的 native 函数,比如 raknet

这极大程度上的限制了基于 nodesamp 插件生态库开发,这一点需要社区共同努力推进。

Bindings支持

很遗憾,本项目是基于32位的嵌入式node.js,对于bindings的支持是不稳定的,你可能会遇到报错等情况。

在使用本项目前,请注意以下版本要求:

  1. Node版本匹配

    • 请确保你的Node主版本号与samp-node依赖的版本一致
    • 例如samp-node依赖22.17.0,则只能使用22.x版本
    • 不兼容的版本如18.x、20.x、24.x等将无法正常工作
  2. 如果项目已经创建:

    • 先检查Node版本是否符合要求
    • 删除node_modules文件夹
    • 重新运行pnpm install

环境支持说明:目前better-sqlite3模块已在Windows平台测试通过

也许在未来64位的omp-node上迎刃而解。

终端阻塞

重要信息

已通过 monkeyPatch 作为目前的解决方案,修复了此问题。

由于底层的 samp-node 对于部分异步的 node 生态库的兼容性不佳,会导致概率性的终端阻塞。

比如 typeorm/sequlizeorm 库,如果使用了,它将一直阻塞导致服务器未响应,除非您手动在终端敲下回车。

所以更建议您采取分布式开发,虽然这听起来很蠢……

即另外再建立一个数据库操作的 node 项目,比如用 nestjs 搭建 api,专门用来 crud,游戏服务端采用 http 请求来访问,或者您可以尝试用一些更高级的 rpc 或者 socket 来实现通信。

不过这样的好处是服务端只处理游戏逻辑,数据库逻辑交给另外的项目,顺手您还可以再开发一个后台管理系统,这样后台和服务端采用的是同一套 api

组成

通常来说您只需要关注第一层,即应用开发层。

Infernus 主要做的就是第二层和第三层的工作,依赖于 samp-nodeomp 游戏服务器。

如果您不知道怎样开始建立一个项目,请参考 快速上手

/介绍
1应用开发层游戏模式,比如自由或角色扮演
2类包装层通过类来调用函数式包装
3函数式包装层例如 samp/omp/streamer 的包装
4Samp NodeSDK 通往底层的桥梁
5Omp 游戏服务器底层

为何开发

对于编程初学者或前端开发者而言,使用类似C语言的面向过程式语言(如Pawn)开发游戏脚本存在显著的学习门槛。相较于现代面向对象语言(如JavaScript),Pawn在基础API设计上更为繁琐——例如字符串拼接、数组操作等底层功能需手动实现,增加了开发复杂度。

此外,Pawn语言生态存在以下局限性:

  1. 异步支持薄弱:原生缺乏类似JavaScript中Promise/Async的异步编程范式;
  2. 国际化障碍:由于Pawn编译器(SA-MP)诞生较早,其字符编码方案依赖操作系统本地化设置:
    • 西欧系统默认采用ISO-8859-1编码;
    • 中文系统依赖GBK编码;
    • 与通用UTF-8标准不兼容。

这种编码强依赖性可能导致不可预见的兼容性问题,例如将GBK数据直接存入UTF-8数据库时,若无转译处理则会出现乱码。

而基于JavaScript的开发方案则能充分利用Node.js生态优势:

  • 工具链丰富:日期处理(Day.js)、数据库驱动(MySQL/Redis/MongoDB)等成熟库;
  • 异步标准化:原生支持Promise/Async异步控制;
  • 编码统一性:全栈采用UTF-8编码,规避国际化兼容问题。

通过迁移至JavaScript技术栈,开发者可显著降低学习成本,同时获得更健壮的国际化支持与现代工具链赋能。