Adding GTA:Online system to MTA:SA

[Bigbossbro08]

I played MTA:SA for a quite long time. But I found that something is missing in MTA:SA. Like traffic and mission system just like GTA:Online.

CrystalMV this guy have added traffic system to MTA:SA. But it was full of bugs because of MTA:SA scripting limitation.

MTA:SA has ped functions but it's not that much of successful due to same MTA:SA scripting limitation.

3rd person shooting multiplayer game must have a co-op system. It really feels make the game more enjoyable.

I don't know if it's right place to post. But I played MTA:SA and I felt too empty by playing multiplayer.

I hope that developer would notice this and add this feature in future updates.

[G-Stefan]

You can do all of these just by scripting

[Simple0x47]

You're just looking out for Artificial Intelligence, it's possible to create it with scripting, don't expect always all kind of things of the developers. That's why MTA is a open source, you can collaborate and make it better.

[Bigbossbro08]

1. Can I add Actors to shoot at me and other players? I searched wiki but found nothing about this. I want to make a mission similar to GTA:Online mission/Single-Player mission in MTA:SA.

2. Can I add traffic system in MTA:SA. Complete functioning? I found a guy named CystalMV who made a traffic script. But it has many bugs. Like can't drag ped out of a vehicle.

3. Does MTA:SA has all functions of SCM?

4. I saw somewhere that if I increase traffic density more than 0.0 then I can see the traffic system. But It won't sync with MTA?

[AlexTMjugador]

I will answer your questions by the order you wrote them:

1. Yes. You just need to use setPedControlState, givePedWeapon and setPedAimTarget. If you can't find that functions it's your own problem, because they are pretty well documented in the wiki. Even the setPedAimTarget article says how you can make a ped shoot.
   
2. Yes. Even if you can't drag peds out of their vehicles by default, you can script your own ped dragging mechanic which can look like the one we all know and love. Besides that, I would not call a currently not implemented feature a "bug".
   
