Jump to content

eAi

Retired Staff
  • Posts

    2,986
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by eAi

  1. @Megadreams I'm interested that you say it's a lot of extra work. Obviously you've already done a lot of work on this - so changing strategy is obviously difficult - and I've not really thought a huge amount about it so maybe it's different to how I expect, but...

    The key difference between transpiling and interpreting is that instead of parsing the SCM and then calling functions based on it, you need to generate code that calls the same functions from the SCM. I imagine that either way you end up writing a library of code that handles each operation, and that library could be almost identical between both systems. With the transpiling approach I'd guess that control flow might be the tricky bit - though I believe Lua now supports 'goto' which could help quite a bit (I'm not sure if MTA has updated Lua yet - I know it was being talked about). 

    Anyway interesting stuff - keep us updated!

    • Like 1
  2. This is pretty cool. I do wonder if it'd be easier to make a system to transpile/decompile the code from SCM to MTA's LUA? Given that you'll need to modify the missions quite a lot, is SCM actually the best place to do this? I assume there will be opcodes that have to be added to SCM to facilitate co-op. It'd also be much faster to run, presumably.

  3. On 09/08/2017 at 04:32, </Mr.Tn6eL> said:

    You can add a dialog before joined the server like Google Play

    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.

    • Thanks 1
  4. On 07/01/2017 at 2:38 PM, AfterAll14 said:

    So... I found a flaw in MTA OOP concept, that compromises the whole idea of OOP being OOP. Take a look at this code:

    
    local M = Matrix( Vector3(10, 0, 0) )
    M.position:normalize()
    

    This code won't work. When you use .position MTA calls its internal function GetPosition() which creates new Vector3 object and pushes it into a script.

    This means original position of matrix is not changed.

    I tried to fix it, but atm I ran into situation where OOP methods are not recognized by Lua :S. (What I did - replaced vPos/vRight/vUp/vFront vectors in CLuaMatrix with pointers to CLuaVector3D objects, and pushed em into script alongside matrix when Create() is called).

    If you have ideas how to fix it without rewriting whole OOP code - put it on the table please.

    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!

  5. 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!

  6. 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.

  7. 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).

    • Thanks 1
  8. Best thing to do is to delete all the resources cached on your client, then join your server, then have a look in the resources folder to see what is there. You can then see if there are any obvious large files.

  9. Lua was an easy language to embed, and also fairly widely used in the games industry. It's undoubtably not the best language - Python is certainly better, but from what I remember, we looked at embedding python, but it wasn't terribly easy to do. There was also probably an element of naivety - it was the first time anyone had integrated a scripting system into another game like this, and it was certainly quite experimental at the time - both in principle and for those doing the implementation.

    That said, there are certainly worse languages to use. Lua has very little boilerplate which makes it very easy for beginners to get started. It doesn't scale well to large systems, unless you're very careful about how you write your code, but then that applies to Python too.

×
×
  • Create New...