Buenas he arrendado un VPS con windows incluido, he tenido algunos problemas y dudas al usarlo.



El primer error es este, que sucede que no carga el streamer.

I'm sure this has already been suggested somewhere but I thought I'd give this a separate thread -?allow us to create gang zones of all basic shapes, so rectangles, triangles, circles and polygons.

Hey, I don't know if you guys plan do add those but here are 3 ideas I think would be awesome.



- Client sided object streamer - basically an object streamer but from the client, so servers won't have to use object streamers and constantly deleting and re-creating object for each player which uses alot of CPU, It would also be cool to increase the maximum object streamed to 2000 like in 0.3DL.



-?A fixed masterlist for the server browser - SA-MP client has had a broken internet masterlist since forever, for now only hosted servers are shown, the internet tab shows the same list as the hosted tab.



- Syncronized GTA Radio - It would be cool if all the players in the server had the same radio time. Players who listen to the same GTA Radio would hear the same song playing in the same time. On sa-mp everyone hears a different song.

Hello, I am Sriyank from CCRP, I am one of the founders. I want to take suggestions on how to improve and I'll consider them if they're really good.
Also one more thing, I've been thinking about changing cities. So shall we stay in Fort Carson or move to Los Santos?
Please vote.

I have suggested this before on Discord, but I feel this should be properly laid out and discussed here as well. This suggestion is motivated by the needs of my server, but I hope this will be useful to a wider range of servers as well.



There is a limit of 1000 objects and 2000 vehicles. This limit is client-side and cannot be circumvented. A streamer can be used to give the illusion of having infinite entity slots to use, while still only showing a limited amount of them to players; however, this feels like an overkill to me when you actually don't need to be able to display seamlessly thousands of objects to players.



I suggest a lightweight alternative to classic streaming using virtual worlds. This has the following specifics:

• There is a fixed limit of entities existing per-world. Creating an entity or moving entity there if it exceeds the limit fails. Creating a global entity (global object) also fails if there is no slot that is unoccupied in all used worlds.
  
  
• An entity has a per-world ID, which is consistent throughout its lifetime and equal to its client-side ID when shown to any player. This is necessary since things like SelectObject and /dl expose the ID.
  
  
• Assigning a per-world ID to an entity should prioritize IDs that are used for other per-world entities in other worlds (configurable). This maximizes the number of slots that are still usable for global entities.
  
  
• The per-world ID of an entity either has to be the primary means of manipulating it server-side (similarly to per-player objects), or there should be a two-way conversion function.
  
  
• When a player changes the virtual world, all the entities there are displayed to them (unless there are type-specific rules, like distance for vehicles), and the old ones are hidden.
  
  
• Having a better track of visibility relations between players and entities decreases the amount of processing needed. Looping specifically over per-world entities (with per-world IDs) further improves the performance.
  
  
• Parallel processing can be used for individual worlds to increase tick rate. If the scripting language allows it, even callbacks can be invoked on different threads.
  
  
• This can be used for objects, vehicles, pickups, 3D labels, actors, and also NPCs.
  
  

OnPlayerTakeDamage is currently called after a player has already taken the damage. This makes it impossible to make a custom damage system.



1. OnPlayerGiveDamage does the same thing. This callback seems redundant anyway since we got lag compensation with 0.3z, no idea why that's still around.

2. OnPlayerWeaponShot prevents bullet data from being sent entirely. People don't even see when they are hit.

3. SetPlayerTeam does not prevent self-inflicted damage.



I'd like to suggest calling OnPlayerTakeDamage BEFORE a player takes damage. This way all damage could be prevented - but not all death events which brings me to my next point: death events hardcoded into the game, like a car explosion while being in the driver's seat or a parachute splat. Having greater control over these as well would give us total control over any and all damage and death events.

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 ??

EDIT: Ya lo resolv?.

A simple suggestion as a nod to biggest projects

because sa-mp's players?limit is the theoretical limit