DiSaMe

Well, I don't see any way to make NPC traffic without involving hardware...

I don't see a reason why well-optimized code would lag.

1. Then work faster, I didn't work as fast as I could. 2. So make the whole script yourself, instead of disassembling gta_sa.exe, finding ped AI code and rewriting it in Lua.

There's no such script released and that's good because if it was made and released, many servers would start using it and originality would be ruined again.

1. No, it doesn't. Making all pedestrian path nodes took ten days for me. Car paths need more work, but still not too much. 2. If anything lags, then make it stop lagging. Any kind of script may lag if it is unoptimized.

It's possible not just "theoretically", it's not even too hard for one person to make. What is so difficult about making a ped which follows path nodes? It seems like hardly anyone even wants NPC traffic, otherwise server owners would script it. I had once made peds walking all around San Andreas: . I was going to make them drive cars too, but I lost the script. Also, there are a few videos with traffic scripted by another person: So we can conclude that NPC traffic is not just possible, but also plausible easily enough. Although server owners act as if NPC traffic was not important to them, I bet we would see the same traffic script in many servers if such script was made and released. Lack of originality is the main thing I don't like about many servers because it makes MTA look much worse than it really is. How long has it been possible to make fully controllable peds? At least two years. Maybe even three. How many scripters have we seen making an AI? Very few. I would be very happy to see someone making NPC traffic, even if it was very basic, using it in their server and not giving it to anyone. Peds have a big potential in MTA and no one uses it... Why doesn't anyone want to make MTA more popular?

MTA hardly has any control over fire. The only thing scripts can do with fire is creating it and it will be unsynced. However, you can try making your own fire system. Here's a resource which will help you: https://community.multitheftauto.com/index.php?p= ... ls&id=1292 . It replaces some models with particle emitters. So you can create the object which has a fire particle effect attached to it and you will have the complete control over it: you can make other fire objects appear randomly around the existing fire and you can destroy them anytime you want.

I don't see any problems with setPedControlState. It's client-side, like all game physics are. There actually IS a reason why MTA uses network...

Good AI, especially pathfinding.

https://wiki.multitheftauto.com/wiki/Scr ... troduction

Waypoints are scriptable in the same way like any other script. What is there to tell? We have tables which we can use to store coordinates and setPedControlState to make the ped perform the actions. That is enough, isn't it?

It must be possible with engineApplyShaderToWorldTexture.

Is that a good server? How much scripting stuff have you done/will you do yourself?

AFAIK, there isn't. It seems like there aren't many people who want this either - otherwise server owners would script traffic for their servers.

If MTA used path data from GTA SA, then those files would need to be checked to avoid desync if the player with modified paths joins. I don't see a need to install path data with MTA either. Everything can be scripted. And it's not just possible, it's plausible. First, unless modified, file only needs to be downloaded once from the server. It's not a big problem to wait a few minutes once if that results in better gameplay. Second, it's not even necessary for the client to download the path data from the server. Better use element data to store the coordinates of nodes which the ped is going to follow, or think of another comfortable way to send only the data which is being used. Then only simple things will need to be done client-side. Third, making all traffic system in the resource gives server owners more functionality. They can make their own custom paths. Data from GTA SA can be converted into format easier to read from scripts. Remaking all nodes may be even better. I once had put ped paths all over San Andreas, using my own simple path editor. This is how it all looked: . It took me a little more than a week to make ped paths. Not so long. Car paths may take a bit longer to make, but it's still not a big problem. A big advantage was reduction of node count as I didn't put them on the straight path.And finally, server owners just seem to be lazy. For example, the function to get ped joint positions has been in MTA for a long time. Yet, some people repeatedly asked to make a function for attaching objects to ped bones "because SA-MP can do that", instead of thinking a little bit and making such function themselves. Then I scripted it when I was making a gamemode and kept it in my resources for a few months, hoping that maybe somebody will make something like that too. That didn't happen, so I put the function into the separate resource, did some work to get it ready for usage from other resources and released it. And when people said "finally someone made this", I felt disappointed about them, as they wanted it, but didn't make it themselves. Is the same going to happen with NPC traffic? Maybe yes, but it won't be me who will make it. In conclusion, MTA doesn't need to change. Community does. Only a small part of MTA potential is used by many servers, so we need to use more of it before we ask to increase it. What I like the most is people making great scripts and using them in their own servers rather than releasing them - that's what makes the servers original. Players are attracted by variety and originality, so MTA can hardly become more popular if every server uses the same resources. People don't get annoyed because they need to wait for download to finish before playing. They get annoyed because they need to wait for download to finish just to find out that the server has the same stuff, nothing exceptional. I'd rather wait 20 minutes to join an original server with unique gameplay than 1 minute to see that it's not even worth playing.

Element streaming in MTA is putting/taking the element into/out of GTA SA. Streaming means that GTA becomes aware of element, so only physical GTA elements can be used by MTA streamer. GTA itself is never aware of custom elements. Also, streamer needs to know element positions. Custom elements don't have positions. Even if you use element data to store coordinates, objectively it's still just element data and not position. So it's easy to understand why custom elements can't be streamed. As I said, just write an algorithm to find the nearest text labels. Lua has everything you may need, like tables or coroutines.

If no one is working on traffic, that means no one wants it so much. I don't see a problem in this.

If you want to lower CPU usage on clients, you will need to do those calculations server-side. It's better to make an efficient algorithm which finds the nearest elements and use it client-side.

Isn't that 500 units? Anyway, all physical elements are streamed in the same way. Streaming is done client-side. Every server-side element is available client-side unless you disable the visibility with setElementVisibleTo or visibility argument in element creation function (if it has such argument). However, visibility can't be toggled on players, vehicles and objects, so to make a server-side streamer, you need to trigger client events and use them to create client-side objects. But I can hardly see any point in streaming elements in such way.

txd_floors is the variable in which you store the TXD element and 7300 is object model ID.

Of course, there must be some points, so that peds would know where the paths are. But that doesn't mean they must follow them in a way as if they were the final destinations. It's fine for a simple traffic system, but if you want them to react correctly to changing conditions, it's easier to use the way which I described.

No, they don't. It looks much better when they walk along lines between those points instead of directly using their positions for destination. When you directly use the positions, you need to check if the ped is near the destination point, and if so, switch to the next. When you use lines between the path nodes, you can check the progress of walking from one point to another. An example: 2 A----1----B-------C A, B and C are the path nodes, 1 and 2 are ped positions. Let's say the ped is walking from point A to B and is in position 1. Then for some reason (for instance, someone pushes him) he appears in position 2 without coming in the range of path node B. So if he directly uses positions of nodes, he will still walk to B before switching destination to C. If he walks along the lines between nodes, the progress of walking from A to B will be more than 100% (as he's behind B if we look from the point A), so he can start walking along the line B-C.

I made this resource, but it's only a test script. It's unsynced. It would need rewriting to work properly, but I don't script on MTA now. I've got other things to work on.

I don't see much difference whether I write 3 or 4894248623187 into the loop which creates peds.

Whoever REALLY wants the peds, will script them themselves, MTA has enough functions. But it seems like hardly anyone wants them