5 hours ago
Setting up an open.mp server takes about ten minutes: download the server package from GitHub, drop your gamemode into the gamemodes folder, edit config.json, and run omp-server. Because open.mp is fully backwards compatible with SA-MP, your old scripts and even old compiled AMX files load straight out of the box, and players can join with the regular SA:MP client.
I have run SA-MP servers on and off since the old 0.3 days, and I moved my last project over to open.mp without any drama. Here is the full walkthrough, including migration from an existing SA-MP setup, a quick Pawn primer for newcomers, and some honest hosting advice.
What open.mp actually is
open.mp (Open Multiplayer) is an open source reimplementation of the SA-MP server. The client side stays the same: people still connect with the SA:MP client (or the open.mp launcher), so you do not lose your player base by switching. What changes is the server binary. You get an actively maintained codebase, a modernized Pawn compiler, a C++ component API for people who want to go beyond Pawn, and a pile of bug fixes the original SA-MP server never got. The project describes itself as fully backwards compatible, and in my experience that claim holds up: an old AMX loads and runs. You can read more on the official open.mp site.
Step 1: Download and unpack
Grab the latest release from the open.mp GitHub releases page. Windows users want open.mp-win-x86.zip, Linux users want open.mp-linux-x86.tar.gz (there is also a dynssl variant if you have OpenSSL issues on your distro).
After extracting you will see a familiar layout if you ever ran SA-MP:
Note the server is a 32-bit binary. On a fresh 64-bit Linux box you will need the 32-bit runtime libraries before it starts (on Debian/Ubuntu that means enabling the i386 architecture and installing the usual 32-bit libc/stdc++ packages).
Step 2: config.json instead of server.cfg
This is the biggest visible change from SA-MP. The old flat server.cfg is replaced by a structured JSON file. The config.json documentation lists every option, but the essentials look like this:
Two things I really like here. First, migrating is painless: run the server with the --dump-config flag and it converts an existing server.cfg into config.json for you. Second, config values support environment variables with ${VAR} and ${VAR:-default} syntax, which is genuinely useful if you deploy with Docker or want to keep passwords out of the file.
Step 3: Migrating an existing SA-MP gamemode
The official installation guide covers this, and the short version is:
If you cannot or do not want to recompile, your existing .amx will still run against the SA-MP compatibility layer. Recompiling against the open.mp includes is still worth it: you get the new natives and better compiler diagnostics. Expect some warnings on old code, mostly tag mismatches and deprecated function names (British spellings like TextDrawColour are now the canonical ones). The docs mention defines like MIXED_SPELLINGS to quiet those down while you clean up gradually.
Plugin-wise, most popular ones have open.mp compatible builds: sscanf, Pawn.CMD and sampvoice all have OMP releases, and FCNPC is superseded by the official open.mp NPC component. The streamer plugin also works fine in legacy mode.
Pawn scripting in 60 seconds
If you are brand new: Pawn is a small C-like language. Your gamemode is one script built around callbacks the server fires. OnGameModeInit runs at startup, OnPlayerConnect when someone joins, OnPlayerCommandText (or a command processor like Pawn.CMD) when someone types a command. A minimal gamemode is maybe 20 lines: set the mode text, add a class with AddPlayerClass, spawn the player in OnPlayerRequestClass. Compile, put the name in pawn.main_scripts, restart, done. The open.mp docs mirror the entire old SA-MP wiki function reference, so anything you learned there still applies.
Hosting: what actually matters
An open.mp server is light. A 100 slot server runs comfortably on a cheap VPS with 1 vCPU and 1 to 2 GB of RAM; the bottleneck is almost never CPU, it is your script doing something silly in a tight timer. My advice:
Frequently asked questions
Can SA-MP players join an open.mp server?
Yes. open.mp is a server replacement only. Anyone with the standard SA:MP client connects normally, the open.mp launcher is optional.
Do I have to rewrite my gamemode?
No. Old compiled AMX files load as-is. For active development you should switch the include to open.mp and recompile, but that is a one line change plus fixing some deprecation warnings.
Does server.cfg still work?
There is legacy support, but config.json is the recommended format and the only one that exposes all the new options. Use --dump-config once to convert and never look back.
What are the minimum server specs?
Very low. Any 1 vCPU / 1 GB VPS handles a small to mid size server. Remember the binary is 32-bit, so install the i386 runtime libraries on 64-bit Linux.
That is everything I would tell a friend setting up their first open.mp box. If you have already migrated a bigger SA-MP project, I would love to hear how the plugin situation went for you, and if you get stuck anywhere during setup, post your config.json and the console output below and I will take a look.
I have run SA-MP servers on and off since the old 0.3 days, and I moved my last project over to open.mp without any drama. Here is the full walkthrough, including migration from an existing SA-MP setup, a quick Pawn primer for newcomers, and some honest hosting advice.
What open.mp actually is
open.mp (Open Multiplayer) is an open source reimplementation of the SA-MP server. The client side stays the same: people still connect with the SA:MP client (or the open.mp launcher), so you do not lose your player base by switching. What changes is the server binary. You get an actively maintained codebase, a modernized Pawn compiler, a C++ component API for people who want to go beyond Pawn, and a pile of bug fixes the original SA-MP server never got. The project describes itself as fully backwards compatible, and in my experience that claim holds up: an old AMX loads and runs. You can read more on the official open.mp site.
Step 1: Download and unpack
Grab the latest release from the open.mp GitHub releases page. Windows users want open.mp-win-x86.zip, Linux users want open.mp-linux-x86.tar.gz (there is also a dynssl variant if you have OpenSSL issues on your distro).
After extracting you will see a familiar layout if you ever ran SA-MP:
- gamemodes: your main .pwn and .amx files
- filterscripts: side scripts
- plugins: legacy SA-MP plugins
- components: native open.mp components (the modern replacement for many plugins)
- qawno: the bundled Pawn compiler and IDE, plus the include files
- scriptfiles: data files your scripts read and write
- config.json: the server configuration
Note the server is a 32-bit binary. On a fresh 64-bit Linux box you will need the 32-bit runtime libraries before it starts (on Debian/Ubuntu that means enabling the i386 architecture and installing the usual 32-bit libc/stdc++ packages).
Step 2: config.json instead of server.cfg
This is the biggest visible change from SA-MP. The old flat server.cfg is replaced by a structured JSON file. The config.json documentation lists every option, but the essentials look like this:
- name: the hostname shown in the browser
- network.port: default 7777, forward it (UDP) on your firewall/router
- max_players: default 50, can go up to 1000
- pawn.main_scripts: your gamemode, for example ["mygamemode 1"]
- pawn.side_scripts: filterscripts
- pawn.legacy_plugins: old SA-MP plugins like mysql or streamer
- rcon.enable and rcon.password: the server refuses to start if the RCON password is still "changeme", which is a nice touch
Two things I really like here. First, migrating is painless: run the server with the --dump-config flag and it converts an existing server.cfg into config.json for you. Second, config values support environment variables with ${VAR} and ${VAR:-default} syntax, which is genuinely useful if you deploy with Docker or want to keep passwords out of the file.
Step 3: Migrating an existing SA-MP gamemode
The official installation guide covers this, and the short version is:
- Copy your gamemode .pwn into gamemodes and your includes into qawno/include
- In the script, replace #include <a_samp> with #include <open.mp>
- Recompile with the bundled qawno compiler (F5 in the IDE)
- Copy compatible plugins into plugins and list them under pawn.legacy_plugins
If you cannot or do not want to recompile, your existing .amx will still run against the SA-MP compatibility layer. Recompiling against the open.mp includes is still worth it: you get the new natives and better compiler diagnostics. Expect some warnings on old code, mostly tag mismatches and deprecated function names (British spellings like TextDrawColour are now the canonical ones). The docs mention defines like MIXED_SPELLINGS to quiet those down while you clean up gradually.
Plugin-wise, most popular ones have open.mp compatible builds: sscanf, Pawn.CMD and sampvoice all have OMP releases, and FCNPC is superseded by the official open.mp NPC component. The streamer plugin also works fine in legacy mode.
Pawn scripting in 60 seconds
If you are brand new: Pawn is a small C-like language. Your gamemode is one script built around callbacks the server fires. OnGameModeInit runs at startup, OnPlayerConnect when someone joins, OnPlayerCommandText (or a command processor like Pawn.CMD) when someone types a command. A minimal gamemode is maybe 20 lines: set the mode text, add a class with AddPlayerClass, spawn the player in OnPlayerRequestClass. Compile, put the name in pawn.main_scripts, restart, done. The open.mp docs mirror the entire old SA-MP wiki function reference, so anything you learned there still applies.
Hosting: what actually matters
An open.mp server is light. A 100 slot server runs comfortably on a cheap VPS with 1 vCPU and 1 to 2 GB of RAM; the bottleneck is almost never CPU, it is your script doing something silly in a tight timer. My advice:
- Get a small VPS instead of shared "game hosting" panels, you will want shell access for the 32-bit libs and for tools like MySQL anyway
- Pick a location close to your players, sync quality in SA-MP/open.mp is very ping sensitive
- Run the server under a non-root user, open only UDP 7777, and put your RCON password somewhere sane
- Use screen, tmux or a systemd unit so the server survives you closing SSH
Frequently asked questions
Can SA-MP players join an open.mp server?
Yes. open.mp is a server replacement only. Anyone with the standard SA:MP client connects normally, the open.mp launcher is optional.
Do I have to rewrite my gamemode?
No. Old compiled AMX files load as-is. For active development you should switch the include to open.mp and recompile, but that is a one line change plus fixing some deprecation warnings.
Does server.cfg still work?
There is legacy support, but config.json is the recommended format and the only one that exposes all the new options. Use --dump-config once to convert and never look back.
What are the minimum server specs?
Very low. Any 1 vCPU / 1 GB VPS handles a small to mid size server. Remember the binary is 32-bit, so install the i386 runtime libraries on 64-bit Linux.
That is everything I would tell a friend setting up their first open.mp box. If you have already migrated a bigger SA-MP project, I would love to hear how the plugin situation went for you, and if you get stuck anywhere during setup, post your config.json and the console output below and I will take a look.