DiSaMe

Good way to make what? If you always pass localPlayer as source and the first argument when triggering from client to server, you may as well not have the first argument, ignore the value of source and just use client variable. Doing comparison of values may help you detect some of the faked calls (if the values don't match, it's obviously faked), but unless you do something different in those cases (such as logging/kicking/banning), I don't see any use in that - if you rely on equality of received values to silently ignore the obviously-faked calls, the hackers will pass equal values to avoid the calls getting detected as faked.

I don't understand what you're saying. Do you mean the hacker triggers events on behalf of other players? So it appears as if a different player triggered it? I've seen enough poorly written scripts to expect that to happen. People tend to pass localPlayer as source element to triggerServerEvent and then use the source variable on the server to identify the caller. But like any data passed to triggerServerEvent, the source element can be faked so the hackers do exactly that to make the events appear to originate from other players. The variable client is the correct way to identify the client that triggered the event. If it is possible to write a client-side script to do something, then that something can be done by hackers. The anti-cheat is there to keep the hackers from doing it but it cannot in principle solve the problem "once and for all" and shouldn't be relied upon for script security.

Improving the anti-cheat can make it harder for malicious users, but it can never solve the problem, because one way or another, it has to rely on things being checked on the client side. It's just impossible to make sure that whatever runs on the client is authentic - what is possible, is to make it harder to replicate the appearance of authentic. But there will always be ways around that. However, These don't sound like anti-cheat problems at all - more like problems in the server. Unless they are MTA server bugs (which would be a huge security issue, very worrying indeed, but I find that very unlikely), they must be caused by scripts you run on the server. Like a server-side script that receives events from the client side and processes them without performing any validation. It's definitely not up to the anti-cheat to take care of that. Just because the anti-cheat makes it harder for hackers to exploit the server's script security holes, that doesn't mean those security holes should be there in the first place. Likewise, compiling the client scripts increases the amount of effort the hackers need to put in, but that's not going to make much difference for someone who can overcome the anti-cheat.

What an opportunity for me to join the rant! I feel your pain. I'm another person who's tired of how you "have" to buy newer and newer and more powerful stuff so that you could continue doing the same thing you have been doing all along with no problems. My most powerful computer is a laptop that I bought 10 years ago, plus I still have my Pentium 4 that I got in 2005. I could easily buy a new computer, much more powerful and all, but what's the point? I've had lots of fun on these two, and the possibilities are far from exhausted, therefore there is nothing wrong with them, and I absolutely refuse to believe otherwise. Not powerful enough to run some software? Guess what, it is software that is wrong. I'm not going to change my opinion about hardware just because someone developed some piece of bloatware. Funnily enough, the people who expect me to accept someone's arbitrary requirements as objective facts without questioning, are the same kind of people who would try to tell me how to stand up for myself and not be a pushover. Hahaha. What a bunch of nonsense. But MTA has hardly ever been a part of this problem for me, so it looks like I'm better off than you in this regard. I'd say it's more Microsoft's fault for making more and more demanding Windows. As for MTA, it just supports the versions of Windows that are supported by Microsoft, which makes sense - although it depends on how you look at it, which I guess is the point of this topic. But I wonder what's wrong with your graphics drivers on Linux. Does MTA not work at all or does it just run poorly? Yesterday I managed to start MTA SA 1.5.9 on that Pentium 4 under Arch Linux 32. It supports OpenGL 1.4 using Mesa i915 driver (or OpenGL 2.1 with some non-default settings, but it may be bad for performance). It was far from playable and had some visual glitches, but it ran. Perhaps could be improved with some settings, because I think I had GTA SA in general run faster in 2011-2013 than it does now - not sure if I can trust my memories, but it doesn't look believable that I could develop the NPC traffic resource and record some MTA videos while lagging that much. As for my laptop, it has Intel HD 2000 (supports OpenGL 3.3) and runs well enough. So it would be surprising to me if your Intel HD from 2010 couldn't run MTA on Linux at all. Without knowing the details, I would expect it to run and be playable at least. Or almost playable, depending on your threshold of "playable" and the server. That said, I do like the idea of MTA keeping support for systems it currently supports, or even supporting XP again. It sounds attractive to be able to run MTA under the same configuration I did in 2008. But as far as OS is concerned, this wouldn't make a practical difference for me because I switched to Linux long ago. So while I do more or less support your position on this matter, I can't personally request the same thing from MTA developers. I mean it doesn't make much sense for me to ask for something that I know I'm very unlikely to make use of. I agree with your notion of universal code that just does what it's supposed to do regardless of environment where it's running. When I write code, I try to make it do its own thing correctly, and depend as little as possible on platform or library specific stuff. But I can't speak for MTA because MTA is not a standalone program, it inherently depends on GTA. Meaning there's lots interaction with some particular executable, in ways defined by Windows and inherently less room for just doing its own thing. In the end, it's nice to know I'm not the only one dissatisfied with this trend of more and more demanding software and thinks there needs to be some resistance. I've just kept MTA out of this because it has been "good enough" for me.

