<![CDATA[open.mp forum - Development Updates]]> https://forum.open.mp/ Sun, 03 May 2026 10:14:36 +0000 MyBB <![CDATA[We are finally open-source!]]> https://forum.open.mp/showthread.php?tid=2335 Mon, 09 Jan 2023 22:34:21 +0000 Y_Less]]> https://forum.open.mp/showthread.php?tid=2335

https://github.com/openmultiplayer/open.mp

Also, server version 1.0 is out with minor fixes from RC1:
  • Server: Fix .so being required on Linux legacy plugins.
  • Server: reloadfs reuses its slot to preserve filterscript order.
  • Server: Attached objects are correctly shown to other players.
  • Server: Fix a crash when loading invalid pawn memory.
  • Pawn: Added GetPlayerMarkerForPlayer.
  • Pawn: Added a_??? file wrappers.
  • Upgrader: Supports multiple codepages.
  • Upgrader: Exclude files.
  • Upgrader: Full replacements report.

This is of course now at the updated download location of:

https://github.com/openmultiplayer/open.mp/releases

Also don't forget...

https://opencollective.com/openmultiplayer
https://www.patreon.com/open_mp]]>

https://github.com/openmultiplayer/open.mp

Also, server version 1.0 is out with minor fixes from RC1:
  • Server: Fix .so being required on Linux legacy plugins.
  • Server: reloadfs reuses its slot to preserve filterscript order.
  • Server: Attached objects are correctly shown to other players.
  • Server: Fix a crash when loading invalid pawn memory.
  • Pawn: Added GetPlayerMarkerForPlayer.
  • Pawn: Added a_??? file wrappers.
  • Upgrader: Supports multiple codepages.
  • Upgrader: Exclude files.
  • Upgrader: Full replacements report.

This is of course now at the updated download location of:

https://github.com/openmultiplayer/open.mp/releases

Also don't forget...

https://opencollective.com/openmultiplayer
https://www.patreon.com/open_mp]]> <![CDATA[open.mp Server RC1]]> https://forum.open.mp/showthread.php?tid=2329 Thu, 05 Jan 2023 22:37:31 +0000 Y_Less]]> https://forum.open.mp/showthread.php?tid=2329
It's here!

It's finally here!

After four years, two rewrites, arguments and drama, and countless other hurdles; it is finally here!

Release Candidate 1 (RC1) of the open.mp server.

This, hopefully, represents the final version of the code for our 1.0 release, and if everything goes smoothly with this version we will be able to finally openthe so-called open.mp in just a few days from now.

Before I get in to the meat of the release I want to first sincerely thank every member of the open.mp team for helping the mod get this far. It has not been easy, mostly because of how invested everyone truly was - we all wanted what was best for the mod, for the community, for SA:MP, for our servers, and for our players; we wouldn't have embarked on this journey if that wasn't the case. Unfortunately strong differing opinions on what is bestsometimes causes friction. But we're here now. So to all, a huge thank you:
  • Amir
  • Cheaterman
  • Freaksken
  • Graber
  • Hual
  • Josh
  • JustMichael
  • kseny
  • Nexius
  • pkfln
  • Potassium
  • Southclaws
  • TommyB
  • Y_Less
  • Zeex
  • And probably more...

Anyway, now the bit you actually care about...

Now we're out of beta, we're (if all goes well this week) releasing on time. So along with the server itself, which you've seen a dozen times before, we have some new goodies for you:

Pawn

The download has the official includes, no more patching the old SA:MP includes with omp.inc, now we're doing it properly! It also has a new compiler. Ever wonder when 3.10.11 was coming? Well wait no longer (if you built it yourself, you could think of this one as 3.10.12)! With this combination you'll probably get loads of new warnings, but worry not - we have a tool for that as well, to automatically upgrade a load of code, adding well-defined symbol names, const, and more in all the right places. Maybe you already noticed this, you've been using it for months, but the virtual machine (the bit inside the server) has been updated as well! Oh, and all those string natives you know and love, like SendClientMessage and AddMenuItem? They all format now. All of them*.

Documentation on the updated includes:

https://github.com/openmultiplayer/omp-stdlib

Documentation on the new compiler:

https://github.com/openmultiplayer/compiler/
https://github.com/pawn-lang/compiler/

Documentation on qawno:

https://github.com/openmultiplayer/qawno/

Documentation on the upgrader tool:

https://github.com/openmultiplayer/upgrade

A full list of what's available:
  • Symbol length limit increased to 64, no more OnPlyrDoTheTing to try and fit your names in. Leading to...
  • Multiple natives decompressed - is Col short for Colour or Collision? Now you know!
  • Tags. Tags everywhere. See the included documentation.
  • The official includes are finally const-correct. No more complaining that some people might not have them.
  • Compiler version updated: __nameof, __addressof, fixes, and too many more things to go in to here.
  • switch is way faster.
  • More warnings for previously undetected issues. The more problems the compiler can find, the fewer you need to.
  • An upgradertool to add tags and const to user-code and fix several new warnings.
  • More consistent naming. Every native has been closely examined and compared to ensure the maximum level of similarity and intuitiveness in naming.
  • Added {Float, _}:... everywhere. What does this mean? It means no more format()**- think y_va but natively.
  • -O2, the highest pawn optimisation level, works when using the new compiler and VM. Some includes may need to be updated, but some already have. To help with that...
  • The __optimisation macro was added so code can configure itself when compiled with -O2.

*Almost all of them.
**Almost no more format().

SDK

Pawn is the long-standing, and still official, way to write modes for your server. It isn't going away, but for those of you who want more control we are finally releasing the full SDK (the Software Development Kit). This is a C++ interface to the server, the same one used by all the components that make up the core open.mp code. Anything they can do you can do too (compared to plugins, which were only designed to provide functions to pawn, not write modes).

We have some documentation under way, it takes time unfortunately. But in the meantime have several example components for those of you who want to get straight stuck in. These are all templates you can build upon, and go from basically nothing to a fully working component with most common features:

https://github.com/openmultiplayer/empty-template
https://github.com/openmultiplayer/basic-template
https://github.com/openmultiplayer/pawn-template
https://github.com/openmultiplayer/full-template

Also a few terms to get you started, so you can start to understand what it is that you're reading:
  • Component - A logical individual piece of the server, like objects or pickups. Ones you don't need don't need to be loaded.
  • Extension - Code that extends another bit of code. You can write component extensions, but the most common ones are player extensions, which define some structure of data to be associated with a player in addition to all their normal data like health and weapons.
  • UID - Unique IDentifier, a number that represents your component, and your component alone. This ia always required and can be got here: http://open.mp/uid
  • Entity - A thing, usually a thing a player can interact with, and which you might have a lot of. Objects are entities, but other players are also entities, even commands in a processor could be called entities.
  • Pool - Something that holds entities. When you have a lot you need to be able to access them by name or ID in some way, this is what a pool does.
  • Interface - Components use an abstract base class as an interface. This declares which methods a component has, but doesn't contain the code for the methods. Interfaces are passed around so that components can communicate with each other, but implementations are kept private.
  • SDK - The collection of all the interfaces defined by the core server.
  • ABI - An Application Binary Interface is the way compiled code talks to other compiled code. The interfaces exported by the SDK are ABI stable, which means that using two components compiled at different times will still work together.
  • pawn-natives - The library on which all native declarations are built. Useing a wrapper called SCRIPT_API around this library: https://github.com/openmultiplayer/pawn-natives
  • Event - Something that happens externally. Things like players connecting and typing commands are events. Any component can define events and tell other components when those events happen.
  • Handler - A component that wants to know when an event happens.

Features

