DiSaMe

You can check which seat the player occupies using getPedOccupiedVehicleSeat function. Other functions involving vehicle seats are getVehicleOccupant and getVehicleOccupants.

Now the question is much clearer. You can query the information about elements using functions like getElementsByType, getElementChildren and getElementData. So if you want to create a list in the GUI that represents a list of elements (like teams or skins), you can do so using getElementsByType and looping through the list of elements and creating a GUI element for each element in the list. getElementData allows you to retrieve attributes such as team name so you can pass the result to GUI functions to have it show up in the GUI. If you use getElementData on map elements from within the client side scripts (like, during the creation of GUI), you need to have <sync_map_element_data>true</sync_map_element_data> in meta.xml of any running resource. But usually a better way to use the team data from the map is to retrieve it on the server side into a table in the beginning, then pass that data to triggerClientEvent when you want to display the spawn selection window for the player.

Depends on how you define 'gamemode', because a gamemode is just another script. mapmanager and other related resources provide a standard way to do some things, but you don't have to use them - in fact, I don't remember ever doing that. I'll assume your confusion is the same as mine was a long time ago, which is getting anything to work at all, so that with the gamemode you would have a minimally playable game. There are several (per-player) things you need to do. First, a player is not physically present in the game world upon joining the server. You need to call spawnPlayer to make them appear. Also, their camera is set to some position where only the sky is visible. To make the player's camera follow the player, call setCameraTarget, passing the player element to both arguments. And last, the screen is black when you start. You have to call fadeCamera for that. That's how the player gets to run around in the game world. The rest is up to your imagination.

You can do that using processLineOfSight function. You cast a ray between two points and it will return information about the surface that it hits, including the material ID.

Perhaps the distinction should be drawn between what can only be controlled by scripts and what can be changed by other means. Position can change because of physics, which is why we want MTA to sync it, but control states cannot be changed by anything but scripts. If the script fully controls them anyway, it makes sense to let it take care of making them consistent. Also, there would be a benefit in syncing some other things besides position (assuming they're not synced already), such as whether the ped is knocked down. It's another thing related to physics that can make a big difference.

Well, that clears it up. I thought there was a possibility that it was changed, but I wasn't thinking of it as something that's supposed to be changed. I would argue that making our own data to describe tasks and using it on all clients independently can give better results than having MTA sync the peds' actions, because high level actions allow more accurate predictions than low level ones. Think "follow a particular element" versus "accelerate and steer right". The former can give acceptable results with much longer sync intervals because the latter will usually become obsolete quickly. This is in contrast to player sync, where primitive actions are the highest level actions we have, which I guess makes player sync a more complicated subject than ped sync.

But my question was, are ped actions resulting from setPedControlState, setPedAimTarget and several other functions even synced? It's understandable that setPedEnterVehicle needs to be synced, because it directly involves other elements. But setPedControlState directly involves just the ped, so is it still synced? If it is, then you're right about why using isElementSyncer would be necessary, but if it's not, then ped state will be inconsistent between clients either way, and all clients should control the ped to make it more consistent, otherwise, as I said, the ped will appear to teleport around while standing still, to everyone but the syncer.

I'm a bit late to the party, but... Shouldn't the client side part of controlling be done on all clients? In other words, are peds' actions synced? I don't know how much it has changed since I last scripted peds, but I was under the impression that it's just placement and velocity that are synced, but actions are not - in which case every client, not just the syncer, should set the control states and other control-related parameters, otherwise non-syncers will see the ped changing position but not actually performing any actions.

Oh, okay. It was the wording that confused me

Yes, peds are more popular than they used to be, it's just that I was expecting them to be even more popular. Not that I have any particular plans to return to scripting, but it's a possibility. I love these videos! I might have gotten some things right, but my goal was to make ped scripting easy so that even beginners could do it. Didn't come close enough because I only implemented very basic tasks. Was thinking of implementing pathfinding but never did. Analyzing how the game does it may help getting the peds behave the way they do in original game, but I'm not a fan of this approach. Reimplementing original behavior wouldn't be satisfying enough, I always wanted peds to perform complex tasks regardless of how the game does it. I'm not sure if I understood what you're saying. I mean I didn't do anything special regarding that. But you're making it sound like I did something that I didn't actually do. When I was playing around with nodes from original game, I found that there were many redundant nodes (or so it looked). But I created my own paths in the end (which is what I created npchlc_traffic_editor for), and obviously, I wouldn't create nodes that I find redundant. So Rockstar created more nodes in their paths than I created in mine. That's it. If I remember correctly, it's just a vector that tells lane position relative to the node position. When you drag while creating a node in the editor, that's when you set RX and RY.

You're right. But I already could tell there was something wrong with the code even then. Which is why I always considered it an unresolved matter from the beginning. Never stopped thinking it would be nice to make a better ped system. You could say it's not pressure, but motivation. In addition, by making the resource I wanted to demonstrate that ped scripting is not really that hard, and encourage more people to try it, hoping that after a while we would have more ped/traffic resources. That didn't come true to the extent that I was hoping

Wow, I'm very happy to see my scripts are still relevant, thanks! But it can be a negative thing as well, I mean it wasn't supposed to end up this way, back then I tried to improve the script, then I tried to make a new, a more advanced ped system from scratch but didn't have enough time, and to make things even worse, the code I wrote then looks horrible to me now So happy to feel appreciated, yet the fact that everyone's focused on my work that still wasn't satisfying enough to myself, gives me this unpleasant feeling that I gotta clean up this mess, gotta finish the work I once started but I don't know when I'm going to try scripting on MTA again Conversion of game paths to my path format sounds interesting, but making my own paths instead of converting the ones from the game was the reason I came up with my format and traffic editor to begin with. I was having trouble understanding some things in the game's format, and the paths have things like multiple nodes in a straight line, which needlessly uses more data. Now, to the documentation details. node_conns tells the connection ID from node IDs. That is, node_conns[node1_id][node2_id] = connection_id. Also, node coordinates are decimal fixed-point numbers, not floats, and RX/RY each takes 2 bytes as opposed to 4. Reading the value as integer and dividing it by 1000, you get the actual value. I had some problems converting between bytes and floats, and integers were faster to process. Finally, traffic lights. The value 3: "PED" means red for all cars, and that's when the peds cross the road. Normally it would work according to pedestrian traffic lights, but as far as I know, those are neither synced, nor scriptable - at least they weren't when I made the resource.

Money limit is 999 999 999 in GTA SA. 10 times more than you're checking against.

I agree. I was expecting it to be easy even without the code because there are few ways for cheaters to falsify the variable values. Turns out I thought wrong.

How would I know? You didn't show any of the code that changes the amount of money the player has. All I can guess is that the client triggers some event from the GUI code using triggerServerEvent and passes some value that the server then uses in givePlayerMoney or setPlayerMoney. At least that's what I've seen other scripters do. If this is the case, then cheaters who trigger fake events with their cheating tools can pass whatever value they want to get the server to give them an arbitrary amount of money. But without seeing what's in your code, I can't know what's really going on.

What do you mean? The reason it evaluates to true is because, well, the player has at least that much money. But this code doesn't tell how the player got that money in the first place. Money is a server side thing, so it must have happened because of setPlayerMoney or givePlayerMoney call in a server side script.

And then it calls triggerServerEvent to pass the player's actions to the server? Perhaps passing the amount of money to be given/taken as well (I've seen people put things like that in their scripts)? If so, that's just another thing the cheaters can falsify. When the client triggers an event on the server, the only data you can trust is client variable.

