Infernus 是什么

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

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

WARNING

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

🚧 施工中

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

差异

有关 omp-node 的具体情况，请以官方后续文档为准。以下内容仅供参考。

/	Infernus + samp-node	omp-node
运行环境	Windows/Linux: Node.js 22.20.0	Windows/Linux: Node.js 18+
模块规范	CommonJS/ESModule	ESModule
架构支持	仅x86	x86/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。

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

32位和Bindings支持

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

在使用本项目前，请注意以下版本要求：

1. Node版本匹配

   • 请确保你的Node主版本号与samp-node依赖的版本一致
   • 例如samp-node依赖22.20.0，则只能使用22.x版本
   • 不兼容的版本如18.x、20.x、24.x等将无法正常工作

2. 如果项目已经创建：

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

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

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

32位的node环境内存受限，建议另外再建立一个数据库操作的 node 项目，运行在宿主机的64位node上，比如用 nestjs 搭建 api，专门用来 crud，游戏服务端采用 http 请求来访问，或者您可以尝试用一些更高级的 rpc 或者 socket 来实现通信。

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

组成

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

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

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

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

为何开发

对于编程初学者或前端开发者而言，使用类似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技术栈，开发者可显著降低学习成本，同时获得更健壮的国际化支持与现代工具链赋能。