infernus icon indicating copy to clipboard operation
infernus copied to clipboard

Project is in Maintenance Mode

Open dockfries opened this issue 2 months ago • 0 comments

Thank you very much for your continued interest in this project.

I actually mentioned this in the documentation a long time ago, and you can see that many repos are already archived.

At this stage, I only fix basic bugs and do not add additional new features.

Whether to adapt omp-node in the future depends on whether it has an api that is backward compatible with past samp-nodes. But even if it is, the performance of the @infernus/core library will still be lower than the @omp-node/core itself.

because I won't consider remapping a large number of the original callNative calls at the bottom layer to the code that doesn't go through the pawn layer or directly calls the SDK. This would be too much work, and this is what omp-node/core is doing.

Moreover, the i18n logic we are currently implementing relies on the interception feature in pawn and the flag a feature of callNative`.

Also, some of our past polyfills were implemented through callPublic, which also poses migration difficulties if there is no api.

Anyway, at least you can still run the @infernus/core library based on samp-node on open.mp for now, and it also supports the NPC component that has not yet been merged and released to the official version.

And the differences between our libraries (including the ecosystem libraries) and the omp-node official ones are always there. For instance, we bundled streamer in the core code.

So if in the future we have the opportunity to adapt to omp-node or we modify samp-node ourselves to a component that calls the omp-sdk instead of a plugin that relies on sampgdk.

We still have a lot of work to do.

The gamemode and polyfill in the starter repository need to be recompiled 2. infernus/create-app requires rewriting the download of omp-node instead of the original samp-node 3. infernus needs to superimpose an encapsulation call on the original global samp api to adapt to the new samp-node component or omp-node component. 4. It's possible that we need to provide both x86 and x64 versions simultaneously. This means that we might have to use the same node version as the official omp-node or compile the corresponding embedded files ourselves. 5. Use the new configuration file to be compatible with the base

For those who use @infernus/core: The new project structure needs to be manually migrated, but there is no need to modify the upper-level code.

But if it's possible, I think we just release a new version of samp-node, which is a component. You just need to replace the original plug-in with a component, and nothing else needs to be changed.

dockfries avatar Oct 18 '25 08:10 dockfries