DiSaMe

Aš kažkada scriptus dariau, ir dar pats savo serverį su savo gamemode sukūręs buvau. Bet laiko nebuvo, tai viską nutraukiau, o po to iš viso nustojau MTA forume lankytis ir apskritai su MTA kažką daryti. Dabar keli metai praėjo. Pasiilgau MTA, sugrįžau čia į forumą. Nekoks jausmas, kad taip ilgai nesilankiau. Nežinau, ar ką nors vėl scriptinsiu, tik norisi prie MTA būti. Bet šitam subforume, žiūriu, tikrai veiksmo beveik nėra.

Hey folks So, I joined this community back in 2008, when MTA SA DM DP1 was released. It was great. I played in servers. I scripted stuff. The scripting part is especially important here, because I was amazed to see what possibilities to customize the game MTA SA gives to the scripters, and that's what got me involved so much. It was by scripting on MTA that I got lots of coding experience. I had such a great time that 2008 was one of the most memorable years for me, because I can still remember the good moments, including my first time playing the non-race version (I played MTA SA Race in 2007, but only a little bit, and didn't think much of it) and my first attempts to script. As time went by, I set goals for myself. I thought of making my own server with my own gamemode. I didn't just want it for my own gains, I wanted it for the good of MTA, too! I wanted to make use of MTA scripting possibilities, to let the greatness of MTA be known! However, as I still wasn't that good at scripting nor at setting goals (they were huge), I wasn't exactly being productive. I experimented a lot and learned a lot, but apart from that, it didn't really go anywhere. After a few years of playing around, I realized my goals weren't going to come true. I decided I just wanted to be useful to MTA community. That's when I made and released a few scripts, including Drawtag, Gravity gun and NPC traffic. Later I made my own server after all, with a gamemode very different from what I had originally planned. But I was too busy with crap in my life to continue working on it, so I had to end it. I didn't want to abandon MTA. All those dreams that never came true. But I didn't see any other way. I stopped playing and scripting on MTA. Eventually I drifted away and stopped visiting this forum altogether. During the time I was away, I was just living life, but not really feeling like I was enjoying it. There were ups and downs. You know, everyone goes through different phases of life. But now I feel bad about it. It wasn't necessarily my fault that I left, but it was my fault that I didn't come back for so long. Now that I finally did, it seems there have been people who were looking for me, but I don't even know if it's of any use to reply to messages I received 3 to 5 years ago. I'm regularly on YouTube though, but even there, often I didn't feel like replying to comments right away and forgot about them later. I'm feeling like a busta who ran away and left his homies when there was no reason to. I'm feeling like I have betrayed MTA because it gave me so much, but I didn't manage to benefit it as much as I thought it deserved. Things have surely changed around here while I was gone. I see there are admins and moderators who weren't even on this forum when I left. And honestly, I don't remember many people in particular. I don't remember well who was and who wasn't here back in those days. I don't know if anyone here misses me. I'm so out of touch. Kinda sucks, doesn't it? After wandering for years, I'm finally back home, but I'm not even sure if it's still the same home that I've been missing because I don't even know if people here are still the same people that I left. But I see some usernames that look familiar and I can take comfort in that. MTA seems to be doing much better than before. I didn't expect it to become so popular! I'm supposed to be happy about this, because it was my dream to see MTA achieve the popularity that it deserves. But it feels like yet another thing I missed out on. I wasn't a part of MTA community during the time that it grew so much. What a shame. Unfortunately, I don't have plans to resume MTA scripting, not big ones at least. It's a pity, seeing how MTA now has scripting features that I used to dream of. But I just don't think I currently can focus on it. Still, it feels tempting to try. I'm curious, how much have peds been improved? In the old days, I would run into problems because the peds would lose information about health, ammo and many other things, when they got streamed out, so I couldn't have them properly synced and had to resort to workarounds. What about model/texture replacing? I see there are some new related functions, so this functionality must have been improved, right? I remember trying to import Liberty City and Vice City back in 2010, and I managed to convert Liberty City, but I couldn't load it all at once, because 512 MB of RAM was not enough to replace that many models at the same time. And replacing the models dynamically (based on distance to the player) wasn't working well, there were bugs and some models weren't actually getting replaced. My scripts website is no longer there. I still have the files, but I see someone made a GitHub repository and uploaded the resources there, so I guess it's okay as it is. The resources are available to everyone and I'm thankful for that. If I ever decided to make scripts for the community to use, I would start from scratch rather than continue working on the old ones. The same can be said about the server I had, I have the gamemode and the database, but if I wanted to run a server again, I would start the gamemode all over. While the future of my involvement in MTA scripting is uncertain, I'm seeking to be active on this forum once again. I want to be in touch with MTA and the community. Maybe I should try helping people in scripting section or something like that. Perhaps make some tutorial. I'm much better at programming than I used to be. I'm working on my own game engine, but I don't want to make it sound like I'm doing something big or anything like that. This is another thing that I took my time to play around with. I started it long ago, I learned a lot, but I have little results. Either way, it was MTA that inspired me to do it. And I have an idea to make a common scripting interface for MTA and my engine so that scripts made using this interface would work on both. Not stating that's what's going to happen, I'm just thinking of ways to make scripts for MTA even when I have to focus on something else. With things I learned in the recent years, some MTA script ideas that I once considered difficult to implement, look much easier now. Hell, even if I made the mistake of leaving MTA for so long, these years were still far from wasted. That's pretty much all I wanted to say for now. I left for several years, now I feel bad about it, "but now I'm back, and I know what I've been missing". Not sure how much I'm going to be involved in MTA scripting, if at all, but I just want to be a part of this community again.

