DiSaMe

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

Yes, they're disabled. Why would anyone want the game to create unsynced peds? Ped functions are in MTA for a reason.

I think all functionality with IPL we need is ability to remove all map objects via server configuration. Game map can be converted to MTA map format which could then be modified in map editor and controlled using scripts. There is some information related to IPL memory addresses here: http://bugs.mtasa.com/view.php?id=5499 . I don't know how much work it would take to remove/recreate IPL instances, but in my opinion, setting Z coordinate of each IPL instance to some negative value shouldn't be too hard.

If you try to use DFF as a ped skin, then MTA won't be able to use it, but if you use a few separate objects in the same way the transformers resource uses cars, then it will work well. You can try bone attachments to do things like getting position/rotation of bones. If transformer has the same size as the ped does, you can just attach objects to bones.

You're trying to load DFFs from folder 'wheel', but in meta.xml you have them in 'models'.

At least do you know what's going on? First I make a resource, post the link in this topic and then you come, talking in the way as if I don't even want bone attachments, then how do you think that resource appeared in community?

That's MTA bug with peds. If the ped is streamed out when the weapon is given, the player will see him shooting only 1 bullet. I have reported this, but nobody seems to have paid attention.

Yes.

What rest? The list has models designed to be used as pickups, there is no need to write all possible models, use object browser in map editor for this.

I had made my own tram system to use both tram lines in SF and move the trams server-side. To keep the tram always on the rail and synced, I used element data to store the position (one number, "progress" of the tram from start to the end). This data (plus the time since the last progress update) was used onClientPreRender to linearly interpolate the position between two nodes and put the tram there, so it was moving at the same speed, no matter what the FPS was.

Accuracy is less important when no one is near the ped/vehicle. That is the point, you can use setElementPosition to update the position if element has no syncer. I had done such updating to make the ped follow the path and it worked fine.

You can't apply some upgrades in a way that would make GTA see them as upgrades, but you can create objects yourself and attach them to vehicle with these functions: createObject attachElements

With server-sided function clients would still get the new control state at different time because it takes different time for clients with different ping to get the data from the server. And ped/vehicle will still be in position where the syncer sees them. The only workaround I see is a client-side script which detects how much the player is lagging and and according to that, get velocity of all vehicles streamed in and put them further in the direction where they're moving. Still, that needs some work with collision detection to prevent vehicles from moving through walls.