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 ??
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 ??
![[Image: disc.png]](https://i.ibb.co/YfQpSD1/disc.png)
?Dimmy#3917
![[Image: 560x95_FFFFFF_FF9900_000000_000000.png]](http://www.game-state.com/141.95.24.129:7777/560x95_FFFFFF_FF9900_000000_000000.png)