Beside all the new features announced for pawn, there are several new (and newly announced) features in the server:
  • Per-player gang zones, as were in YSF.
  • Per-player pickups, also as in YSF.
  • AttachPlayerObjectToPlayer.
  • Better PawnPlus support.
  • :memory:, and other special names support in SQLite.
  • SQLite open flags.
  • exclude config option to not load certain components.
  • Show config parse errors, don't just silently fail.
  • SDK major version check, just in case we ever make major server changes (hopefully we won't).

Fixes

There were a few new bugs introduced in beta 11, and a few minor ones left over from before. The ones fixed include:
  • funcidx already registered warning.
  • GDK plugins (streamer etc) missing natives.
  • Random crash on GMX.
  • GDK callbacks sometimes not called.
  • No logging when requested in SQLite component.
  • Some settings not reset on GMX.
  • NPCs were connecting when there were a lot done at once.
  • .so was still needed in Linux legacy plugin names.

Links

Firstly, of course, is the new server version:

https://github.com/openmultiplayer/server-beta/releases

Secondly, the forums are back up. Head there for all your questions:

https://forum.open.mp/

Or if you prefer:

https://vk.com/open_mp

Finally, despite it being offered a few times, we have explicitly resisted any money up to this point; because we didn't feel it was right until we had proven ourselves with a release. With this post, that time is now, so if anyone wants to help support us (all donations will go towards infrastructure and future client dev work), it would be most appreciated:

https://www.patreon.com/open_mp
https://opencollective.com/openmultiplayer

And of course everything is still in active development, so please do check all the links above regularly to see what's new that we have.]]>
It's here!

It's finally here!

After four years, two rewrites, arguments and drama, and countless other hurdles; it is finally here!

Release Candidate 1 (RC1) of the open.mp server.

This, hopefully, represents the final version of the code for our 1.0 release, and if everything goes smoothly with this version we will be able to finally openthe so-called open.mp in just a few days from now.

Before I get in to the meat of the release I want to first sincerely thank every member of the open.mp team for helping the mod get this far. It has not been easy, mostly because of how invested everyone truly was - we all wanted what was best for the mod, for the community, for SA:MP, for our servers, and for our players; we wouldn't have embarked on this journey if that wasn't the case. Unfortunately strong differing opinions on what is bestsometimes causes friction. But we're here now. So to all, a huge thank you:
  • Amir
  • Cheaterman
  • Freaksken
  • Graber
  • Hual
  • Josh
  • JustMichael
  • kseny
  • Nexius
  • pkfln
  • Potassium
  • Southclaws
  • TommyB
  • Y_Less
  • Zeex
  • And probably more...

Anyway, now the bit you actually care about...

Now we're out of beta, we're (if all goes well this week) releasing on time. So along with the server itself, which you've seen a dozen times before, we have some new goodies for you:

Pawn

The download has the official includes, no more patching the old SA:MP includes with omp.inc, now we're doing it properly! It also has a new compiler. Ever wonder when 3.10.11 was coming? Well wait no longer (if you built it yourself, you could think of this one as 3.10.12)! With this combination you'll probably get loads of new warnings, but worry not - we have a tool for that as well, to automatically upgrade a load of code, adding well-defined symbol names, const, and more in all the right places. Maybe you already noticed this, you've been using it for months, but the virtual machine (the bit inside the server) has been updated as well! Oh, and all those string natives you know and love, like SendClientMessage and AddMenuItem? They all format now. All of them*.

Documentation on the updated includes:

https://github.com/openmultiplayer/omp-stdlib

Documentation on the new compiler:

https://github.com/openmultiplayer/compiler/
https://github.com/pawn-lang/compiler/

Documentation on qawno:

https://github.com/openmultiplayer/qawno/

Documentation on the upgrader tool:

https://github.com/openmultiplayer/upgrade

A full list of what's available:
  • Symbol length limit increased to 64, no more OnPlyrDoTheTing to try and fit your names in. Leading to...
  • Multiple natives decompressed - is Col short for Colour or Collision? Now you know!
  • Tags. Tags everywhere. See the included documentation.
  • The official includes are finally const-correct. No more complaining that some people might not have them.
  • Compiler version updated: __nameof, __addressof, fixes, and too many more things to go in to here.
  • switch is way faster.
  • More warnings for previously undetected issues. The more problems the compiler can find, the fewer you need to.
  • An upgradertool to add tags and const to user-code and fix several new warnings.
  • More consistent naming. Every native has been closely examined and compared to ensure the maximum level of similarity and intuitiveness in naming.
  • Added {Float, _}:... everywhere. What does this mean? It means no more format()**- think y_va but natively.
  • -O2, the highest pawn optimisation level, works when using the new compiler and VM. Some includes may need to be updated, but some already have. To help with that...
  • The __optimisation macro was added so code can configure itself when compiled with -O2.

*Almost all of them.
**Almost no more format().

SDK

Pawn is the long-standing, and still official, way to write modes for your server. It isn't going away, but for those of you who want more control we are finally releasing the full SDK (the Software Development Kit). This is a C++ interface to the server, the same one used by all the components that make up the core open.mp code. Anything they can do you can do too (compared to plugins, which were only designed to provide functions to pawn, not write modes).

We have some documentation under way, it takes time unfortunately. But in the meantime have several example components for those of you who want to get straight stuck in. These are all templates you can build upon, and go from basically nothing to a fully working component with most common features:

https://github.com/openmultiplayer/empty-template
https://github.com/openmultiplayer/basic-template
https://github.com/openmultiplayer/pawn-template
https://github.com/openmultiplayer/full-template

Also a few terms to get you started, so you can start to understand what it is that you're reading:
  • Component - A logical individual piece of the server, like objects or pickups. Ones you don't need don't need to be loaded.
  • Extension - Code that extends another bit of code. You can write component extensions, but the most common ones are player extensions, which define some structure of data to be associated with a player in addition to all their normal data like health and weapons.
  • UID - Unique IDentifier, a number that represents your component, and your component alone. This ia always required and can be got here: http://open.mp/uid
  • Entity - A thing, usually a thing a player can interact with, and which you might have a lot of. Objects are entities, but other players are also entities, even commands in a processor could be called entities.
  • Pool - Something that holds entities. When you have a lot you need to be able to access them by name or ID in some way, this is what a pool does.
  • Interface - Components use an abstract base class as an interface. This declares which methods a component has, but doesn't contain the code for the methods. Interfaces are passed around so that components can communicate with each other, but implementations are kept private.
  • SDK - The collection of all the interfaces defined by the core server.
  • ABI - An Application Binary Interface is the way compiled code talks to other compiled code. The interfaces exported by the SDK are ABI stable, which means that using two components compiled at different times will still work together.
  • pawn-natives - The library on which all native declarations are built. Useing a wrapper called SCRIPT_API around this library: https://github.com/openmultiplayer/pawn-natives
  • Event - Something that happens externally. Things like players connecting and typing commands are events. Any component can define events and tell other components when those events happen.
  • Handler - A component that wants to know when an event happens.

Features

Beside all the new features announced for pawn, there are several new (and newly announced) features in the server:
  • Per-player gang zones, as were in YSF.
  • Per-player pickups, also as in YSF.
  • AttachPlayerObjectToPlayer.
  • Better PawnPlus support.
  • :memory:, and other special names support in SQLite.
  • SQLite open flags.
  • exclude config option to not load certain components.
  • Show config parse errors, don't just silently fail.
  • SDK major version check, just in case we ever make major server changes (hopefully we won't).

Fixes

There were a few new bugs introduced in beta 11, and a few minor ones left over from before. The ones fixed include:
  • funcidx already registered warning.
  • GDK plugins (streamer etc) missing natives.
  • Random crash on GMX.
  • GDK callbacks sometimes not called.
  • No logging when requested in SQLite component.
  • Some settings not reset on GMX.
  • NPCs were connecting when there were a lot done at once.
  • .so was still needed in Linux legacy plugin names.

Links

Firstly, of course, is the new server version:

https://github.com/openmultiplayer/server-beta/releases

Secondly, the forums are back up. Head there for all your questions:

https://forum.open.mp/

Or if you prefer:

https://vk.com/open_mp

Finally, despite it being offered a few times, we have explicitly resisted any money up to this point; because we didn't feel it was right until we had proven ourselves with a release. With this post, that time is now, so if anyone wants to help support us (all donations will go towards infrastructure and future client dev work), it would be most appreciated:

https://www.patreon.com/open_mp
https://opencollective.com/openmultiplayer

And of course everything is still in active development, so please do check all the links above regularly to see what's new that we have.]]> <![CDATA[SA-MP 0.3DL compatibility plus other added features and bug fixes - SERVER BETA RELEA]]> https://forum.open.mp/showthread.php?tid=2318 Thu, 08 Sep 2022 09:26:16 +0000 Potassium]]> https://forum.open.mp/showthread.php?tid=2318 Posted in our Discord server announcements channel by kseny (discord.gg/samp)



Hello everyone



We have just released open.mp server beta 9, fixing several reported issues and adding several new features. The most notable change being - SA:MP 0.3DL support. You can now run 0.3.7 and 0.3.DL compatible servers from the same binary!



Other Changes


  • Dynamic tick rate. Specify a target tickrate, rather than a fixed sleep time.

    - Use the tickrate console command to set the rate

    - sleep can now be a float to accomodate precise tick rates.
  • More plugin compatibility - fsutil, Discord connector (only with non static build)

  • SetSpawnInfo return fixed.

  • Fix weather and time not resetting after GMX.

  • Fix various GMX bugs.

  • Fix various console commands.

  • Fix GetPlayerClass.

  • Fix GetVehicleLastDriver.

  • Add GetVehicles native.

  • Add GetPlayers native.

  • Add GetActors native.

  • All lagcomp modes are now available through config.

  • Fix trailer sync.

  • Fix GetVehicleLastDriver.

  • Fix GetPlayerRotationQuat.

  • Fix crash in vehicle component.






SA:MP DL





This is the big news obviously, and comes with a whole host of new settings:


  • Implemented all DL natives and callbacks (AddSimpleModel, AddSimpleModelTimed, GetPlayerCustomSkin, OnPlayerFinishedDownloading, OnPlayerRequestDownload):

    - RedirectDownload native and OnPlayerRequestDownload callback are now deprecated in favour of CDN config options.

  • Add artwork.enable (legacy: useartwork) config option.

  • Add artwork.models_path (legacy: artpath) config option.

    - Server can load custom models from artconfig.txt file like SA:MP does.

  • 0.3.7 compatibility is preserved and can be configured by network.allow_037_clients config option (true by default).

  • open.mp server comes now with a built in webserver used to serve custom models

    - Webserver is using open.mp server bind address and port. Please allow TCP connections on your port in firewall if you plan to use it.- If your public IP address is different than bind address (ex: you're behind a router) you'll need to set it in network.public_addr config option.


Notes


  • Due to few changes old config.json files may not work properly. Please use ./omp-server --default-config to generate a new one

  • server.cfg users are not affected.

  • While allowing 0.3.7 connections only 1000 objects can be created

  • open.mp server now provides two types of Linux builds, standard and static. You are encouraged to use the standard build if possible, it will minimize incompatibilities with various plugins; however, it will require openssl 1.1 installed on your system. If you can't install modern openssl on your system (typically if it's very old), you can use the static build, but some plugins or components might fail to load and crash the server.


Official Includes



Preparing a full release is not just having a working server, but all the other peripherals as well - libraries, tools, documentation, and more. On the pawn side open.mp is a significant upgrade, with many QoL improvements already seen through fixes and new functions, and more to come. A big part of this push is more compiler diagnostics to find code problems ahead of time, mostly through more tags and const-correctness. While the offical versions aren't out yet you can still help in the meantime by testing your code with the following includes and tools:



https://github.com/pawn-lang/samp-stdlib...y-overhaul?

https://github.com/pawn-lang/pawn-stdlib...ed-natives?

https://github.com/openmultiplayer/upgrade?

https://github.com/pawn-lang/compiler



These were originally developed to improve the default SA:MP includes, but never fully released (i.e. never merged to master, despite the PR being accepted). The open.mp includes build on the foundation established here so think of these as a stepping-stone to full open.mp tag and const safety; and important feedback on their direction. See the links above for far more information and documentation on upgrading.



As ever, if you don't want to upgrade old code and includes will still work (at least for the first release).]]> Posted in our Discord server announcements channel by kseny (discord.gg/samp)



Hello everyone



We have just released open.mp server beta 9, fixing several reported issues and adding several new features. The most notable change being - SA:MP 0.3DL support. You can now run 0.3.7 and 0.3.DL compatible servers from the same binary!



Other Changes


  • Dynamic tick rate. Specify a target tickrate, rather than a fixed sleep time.

    - Use the tickrate console command to set the rate

    - sleep can now be a float to accomodate precise tick rates.
  • More plugin compatibility - fsutil, Discord connector (only with non static build)

  • SetSpawnInfo return fixed.

  • Fix weather and time not resetting after GMX.

  • Fix various GMX bugs.

  • Fix various console commands.

  • Fix GetPlayerClass.

  • Fix GetVehicleLastDriver.

  • Add GetVehicles native.

  • Add GetPlayers native.

  • Add GetActors native.

  • All lagcomp modes are now available through config.

  • Fix trailer sync.

  • Fix GetVehicleLastDriver.

  • Fix GetPlayerRotationQuat.

  • Fix crash in vehicle component.






SA:MP DL





This is the big news obviously, and comes with a whole host of new settings:


  • Implemented all DL natives and callbacks (AddSimpleModel, AddSimpleModelTimed, GetPlayerCustomSkin, OnPlayerFinishedDownloading, OnPlayerRequestDownload):

    - RedirectDownload native and OnPlayerRequestDownload callback are now deprecated in favour of CDN config options.

  • Add artwork.enable (legacy: useartwork) config option.

  • Add artwork.models_path (legacy: artpath) config option.

    - Server can load custom models from artconfig.txt file like SA:MP does.

  • 0.3.7 compatibility is preserved and can be configured by network.allow_037_clients config option (true by default).

  • open.mp server comes now with a built in webserver used to serve custom models

    - Webserver is using open.mp server bind address and port. Please allow TCP connections on your port in firewall if you plan to use it.- If your public IP address is different than bind address (ex: you're behind a router) you'll need to set it in network.public_addr config option.


Notes


  • Due to few changes old config.json files may not work properly. Please use ./omp-server --default-config to generate a new one

  • server.cfg users are not affected.

  • While allowing 0.3.7 connections only 1000 objects can be created

  • open.mp server now provides two types of Linux builds, standard and static. You are encouraged to use the standard build if possible, it will minimize incompatibilities with various plugins; however, it will require openssl 1.1 installed on your system. If you can't install modern openssl on your system (typically if it's very old), you can use the static build, but some plugins or components might fail to load and crash the server.


Official Includes



Preparing a full release is not just having a working server, but all the other peripherals as well - libraries, tools, documentation, and more. On the pawn side open.mp is a significant upgrade, with many QoL improvements already seen through fixes and new functions, and more to come. A big part of this push is more compiler diagnostics to find code problems ahead of time, mostly through more tags and const-correctness. While the offical versions aren't out yet you can still help in the meantime by testing your code with the following includes and tools:



https://github.com/pawn-lang/samp-stdlib...y-overhaul?

https://github.com/pawn-lang/pawn-stdlib...ed-natives?

https://github.com/openmultiplayer/upgrade?

https://github.com/pawn-lang/compiler



These were originally developed to improve the default SA:MP includes, but never fully released (i.e. never merged to master, despite the PR being accepted). The open.mp includes build on the foundation established here so think of these as a stepping-stone to full open.mp tag and const safety; and important feedback on their direction. See the links above for far more information and documentation on upgrading.



As ever, if you don't want to upgrade old code and includes will still work (at least for the first release).]]> <![CDATA[OCTOBER 2020 Q&A Live stream recording and podcast]]> https://forum.open.mp/showthread.php?tid=1271 Sat, 24 Oct 2020 02:33:44 +0000 Potassium]]> https://forum.open.mp/showthread.php?tid=1271
Text transcript will be on the forum within the next few days.

Feel free to offer your feedback on how we can improve our streams :)

The podcast can be found here:?https://www.buzzsprout.com/1439923/6037927

And the video:

]]>
Text transcript will be on the forum within the next few days.