It looks like my post is irrelevant then. I was assuming you wanted to make new dimension IDs so that it would be easier to avoid such mistakes like accidentally using same dimension ID for things that should be in separate dimensions. But from what I understand, that's not the problem, so you can just pick some ID and use it for your island. Dimensions don't have weathers, all they have is elements. However, if you set weather in the client-side script, it only changes for that player. If you change the weather for the player alongside putting that player in the dimension, from their perspective it will appear as if that dimension has a different weather. To achieve this, whenever you call setElementDimension, you can also call triggerClientEvent to trigger a custom event, which then you would use to call setWeather on the client-side script. For customizing weather-related properties, in addition to links that @FlorinSzasz posted, there are several other functions, such as setColorFilter and setFogDistance, that you would call on the client side.

You can do that using setWeaponProperty function. I haven't used it myself so I'm not familiar with it, but according to that page, you need to modify anim_loop_stop to increase the firing rate.

That's a low level of detail object, which appears when the original one isn't showing. It's a separate object with a different model ID, so you need to add another removeWorldModel call with that other model ID.

onClientElementColShapeHit event doesn't trigger for vehicles, only colshapes. You must be looking for onClientVehicleCollision.

You can't "create" new dimensions. But the element limit is 2^16 = 65536. And there are also 65536 dimensions - just enough to store each element into its own separate dimension. This allows you to create your own dimension system, based on the built-in one. In fact, I tried something like that a long time ago. A dimension system that used arbitrary values as dimension IDs, with each value being assigned a unique integer from 0 to 65535. You can use tables to track things like which elements each dimension contains and which custom dimension system ID corresponds to which built-in dimension system ID.

The proper way in Lua to use arguments in a function created using loadstring is vararg expression, written as three dots. local argument1, argument2, argument3 = ... In your case, the function body would look like this: local player = ... return getPlayerName(player) == 'owner' An example with loadstring: local func_str = "local player = ... return getPlayerName(player) == 'owner'" local loadstringed = loadstring(func_str) local testPlayer = getPlayerFromName("player1") local success, info = pcall(loadstringed, testPlayer)

Resources do not run "for specific players". Each resource runs for all players and on both server and the client. Nothing to start/stop/restart on player join - you do it when starting up the server, just like with ordinary gamemodes. It's just that the gamemodes have to be modified so that instead of doing stuff on the global level, they would do it in their own scopes. For example, if the gamemode executes some code in onPlayerJoin event, you have to modify it to execute that code when the player enters that gamemode instead. Likewise, if the gamemode does something in onPlayerQuit, it has to be done when the player leaves the gamemode - which could be when the player quits, or when they switch to a different gamemode. If the gamemode calls getElementsByType to retrieve all elements of a particular type in the server, it has to pick out its own elements only, to avoid acting on another gamemode's elements.

I guess motorcycles and bicycles have some tilt property that is separate from rotation and changes as you steer. Maybe it's just visual. Maybe it's not even a property on its own, but rather one of the effects of steering state. And I also assume that setElementFrozen only locks position, rotation and velocity - in which case that tilting property would remain unaffected. A long time ago, I tried making a CLEO script that records the player's driving route by writing the vehicle's position, rotation and velocity to a file in short intervals, and then plays it. I wasn't able to get it to look properly on bikes, because the bike wasn't tilting to the side it was steering during the playback - to the contrary, it was slightly steering to the opposite side. I did realize it was because of lack of control states, but didn't know how to overcome that problem. Now that you pointed out the behavior of setElementFrozen, it looks related. Interesting to find out many years later

