• Content Count

  • Joined

  • Last visited

Community Reputation

6 Neutral


About CrystalMV

  • Rank
    Lil' G
  • Birthday 20/02/1993


  • Location

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. MTA 1.5 and greater versions seem to have problem with launching under Wine. I need to test if that's true someday. ... nux_Manual The last time I tested, I had problems running it on 64-bit wine prefix, but it worked on 32-bit.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. CrystalMV


    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?
  8. 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 (
  9. 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.
  10. object:method(arg1, arg2, ...) Is the same as object.method(object, arg1, arg2, ...) Therefore player:setMuted(muted) Is the same as setPlayerMuted(player, muted)
  11. 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.
  12. Or, when the player is still aiming, but in another direction, they will stop aiming at the objet too...
  13. Except "onPlayerTarget" doesn't detect when the player starts/stops aiming, but rather when the player starts/stop aiming at particular element.
  14. CrystalMV

    Vehicle aim

    By 'aiming vector' I mean the vector pointing to direction where the turret is aiming. And I said which matrix exactly, vehicle's matrix.
  15. '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.