DiSaMe

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.

These kinds of things don't usually go to waste either way - if it gets released, there are going to be people who will use it in MTA. But letting people outside MTA community know about it would make things even better. It could set higher standards for GTA multiplayer in general. An unfamiliar person might expect that multiplayer has the same things that single player does, except it allows multiple players to play together - seems like what you were thinking of back then, if I understand you correctly. With Sphene, that could become a standard rather than just an expectation. An in-game editor? That's amazing! Sure, if we have a map editor that people use for purposes not limited to MTA, why not a SCM script editor as well?

Yeah, I guess even if creating a custom weapon and attaching it is kind of a workaround, it comes in handy. I see there's accuracy among properties - if they can shoot in a different direction than they're pointing at, then it's one of the things setPedAimTarget can't do. When I wanted to simulate imperfect accuracy using setPedAimTarget, I did it using math.sin with time as parameter. Everything looked okay until I looked at the ped from up close and realized that it's very noticeable how it waves the weapon around Your approach reminds me of back when peds couldn't enter/exit vehicles apart from warping instantly (that's a recent addition, right?), and I was thinking of reimplementing vehicle enter/exit animations using attached elements, ped animations and vehicle door rotation. Didn't go anywhere with it though. Had I done that, it would have helped me with train system that I was thinking of doing. I wanted to define my own train tracks, and in order to do this, I had to set the train as derailed and control its position from the script. But you can't enter the derailed train, and making my own vehicle enter/exit system would have solved this problem. I once did the "define my own tracks" thing for the tram by the way (wanted to use both tram tracks in SF), but later I lost the script, though it looks pretty easy to make now that I think about it. It gets in the way when we have to resort to workarounds, especially when it's due to bugs like that one I had with setPedAimTarget, and yet, the very fact that we can implement those workarounds to begin with, just shows how powerful MTA is. I don't think that's specific to server peds, although I never checked this. Element streaming is a client-side thing, element disappears from GTA when you get further, but MTA client still remembers it. It just seemed not to remember things like stats, health and ammo. So unless this has been fixed, your peds might also be susceptible. It would be harder to notice on your peds since they're centered around the local player, plus if shooting is implemented using custom weapons, you can't observe the same bug with ammo. Being pragmatic can get things done here and now, but perfectionism has its benefits in the long term. When I was making my traffic and my server, I was also being somewhat pragmatic. On the other hand, there have been many moments when I tried to code something but couldn't think of a good approach, data structures and stuff. And it felt like my perfectionism was holding me back. However, now I realize it wasn't for nothing. Far from it. I was just looking for something, and it was that "something" that made me much better at coding. Glad to know it's interesting to you. But because I have lots of things to do, I don't want to get your hopes up too high - no idea when I'm going to make something. Anyway, I can say the same to you, good luck to you too

Oh, so that's what you've gone through. Workaround after workaround. Never tried custom weapons myself, but that's not the standard way to make peds shoot, so it's not really peds that you had a problem with, but rather a separate MTA feature that I've never seen being used anywhere else in GTA. But I guess you did it that way because you had issues getting them to shoot the standard way? I used to call setPedAimTarget and set the fire control state, and the peds would appear to shoot, the weapons would appear to fire, but the bullets sometimes wouldn't fly out. Turns out a NaN would appear somewhere in calculations in the game itself. But the problem would not occur at longer distances, so the workaround was simple: put the target thousands of units further in the same direction. Drive-by was even more problematic, I called setPedDoingGangDriveby along with setPedAimTarget, and while peds did appear to shoot, I never managed to get their bullets to fly out reliably, plus they were visually aiming in the wrong direction. And regarding info not being preserved between stream out and stream in: I create a ped. I give that ped a weapon using giveWeapon. Seems okay. Then I go further away and return back. The ped only has one bullet. If I try to make it shoot, it shoots one bullet and then continues the shooting animation but the weapon doesn't fire and no bullets appear. With no client-side giveWeapon, my workaround was to call it on the server side every couple seconds or so. Many other properties were not preserved either. Health being one of them, but this didn't get in the way when I had my own server because I had a custom health system anyway. I don't know how much the situation changed since then, I have been assuming things have improved, considering peds can enter/exit vehicles now. It's surely interesting to know how it all works. I agree, the game world just doesn't feel that empty with peds around. And you did what I didn't find time to do. You made peds more interactive, which is why yours feel more alive. But I couldn't limit myself to client-side peds. I understand your reasons, but when I make peds for players to interact with, I want them to be synced, because that's one of the things I love about MTA: synced peds. And if actual server-side peds were still too heavy for my purposes, I would try implementing my own using client-side peds and triggerServerEvent/triggerClientEvent. But to each their own, sometimes I get a bit perfectionistic with things like these ? I'm also happy to have someone to talk to about peds. When I was scripting mine, I felt alone. All I could see was people occasionally posting things like "is there a resource to have peds walking and driving everywhere?" People only wanting a traffic resource but not trying to make one themselves. It's not even that hard to make something basic that works. I currently can't run MTA because of some hardware issues (should be simple to resolve, just haven't gotten myself to do it for a while), but that isn't my focus. I've become better at programming in the recent years and I've learned to make my code much more reusable. What I've been thinking is that I could try making something that runs on anything running Lua, with minimal additional code needed to bind it specifically to MTA API.

