DiSaMe

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.