databits Posted May 14, 2012 Group: Members Topic Count: 1 Topics Per Day: 0.00 Content Count: 8 Reputation: 4 Joined: 05/14/12 Last Seen: May 25, 2012 Share Posted May 14, 2012 I just today found out about this project, and it seems interesting to say the least. Awhile back I went ahead and forked the eA project personally as well. The goal was to re-architect both the SQL database design, and actual SQL bindings in the server itself. Primarily because both the database schema, and the C libmysql database bindings used are horrible. They're also missing a lot of critical information (date and time info for creating and modification please?), introduce obvious points of failure (when I saw in the source code that there are 4 separate notions of an item instance it was quite an amusing day), and use prepared statements incorrectly. Forking and fixing was my alternative to writing database views for -every- table in eA. So then I came across this project, and have been reading through some things here and there. As I said, I find it interesting that this project has started while eA has more or less died off. But also have a few questions. My first question is, has anyone thought about switching from SVN to a more robust version control system like GIT or Mercurial? Ok, sure, the SVN repository fork allows you to keep around all the old commit logs (though you can import SVN into other systems), but there are so many more advantages to using an actual distributed source control system over SVN now days. What's more, the tools (for Mercurial at least) are better in Windows, OSX, and Linux. Also, you can use both Github and Bitbucket for respository hosting which tend to have better repository interfaces than sourceforge. The second question is, would you entertain the idea of abandoning the out of date "strict C" ideal? Now days there's no real good reason to write things in C. In many cases, it makes things harder to read, and requires more code to write. It's not like you'd be running this on hardware that could only support ANSI C stuff either. You also lose out on all the advantages of newer C++ language features, and possibly some optimizations. Though, I somehow doubt any single person is actually compiling eA or rA with a C compiler. One reason that I bring these up is the debate about keeping support for pre-RE while still working on RE. Under both GIT and Mercurial this is trivial because the branching and re-merging support is far easier to use than SVN's. If things were abstracted out better than they are now, it should be possible to maintain support for both, while also allowing bug corrections to both branches at the same time for shared code. It's not like new code would need to be written for pre-renewal servers. Outside or major refactoring, at this point it's mostly bug support and adding features/improvements that could be used for both branches. Additionally, while I support the idea of dropping flat-text files, keep in mind that the servers should not be reading or writing directly to/from the flat files or database all over the place. This should be abstracted using a common interface to serialize/deserialize information. Most the server itself should more or less be ignorant to how the data is read/written. This allows for using any back end for reading and storing the data, be it flat-text, MySQL, MsSQL, Postgresql, Oracle, SQLite, XML, JSON, or whatever format you choose. Though from my experience in the eA code, revising at that level would be a major task (and pain in the ass)... but not one taken lightly if you're truly serious about improving the server. Another idea would be to start consolidating things more toward a component-based design. Though this would be an even more massive level change that would take a ridiculous amount of time (it may be easier to just start writing a new server from the ground up and piecing in code), it would vastly improve the server itself and make it a hell of a lot easier to extend game objects with new functionality. Quote Link to comment Share on other sites More sharing options...
GreenBox Posted May 14, 2012 Group: Members Topic Count: 9 Topics Per Day: 0.00 Content Count: 303 Reputation: 101 Joined: 11/13/11 Last Seen: October 11, 2023 Share Posted May 14, 2012 My first question is, has anyone thought about switching from SVN to a more robust version control system like GIT or Mercurial? Ok, sure, the SVN repository fork allows you to keep around all the old commit logs (though you can import SVN into other systems), but there are so many more advantages to using an actual distributed source control system over SVN now days. What's more, the tools (for Mercurial at least) are better in Windows, OSX, and Linux. Also, you can use both Github and Bitbucket for respository hosting which tend to have better repository interfaces than sourceforge. Yup, there was a lot of discussions about this in past. I prefer Git over SVN. The second question is, would you entertain the idea of abandoning the out of date "strict C" ideal? Now days there's no real good reason to write things in C. In many cases, it makes things harder to read, and requires more code to write. It's not like you'd be running this on hardware that could only support ANSI C stuff either. You also lose out on all the advantages of newer C++ language features, and possibly some optimizations. Though, I somehow doubt any single person is actually compiling eA or rA with a C compiler. Switch *Athena code from C to C++ is suicide, to archive this with success is necessary to rewrite the entire emulator. Quote Link to comment Share on other sites More sharing options...
databits Posted May 14, 2012 Group: Members Topic Count: 1 Topics Per Day: 0.00 Content Count: 8 Reputation: 4 Joined: 05/14/12 Last Seen: May 25, 2012 Author Share Posted May 14, 2012 Glad to hear there's more support for GIT. I love it, and use it for a lot of projects, but be wary that the Mercurial tools are far superior under Windows (TortoiseHG) than the GIT tools (Msysgit + TortoiseGit). Though that may change soon enough. After talking to the GitHub devs at GDC this year, they seem to really be gunning for better Windows GIT support, so we may see those sooner than later. As for switching over to C++ from C, it really isn't suicide. eA isn't really pure C to begin with as it is, and I'd wager it's probably already compiled as C++ in almost every case (especially in VC since it hasn't even updated its C compiler in ages). Gradual re-factoring over time is possible in any project, more so with C/C++. The problem is finding out what portions of the source code itself do, since as previously pointed out in other posts, it's not exactly well documented what everything does (not exactly self documenting code either). A lot of the code could really stand to be cleaned up with proper interfaces and abstraction. In either case, a lot of it's just thoughts. I WOULD suggest that at the very least you do the same thing I've been working on. Combine items in storage, guild storage, carts, inventory, equips, and drops into a single item instance object. There shouldn't be multiple notions of the exact same data strewn all over the server. It's one of the things that I've been working to clean up. The problem is, when I forked things, not only did I not stick with SVN (moved to GIT, possibly may move again to Hg), I also wiped out portions of the code that I myself had no intention of using as a server operator (for instance, among other things, I removed both auction house and mercenary support from my server, as I never intend on having them in the server). Quote Link to comment Share on other sites More sharing options...
GreenBox Posted May 14, 2012 Group: Members Topic Count: 9 Topics Per Day: 0.00 Content Count: 303 Reputation: 101 Joined: 11/13/11 Last Seen: October 11, 2023 Share Posted May 14, 2012 As for switching over to C++ from C, it really isn't suicide. eA isn't really pure C to begin with as it is, and I'd wager it's probably already compiled as C++ in almost every case (especially in VC since it hasn't even updated its C compiler in ages). You is wrong, VC++ compiler choose the language based on the extension, if you force it to compile as C++ you will get 2473894234723 errors(like missing cast, etc etc). 1 Quote Link to comment Share on other sites More sharing options...
databits Posted May 14, 2012 Group: Members Topic Count: 1 Topics Per Day: 0.00 Content Count: 8 Reputation: 4 Joined: 05/14/12 Last Seen: May 25, 2012 Author Share Posted May 14, 2012 I'm well aware of the warnings, you you get a crap load of the warnings when compiling under Linux with GCC (mostly casts). Yes, because it's being compiled as C++, not C, I get that. In the case of Visual Studio, it's not the compiler that chooses, it's the build system for VS that chooses. Microsoft has 2 compilers, their C compiler, and their C++ compiler. The C compiler for MSVS hasn't had a major update in a long time, where as each new release to VC (now 2011) adds new C++ features, optimizations, and improvements to the C++ compiler. Sticking to strict C, at least for the case of the VS builds, is sort of self-hindering. I'm not saying that you have to switch to C++, it's more of a suggestion than anything. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.