MTA 1.5 and greater versions seem to have problem with launching under Wine. I need to test if that's true someday. https://wiki.multitheftauto.com/wiki/Cl ... nux_Manual The last time I tested, I had problems running it on 64-bit wine prefix, but it worked on 32-bit.

I have done this on Linux by running two instances of Wine and an instance of MTA in each of them. Not sure if there's any solution other than virtual machines on Windows.

You can change the ped's position on the client without changing it on the server. But you can't do the opposite. You can't change the server-side position (which determines who's the syncer, and some other stuff) without making this change visible for all players.

Scripting-wise peds are almost as good as they need to be. Most problems are related to sync and/or element streaming, not scripting. To make the peds function properly, we need the changes which I could classify into 3 parts: 1. Sync more of the peds' properties and make them retainable between streamout and streamin on the client. Lots of times people have wondered why the ped only shoots 1 bullet, or why the ped doesn't play the animation. That's because some of the important properties are synced improperly or are not retained on the client. Those include weapon ammo, health and stats. If the server sets the property when the ped is streamed in for the client, it seems fine. Then you go away and come back, it's not the way it was. Or you join the server after it was set, you don't see it. This problem can be worked around by creating a timer which keeps setting the property every few seconds or so, but it consumes CPU and bandwidth, therefore, it's the most important issue about ped sync to fix. 2. Ability to set the element properties in server without syncing them with the clients. For example, if you set the element's position, it will be sent to all clients, so that all of them would see it in the new position. But what if the element is far away from the client? The position will still be updated, even if it's not necessary since the client might not need to see what's happening miles away. Take my traffic resource, for example. Since the peds which have no streamer are not affected by physics and I still need them to move, I simulate this movement by setting their positions on the server every two seconds or so. If the players are spread all around the map, there are peds all around the map as well, and they are all updated for all players all the time, which is very bandwidth-inefficient. Every player only needs to be aware of correct positions of a small fraction of peds. So if we could set the element's position (and other properties) on the server without syncing it with the clients (or only syncing it for particular clients), we could move the peds without syncers without using up lots of bandwidth. 3. Peds entering/exiting vehicles. This one is the least important, since as AlexTMjugador has said, it can be achieved by scripting. Actually, I was once going to make it (but didn't). It's still preferable to have a built-in one, because making use of existing gameplay mechanics is better than creating the new one. But it's not as important as the other two issues. With these issues taken care of, MTA would give us pretty much of what we need to have properly functioning peds.

Excuse me, but you're kind of putting words in my mouth, because that's not what I've said. Actually, Lua is my favorite language. I'm making a game engine in C and it's scriptable in Lua. That's because it's inspired by MTA. OOP is one of the aspects where I can see the beauty of Lua's simplicity. Instead of providing us with a built-in class system, it allows us to control the behavior of individual tables, which enables us to make classes ourselves. Not sure where C fits into this OOP thing, since it doesn't have any syntax for OOP at all. I do write OOP in C using opaque pointers and functions that receive those pointers as arguments. That's what I pretty much got used to doing in C, but that's not as convenient as OOP in Lua. Lua does allow you to make variables only accessible via particular objects. Consider this example: function Person(name) local self = {} local person_name = name function self.getName() return person_name end return self end Calling 'Person' function will create and return a table (an 'object'), and the value passed as the first argument can only be read by calling getName field of this table, and it cannot be accessed from outside the 'Person' function. C/C++ easier, really? Easier how? I mean... Strong typing, pointers, all that stuff... How is that easier than Lua? Speaking of performance, one of the reasons C/C++ are so fast is because there are many things that have undefined behavior. Which allows the optimizer to pretend that those situations will not occur, making more assumptions about execution of code during the compilation. Undefined behavior would totally kill security in MTA, because the servers can execute code on clients' computers. To avoid this problem, all behavior needs to be defined, and such implementation of C/C++ wouldn't be that fast. Though it would probably still be faster than Lua can be made, because Lua is more dynamic, the point is, what makes C/C++ fast, the same thing makes the language unsuitable for software that lets the servers execute code on clients' computers.

I've heard that having 65536 slots (back when the player limit was that high) caused the RAM usage to go up by 512 MB, even though those slots were empty. So if it still works the same way, 4096 slots would take 32 MB.

Seriously, what does that even mean, "coroutines are useless"? Coroutines are the way to separate the procedure that's performed in steps (rather than all at once) from the rest of the program. If they are useless, aren't functions useless as well?

Calling dbPoll with -1 timeout parameter will wait for response. That's how it will return the result to the calling function. If you instead want to suspend the execution of function and resume it when result is available (without forcing the whole server to wait), use coroutines (http://www.lua.org/manual/5.1/manual.html#2.11).

If you rotate an object 180 degrees around X axis and then 180 degrees around Z axis, you get the same result which you do by rotating the object 180 degrees around Y axis. Whether it's in degrees or radians, it's still the same.

object:method(arg1, arg2, ...) Is the same as object.method(object, arg1, arg2, ...) Therefore player:setMuted(muted) Is the same as setPlayerMuted(player, muted)

Of course you can't cancel the damage that has already been done. You can't prevent the event from having occurred because you can't change the past. This is the case with server-side damage events, they are triggered after the ped/player was damaged.

Or, when the player is still aiming, but in another direction, they will stop aiming at the objet too...

Except "onPlayerTarget" doesn't detect when the player starts/stops aiming, but rather when the player starts/stop aiming at particular element.

By 'aiming vector' I mean the vector pointing to direction where the turret is aiming. And I said which matrix exactly, vehicle's matrix.

'localPlayer' outside functions doesn't come from anywhere. It's nil in that line where 'addEventHandler' is called. And I don't know what tables you're talking about. The problem is exactly not that - 'unpack' takes a table as an argument, but you're passing an element.

Also, while ipairs starts at key 1 and increases it, pairs loops through the table in unspecified order.

'ipairs' iterates up to first nil value. Which means no subsequent values are processed in your code.

isElementWithinMarker

If I get it right, returned rotation of turret is relative to vehicle's rotation. So in order to get the target position, you would have to get the aiming vector from turret's rotation, combine it with turret's position using getVehicleComponentPosition and then transform the result into world coordinate system by multiplying it by vehicle's matrix (getElementMatrix).

You're welcome

Oh, come on... local visitCount = 0 function increaseVisitCountOnJoin() visitCount = visitCount+1 end addEventHandler("onPlayerJoin", root, increaseVisitCountOnJoin) Of course, this is server-side, and in order to draw it via DX drawing functions on the client-side, you need to use element data or custom events to send the data to the client.

Maybe this function will help: getPedTask But I don't know if it has some 'aiming' task, you should play around with it and see what it returns to find out. If there isn't such task, then the closest thing you can do is probably checking when aiming control state changes: bindKey But it's not that accurate for detecting when player stops aiming.

So that the effect would be undetectable by visual means but still would exist and eventually cause the element limit to be reached.