nevelis

@Vach - this is an improvement firstly to the parser (the code that reads script files), and soon the compiler (uses the parser to generate bytecode) & virtual machine (executes the bytecode). It won't change the way your scripts are written and it won't change any of the existing script commands. It should make it easier for developers to maintain the part of rA that executes scripts though, there may or may not be performance gains. And stability is definitely more important than speed, so if it's easy enough to keep stable then we can tune it for speed later

Bahaha yeah dolan!! Love the avatar. And hell yes, your VM code is easy on the eyes really readable, good stuff! I think we're both in luck I've got plenty of experience writing parsers and compilers, so I could definitely write a parser/compiler for eAscript & generate bytecode run on your VM. Want to team up on this one? I'm keen on giving this a decent crack. I'm about halfway through the lexer now, I'll have something up on github soon. I'll PM you my contact details if you want to chat. LEGENDARY!

I'm embarking on a quest to improve the script engine I think a sensible thing to do is to use flex & bison to do the parsing. I'm going to guess at the near 18,000 lines in script.c, about 3000 of them are involved in parsing, and I think we can reduce that to maybe 100-200. This would simplify the file a lot, it'll help compile times and most importantly: it'll help us extend the language easier. Work has been done recently (recently being in terms of the project but this was a few months ago ) to add an assignment operator... I would've thought any language would've added this in the beginnings of its life would've opted to use an operator instead of a keyword to set variables, so I can only guess it took so long because its too damned complicated. There was also work done on the Lua project to replace the script engine with Lua... I really love the idea but I think it's just completely unrealistic. There are tens of thousands of lines of script source that will probably never be updated, because it works fine the way it is. So if we can decouple the parser, we can improve the language a lot easier and not have to resort to something as drastic as a complete rewrite. I'm posting here to gauge feeling from the dev team. The idea is to write another parser equal to the current parser, so all existing scripts will function correctly. Does this subproject interest anyone out there? Cheers!

I sure do prefer git to SVN, it makes merging changes from rAthena & branching really bloody easy. I set up a git mirror of official rAthena here: https://github.com/nevelis/rAthena It's updated every few minutes so it's recent. I would strongly encourage the core dev team move to git too - this will allow people to send in pull requests for features & bug fixes.