Feel free to offer your feedback on how we can improve our streams :)

The podcast can be found here:?https://www.buzzsprout.com/1439923/6037927

And the video:

]]> <![CDATA[open.mp Frequently Asked Questions (FAQ) | APRIL 2020]]> https://forum.open.mp/showthread.php?tid=1068 Sun, 26 Apr 2020 03:56:35 +0000 Media]]> https://forum.open.mp/showthread.php?tid=1068 Good morning fellow San Andreas residents! ☀️

Today we’re answering some of your most frequently asked and most interesting questions, to hopefully give you a better idea of where we’re at with the development of open.mp! 


-----


Will you be fixing GTA SA game bugs, as well as SA-MP bugs? 


Yes we are! 🦠 Please help out by reporting bugs here if you know how to use GitHub (this is our preference): https://github.com/openmultiplayer/samp-bugs/

Or on the forum if you aren’t familiar with GitHub: https://www.burgershot.gg/showthread.php?tid=99


-----


Which versions of SA-MP will be supported? Is 0.3.DL included? 


We aren't officially adding versions lower than 0.3.7, but you are welcome to do it yourself if you need to (that’s the beauty of open source!) 🔧

If a lot of servers would use 0.3.DL then we’d like to include these features, but if people aren’t that bothered then we won’t. 🤷‍♂️