Wow guys, I'm very happy to know you appreciate my work! When I was making the traffic in 2012, even though I stayed around for quite a while afterwards and even made my own server, it was already MTA scripting sunset for me. I had no idea where my life was going, and since I still had barely made anything usable on MTA in general, I wanted to finally produce something that actually works. But I didn't know what would come of it. And I wouldn't have thought that after this many years, my scripts would still have such an impact. It seems like not only it didn't fade away with time, but to the contrary, over time more and more people see them, get inspired and make their own works that impress me. It's a little hard to believe that this much time has passed, and I miss those days I scripted on MTA. Not making any actual plans yet, but maybe after the sunset the new day has to come Precisely what I used to think, though depends on what that "weird stuff" is. Some things may be unexpected and look very weird at first but totally understandable once you get to know them, like ped without syncer ending up in completely different positions for server and clients. Others, such as health or ammo not being preserved between stream out and stream in, look like bugs, although I don't know if that's still the case. I was a little worried we might hijack this topic if I start commenting about your videos without saying anything else, but now I feel as if I had done some backseat moderating or something like that, I don't know, maybe I'm just thinking too much ?

This is great, I can't believe I missed it. And I never thought anyone would ever make that much use of it. But this topic is not exactly the right place for this, because this is where @EnemyChad demonstrates his NPC system, so posts that only focus on other systems are a bit out of place here.

Yes, rendering, that's what I had in mind. And it's nice to know you use coroutines, a very useful mechanism that is underused. If you implement all those game features, it could eventually replace single player. I mean even people who just want to play alone, could do so on their own local servers, with ability to run other MTA resources being the bonus. This inspires me to do some related scripting, not necessarily something exclusively for MTA, but something that could be used on MTA.

Wow, I've had an idea like this myself a long time ago - didn't think that someday someone would make this. Where does the SCM execution take place? Server or client? When I had the idea, I was thinking it should be on client because some parts of SCM scripts are supposed to work without delay for the player. For example, if we have an operation "wait 0", execution will wait for the next frame before proceeding. But what I considered the problem was that if the script creates elements (like vehicles) and they're supposed to be synced, the client has to tell the server to create the element, and since there will be a delay before the client becomes aware of that element, execution will have to pause as SCM script won't be able to use the element which doesn't exist on the client yet. But now it doesn't look like a big problem, just making some wrapper that will take care of sync stuff, and operating on that wrapper. On the other hand, relying on client to tell the server what to do may cause problems like hackers creating lots of cars in one place, or creating an army of peds and sending them after some player But making all SCM scripts of GTA work with this is much more than just making an interpreter, right? SCM relies on lots of other functionality that has to be reimplemented in Lua. Ped AI, zones, gang wars, wanted levels. I mean some of those things are big enough to be made into separate projects, with SCM interpreter using them as dependencies. Anyway, looks great, and I hope you guys will be able to do even better.