Oh, hey there Slothman! Long time no see. Although I do not tend to know people well (since I'm not a very social person), you're one of the people I remember when I think of the old days. For this reason, when I returned to this forum a couple of years ago, after not visiting for several years, it was sad to find that some of the people I could recognize, including you, were no longer here. So happy to see you again! Because peds are my favorite MTA feature, I consider your creation of Zday and Slothbot an important step towards getting the community to use this feature (although I'm not sure if I have even seen Slothbot in action). But I can still remember feeling disappointed when peds remained criminally underused. My NPC HLC resource that I made in 2012, was supposed to serve as a library for people who want to control peds from their scripts without having to take care of low level stuff like individual control states - thought it would make ped scripting more popular. But even though I based my traffic resource on it, in the end it hardly got anywhere, because of all things I wanted to implement, it only had the most basic tasks. From what I know, there have been more people making use of peds in the recent years. But I still want to do what I was trying to do many years ago. To turn ped scripting into an easy task that even beginners could do.

The purpose is to alter the behavior of functions - or so it appears. It's all just assignment to variables. local _triggerClientEvent = triggerClientEvent This line creates a local variable _triggerClientEvent and assigns the value from triggerClientEvent - which usually means that _triggerClientEvent now refers to the MTA-defined function that triggers the client events from the server. function triggerClientEvent( triggerFor, name, theElement, ... ) ... end This one creates a function and assigns it to the global variable triggerClientEvent, meaning that calls to triggerClientEvent from other scripts in the same resource will call this function instead of the original one. This new function probably contains _triggerClientEvent calls, which are calls to the MTA-defined function.

I played MTA SA in 2007 several times but because it was the non-scriptable, Race version, it didn't mean much to me. But things changed in 2008, when Deathmatch version was released. For the next several years, I spent lots of time scripting, because that was what I loved doing the most, and I don't regret it the least bit. I could perhaps have made better decisions regarding various details, but I would still have spent hours upon hours scripting either way. Joining in 2007-2008 means MTA was already in the middle of action. I miss those days, and I'm not sure how I feel about "then vs now". On one hand, seeing lots of new members makes me happy that MTA is gaining popularity that it deserves. On the other hand, it often seems to me that few people from those days are still around, that things have changed and they will never be the same again. But seeing several people senior to me posting now in this topic contradicts my usual perceptions, which is very comforting . It's great that in addition to new members coming, MTA community still has active members from the old days. I have some plans to get back into scripting, because there are things I was supposed to make many years ago, but didn't. Well, actually, I did try scripting a while ago, and it was as enjoyable as it had always been. That's when I remembered what I had been missing. This evokes nostalgia, and I don't think I have even played MTA VC

The only way I can think of that I know would work is, opening and reading the model file using fileOpen/fileRead to retrieve the UV data into a table. Then drawing it with dxDrawLine or dxDrawPrimitive. In other words, your script needs to parse the DFF files, which may be quite some work if you're not familiar with DFF format - unless there's some library that does it for you, but I'm not aware of any. Plus you can't just access the original game files using file functions, there needs to be a DFF file in the resources - which may also be the reason it's all done on custom cars in that video.

Maybe this has something to do with non-power-of-2 dimensions? If so, then 16x16 or 32x32 would give a better result than 20x20. I don't see an obvious reason why it would be like that, since if it can properly load the data coming from a file, it should be able to load the same data coming from a string. But it all depends on what's happening inside dxCreateTexture. I guess there might be some indirection involved, like drawing the texture to a buffer and then reading it to produce the final texture, which could degrade the quality for non-power-of-2 textures.

You can use split to split the string into tokens and convert each of them to numbers. local xyz_str = guiGetText(edit_box) local xyz = split(xyz_str, ",") -- xyz is now a table of tokens if #xyz == 3 then -- check if there are exactly 3 coordinates local x, y, z = tonumber(xyz[1]), tonumber(xyz[2]), tonumber(xyz[3]) if x and y and z then -- check if each coordinate is a valid number -- code to execute if coordinates were parsed successfully else -- code to execute if not all coordinates are valid numbers end else -- code to execute if there aren't exactly 3 coordinates end This is a good start, but the space characters have to match exactly, and the numbers can only be non-negative integers. I was going to improve the pattern to allow arbitrary number of spaces, but then I remembered non-integers and negative numbers and thought it would be too much hassle to get it right. With split, we allow tonumber to take care of all number formats and space characters.

You can do that in two ways. The first way is the way you worded it - damage gets disabled or enabled when a player enters or exits the vehicle. To do that, you need these events: onPlayerVehicleEnter or onVehicleEnter - to detect when a player enters the vehicle onPlayerVehicleExit or onVehicleExit - to detect when a player exits the vehicle And this function to toggle the damage: setVehicleDamageProof Also, it depends on whether it has to work just for the driver seat or all seats. If you want it for the driver seat only, then you need to check if the seat parameter is 0 in vehicle enter/exit events. If you want it for all seats, then in vehicle exit event you need to retrieve the list of players in the vehicle using getVehicleOccupants and check if it is empty - so the damage will only be enabled if there are no other players remaining in the vehicle. The second way is to check every time the vehicle is damaged, and cancel the damage if it's occupied. This has to be done client-side because only client-side damage events can be cancelled. You need this event to detect when the vehicle gets damaged: onClientVehicleDamage And call this function from within that event to cancel the damage: cancelEvent If you need it for the driver seat only, use getVehicleOccupant to check if there's a player in the seat 0. For all seats, retrieve the list of players in the vehicle using getVehicleOccupants and check if it is non-empty.

It seems like you're asking two different questions here. If you want to detect actual collisions of the object (instead of just origin point of the object, which Spakye's post assumes) near the player, you could cast lines in several directions from the player and see if any of them detects an object. It may be sufficient if you just need to detect large objects (terrain, buildings), but not that reliable for smaller ones since collision checking lines are likely to miss the objects. What points do you pick for line of sight? Collisions mainly consist of boxes, spheres and meshes. For boxes and spheres (the former of which are used by some buildings), it can be objectively determined whether a point is "inside" or "outside", so perhaps if you cast some line from the object's position to some nearby point, the collision gets detected, which is why it happens to work for you with buildings. But objects of arbitrary shape use meshes, and there's no "inside" for meshes - a mesh is just a bunch of triangles put together to form a surface. When the line of sight crosses the surface, a collision is detected. A primitive solution is to use getGroundPosition or getRoofPosition to check if there's anything above the point you're checking. But it will fail if there are ceilings. Or you could choose several points on the "outside" so that at least one point would be visible from any place that is "outside". Then, whenever you want to check if some position is "outside", use processLineOfSight between that position and all of your chosen points. If at least one of them is visible from that position, that means it is "outside". This solution should be reliable, but manually choosing the visibility points beforehand means it will only work in that area. If the area you want to cover is large, that means lots of work (unless you make a script that automatically picks the points for you), plus you need to limit the number of points being checked because lots of processLineOfSight calls will be bad for performance.

It's not clear from the code and other info you've given what exactly the problem is. I mean if location is meant to indicate that the character is newly created, you need to pass it to this code when the player creates a new character. How creation/selection of characters is done in your script, that's another thing, we don't know that.

I'm glad that was helpful

I'm not sure if I understood what your problem is because it doesn't make sense to somehow get some Z coordinate from two XY points and some angle which was used to get one of those XY points. But I'll assume this is what you're trying to achieve: you have two points, origin and target, and you want to get a third point, which is in the same direction from origin as target is, but at arbitrary distance. So you could effectively push the target towards or away from origin. Is that right? If so, then it's some basic vector math. local newDistance = 50 -- set dX, dY, dZ to offset from origin to target local dX, dY, dZ = targetX-originX, targetY-originY, targetZ-originZ -- using Pythagorean theorem, calculate the length of dX, dY, dZ vector local oldDistance = math.sqrt(dX*dX + dY*dY + dZ*dZ) -- multiply each component dX, dY, dZ by newDistance and divide by oldDistance -- so newX, newY, newZ becomes the offset from origin to your desired point local newX, newY, newZ = dX*newDistance/oldDistance, dY*newDistance/oldDistance, dZ*newDistance/oldDistance -- add origin to newX, newY, newZ newX, newY, newZ = originX+newX, originY+newY, originZ+newZ -- newX, newY, newZ now contains the coordinates we're looking for newDistance/oldDistance expression repeats 3 times so we can calculate it once, store it in a variable and reuse for each component. Also, multiplication/division line can be combined with addition line. Then we get this: local newDistance = 50 local dX, dY, dZ = targetX-originX, targetY-originY, targetZ-originZ local oldDistance = math.sqrt(dX*dX + dY*dY + dZ*dZ) local multiplier = newDistance/oldDistance local newX, newY, newZ = originX+dX*multiplier, originY+dY*multiplier, originZ+dZ*multiplier

The global environment (the table holding the global variables) can be accessed using variable _G. local playerName = getPlayerName( player ) local variableName = "Timer"+playerName _G[ variableName ] = setTimer ( function() end, 1000, 0 ) However, building variable names is usually not recommended for generic manipulation of data. Instead of putting the timers into global variable space, you can create your own table specifically for timers: -- at the top of the script playerTimers = {} -- then, somewhere in the code local playerName = getPlayerName( player ) playerTimers[ playerName ] = setTimer ( function() end, 1000, 0 ) But I suspect that's still not exactly what you want to do. Should the timer be linked to player's name, or to the player? If it's linked to the player's name, then if the player changes their name during the game, playerTimes[playerName] will no longer refer to the timer created before the change. If that's not what you want, you can bypass the retrieval of the name and just use the player element directly as table key: -- at the top of the script playerTimers = {} -- then, somewhere in the code playerTimers[ player ] = setTimer ( function() end, 1000, 0 )

You can make the ped perform actions using setPedControlState, with accelerate, vehicle_left and vehicle_right being the most important controls you would want to use for driving. You also need to retrieve the relative placement between ped's and player's cars, using functions such as getElementPosition and getElementRotation and some math. All these things need to be done repeatedly so that the control states would be updated as the elements move. If you also want to make the ped follow the roads (instead of going straight towards the player), then it gets more complicated because the script has to do pathfinding.