We had an unofficial vote about it on the forum to get some opinions, and out of 77 votes, 73 support adding these features. So it’s likely we will see them in open.mp in the future, just not in the initial release! ✔️ https://www.burgershot.gg/showthread.php?tid=1039


-----


Will there be a fixed release cycle for new open.mp versions?


No. Fixed release cycles require a level of predictability and support we just don't have right now. You need people who are guaranteed to be able to work on it at a very consistent level, but since the team are all volunteers there's no way to get this reliability. Things, mostly our jobs, get in the way.

Maybe if this gets bigger we'll eventually have the support required for this. But we don't yet. However, while we won't be able to say for certain when the next release will be, with this being open-source you will at least be able to follow along and see that things are happening. We’ll do our best to always communicate with the community and stay active online between releases!


-----


Can we make feature requests, and will you be adding previous requests from the SA-MP forum?


We would LOVE for the community to be more involved, so we encourage everyone to make suggestions and requests! 💕 You can do this here: https://www.burgershot.gg/forumdisplay.php?fid=42&page=6 

Of course, there is no guarantee that every idea will be accepted or implemented… but that’s the great thing about open source - if you want something added, you can do it yourself!


-----

Will there be a built-in anti-cheat system?


Short answer: Yes. 👮‍♂️✋🛑

The longer answer requires explaining quite a lot about the internal architecture of the server. Everything uses a pub-sub event system. Incoming packets, outgoing packets, and callbacks are all sent around using this system, and modules (related blocks of functionality) can listen to all these events at various priority levels. There are several high priority levels dedicated to AC systems, and different modules can hook in to different events, potentially blocking them entirely. So we can have very small modules looking for specific different cheats totally independently of other code (this modularity was designed in from the very start for exactly this reason). There may not be one official huge anti-cheat, but there will be lots of modules detecting different cheats, and there's no reason they can't be bundled and distributed together.


-----


Will PAWN remain the "official" scripting language of open.mp? Can we use other languages?


All dev work, testing, and documentation, will be done in PAWN. ♟️

However, we have a C API which will allow anyone else to implement any other language! 🤖 The C API is used by PAWN itself, so any other language using the API will have exactly the same level of access to the internals as PAWN - as opposed to SA-MP scripting where other languages have to be integrated into PAWN scripts.

We have also been discussing implementing some semi-official language modules, but PAWN is still the main and supported scripting language.


-----


What is the dev team's stance on client-side scripting with other languages?


Mixed. It is nice for some things, but also tricky to fully sandbox, which would be absolutely required were it to be added. As it stands, PAWN has been broken to the point of allowing arbitrary assembly to be executed from a compiled script. That's fine on a server, but not on a client.  So this needs patching out first. Using a different language would raise the question of why client and server are different, switching the server language would break the promise of backwards compatibility, and having two in any manner would double the support load.

The other idea thrown around is that of client-side plugins that they control and access from a central location. If your server needs the "Advanced Image Preview" client-side plugin, your server advertises this fact and a connecting client will either already have it or download it from the central repository. This gives everyone the ability to inspect exactly what code is being run on their own machine, build it themselves if they want to, and be certain of the provenance. The major downside to this is then hosting and vetting these plugins.


-----


Will SA-MP plugins work on open.mp?


The word "plugins" is now used to describe legacy plugins - the ones that were written for SA-MP (such as sscanf, MySQL etc) - and open.mp has an API to load these existing plugins. 

Our new name for plugins going forward is "Modules" - this is the name given to any plugins (and internal code) that use the newer, far more expansive, API with open.mp.

Legacy plugins still work fine and will continue to do so, unless they use memory hacking, like YSF - that relies on addresses and structures which are just nothing alike in this server. 

But most of these old memory hacks were created to add features that will be native in open.mp, meaning we won’t need these plugins anyway!


-----


Will database functions be restricted to SQLite, or we can use MySQL?


The default database functions are the same as they were before - SQLite. But, as stated above, open.mp has an API to load existing plugins, so we won’t need to change anything internally with regard to database functions - this can still be done via your existing plugins.

Third-party modules are fully supported and treated as first-class citizens in the code - callbacks and natives are all available to them in exactly the same way as to internal code, so there's no drawbacks to putting things in external modules. 


-----


Will there be more customisation for elements such as HUD, stamina, minigames (pool, gym, etc), different vehicle variants, vehicle indicators/turn signals, SA-MP+ features, etc? Will there be support for more customisable GUIs, as opposed to the limited textdraws in SA-MP? CEF? How will this stuff be protected?


We got soooo many questions about this sort of stuff, so grab a snack, this is gonna be a long answer! 🍿

Having Hual (creator of SA-MP+) on our development team, who knows what the future will bring? 👀

The major thing that differentiated SA-MP from MTA was expressed well in the names - SA-MP was literally "San Andreas Multiplayer", a multiplayer version of the game GTA San Andreas., while MTA is a more generic platform set in that world. 

Features were added to SA-MP that fit closely with the feel of the original game, and while there are obviously ways that it has gone beyond those limits, things were still done very conservatively. 

