Jump to content

eAi

Retired Staff
  • Posts

    2,986
  • Joined

  • Last visited

  • Days Won

    1

eAi last won the day on January 6

eAi had the most liked content!

Member Title

  • Retired MTA Team

Details

  • Location
    London, UK

Recent Profile Visitors

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

eAi's Achievements

Foot Soldier

Foot Soldier (41/54)

35

Reputation

  1. This is an amazing milestone. I've not been involved really now since around 2007-8, but for some years Multi Theft Auto was (almost) my life. I spent most of my nights and spare time as a teenager and while at University focused on developing MTA. I started playing almost back at the start - probably a month or so after the initial MTA for GTA 3 was released. I remember trying to play - and finding the experience really quite bad - endless crashes and loads of limitations, but I loved MTA from the start: the way it opened my eyes to a technical way of achieving was initially seemed impossible, the ambition of the project and the enthusiastic community around the project. Everyone could see what MTA should be - the product vision was obvious - it was just a massive challenge to get it there. As I was a fairly competent Visual Basic programmer (the first version of MTA was built by modifying an existing trainer for GTA3) I was able to get involved and help out fairly quickly. IJs let me join around the time that MTA:Blue was just starting development. This was a big rewrite of MTA and the foundations of what MTA is today. I cut my teeth as a C++ programmer with this project which was really ambitious - we were almost writing a parallel game engine alongside the GTA engine that had to map almost 1-2-1 to it. This involved learning a lot of techniques for reverse engineering, C++ and assembly language. At this time, there was probably a core of 2-3 people working actively on the project in their spare time as developers and there was a lot of pressure to deliver something. We deliberately picked an easier goal - adding a racing mode, so that we didn't need to achieve some challenging features such as shooting synchronization. MTA Race was a big success and it was around this time that we had the rise of other copycat mods which really heaped on the pressure. At times the community seemed to turn into a battlefield between the different mods with cheaters thrown in the mix. We also had to handle various people from the cheating community making cheats as performing DDOS attacks against our infrastructure. Now days these things are easier to mitigate against, but as a small volunteer run project, these caused us a lot of hassle. After MTA Race, we were really ambitious with what we wanted to achieve - we wanted to add scripting to the game, and we wanted to build a modding infrastructure that was really flexible. I remember being proud of designing the resource system that MTA is still using today (though I'd definitely do some things differently now!) The version we released was really powerful - with a pretty good, extensible editor, downloadable resources, a web admin interface and pretty good synchronisation of gameplay. At times during the development I was the only developer for a while, so I like to think that MTA wouldn't have survived if I hadn't carried on fighting to make progress. I remember spending a whole summer trying to get shooting to work! But I think MTA was such a strong idea and had such a fan base that I'm sure someone would have picked up the torch. Now days I run a small games development company (www.fireboltgames.com) and I've worked professionally in the games industry for the last 15 years, and I'm certain I wouldn't have got where I am or have the skills I do without MTA, and for that I'm really glad. It's still one of the most successful things I've worked on and one I'm really proud of. It's certainly the longest-lived! We actually created a Roblox game recently inspired by the Hay mode made by Aaron for MTA - check it out here: https://www.roblox.com/games/6645345380/Climb-King The community around MTA was what made it all worth it - it was hard work, but there were so many good, enthusiastic people, all working together towards a common goal. We never met - we never even talked (this was before voice-chat was so widely available!) - but we were good friends and had a lot of respect for each other. All in all, this is a really well deserved milestone and I'm so glad I had a chance to be part of the history of this great project. Here's to another 20 years! PS: I designed the front page about 16 years ago - it is probably time to update it! Here's a few random screenshots from my archive: MTA:Green (MTA:Blue for GTA3, never released): http://opencoding.net/old_opencoding_net/misc/MTA/green_progress_6.JPG Old website design: http://opencoding.net/old_opencoding_net/misc/MTA/mta_site_design_2.jpg http://opencoding.net/old_opencoding_net/misc/MTA/mta_hud_9d.JPG
  2. Well done everyone - can’t believe it’s been almost 20 years. Given how close the project felt to dying at some points when I was working on it, it’s amazing to see it going so strong now! Looking forward to celebrating the aniversary.
  3. Congrats on the release! Great to see so much progress still happening!
  4. @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!
  5. 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.
  6. As the original website designer from approaching 10 years ago(!), I agree it needs an update. But I don't feel this is quite enough. The key art at the top is less interesting, and the rest is just a bit more square. I'm not really involved these days, so whatever I say has very little importance, but I think a more substantial redesign could be worthwhile.
  7. 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.
  8. Client side modules would be a massive security hole as they'd allow you to run arbitrary native code on the client.
  9. 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!
  10. 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).
  11. 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.
  12. 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!
  13. Tables aren't arrays, so they only allocate memory for the keys that contain values.
×
×
  • Create New...