DiSaMe

I can somewhat relate to you, but it's a little different. I don't have any specific plans for MTA at the moment, but I also have thoughts on single player vs multi player occasionally. It's nice to have your own server, but the idea of using MTA as a scripting engine for single player is also very attractive. When I ran a server many years ago, it had NPCs, but they didn't do much, and the server wasn't popular enough to become heavy on hardware, so my laptop was able to handle it without problems. Having NPCs walking and driving around all over the game world with lots of players in the server, would be much more demanding. My suggestion is to make your own NPC system, with custom sync and all, although it's going to be a challenge. For example, you can start with client-only NPCs, with scripted movement that overrides the game's physics (like setElementPosition/setElementVelocity in onClientPreRender or a timer with short intervals). Every client generates and moves the NPCs based on values of random seed and time. This way, you can get all players to see the same thing, just by having the server sync those values (you'll need a custom random number generator because Lua's math.random isn't guaranteed to produce the same values between players). Then you'll likely want to allow player interaction with NPCs. If a player crashes a vehicle into NPC's vehicle, you'll need to stop overriding the position, destroy the client-side NPC and create a server-side one, allowing the game's built-in physics and MTA's built-in sync to take over so everyone would see the NPC's vehicle being pushed and otherwise affected by collision. It's a lot of work, but it can make multiplayer with NPCs around the map feasible.

I never got to know you, but it's sad to see someone leave MTA. But I have "left MTA" long ago and I still visit here all the time, so leaving doesn't have to be what it looks like. Your post serves as a wake-up call reminding me that I should find some time to script on MTA for once. Whatever path in the life you're taking, I hope it's for the better

MTA doesn't save the domain names? Didn't know that. I agree, it can be a problem. When I ran my own server many years ago, I wasn't sure if my IP address could change so I used a domain for this purpose. If the address changes, the domain can still serve as unchanging reference. If MTA only remembers the IP address, that doesn't eliminate all advantages of domains, but still does make the change of address a bigger inconvenience than it should be.

When you set the property, it stays frozen. So for example if you call getWorldProperty and then pass its return value to setWorldProperty, that value will stay until you call resetWorldProperty. But some of those functions (including getSkyGradient) are limited because they can only return the values previously assigned by script - meaning you can't get the unmodified value and assign it to freeze it. It seems that smooth transition is possible for color filter, because getColorFilter has isOriginal argument, allowing you to take the values that would be there if they weren't overridden by script so you can know exactly what values to interpolate to. But it doesn't help much when the same can't be done to other parameters.