We stuck with SA-MP this long because we preferred their approach, but we do want slightly more features (that's why we branched out in the first place), but we don't want to go too far. We will add new features, some of them won't have been in the original game, but we'll still carefully weigh the effects of each one. 

Is allowing slightly wider dialog boxes a crazy addition that pushes the boundaries of what's considered canonical GTA? Probably not. 

Is adding CEF too far? Yes - that won't happen. 🙅‍♂️

The line is somewhere between the two.

However, people have always been incredibly creative in what they could achieve with limited support already, and we’re sure that won’t change. We will always encourage players and developers to be as creative as they like with the mod - hence why it’s open source - we’ll even help and support them in doing it, but it won’t be our primary focus.

The primary concern is for the clients themselves. We don’t want server owners to be able to distribute anything potentially malicious. San Andreas was not designed for multiplayer or modding, and many of the loaders are not hardened against malformed files - there was simply no need. This is something that SA-MP struggled with when adding custom models, and this is a problem for us as well. 

Any part of the game we make customisable we have to first ensure there are no exploits in the file formats and loaders. We know for a fact that models and scripts have been compromised already, others may have also already been compromised and absolutely will be when we start adding arbitrary downloads to servers.

As for asset protection, that’s simply impossible. To show a custom model to a client, you need to send them the custom model. Then, they by definition have the custom model on their computer. What they do with it from there is out of our hands. There are ways to make it slightly harder, but they aren’t foolproof. There are techniques that the web uses like DRM and secure enclaves, but they require sacrificing open-source principles to make them work. Look up the controversy surrounding EME and closed-source binary blobs inside Firefox.


-----


Control over specific keys? Key binding?


“Keys” isn't really the right wording. A better way to think about the existing functions is as “actions” - reflected in the new names - Player_GetActions, and OnPlayerActionChange. The client has never exposed “keys” to the server. Those you can listen into too much - we basically become a keylogger. This is also why there have always been codes to say “press JUMP to open”, because players may remap their keys so that what one person has for jumping is different to the next person.


-----


Better support for NPCs?


This is not a main focus at this point in time, but from a client point of view NPCs are exactly the same as normal players. We’d at least like our NPC functions to mirror that of FCNPC. This is definitely something we can look into for future releases.


-----


You said you’ve removed limits in open.mp - how does this actually work? Is it like a streamer?


It is exactly like a built-in streamer. However, it is more integrated than the streamer plugin, so we can stream vehicles and players as well, and mess around with local IDs in ways far beyond what the plugin does (it could in theory do the same things, it just doesn't).


-----


Will we be able to attach players to entities (vehicles, objects, other players)? 


Yep! We have already implemented this! 😁


-----

When open.mp has finished implementing SA-MP features, what new things will you add?


We’re very open (pun intended 🤪) about what our plans are, just follow along with our posts and progress and you’ll see! 



-----


Are you allowed to use the SA-MP client to join open.mp servers?


SA-MP is a mod using reverse engineering to interface with a program made by someone else, and open.mp is doing exactly the same thing. So our legal standing is exactly the same as the SA-MP legal standing. We are not using any of the leaked SA-MP source code at all - this point has been made multiple times, and will be blatantly obvious to the community once the code is released!


-----


What are going to be the biggest challenges for the new open.mp client?


Writing it! 🤓


-----


Where do you see open.mp in 5 years?


Don’t you worry about that, we have plenty of long-term ideas 😉


-----


Where do you see SA-MP in 5 years?


That’s up to the SA-MP team, not us! It’s not our place to speculate! 🤷‍♂️


-----


Have you ever lost will to continue working on open.mp? Why or why not?


Yes, because we are normal people. 😴


-----


And finally, the most commonly asked question:
When will open.mp be released?


When it’s ready 😉😉😉


Have a great week ahead!

Love,
The open.mp Team 💜]]> Good morning fellow San Andreas residents! ☀️

Today we’re answering some of your most frequently asked and most interesting questions, to hopefully give you a better idea of where we’re at with the development of open.mp! 


-----


Will you be fixing GTA SA game bugs, as well as SA-MP bugs? 


Yes we are! 🦠 Please help out by reporting bugs here if you know how to use GitHub (this is our preference): https://github.com/openmultiplayer/samp-bugs/

Or on the forum if you aren’t familiar with GitHub: https://www.burgershot.gg/showthread.php?tid=99


-----


Which versions of SA-MP will be supported? Is 0.3.DL included? 


We aren't officially adding versions lower than 0.3.7, but you are welcome to do it yourself if you need to (that’s the beauty of open source!) 🔧

If a lot of servers would use 0.3.DL then we’d like to include these features, but if people aren’t that bothered then we won’t. 🤷‍♂️

We had an unofficial vote about it on the forum to get some opinions, and out of 77 votes, 73 support adding these features. So it’s likely we will see them in open.mp in the future, just not in the initial release! ✔️ https://www.burgershot.gg/showthread.php?tid=1039


-----


Will there be a fixed release cycle for new open.mp versions?


No. Fixed release cycles require a level of predictability and support we just don't have right now. You need people who are guaranteed to be able to work on it at a very consistent level, but since the team are all volunteers there's no way to get this reliability. Things, mostly our jobs, get in the way.

Maybe if this gets bigger we'll eventually have the support required for this. But we don't yet. However, while we won't be able to say for certain when the next release will be, with this being open-source you will at least be able to follow along and see that things are happening. We’ll do our best to always communicate with the community and stay active online between releases!


-----


Can we make feature requests, and will you be adding previous requests from the SA-MP forum?


We would LOVE for the community to be more involved, so we encourage everyone to make suggestions and requests! 💕 You can do this here: https://www.burgershot.gg/forumdisplay.php?fid=42&page=6 

Of course, there is no guarantee that every idea will be accepted or implemented… but that’s the great thing about open source - if you want something added, you can do it yourself!


-----

Will there be a built-in anti-cheat system?


Short answer: Yes. 👮‍♂️✋🛑

The longer answer requires explaining quite a lot about the internal architecture of the server. Everything uses a pub-sub event system. Incoming packets, outgoing packets, and callbacks are all sent around using this system, and modules (related blocks of functionality) can listen to all these events at various priority levels. There are several high priority levels dedicated to AC systems, and different modules can hook in to different events, potentially blocking them entirely. So we can have very small modules looking for specific different cheats totally independently of other code (this modularity was designed in from the very start for exactly this reason). There may not be one official huge anti-cheat, but there will be lots of modules detecting different cheats, and there's no reason they can't be bundled and distributed together.


-----


Will PAWN remain the "official" scripting language of open.mp? Can we use other languages?


All dev work, testing, and documentation, will be done in PAWN. ♟️

However, we have a C API which will allow anyone else to implement any other language! 🤖 The C API is used by PAWN itself, so any other language using the API will have exactly the same level of access to the internals as PAWN - as opposed to SA-MP scripting where other languages have to be integrated into PAWN scripts.

We have also been discussing implementing some semi-official language modules, but PAWN is still the main and supported scripting language.


-----


What is the dev team's stance on client-side scripting with other languages?


Mixed. It is nice for some things, but also tricky to fully sandbox, which would be absolutely required were it to be added. As it stands, PAWN has been broken to the point of allowing arbitrary assembly to be executed from a compiled script. That's fine on a server, but not on a client.  So this needs patching out first. Using a different language would raise the question of why client and server are different, switching the server language would break the promise of backwards compatibility, and having two in any manner would double the support load.

The other idea thrown around is that of client-side plugins that they control and access from a central location. If your server needs the "Advanced Image Preview" client-side plugin, your server advertises this fact and a connecting client will either already have it or download it from the central repository. This gives everyone the ability to inspect exactly what code is being run on their own machine, build it themselves if they want to, and be certain of the provenance. The major downside to this is then hosting and vetting these plugins.


-----


Will SA-MP plugins work on open.mp?


The word "plugins" is now used to describe legacy plugins - the ones that were written for SA-MP (such as sscanf, MySQL etc) - and open.mp has an API to load these existing plugins. 

Our new name for plugins going forward is "Modules" - this is the name given to any plugins (and internal code) that use the newer, far more expansive, API with open.mp.

Legacy plugins still work fine and will continue to do so, unless they use memory hacking, like YSF - that relies on addresses and structures which are just nothing alike in this server. 

But most of these old memory hacks were created to add features that will be native in open.mp, meaning we won’t need these plugins anyway!


-----


Will database functions be restricted to SQLite, or we can use MySQL?


