DiSaMe

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!

I'm okay with the idea, but I'm not so sure if it's keyboard that's causing the problem. I mean if I tried to get support, I would try to explain clearly regardless of what device I use. But then again, maybe I think differently from most people.

I don't know if this still works, but I have run two instances of MTA in the past. On Windows, I ran separate MTA instances on separate users. It was inconvenient because I couldn't see both windows at the same time. On Linux, I made another Wine prefix. Separate Wine prefixes work as separate Windows systems and each can run its own instance of GTA SA.

I don't know what this has to do with dimensions. The code should work unless thePlayer variable is changed before the timer elapses. Therefore the part where thePlayer gets changed must be where the problem comes from, but you're not showing us that part. @The_GTA showed you how the code can be modified so that changes to thePlayer wouldn't cause this problem.

It's amazing how you know all these details. Knowledge about TXD/DFF in general would have helped me a lot back then. And even though I don't do anything related anymore, that doesn't make your findings any less interesting

What an interesting finding. If RenderWare developers specifically made textures work that way, then it's not a bug of RenderWare. Is it a bug of MTA, though? That's a separate issue. If the purpose of TXD functions was to make custom textures apply to models and nothing else, then yes, it's a bug that's caused by absence of data validation in engineLoadTXD. If the purpose was to load the data the exact way RenderWare does it, it's not a bug. But that's just playing around with words - even if it's not a "bug", whether we should keep it or not is another separate issue Where is it specified? I'm looking at https://gtamods.com/wiki/Raster_(RW_Section) and there's some rasterType structure member but no description, is that it? Remembering the times I used to read/write TXD files, it's interesting to find out that there's this thing I never knew about. On the other hand, it's likely I wouldn't have found it interesting if I somehow managed to get this behavior back then, without knowing how it works.