There are several functions for controlling the relevant properties, such as setSkyGradient, setWorldProperty and setColorFilter. But this seems like such a hacky way to do it that I'm not even sure if it can even be done properly, because lighting is not just time-dependent, it's weather-dependent too. So even if you freeze the lighting, it's going to switch suddenly (from old weather to new weather) when you unfreeze it. A more reliable solution is to take full control of those properties, completely overriding the built-in weather and implementing your own weather system. I've had this idea in the days before it was possible in MTA (because MTA didn't have all those functions), but it may be an overkill, depending on your needs.

You can make your own functions that operate in terms of your custom concepts, and use dxDrawRectangle/dxDrawText under the hood for actual drawing. An example: function getCoords(coordSys, x, y) if coordSys then x, y = coordSys.x+x, coordSys.y+y end return x, y end function makeCoordSystem(parent, x, y) local finalX, finalY = getCoords(parent, x, y) return { x = finalX, y = finalY } end function drawText(coordSys, text, x, y) local finalX, finalY = getCoords(coordSys, x, y) dxDrawText(text, finalX, finalY) end function drawRectangle(coordSys, x, y, width, height, color) local finalX, finalY = getCoords(coordSys, x, y) dxDrawRectangle(finalX, finalY, width, height, color) end This implements a concept of coordinate system, the coordinate offset described by table with keys x and y. With this, you can do: local onScreenHud = makeCoordSystem(false, x*1200, y*120) -- false means onScreenHud will be placed in absolute coordinates function drawHUD() drawRectangle(onScreenHud, 0, 0, x*1400, y*400, tocolor(0, 0, 0, 150)) drawText(onScreenHud, "Text", x*20, y*10) end Since makeCoordSystem has parent as first argument, even coordinate systems themselves can be positioned with respect to other coordinate systems: local someInnerHud = makeCoordSystem(onScreenHud, x*20, x*40) function drawInnerHUD() drawText(someInnerHud, "Text in the inner HUD", x*20, y*10) end It's all about coming up with the right abstractions. As an example, you could modify this to add width and height properties to coordinate systems, and use them in calculations so you wouldn't have to write x* and y* everywhere.

I thought there was a setting for auto-updates, until I checked to find out it only allows choosing between stable and nightly. Too bad. But doesn't auto-update ask for confirmation? I can remember MTA asking if I want to update or not. Although it's probably just some old memories, and even then, having to reject every time would be inconvenient. I haven't used MTA in a connected environment for quite some time so I haven't been aware of how it works. Auto-updates in MTA have never been a problem personally for me, but I agree with all your points. The reason I got so hooked on MTA is the freedom it gives. It was mostly about creative freedom, but that's just a part of it. I've seen MTA receive undeserved hate because of things it does right, like disabling glitches by default and allowing to enable them on a per-server basis. So it stands out when MTA, while otherwise being the best multiplayer at giving freedom, actively limits the freedom like that. You're right about local play. While it's a great thing to be able to play with hundreds of other players over the Internet, I don't like the idea that multiplayer must revolve around online play. Playing locally is just as valuable, even solo - with MTA's scripting capabilities, playing alone can make as much sense as playing with others (funny because I probably spent most time in MTA alone, although I was scripting rather than merely playing, so it doesn't count). I don't like living in the so-called "modern world" of "smart" devices and apps and some other crap where you're supposed to be part of a whole and blindly accept whatever they shove your way. If they want, they can make the software stop working the way it was working, and you will no longer be able to do what you used to do. I prefer being in control of what happens on my devices. With stuff like CrowdStrike incident happening not so long ago, I thought people would understand why someone would not want automatic updates. Well noticed regarding the <min_client_version> parameter. It's contradictory to have a parameter that allows or disallows the players to do something that they're not allowed to do anyway. But I can see a problem with making updates optional - even if the choice was added to the new versions, you still wouldn't be able to choose versions prior to that (because the earlier versions would still auto-update), unless those earlier versions were also updated to add the choice. With MTA being open source, you can compile older versions yourself and otherwise suit it for your own needs, so ultimately it does leave it up to you to choose, but compiling just to disable auto-updates is an overkill. Sorry, but you got it backwards. It doesn't make sense to require justification not for imposing limitations.

Hey, I never used to be interested in GTA3/VC versions of MTA. Their popularity must have already been in demise when I joined this community. I only got seriously involved in MTA after MTA SA DM DP1 was released, because of endless scripting capabilities it offered. Most of the time I spent in MTA SA, I did so alone, scripting in my own local server. And even though there were moments I enjoyed playing on other servers, that was usually because they, too, made use of those scripting capabilities. So it's easy to understand why earlier MTA versions didn't catch my interest. However, it's a bit of a sad realization that MTA for GTA3 and VC has been forgotten for the most part. I mean that's where it all started. Sometimes I wish I had been there to experience this greatness in its early days (but I didn't even have the internet connection back then). And because of that, it's nice to see that you guys are still working on it. Still keeping roots of MTA alive - great job! I wish the current MTA supported GTA 3 and VC the way it supports SA - from what I read on other topics, that's how it was initially intended to be. But it's easier said than done.

Downloading the missing files from https://packages.debian.org works for me. At least it did when I tried, which was the last year (maybe even this year too, can't remember). In addition, I don't install them into the system - I put them into some directory and run the server with environment variable LD_LIBRARY_PATH=path/to/directory instead. So even if not a "proper" solution, it doesn't mess with system directories.

setWeaponProperty can change the damage property, but it will affect all players. To change the amount of damage done by individual players, you can detect the damage using onClientPedDamage and onClientVehicleDamage and calling setElementHealth to reduce the health further, and you may also want to call killPed if the adjusted health gets to 0 or lower, in order to attribute the kill to the attacking player.

If you want to apply the shader to texture, you need engineApplyShaderToWorldTexture. But you're calling engineRemoveShaderFromWorldTexture, which does the opposite thing - it restores the original appearance that was previously modified using engineApplyShaderToWorldTexture.

This block: for theKey,theSound in pairs(spawnedSounds) do -- end was meant to be used separately from the code that starts the sounds. By putting it into the same block, you're stopping the sounds for all peds if the current ped has deadzombie set to true, as it loops through spawnedSounds table. I'd say your initial code is close enough, you just need to use spawnedSounds[peds] to refer to the current ped's sound. But then the warning will still be there, it happens because calling stopSound destroys the sound element, but the (no-longer-valid) handle is still in spawnedSounds table, so when it gets passed to stopSound the next time, you get a warning. You can remove a value from the table by assigning nil to it, so destroying the current ped's sound would look like this: stopSound(spawnedSounds[peds]) -- stop the sound, destroy the sound element spawnedSounds[peds] = nil -- remove the no-longer-existing element from the table But even then, I can think of scenarios where things go wrong. Like for example the loop is executed every 6 seconds, so you call playSound3D and store the result to spawnedSounds[peds] repeatedly, meaning the sound element from the previous execution is still overwritten by new sound element. So the next stopSound call will only stop the ped's most recent sound. I guess the right way to handle this depends on your needs, but in any case, assuming you clean up the sounds from the table after stopping them, you can check if the sound from earlier executions exists by directly checking the value in the table: if spawnedSounds[peds] then -- called if the sound exists else -- called if the sound doesn't exist end

Maybe for a more intuitive understanding, you shouldn't think of them as asynchronous code that executes "alongside" the rest of the code, but rather as code that executes "inside" coroutine.resume. Because that's exactly what happens. When execution enters coroutine.resume, it enters the coroutine, then when it reaches coroutine.yield, it leaves the coroutine and returns from coroutine.resume. Consider this concept of a coroutine-like construct: function resumeCustomCoroutine(co) local nextFunction = co.functions[co.index] nextFunction() co.index = co.index+1 end local testCo = { index = 1, functions = { function() print("first") end, function() print("second") end, function() print("third") end } } resumeCustomCoroutine(testCo) -- prints: first resumeCustomCoroutine(testCo) -- prints: second resumeCustomCoroutine(testCo) -- prints: third You have no problem understanding that all code inside testCo.functions is executed inside resumeCustomCoroutine, do you? And yet, testCo.functions looks like a piece of code that executes "in parallel" to the code that calls resumeCustomCoroutine. You can think of coroutine.resume the same way, only instead of separate functions, you have "segments" between the start of the function, coroutine.yield calls and the end of the function. Lua itself has no such thing like JavaScript's event loop. And I don't know how MTA does things internally, but that doesn't matter - it just makes calls into Lua through event handlers or various callbacks, including those passed to fetchRemote. And wherever you call coroutine.resume from, it will advance the coroutine's execution up to the next coroutine.yield call. Actually, if you look at makeCallback in that link, you can see it calls coroutine.running to store the current coroutine into variable thread, which is later passed (indirectly through nested function, then assertResume) to coroutine.resume. connect function uses makeCallback to create such coroutine-resuming function and passes it as a callback to socket:connect, then calls coroutine.yield to pause its own execution. So not only it's possible in MTA - it's the very same thing I did with fetchRemote, only structured slightly differently.

Your start angle is -270. The stop angle is: When the health is 100: (100 * 6.3 / 2 - 90) = 225 When the health is 0: (0 * 6.3 / 2 - 90) = -90 So the stop angle is always larger than the start angle, making the arc always visible. You need to choose such numbers that the stop angle would match the start angle when the health is 0.

That's the point, you're supposed to do the work from within the coroutine. testFetchAndOutput is an example of such function. It looks like a single function but executes over multiple invocations of the main thread. So you need to transform testFetchAndOutput into something that does all the work you need to do. Well, you shouldn't be resuming this coroutine like that. The coroutine should be resumed when the response data arrives, which the callback in fetchRemoteAsync already takes care of. What you need to do from the main thread is what my example already does, which is creating and starting the coroutine using coroutine.create and a single coroutine.resume call (optionally you can pass arguments to coroutine.resume to be used as arguments for coroutine's function). The rest of the coroutine will execute when response arrives. Until then, the coroutine will be in a suspended state and the main thread (the rest of the stuff that happens in the server, including the code following the initial coroutine.resume call) will be executing. That basically turns the coroutine into a thread - not in a technical "OS thread" sense, but in a logical sense. fetchRemoteAsync doesn't execute instantaneously - between calling and returning, the time passes and other things update on the server. Coroutines allow you to avoid callbacks, but they can't just make asynchronous code run synchronously with respect to the main thread. Even if they could - unless it's some initialization code that runs once on start, you don't want to freeze your server in case the remote server takes a while to respond, do you? In general, coroutines are one of my favorite Lua features. Unfortunately, they're very unpopular, and I'm hardly aware of sources of more info on this. Maybe searching in http://lua-users.org/wiki/ will give you some results. It's not just in Lua that they're unpopular. An analogous feature in other languages that I'm aware of is generator functions in JavaScript (using function*, yield and yield* syntax and iterators) and Python (yield and yield from syntax and iterators). In those languages, it's probably overshadowed by async functions, using async/await syntax - in fact, most likely that's what we would be using for this fetchRemote stuff if it was in those languages instead of Lua. Maybe I should make a tutorial on coroutines someday. But in the end, it's a simple concept, the coroutine execution just advances between coroutine.yield calls every time you resume it.