Not enough information, really. By "server's bank account", do you mean some money system separate from the money that's shown in the HUD? I assume you might be using element data to store money, and since setElementData allows the client to modify the element data as seen by the server, cheaters can fabricate it and set it to whatever they want. If that is the problem you're having, you have to detect when the element data gets modified by a client using onElementDataChange and reset it to the old value. It would look something like this: function undoMoneyChangeByClient(theKey, oldValue, newValue) -- if the variable 'client' is set, that means the element data change was done by a player if client and theKey == "money" then setElementData(source, theKey, oldValue) end end addEventHandler("onElementDataChange", root, undoMoneyChangeByClient) It's the same kind of thing as "Validating client setElementData" section in the page that @The_GTA posted a link to.

Have you tried different parameters for setPedAnimation? I think some combinations override the walking animation and some don't, but if I remember correctly, it also depends on animation getting applied - some of them just don't allow you to walk. If you already did that and nothing works, you can try overriding the bone placement using setElementBoneMatrix (or setElementBonePosition + setElementBoneRotation) and updateElementRpHAnim.

It's an important distinction to make, yes. Doesn't make much difference in this case since the objective is to increase the streaming distance, but it's important not to forget (yet looks easy to confuse) because the same won't work if we want to decrease the distance. If I correctly understand how the function works, then it's not even "disabling" the MTA streamer. If you "disable" the streamer for too many elements, the number will go beyond GTA limits so some of them will have to be streamed out regardless. What the function does is disabling the distance limit for the streamer and changing the priority so that elements with normal priority will get streamed out before those for which the streamer is "disabled".

In case it's MTA streamer in play like @The_GTA says, there's a function setElementStreamable. Since it's just enable/disable function, increasing the vehicle visibility distance would work by checking the distance repeatedly and enabling or disabling streaming based on that. But if you want to do this for all vehicles, doing it efficiently is where it gets complicated.

That is a possibility if resource gets restarted, yes. But it can be avoided by looping through all players and removing the element data when resource gets stopped. Conversely, using a Lua table with player as key requires removing the player data from that table when the player quits if you want to avoid similar problems. But now that you mentioned pointing to different elements, doesn't that look like a problem in design of MTA? I don't want to start a long discussion in this topic because it's not the right place, but generally I would expect that a variable will never start pointing to a different element than the one it was assigned.

You can make a table that contains the list of cars and store it as element data. function makeveh( player, command, model ) local x, y, z = getElementPosition(player) local rotX, rotY, rotZ = getElementRotation(player) rotZ = rotZ + 90 y = y + 5 local vehicle = createVehicle(model, x, y, z, rotX, rotY, rotZ) warpPedIntoVehicle(player, vehicle) local vehicles = getElementData(player, "vehicles") or {} -- retrieve the existing data, or an empty table if no data has been set table.insert(vehicles, 1, vehicle) -- insert the vehicle as first item, shifting other vehicles higher up in the list if vehicles[3] then -- if the third item in the list exists destroyElement(vehicles[3]) -- destroy the vehicle vehicles[3] = nil -- remove the vehicle from the list end setElementData(player, "vehicles", vehicles, "local") -- store the new vehicle list as element data end addCommandHandler('makeVeh', makeveh, false, false) Because inserting into the list shifts the previously created vehicles to higher indices, the first vehicle will be shifted to third index when you use the command the third time.

setRainLevel function allows you to have rain regardless of actual weather.

Wow... When I saw that MTA allows creating new model IDs but it was only client-side, I though, "oh, that's nice, we're close to it, but it's not time for it yet". It never occurred to me that we can just create elements with built-in models and then call setElementModel on the client. Great job!