The default database functions are the same as they were before - SQLite. But, as stated above, open.mp has an API to load existing plugins, so we won’t need to change anything internally with regard to database functions - this can still be done via your existing plugins.

Third-party modules are fully supported and treated as first-class citizens in the code - callbacks and natives are all available to them in exactly the same way as to internal code, so there's no drawbacks to putting things in external modules. 


-----


Will there be more customisation for elements such as HUD, stamina, minigames (pool, gym, etc), different vehicle variants, vehicle indicators/turn signals, SA-MP+ features, etc? Will there be support for more customisable GUIs, as opposed to the limited textdraws in SA-MP? CEF? How will this stuff be protected?


We got soooo many questions about this sort of stuff, so grab a snack, this is gonna be a long answer! 🍿

Having Hual (creator of SA-MP+) on our development team, who knows what the future will bring? 👀

The major thing that differentiated SA-MP from MTA was expressed well in the names - SA-MP was literally "San Andreas Multiplayer", a multiplayer version of the game GTA San Andreas., while MTA is a more generic platform set in that world. 

Features were added to SA-MP that fit closely with the feel of the original game, and while there are obviously ways that it has gone beyond those limits, things were still done very conservatively. 

We stuck with SA-MP this long because we preferred their approach, but we do want slightly more features (that's why we branched out in the first place), but we don't want to go too far. We will add new features, some of them won't have been in the original game, but we'll still carefully weigh the effects of each one. 

Is allowing slightly wider dialog boxes a crazy addition that pushes the boundaries of what's considered canonical GTA? Probably not. 

Is adding CEF too far? Yes - that won't happen. 🙅‍♂️

The line is somewhere between the two.

However, people have always been incredibly creative in what they could achieve with limited support already, and we’re sure that won’t change. We will always encourage players and developers to be as creative as they like with the mod - hence why it’s open source - we’ll even help and support them in doing it, but it won’t be our primary focus.

The primary concern is for the clients themselves. We don’t want server owners to be able to distribute anything potentially malicious. San Andreas was not designed for multiplayer or modding, and many of the loaders are not hardened against malformed files - there was simply no need. This is something that SA-MP struggled with when adding custom models, and this is a problem for us as well. 

Any part of the game we make customisable we have to first ensure there are no exploits in the file formats and loaders. We know for a fact that models and scripts have been compromised already, others may have also already been compromised and absolutely will be when we start adding arbitrary downloads to servers.

As for asset protection, that’s simply impossible. To show a custom model to a client, you need to send them the custom model. Then, they by definition have the custom model on their computer. What they do with it from there is out of our hands. There are ways to make it slightly harder, but they aren’t foolproof. There are techniques that the web uses like DRM and secure enclaves, but they require sacrificing open-source principles to make them work. Look up the controversy surrounding EME and closed-source binary blobs inside Firefox.


-----


Control over specific keys? Key binding?


“Keys” isn't really the right wording. A better way to think about the existing functions is as “actions” - reflected in the new names - Player_GetActions, and OnPlayerActionChange. The client has never exposed “keys” to the server. Those you can listen into too much - we basically become a keylogger. This is also why there have always been codes to say “press JUMP to open”, because players may remap their keys so that what one person has for jumping is different to the next person.


-----


Better support for NPCs?


This is not a main focus at this point in time, but from a client point of view NPCs are exactly the same as normal players. We’d at least like our NPC functions to mirror that of FCNPC. This is definitely something we can look into for future releases.


-----


You said you’ve removed limits in open.mp - how does this actually work? Is it like a streamer?


It is exactly like a built-in streamer. However, it is more integrated than the streamer plugin, so we can stream vehicles and players as well, and mess around with local IDs in ways far beyond what the plugin does (it could in theory do the same things, it just doesn't).


-----


Will we be able to attach players to entities (vehicles, objects, other players)? 


Yep! We have already implemented this! 😁


-----

When open.mp has finished implementing SA-MP features, what new things will you add?


We’re very open (pun intended 🤪) about what our plans are, just follow along with our posts and progress and you’ll see! 



-----


Are you allowed to use the SA-MP client to join open.mp servers?


SA-MP is a mod using reverse engineering to interface with a program made by someone else, and open.mp is doing exactly the same thing. So our legal standing is exactly the same as the SA-MP legal standing. We are not using any of the leaked SA-MP source code at all - this point has been made multiple times, and will be blatantly obvious to the community once the code is released!


-----


What are going to be the biggest challenges for the new open.mp client?


Writing it! 🤓


-----


Where do you see open.mp in 5 years?


Don’t you worry about that, we have plenty of long-term ideas 😉


-----


Where do you see SA-MP in 5 years?


That’s up to the SA-MP team, not us! It’s not our place to speculate! 🤷‍♂️


-----


Have you ever lost will to continue working on open.mp? Why or why not?


Yes, because we are normal people. 😴


-----


And finally, the most commonly asked question:
When will open.mp be released?


When it’s ready 😉😉😉


Have a great week ahead!

Love,
The open.mp Team 💜]]> <![CDATA[TESTING/DEBUGGING in open.mp]]> https://forum.open.mp/showthread.php?tid=1044 Thu, 16 Apr 2020 01:14:11 +0000 Media]]> https://forum.open.mp/showthread.php?tid=1044 What kinds of things are you looking forward to seeing with regard to script TESTING and DEBUGGING in open.mp?





Check out our new blog post for the inside info on how it works so far???????



???https://www.open.mp/blog/debugging]]> What kinds of things are you looking forward to seeing with regard to script TESTING and DEBUGGING in open.mp?





Check out our new blog post for the inside info on how it works so far???????



???https://www.open.mp/blog/debugging]]> <![CDATA[Your thoughts on SAMP 0.3.DL compatibility]]> https://forum.open.mp/showthread.php?tid=1039 Wed, 15 Apr 2020 02:15:30 +0000 Media]]> https://forum.open.mp/showthread.php?tid=1039 (thank you Manyula and dreftas for submitting these) and we were going to save this one for the Q&A, but thought it deserved its own thread as we would like?community input on this topic.

Will open.mp be compatible with 0.3.DL?
This is the discontinued release that included server-side custom models.

The answer is simple - if the majority?will use it then yes. If they?won't, then no.

We believe that SAMP 0.3.DL was discontinued because the big?servers in general?weren't using it, however, we also believe that the reason the big?servers weren't using it was because it was not officially supported by the SAMP dev team. So it was?a bit of a chicken-and-egg situation - it wasn't supported because no one was using it, but no one was using it because it wasn't supported.

So what do you guys want?

Is there enough community support for DL features?

Are you a server owner or developer who would only switch to open.mp if these features existed?

Please vote in the poll, and also leave a comment below with your opinions!

Don't forget you have a few more days to ask your burning questions about open.mp for our Q&A post!?https://www.burgershot.gg/showthread.php?tid=1035

[Image: qsebnEb5vsA.jpg]
image from gold?roleplay -?posted by user?Arsenka123 on the SAMP forum]]> (thank you Manyula and dreftas for submitting these) and we were going to save this one for the Q&A, but thought it deserved its own thread as we would like?community input on this topic.

Will open.mp be compatible with 0.3.DL?
This is the discontinued release that included server-side custom models.

The answer is simple - if the majority?will use it then yes. If they?won't, then no.

We believe that SAMP 0.3.DL was discontinued because the big?servers in general?weren't using it, however, we also believe that the reason the big?servers weren't using it was because it was not officially supported by the SAMP dev team. So it was?a bit of a chicken-and-egg situation - it wasn't supported because no one was using it, but no one was using it because it wasn't supported.

So what do you guys want?

Is there enough community support for DL features?

Are you a server owner or developer who would only switch to open.mp if these features existed?

Please vote in the poll, and also leave a comment below with your opinions!

Don't forget you have a few more days to ask your burning questions about open.mp for our Q&A post!?https://www.burgershot.gg/showthread.php?tid=1035