3. No, but why do you need them? To manipulate memory, a practise which can entirely compromise the client's computer? To use opcodes which can already be scripted in MTA with enough work? I don't see how SCM is a "reference" to MTA: SA, providing that the former already has enough features to script almost anything and that they target a completely different use case scenario (I don't think SCM was ever meant to be a language to script the GTA: SA engine from the ground up).
   
4. I would say it won't, and in the strange case it did it would crash everything, so it would not last long. Anyway, GTA: SA AI is pretty basic in most things and scripting it again in Lua is not a big deal. The CrystalMV's resource you mentioned is a good example of that: the peds created by that resource are as intelligent as they are in singleplayer. And with enough environment data gathered via processLineOfSight, physics and elements it could be vastly improved, at least conceptually. Last, but not least, there is the possibility that the MTA developers want to give us a function like createTrafficVehicle which syncs without any further scripting some day, and everything I said will be reduced to the use of that function.

On top of that, if you think that MTA: SA has some important missing features which should be addressed inmediately, a good idea would be to learn C++, assembly and understand how does the GTA: SA engine work and get your own hands on that. We all will thank you for that, and it will rewarding, I promise

[DiSaMe]

Scripting-wise peds are almost as good as they need to be. Most problems are related to sync and/or element streaming, not scripting. To make the peds function properly, we need the changes which I could classify into 3 parts:

1. Sync more of the peds' properties and make them retainable between streamout and streamin on the client. Lots of times people have wondered why the ped only shoots 1 bullet, or why the ped doesn't play the animation. That's because some of the important properties are synced improperly or are not retained on the client. Those include weapon ammo, health and stats. If the server sets the property when the ped is streamed in for the client, it seems fine. Then you go away and come back, it's not the way it was. Or you join the server after it was set, you don't see it. This problem can be worked around by creating a timer which keeps setting the property every few seconds or so, but it consumes CPU and bandwidth, therefore, it's the most important issue about ped sync to fix.

2. Ability to set the element properties in server without syncing them with the clients. For example, if you set the element's position, it will be sent to all clients, so that all of them would see it in the new position. But what if the element is far away from the client? The position will still be updated, even if it's not necessary since the client might not need to see what's happening miles away. Take my traffic resource, for example. Since the peds which have no streamer are not affected by physics and I still need them to move, I simulate this movement by setting their positions on the server every two seconds or so. If the players are spread all around the map, there are peds all around the map as well, and they are all updated for all players all the time, which is very bandwidth-inefficient. Every player only needs to be aware of correct positions of a small fraction of peds. So if we could set the element's position (and other properties) on the server without syncing it with the clients (or only syncing it for particular clients), we could move the peds without syncers without using up lots of bandwidth.

3. Peds entering/exiting vehicles. This one is the least important, since as AlexTMjugador has said, it can be achieved by scripting. Actually, I was once going to make it (but didn't). It's still preferable to have a built-in one, because making use of existing gameplay mechanics is better than creating the new one. But it's not as important as the other two issues.

With these issues taken care of, MTA would give us pretty much of what we need to have properly functioning peds.

[Captain Cody]

You could use getDistanceBetweenTwoPoints and if the player is closer or equal to said distance, send the info client side of the ped. If that makes any sense.

[DiSaMe]

You can change the ped's position on the client without changing it on the server. But you can't do the opposite. You can't change the server-side position (which determines who's the syncer, and some other stuff) without making this change visible for all players.

[Captain Cody]

Well here's what I was thinking.

Keep a table of the ped positions and stuff (Update them every so often), make the peds only move for the clients within certain range, and as soon as another client comes within said range, update the peds position and rotation. So you only update their position and what not for the clients in range preventing lots of CPU usage and what not

[darkdreamingdan]

Scripting-wise peds are almost as good as they need to be. Most problems are related to sync and/or element streaming, not scripting. To make the peds function properly, we need the changes which I could classify into 3 parts:

1. Sync more of the peds' properties and make them retainable between streamout and streamin on the client. Lots of times people have wondered why the ped only shoots 1 bullet, or why the ped doesn't play the animation. That's because some of the important properties are synced improperly or are not retained on the client. Those include weapon ammo, health and stats. If the server sets the property when the ped is streamed in for the client, it seems fine. Then you go away and come back, it's not the way it was. Or you join the server after it was set, you don't see it. This problem can be worked around by creating a timer which keeps setting the property every few seconds or so, but it consumes CPU and bandwidth, therefore, it's the most important issue about ped sync to fix.

2. Ability to set the element properties in server without syncing them with the clients. For example, if you set the element's position, it will be sent to all clients, so that all of them would see it in the new position. But what if the element is far away from the client? The position will still be updated, even if it's not necessary since the client might not need to see what's happening miles away. Take my traffic resource, for example. Since the peds which have no streamer are not affected by physics and I still need them to move, I simulate this movement by setting their positions on the server every two seconds or so. If the players are spread all around the map, there are peds all around the map as well, and they are all updated for all players all the time, which is very bandwidth-inefficient. Every player only needs to be aware of correct positions of a small fraction of peds. So if we could set the element's position (and other properties) on the server without syncing it with the clients (or only syncing it for particular clients), we could move the peds without syncers without using up lots of bandwidth.

3. Peds entering/exiting vehicles. This one is the least important, since as AlexTMjugador has said, it can be achieved by scripting. Actually, I was once going to make it (but didn't). It's still preferable to have a built-in one, because making use of existing gameplay mechanics is better than creating the new one. But it's not as important as the other two issues.

With these issues taken care of, MTA would give us pretty much of what we need to have properly functioning peds.

Hey CrystalMV, how's it going?

I was recently experimenting with your traffic resource, and I'm interesting to try and focus on some perhaps special functionality to get something that is comparable with single player. One thing I noticed (on top of the issues you mention) is that it also really strains the CPU and seems to be very heavy (on an empty server on my own) - I wonder if this is down to the modular system you employ. Regarding point #2, can we not set positions clientside instead?

I'd love to have a deep discussion sometime over what things we can build within MTA to get things working well.