Cicero Report post Posted November 30, 2004 (edited) Some important links: BerlioOS project page: (BerliOS is a site running an old version of Source Forge) http://developer.berlios.de/projects/elc/ Development home page: http://elc.berlios.de/ Rules (strong preferences) for patches: Must be a clean, unified diff on the current CVS code. "diff -Naur" is a personal favorite of mine. Basically, I should be able to apply it easily with patch -p1. CVS diffs are also acceptable sometimes, as long as I can get them to work. A CVS diff won't work if you have added files, however. UNIX newlines are _preferred_. DOS Newlines don't play well with berlios, especially those produced by Dev-Cpp. (Use dos2unix on patch files). Must compile on Windows, Linux, and FreeBSD, and compile cleanly with -Wall on gcc. Also should not break any existing part of the client. Must be useful, and not encourage any kind of cheating and/or macroing. As well, don not attempt to recreate or submit any patch which has already been rejected, or has been rejected because it encourages any of which listed above. Patches should be submitted on the appropriate part of the BerliOS project page, but you can post a topic here for discussion (and to get my attention). Binary Releases You should follow the rules listed by the license, mainly: - Release the source code with any modified clients you redistribute. - Through you can connect to the server for development purposes, this is not to be taken to mean you can include patches already rejected, or rejected/disallowed on principle. You should check on berlios.de for this status - open and accepted patches may be distributed in clients. Unreleased patches (which have NOT been submitted to berlios.de) should not be included; including these mean the distributed client cannot connect to the server (without permission from a leading developer). - Any other rule listed in the license, which is not mentioned here. The license can be found here: http://cvs.berlios.de/cgi-bin/viewcvs.cgi/...type=text/plain This post will probably be amended in the future. Updated: 01/04/2006 by crusadingknight, added a link to the license text itself. Edited April 1, 2006 by crusadingknight Share this post Link to post Share on other sites
Wytter Report post Posted June 20, 2005 (edited) Hey all, I just set up a mailing list for the CVS commit/add log. If you wish to subscribe go to: http://lists.berlios.de/mailman/listinfo/elc-cvs Sample message: Update of /cvsroot/elc/elc In directory sheep:/tmp/cvs-serv28693 Modified Files: elconfig.c Log Message: This commit makes vertex buffer objects an option that is normally disabled - you should enable it by adding #use_vertex_buffers = 1 to your el.ini. Furthermore you can now choose whether you want to see the experience messages above your head or not (#use_floating_messages = 1) Index: elconfig.c =================================================================== RCS file: /cvsroot/elc/elc/elconfig.c,v retrieving revision 1.39 retrieving revision 1.40 diff -C2 -d -r1.39 -r1.40 *** elconfig.c 15 Jun 2005 13:26:45 -0000 1.39 --- elconfig.c 20 Jun 2005 22:43:41 -0000 1.40 *************** *** 447,450 **** --- 447,451 ---- add_var(SPECINT,"use_vertex_array","vertex",&use_vertex_array,change_vertex_array,0); + add_var(BOOL,"use_vertex_buffers","vbo",&use_vertex_buffers,change_var,0); add_var(INT,"mouse_limit","lmouse",&mouse_limit,change_int,15); *************** *** 515,518 **** --- 516,520 ---- add_var (BOOL, "ati_click_workaround", "atibug", &ati_click_workaround, change_var, 0); add_var (BOOL, "use_alpha_border", "aborder", &use_alpha_border, change_var, 1); + add_var (BOOL, "use_floating_messages", "floating", &floatingmessages_enabled, change_var, 1); add_var (BOOL, "personal_chat_separate", "pmsep", &personal_chat_separate, change_var, 0); add_var (BOOL, "guild_chat_separate", "gmsep", &guild_chat_separate, change_var, 1); _______________________________________________ elc-cvs mailing list elc-cvs@lists.berlios.de http://lists.berlios.de/mailman/listinfo/elc-cvs Edited July 9, 2007 by crusadingknight Share this post Link to post Share on other sites
ttlanhil Report post Posted March 2, 2006 (edited) Getting started with Eternal Lands Client Development target audience: those who compile elc themselves (or at least are capable of it), and have some experience with programming (not necessarily C) if you don't fit that, then you should work on it first. (footnote with some details for those who are close) now, this won't all be free... because you need to pay for internet connection you don't need to pay any other monetary costs though (you could pay for commercial addons, tools, etc if you wish, of course) foreword: if you're looking to gain from coding for EL you may be out of luck. you get benefits, but it's not in-game stuff or money (usually). on the other hand, you do get to know the client a lot better, and will come across features that other people don't use because they don't know them. you also get features you want added (if they're accepted), and you get the experience. first off, you need to be okay with all the general EL development stuff (not code-specific). that means agreeing to the license conditions, following the game rules (including not using modified clients on the main server (we'll get back to that)), development rules (right now you won't need to worry about this as much, as it's mostly license), etc pay attention to the forums. especially the dev parts. you don't have to read all new posts each day (though you can if you wish), but knowing what other people are working on and would like added is important (though not critical. we'll get back to that too). even more important is knowing what ideas have been rejected if you don't have one already, get an account on http://developer.berlios.de. that's where the source code is, a patch manager for elc, the mailing list setup, etc. you won't need an account to check out the code, and you can post patches on your own webpages, but it's a lot simpler this way I strongly recommend you subscribe to the cvs-commit mailing list. it's pretty low volume right now (one message per couple of days to a week, perhaps) it will give you a better idea of the progress/changes than just `cvs up` I assume you know how to use your compiler now to the coding stuff the eternal lands client is written mostly in C. that'll be what you get started with. if you don't know C (or not well), that's okay. experience with some of the libraries/languages like OpenGL(& shader language), OpenAL, SDL, ogg/vorbis, C++ (for the cal3d stuff), XML, etc will be useful... in the areas that use them. if you know them, then here's a chance to use them. if you don't know one of them, but want to learn it (for whatever reason) then this is a good place to practice (it's already a complex system with everything else set up. if you want to play with certain OpenGL stuff, you don't need to set up a program and all the basics; that's already done) If you're not particularly interested, then you can ignore them (although if you work at it for long you'll pick up knowledge about various parts) now it's time to plan for your first change! pick something you'd like to do (scratch-your-own-itch is one of the things that makes open source work). pick something small to start with. even if you're an experienced coder, starting small as you adjust to elc is a good idea. if you're not skilled with C, then this is the only option (and you can learn C by reading online and coding on elc) check the forums and the patch manager (view the rejected/deleted patches) to see if someone has thought of this or is doing it already still good to go? start editing! (and perhaps post that you're doing it, so no-one else starts at the same time) you can't run the modified version on the main server, but you're allowed to use the test server for stuff like this. just go to port 2001 and test away! if you run into problems because of C, then investing in a good intro to C book may be advisable (it's a common language, so you'll be able to use it a lot if you so desire). there's also many good tutorials online (just ask google) for details on commands and libraries themselves, check the man pages. *nix users will know where they are, but windows users are probably right now 'man' pages are the manuals on a *nix system. they cover many topics and commands, including the C language's headers (and the commands in them) now, yes, it seems odd to use these when on windows... but it's what works for me (the full set of man pages is available from many websites. as a bonus, they're hyperlinked) side-note: if you're using MSVC then get used to using the intellisence tooltips. it'll tell you what parameters a function wants, and that can save a lot of hassles if you get stuck, or need someone to check over what you've done, whatever, then ask. usually someone on the forums knows the answer when you're ready to share your code (either because the change is finished, or because you're at a version0.1 stage, where the first part works), post it to the patch manager on berlios, and post on the forums. include details on the forum; what it does (unless you posted that you were going to do this), the link to the patch on berlios, problems, things you're not sure of, if it's done, etc and lastly: on bracing and commenting use the brace style of the code that's already there. even if you don't like it. consistency is a good thing. if you're writing a larger block of code, then you can use whatever brace style you prefer (within reason) however with commenting, do more than what you typically see in the client. a line or three at the top of a function saying what it does, and then notes on any tricky bits in the function is generally enough --- feetnotes if you don't have a C/C++ compiler, and you're on windows, then you could get dev-cpp. it is (or perhaps was) common for el users. it's gcc-based, so it's less likely to have version problems than MSVC, but you will likely also want to get a good editor or IDE, etc another option is MS's visual C++ compiler (it does plain C too). in fact, they've made it free for people to get the latest version (the basic/intro version only, but it will do all you need). MSVC includes a graphical debugger, decent IDE, and a number of tools all in the one installation on any other platform then gcc, g++ & make will be your best bet if you have problems with compiling elc then check the docs on that CVS on windows: I recommend tortoiseCVS. you can use any other CVS system you prefer, of course Edited July 9, 2007 by crusadingknight Share this post Link to post Share on other sites