[Image: qsebnEb5vsA.jpg]
image from gold?roleplay -?posted by user?Arsenka123 on the SAMP forum]]> <![CDATA[Scripting API blog post discussion]]> https://forum.open.mp/showthread.php?tid=1036 Tue, 14 Apr 2020 19:00:36 +0000 Y_Less]]> https://forum.open.mp/showthread.php?tid=1036


https://www.open.mp/blog/scripting-api



Please read that, then feel free to comment on anything it brings up.]]>


https://www.open.mp/blog/scripting-api



Please read that, then feel free to comment on anything it brings up.]]> <![CDATA[UPDATES, Q&A, SOCIAL MEDIA, ONE YEAR ANNIVERSARY!]]> https://forum.open.mp/showthread.php?tid=1035 Tue, 14 Apr 2020 11:46:57 +0000 Media]]> https://forum.open.mp/showthread.php?tid=1035
This week is officially ONE YEAR since we came together to start building open.mp!

Our devs have been working hard around their busy everyday lives and full-time jobs to get the core of the project built, and we are hoping to have it ready for public testing very soon!

We are launching our official social media accounts today, with the intention of giving much more frequent updates, community interaction, and more general open-ness about the project. So follow us to stay up to date! 👀

A little look at the modules we've completed so far:

✔️ Actors
✔️ Camera
✔️ Checkpoints
✔️ Classes
✔️ Dialogs
✔️ Legacy Plugins
✔️ Map
✔️ Menus
✔️ Net Stats
✔️ Objects
✔️ PAWN
✔️ Pickups
✔️ Text 3D
✔️ Textdraws
✔️ Timers
✔️ Vars
✔️ Vehicles

We have removed all limits - no streamers are required. This means that OMP servers will be able to use unlimited objects, icons, checkpoints, and vehicles!

We also have a brand spankin' new API which will enable other languages to be added to servers easily!


WHAT DO YOU WANT TO KNOW ABOUT OPEN.MP?
Ask your questions below, and we'll do a big Q&A post later in the week where we answer them!

Make sure you join our forum and follow us on social media to get the latest news and updates from our team!

👇👀👇👀👇👀👇👀👇👀👇


Quote:▪️ Website: 
https://www.open.mp/

▪️ Progress log: 
https://www.open.mp/progress

▪️ Blog: 
https://www.open.mp/blog

▪️ Forum:
http://burgershot.gg

▪️ Facebook:
http://facebook.com/openmultiplayer

▪️ Twitter: 
http://twitter.com/open_mp 
(this name is temporary, but follow it now and you'll still be following the correct account when the name changes!)

▪️ Instagram: 
http://instagram.com/openmultiplayer

▪️ GitHub: 
https://github.com/openmultiplayer


See you soon for testing!

Love,
The open.mp team ❤️

[Image: ScsSW.jpg]]]>
This week is officially ONE YEAR since we came together to start building open.mp!

Our devs have been working hard around their busy everyday lives and full-time jobs to get the core of the project built, and we are hoping to have it ready for public testing very soon!

We are launching our official social media accounts today, with the intention of giving much more frequent updates, community interaction, and more general open-ness about the project. So follow us to stay up to date! 👀

A little look at the modules we've completed so far:

✔️ Actors
✔️ Camera
✔️ Checkpoints
✔️ Classes
✔️ Dialogs
✔️ Legacy Plugins
✔️ Map
✔️ Menus
✔️ Net Stats
✔️ Objects
✔️ PAWN
✔️ Pickups
✔️ Text 3D
✔️ Textdraws
✔️ Timers
✔️ Vars
✔️ Vehicles

We have removed all limits - no streamers are required. This means that OMP servers will be able to use unlimited objects, icons, checkpoints, and vehicles!

We also have a brand spankin' new API which will enable other languages to be added to servers easily!


WHAT DO YOU WANT TO KNOW ABOUT OPEN.MP?
Ask your questions below, and we'll do a big Q&A post later in the week where we answer them!

Make sure you join our forum and follow us on social media to get the latest news and updates from our team!

👇👀👇👀👇👀👇👀👇👀👇


Quote:▪️ Website: 
https://www.open.mp/

▪️ Progress log: 
https://www.open.mp/progress

▪️ Blog: 
https://www.open.mp/blog

▪️ Forum:
http://burgershot.gg

▪️ Facebook:
http://facebook.com/openmultiplayer

▪️ Twitter: 
http://twitter.com/open_mp 
(this name is temporary, but follow it now and you'll still be following the correct account when the name changes!)

▪️ Instagram: 
http://instagram.com/openmultiplayer

▪️ GitHub: 
https://github.com/openmultiplayer


See you soon for testing!

Love,
The open.mp team ❤️

[Image: ScsSW.jpg]]]> <![CDATA[Turfs (formerly gangzones) module]]> https://forum.open.mp/showthread.php?tid=826 Sat, 19 Oct 2019 16:20:08 +0000 Josh]]> https://forum.open.mp/showthread.php?tid=826


I have just finished our Turf implementation into the server and I thought of posting a overview of this module and to show we haven't quit or anything!



PHP Code:
// Creates a Turf. A playerid can be passed in order to make it a player turf.

native Turf:Turf_Create(Float:minx, Float:miny, Float:maxx, Float:maxy, Player:owner = INVALID_PLAYER_ID);



// Destroys a turf.

native Turf_Destroy(Turf:turf);



// Shows a Turf to a player or players.

// Will send to all players if playerid = INVALID_PLAYER_ID.

native Turf_Show(Turf:turf, colour, Player:playerid = INVALID_PLAYER_ID);



// Hides a Turf from a player or players.

// Will send to all players if playerid = INVALID_PLAYER_ID.

native Turf_Hide(Turf:turf, Player:playerid = INVALID_PLAYER_ID);



// Flashes a Turf for a player or players.

// Will send to all players if ?playerid = INVALID_PLAYER_ID.

native Turf_Flash(Turf:turf, colour, Player:playerid = INVALID_PLAYER_ID);



// Stops a Turf from flashing for player(s).

// Will send to all players if playerid = INVALID_PLAYER_ID.

native Turf_StopFlashing(Turf:turf, Player:playerid = INVALID_PLAYER_ID); 



This is obviously different from the traditional API, but not to worry, there will be wrappers in place for this kind of stuff to make sure a normal script can be recompiled with no issues and without edits.

Another important fact that you may want to know is that every turf is in the same pool and there's a maximum of 4,294,967,295 turfs to be created from the script.

However, the client can only handle 1024 turfs at one time.]]>


I have just finished our Turf implementation into the server and I thought of posting a overview of this module and to show we haven't quit or anything!



PHP Code:
// Creates a Turf. A playerid can be passed in order to make it a player turf.

native Turf:Turf_Create(Float:minx, Float:miny, Float:maxx, Float:maxy, Player:owner = INVALID_PLAYER_ID);



// Destroys a turf.

native Turf_Destroy(Turf:turf);



// Shows a Turf to a player or players.

// Will send to all players if playerid = INVALID_PLAYER_ID.

native Turf_Show(Turf:turf, colour, Player:playerid = INVALID_PLAYER_ID);



// Hides a Turf from a player or players.

// Will send to all players if playerid = INVALID_PLAYER_ID.

native Turf_Hide(Turf:turf, Player:playerid = INVALID_PLAYER_ID);



// Flashes a Turf for a player or players.

// Will send to all players if ?playerid = INVALID_PLAYER_ID.

native Turf_Flash(Turf:turf, colour, Player:playerid = INVALID_PLAYER_ID);



// Stops a Turf from flashing for player(s).

// Will send to all players if playerid = INVALID_PLAYER_ID.

native Turf_StopFlashing(Turf:turf, Player:playerid = INVALID_PLAYER_ID); 



