DiSaMe

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.

What function? MTA doesn't count the players who have visited. You have to do it. Using "onPlayerJoin" event.

I'm not sure how you managed to get a warning related to 'getVehicleOccupant', since I don't see it inside your script. Not at line 52, at least. As for 'unpack', that's obvious: trainData[vehicle] = { ["money"]=trainTable["money"], ["spawn"]=trainTable["spawn"], ["marker"]=trainTable["marker"], ["train"] = vehicle, ["blip"] = finishBlip, ["finishmarker"] = finishMarker } destroyElement (unpack(trainTable["finishmarker"])) destroyElement (unpack(trainTable["blip"])) destroyElement (unpack(trainTable["train"])) trainTable["finishmarker"], trainTable["blip"] and trainTable["train"] are elements and you're passing them to 'unpack'. Also, I don't know what this thing means: addEventHandler("startTrainJob", root, startTrainJob, localPlayer) 'localPlayer' is nil on the server-side (unless you assign anything to this variable yourself, of course) and 'addEventHandler' takes a boolean as 4th argument, but this argument is about propagation, and I don't think it's related to whatever you're trying to do.

Animations, weapon ammo, stats and other stuff are not visible to the client unless they were set since the last time the ped was streamed in. If animation is applied before the ped has time to be streamed in for the client, the animation won't show. In either case, it won't show when the player goes far away and returns back. The simplest workaround is setting a timer which keeps applying the animation every few seconds. By the way... setTimer(setPedAnimation(c_Dancers, "DANCING", "dnce_M_a"), 5000,1) This executes setPedAnimation, which most likely returns true, and then passes true as the first argument to setTimer. Which changes nothing except calling setTimer with invalid arguments, producing a warning message. Instead, you need to pass the called function and its arguments as arguments of setPedAnimation: setTimer(setPedAnimation, 5000,1, c_Dancers, "DANCING", "dnce_M_a")

https://wiki.multitheftauto.com/wiki/OnPlayerJoin https://wiki.multitheftauto.com/wiki/OnPlayerQuit

takePlayerMoney needs player as the first argument. And = is assignment operator. Use == to check if values are equal to each other (though there's no need to check for equality in this case).