eAi

Administrators
  • Content count

    2,981
  • Joined

  • Last visited

Community Reputation

3 Neutral

7 Followers

About eAi

  • Rank
    Godfather (The MTA Team)
  1. Modules

    What would that dialog say? "Would you like to run this plugin? It may destroy your computer? [Yes] [No]" There's no easy way to judge whether code is 'good' or 'bad'. On Android, code runs in a fairly protected sandbox (unless you root your phone) so it can't do anything too nefarious. A native plugin on Windows could do pretty much anything - from deleting all your files, to exploiting the OS to install a rootkit - and there's no way to really detect this ahead of time.
  2. Modules

    Client side modules would be a massive security hole as they'd allow you to run arbitrary native code on the client.
  3. Wanna contribute, need some help

    I wouldn't say that breaks OOP - it's a fairly common situation (for example, Unity would behave exactly the same way). Perhaps .position should be be a function called GetPosition? I'm way out of the loop on this stuff though!
  4. Wanna contribute, need some help

    It's pretty unusual for games to use double precision floating points - for example both Unity and Unreal don't support it (of course, you can use 64 bit floating point numbers, but everything internal uses 32 bit floats).
  5. Wanna contribute, need some help

    It's been basically forever since I wrote any MTA code, but CMatrix and CVector are classes that need to match those in GTA - so their sizes can't be changed. You may have already realised this! This also applies to any class that is suffixed with Interface.
  6. That's correct. There were (years ago, now) some discussions about implementing server-side physics, but it was never going to be an easy task (and would probably require rewriting the client-side physics too, to make them match. It's been a while since I've contributed, but from what I remember, each object has a concept of an owner, and they're responsible for synchronising the physics. Vehicles have dead-reckoning, which makes them have quite good looking physics (though collisions can be an issue sometimes, depending on latency). There's a difference between physics being accurate versus being smooth - and MTA tends towards the latter, which is mostly what you'd want!
  7. Multi Theft Auto: San Andreas 1.5 released!

    Well done everyone!
  8. Question regarding Lua tables

    Tables aren't arrays, so they only allocate memory for the keys that contain values.
  9. Shared means that it will be loaded on both the server and client. You can't share functions between resources except via exports. What's wrong with doing it that way?
  10. Sure, that's true if you only want to send your data to a single player, but if you want every player to get that data, then I'm fairly sure that setElementData is the most optimal way, or at worst, it makes very little difference.
  11. See this post: viewtopic.php?f=148&t=77161 I'd say get/set element would be more optimal than the code provided.
  12. Try using onClientPreRender rather than onClientRender. By using onClientRender, you're taking the position of the bone just after it has been rendered, then setting the position of the attached object in the next frame, so you always see your attached object where the bone was the previous frame. Your variable and function names are atrocious.
  13. It depends what the data is. If you can put it on the server, you probably should, especially if it's something where the player would gain some advantage by change it. That's generally the principle of multiplayer networking - don't trust the client.
  14. I would expect that exporting methods for accessing a table would be more expensive than using un-synced element data. Calling methods between resources is a relatively expensive thing to do. setElementData and getElementData are great for syncing little bits of data easily. Unsynced, they're also a good way to share data between resources. If you don't care about doing either of those things, then the method described in the original post is obviously the best way to go - you're keeping your data inside the LUA virtual machine, which is much faster. Overusing synced element data - when you don't actually want to sync that data - is actually going to have quite a bit more of an impact than the original post states as it'll increase the amount of data that has to be sent (increasing bandwidth usage), increase the load on the clients and increase the load on the server (as some of the networking will be asynchronous).
  15. Shader Question

    You'd need to set the texture filter mode to nearest neighbour (see here). Unfortunately MTA doesn't support this. It think it would be fairly easy to add it to dxCreateTexture though.