This is obviously different from the traditional API, but not to worry, there will be wrappers in place for this kind of stuff to make sure a normal script can be recompiled with no issues and without edits.

Another important fact that you may want to know is that every turf is in the same pool and there's a maximum of 4,294,967,295 turfs to be created from the script.

However, the client can only handle 1024 turfs at one time.]]> <![CDATA[Modeller wanted]]> https://forum.open.mp/showthread.php?tid=595 Fri, 24 May 2019 14:33:59 +0000 Y_Less]]> https://forum.open.mp/showthread.php?tid=595


Further down the line we'll want to start producing our own library of models to be distributed with the mod, as SA:MP does now, but you need not sign up to all that right now.



Thanks,



Y_Less]]>


Further down the line we'll want to start producing our own library of models to be distributed with the mod, as SA:MP does now, but you need not sign up to all that right now.



Thanks,



Y_Less]]> <![CDATA[Timers module]]> https://forum.open.mp/showthread.php?tid=583 Wed, 22 May 2019 15:15:29 +0000 Y_Less]]> https://forum.open.mp/showthread.php?tid=583
PHP Code:
native SetTimer(const func[], msInterval, bool:repeat) = SetTimerEx;
native SetTimerEx(const func[], msInterval, bool:repeat, const params[], GLOBAL_TAG_TYPES:...);
native KillTimer(timer) = Timer_Kill;

// CreateTimer
native Timer:Timer_Create(const func[], usDelay, usInterval, repeatCount, const params[] = "", GLOBAL_TAG_TYPES:...);

// KillTimer
native bool:Timer_Kill(Timer:timer);

// Return time till next call.
native Timer_GetTimeRemaining(Timer:timer);

// Get number of calls left to make (0 for unlimited).
native Timer_GetCallsRemaining(Timer:timer);

// Get `repeatCount` parameter.
native Timer_GetTotalCalls(Timer:timer);

// ?Get `usInterval` parameter.
native Timer_GetInterval(Timer:timer);

// Reset time remaining till next call to `usInterval`.
native bool:Timer_Restart(Timer:timer); 

The first two are just for backwards-compatibility, the rest are the improved API:

PHP Code:
native Timer:Timer_Create(const func[], usDelay, usInterval, repeatCount, const params[] = "", GLOBAL_TAG_TYPES:...); 
  • `func` - Fairly obvious; what to call.
  • `usDelay` - Again obvious, the delay before the call (in microseconds).
  • `usInterval` - What to reset `usDelay` to after the first call. ?So if you wanted a timer on the hour every hour, but it was 8:47am right now, the call would be `Timer_Create("OnTheHour", 780 SECONDS, 3600 SECONDS, 0);`
  • `repeatCount` - Unlike the old functions, which are just "once" or "forever", this instead takes the number of times to call the function. ?"once" would be `1`, `500` would stop after 500 calls, and (backwards from the old API) `0` means "forever".
  • `GLOBAL_TAG_TYPES` - Like `{Float, ...}`, but with more tags.
]]>
PHP Code:
native SetTimer(const func[], msInterval, bool:repeat) = SetTimerEx;
native SetTimerEx(const func[], msInterval, bool:repeat, const params[], GLOBAL_TAG_TYPES:...);
native KillTimer(timer) = Timer_Kill;

// CreateTimer
native Timer:Timer_Create(const func[], usDelay, usInterval, repeatCount, const params[] = "", GLOBAL_TAG_TYPES:...);

// KillTimer
native bool:Timer_Kill(Timer:timer);

// Return time till next call.
native Timer_GetTimeRemaining(Timer:timer);

// Get number of calls left to make (0 for unlimited).
native Timer_GetCallsRemaining(Timer:timer);

// Get `repeatCount` parameter.
native Timer_GetTotalCalls(Timer:timer);

// ?Get `usInterval` parameter.
native Timer_GetInterval(Timer:timer);

// Reset time remaining till next call to `usInterval`.
native bool:Timer_Restart(Timer:timer); 

The first two are just for backwards-compatibility, the rest are the improved API:

PHP Code:
native Timer:Timer_Create(const func[], usDelay, usInterval, repeatCount, const params[] = "", GLOBAL_TAG_TYPES:...); 
  • `func` - Fairly obvious; what to call.
  • `usDelay` - Again obvious, the delay before the call (in microseconds).
  • `usInterval` - What to reset `usDelay` to after the first call. ?So if you wanted a timer on the hour every hour, but it was 8:47am right now, the call would be `Timer_Create("OnTheHour", 780 SECONDS, 3600 SECONDS, 0);`
  • `repeatCount` - Unlike the old functions, which are just "once" or "forever", this instead takes the number of times to call the function. ?"once" would be `1`, `500` would stop after 500 calls, and (backwards from the old API) `0` means "forever".
  • `GLOBAL_TAG_TYPES` - Like `{Float, ...}`, but with more tags.
]]> <![CDATA[Two screenshots]]> https://forum.open.mp/showthread.php?tid=536 Wed, 08 May 2019 16:30:27 +0000 Y_Less]]> https://forum.open.mp/showthread.php?tid=536


[Image: Qu6T4l3.png]



[Image: vVdfjOt.png]]]>


[Image: Qu6T4l3.png]



[Image: vVdfjOt.png]]]> <![CDATA[Want to follow our development?]]> https://forum.open.mp/showthread.php?tid=351 Thu, 18 Apr 2019 10:37:48 +0000 JustMichael]]> https://forum.open.mp/showthread.php?tid=351
We have just setup a new Github repository, that the O:MP team will start using to publicly display the tasks we will be tackling throughout. You have this opportunity to follow us on our journey through our development cycle, this includes all O:MP and Burgershot projects.

We hope that this will keep you all informed, and even more excited for the upcoming release of O:MP. If you see we are working on a task?and you want to suggest new idea or suggestions then feel free to post all suggestions or questions here:?https://www.burgershot.gg/forumdisplay.php?fid=42

You can find the link to the Todo's repo here:?https://github.com/openmultiplayer/todo/issues]]>
We have just setup a new Github repository, that the O:MP team will start using to publicly display the tasks we will be tackling throughout. You have this opportunity to follow us on our journey through our development cycle, this includes all O:MP and Burgershot projects.

We hope that this will keep you all informed, and even more excited for the upcoming release of O:MP. If you see we are working on a task?and you want to suggest new idea or suggestions then feel free to post all suggestions or questions here:?https://www.burgershot.gg/forumdisplay.php?fid=42

You can find the link to the Todo's repo here:?https://github.com/openmultiplayer/todo/issues]]> <![CDATA[git.io/open.mp]]> https://forum.open.mp/showthread.php?tid=343 Thu, 18 Apr 2019 02:39:04 +0000 Y_Less]]> https://forum.open.mp/showthread.php?tid=343 https://git.io/open.mp



This is the direct (nice) link to our github organisation, on which most development will be hosted. There is one notable absence for now - the actual mod. However, all graphics, operations, and modes are being put on there.



Interested in graphics? Star the graphics repo and make some issues.



Want to improve the forums? They're there as well.



Got a simple mode you want including with the server? We'd love to see it.





Note that everything will be MPL 2.0 or CC-BY-SA 3.0. We are setting up CLAs, which is basically just a way of enabling you to say you agree to let us use the things you submit.]]> https://git.io/open.mp



This is the direct (nice) link to our github organisation, on which most development will be hosted. There is one notable absence for now - the actual mod. However, all graphics, operations, and modes are being put on there.



Interested in graphics? Star the graphics repo and make some issues.



Want to improve the forums? They're there as well.



Got a simple mode you want including with the server? We'd love to see it.





Note that everything will be MPL 2.0 or CC-BY-SA 3.0. We are setting up CLAs, which is basically just a way of enabling you to say you agree to let us use the things you submit.]]>