crusadingknight

ONLY PROGRAMMERS WHO NEED TO UPDATE THIS COMPILATION GUIDE SHOULD POST HERE! Compiling Eternal Lands with Dev-C++ Updated guide by Emajekral Before attempting this Guide please start with a fresh CVS checkout. If you have made changes to and .c .cpp or .h files you can copy them over later. You may wish to reinstall Dev-C++ as well. I do that every time I refresh this guide. Now, a step by step Dev-C++ install and compilation: Get Code Get code from cvs: TortoiseCVS works well, just follow directions in head post. Get Compiler Get this version of Dev-C++. Start it and go oooh, aaaah! Set Up Compiler Set up your development libraries by clicking these links, downloading what's there and clicking next until Finish shows up. (Placid, there's several new libraries. I'm hosting them at my University, but I'd prefer if they were elsewhere... please?) Cal3d and cal3d_extra Internationalization support library XML support library zlib compression library png picture format library jpeg picture format library Ogg Vorbis SDL development package SDL image support I just made these three DevPaks. I've tested them, but I don't trust them. Please try them and report any problems you have. SDL network support OpenAL sound library OpenAL sound library utilities The glext.h that comes with Dev-Cpp is out of date. Save the new version in C:\Dev-Cpp\include\GL\ by right clicking on this link: glext.h At this point you have two choices: While you are in c:\dev-cpp\include copy the contents of the "AL" and "SDL" directories up one level to c:\dev-cpp\include (Hack way) OR Tell Dev-Cpp that you want AL and SDL directories to be in the include path. (Right-er way)Go to Tools>Compiler Options Click on the Directories tab Click on the C Includes tab Click on the button just above the Delete Invalid button. It's next to a small empty text box. It opens a folder browser. Find c:\dev-cpp\include\SDL and press OK The empty textbox now has c:\dev-cpp\include\SDL in it. Press the add button. Repeat the last three steps for c:\dev-cpp\include\AL (or copy and paste the directory into the empty box. Your choice.***Don't forget to "Add" the directory***) Create Your Project Now click on File > New > Project... Make this: an Empty Project a C Project and Give it a name... I recommend el [*]Save the project in your elc development directory - NOT the Dev-Cpp directory that you see as a default [*]Click on Project > Add to Project [*]Click on the upper rightmost file or directory. [*]Press and HOLD the shift key. [*]Hit combinations of Page Down and the arrow keys until all files are selected. (Alternately click then scroll all the way to the right, hold shift and click on the last file you see.) [*]Release the shift key. [*]Locate cal3dwrapper.c and cal3dwrapper.h [*]Press the control key. [*]Click those two files. [*]Press the "Open" button. [*]Wait while Dev-C++ processes these files. Configure Your Project Press Alt + P or click Project > Project Options Click the "Makefile" tab. Click the "Use Custom Makefile" checkbox Include Makefile.win - yu may need to navigate to your cvs directory. Typing *win in the "file name" box will make finding the file easier. in your CVS checkout directory rename make.default to make.conf open make.conf (use notepad) and add this line to the end EXTRA_LIBS=-lstdc++ EXTRA_INCLUDES=-IC:\\Dev-Cpp\\Include\\AL -IC:\\Dev-Cpp\\Include\\SDL Compile Your Project Click Compile, or Execute > Compile, or Ctrl + F9. Wait. You will get some warnings (about 1 three lines long about strstr last time I wrote this ). Ignore them (unless you're on the Dev team. C'mon guys... ;P ) Install Your Compiled Project Copy el.exe from your CVS folder to your Eternal Lands folder (This would be c:\Program Files\Eternal Lands\ by default) Back up cal3d.dll if the Eternal Lands folder you are using is your only one (Bad plan). Go to c:\dev-cpp\dll Copy the libcal3d.dll and libcal3d_extra.dll you found there to the same folder you copied YourProjectName.exe You may have to overwrite the existing cal3d.dll file. Copy alut.dll from c:\dev-cpp\lib the folder where you copied the previous 3 files. Run. Enjoy. Jun. 12/07 update: Changed instructions to handle changes brought on by EYE_CANDY. Made DevPaks for libraries that needed them. (glext.h doesn't have one cause its not worth the effort.) OLD GUIDE BELOW ------------------------------------------------------------------------------------- Table of Contents 1. Getting a CVS program and the CVS code 1.1 using WinCVS 1.2 using TortoiseCVS [*] 2. Getting and installing libraries 2.1 using DevC++ 2.2 using Microsoft Visual C++ [*] 3. Compiling and installing the EL Client 3.1 using DevC++ 3.2 using Microsoft Visual C++ [*] 4. Final Installation 1. Get a CVS program and CVS code 1.1 WinCvs Download (3.48 mb). Next, install both exe files that come with that package (if you got wincvs). Start up your CVS and don't worry if it nags you about python because you don't need it. Then go to the command prompt part at the bottom and type: cvs -d:pserver:anonymous@cvs.elc.berlios.de:/cvsroot/elc login cvs -z3 -d:pserver:anonymous@cvs.elc.berlios.de:/cvsroot/elc co modulename Fill in modulename with "elc" without quotes. Now you should have a complete set of the source code and the folder called actor_defs which will be very important later. 1.2 TortoiseCVS Download (4.7 MB) Go to the directory where you want to checkout the source, then right click in the explorer window, and select "CVS Checkout", and specify the CVSROOT- :pserver:anonymous@cvs.elc.berlios.de:/cvsroot/elc the specify the module- elc Then press OK to checkout the source. 2. Getting and Installing the libraries 2.1 MICROSOFT VISUAL C++ You will need 6 libraries and an OpenGL SDK to compile the code. Get the win32 versions of libxml, OggVorbis, OpenAL, iconv, SDL, and SDL_net. You will also need Glut which is part of OpenGL. Here are the versions I got to compile Eternal Lands 1.0.1: libxml2-2.6.19.win32 (1.40 mb) OggVorbis-win32sdk-1.0.1 (2.27 mb) OpenAL SDK (version 1.0) (8.50 mb) iconv-1.9.1.win32 (1.21 mb) SDL-devel-1.2.8-VC6 (546 kb) SDL_net-devel-1.2.5-VC6 (21.1 kb) I also got glut-3.7.6-bin (117 kb) since the OpenGL sdk I had did not come with Glut. Go to the OpenGL page to figure out how to get the OpenGL SDK if it is not already installed. Now you need to put all the .h files from those into a folder called "include". A lot of those packages already have their .h files in a folder named that so just copy them all over. Then you will need another folder called "lib". Put all .lib and .dll files in there. Now you need to set the path in your compiler so that it knows where all of these files are. In Visual Studio.NET go to Tools->Options->Projects->VC ++ Directories. Then add the path to your include file in the include section and the path to your lib file in the libraries section. 2.2 BLOODSHED DEV-C++ Open Dev-Cpp, and go to Tools->Check for Updates/Packages, and download select versions of the following packages: libxml2-2.6.19.win32 OggVorbis-win32sdk-1.0.1 OpenAL SDK (version 1.0) iconv-1.9.1.win32 SDL-devel-1.2.8-VC6 SDL_net-devel-1.2.5-VC6 You may need to switch mirrors to get all of the packages. Dev-Cpp will install all of the files to their correct directories. 3. Compiling and Installing The Eternal Lands Client 3.1 MICROSOFT VISUAL C++ Open the elc.dsw file and compile. In VC.NET it will complain that elc.dsw is a VC6 format and if you want to convert to VC.NET format. Click yes. Now when you go to open your project file for EL always open elc.sln. Don't worry about the map editor code because chances are you don't need it. I couldn't get it to compile so you will probably have trouble with it also. Now make sure cal3dwrap.c and cal3dwrap.h are removed from your project (called a solution in .NET). You do not want those files because right now they will give you errors. This part is very important if you are using Visual Studio.NET. Open global.h and type #define inline __inline Put that after the line: #define __GLOBAL_H__ It seems to be nice to include elc_private.rc to your project (solution) although it is probably not necessary. It looks like it adds the right icon for the exe file once it is created. You will probably want to compile the EL client using the Debug setting the first time (or if you want to debug the code). You could also compile it in Release mode if you know what you are doing. You will get better performance from Release. Also you may need to compile with the /D "ELC" flag set in the Property Pages under Command Line. I think mine worked without it though. Then, just compile/link the code. Now you should have a compiled exe. It should be in a folder called Debug or Release where ever your eternal lands CVS code is. Copy that exe file to where ever you have eternal lands installed. If you compiled in Debug mode you will need some extra .dll files in your EL game directory. Eternal Lands will nag you until you have the right .dll files. The debug dll files start with the same name but end with _d.dll so they should be easy to find. You might notice that the music won't play. I am still trying to figure out how to get that working. I'll update or add to this thread once I figure that out. Also, the CVS EL client code seems to hang on exit. Ctrl Alt Delete eternal lands to close it. Again, I'm not sure why that is happening. Be sure to check out http://elc.berlios.de/build.php to find links to get the libraries or for build instructions on other platforms. 3.2 BLOODSHED DEV-C++ On Dev-Cpp, just create a new C project with all of the files, except cal3dwrap.c and cal3dwrap.h. Then, you can just hit compile, or you can use the default Makefile by opening Project->Project Options, select Makefile, tick off "Use Custom Makefile", click the button on the right (Load), and select Makefile.win, THEN hit compile. If you chose not to use the makefile, set up the parameters as follows: Open Project->Project Options, open the tab Parameters. Then add the following to "Compiler": -DWINDOWS -Wall -DELC -DWINDOW_CHAT -DNOTEPAD -DSTORAGE --Note that the three last of these will be removed in the future. Then, add this under the "Linker" column: -mwindows -lSDL -lopengl32 -llibxml2 -lSDL_net -lALut -lOpenAL32 -lvorbisfile -liberty C:\Dev-Cpp\lib\iconv.lib --Note that the last changes depending where you installed Dev-C++ to. Then, hit the compile button. BTW, be sure to copy over the created executable to your Eternal Lands directory, unless you building straight to that directory. (As set in Project->Project Options, Build Options). DO NOT ATTEMPT TO RUN THE COMPILED EXECUTABLE WITH THE DEV-C++ RUN BUTTON - it will have undesirable results. 4. Final Installation And now the MOST IMPORTANT step is to COPY the folders called actor_defs and languages from your Eternal Lands CVS folder to your Eternal Lands game folder. If you do not do this the game will come up to the log in screen and the program will crash when you try to play. MAKE SURE YOU DO THIS. After that you should be good to go. Authors: Ryldnozz Getting the source code with WinCVS Compiling With Microsoft Visual C++ [*] CrusadingKNIGHT Getting the source code with TortoiseCVS Compiling with Bloodshed Dev-C++

This would be easier to take seriously if it didn't look like the complainant had swallowed and yet failed to comprehend a thesaurus. Most of Spikebigpapa's postings have been impressive in their conflation of content with verbosity, the majority of which consists of absolute nonsense or misplaced adjectives. I suppose I could scribe an equally loquacious assay into deciphering for him the necessity of concisely phrasing communications, but I'm afraid his egomania and persecution complex totally eclipses any attempt to pierce the delusions of grandeur he has erected to shield himself from both humanity and informed exchanges. (Please shoot me if I ever write something else this indecipherable on these forums.) Oh, and spike: before you accuse me of being a supplicant, please look up the meaning of the word. You're actually looking for the word 'sycophant'. Supplication does not imply sycophancy, nor vice versa.

You could try wubi and just install it on Windows. It won't be as fast as it would if it was running on bare metal, but if you're just looking for the easiest way to try it out without any installation, that should do the trick. Not worth fumbling with the bootloader to install it on an external HD, or trying to get something installed to a USB drive from Windows if you don't know that you will like it. Uhhh.... no. Just no. You shouldn't need to recompile your kernel on a regular basis (the only time I have in the last two years was from a pre-configured PKGBUILD on Arch so that I had full support for my AA1), nor should you need to compile software as an end-user (again, I only fall back to PKGBUILDs for uncommon software, and write my own for rare software) as sorting out and updating packages installed outside of the package manager will prove an immense nuisance.

Since nobody else seems to want to admit to it, I'll go second. I'm rural Nova Scotian born and bred, and at the time of writing I remain a current resident. Unfortunately it's up in the air how long I have left here before I migrate westward, since software development isn't exactly a common job in the area.

alloca won't really help there, since it takes little work to free a chunk of memory at the end of the scope it was allocated it in - less work, in fact, than to change all scope-local memory allocations over to alloca and remove the corresponding calls to free. In my experience, most memory leaks come from manipulating and tearing down with more complex (global) structures rather than from within a single scope. Besides, I don't think EL should be able to leak 400MB of scope-local memory within a few days, unless you're frequently allocating obscenely large transient buffers. Out of curiosity, have you tried compiling with -DMEMORY_DEBUG to see if you can pin down the memory leaks, or at least determine whether they are in sections of code using the C allocators?

There are a few caveats to ponder first when considering using alloca: Obviously, there can't be many places in EL where memory is allocated for use and freed within a single scope. In fact, the only examples I can think of are creating strings for filenames, which could quite simply use variable-length arrays - however, last time I checked (a *long* time ago), EL was only using C89-compliant features. It's not standard ANSI C of any variety, though GCC, MSVC (via _alloca_s) and tcc (x86 only?) support it. "Portable" alloca implementations tend to make non-standard assumptions about the underlying architecture, and thus don't offer a guaranteed userspace alternative when the compiler fails to implement it. IIRC the GCC implementation doesn't cleanly return NULL when you allocate too much memory, but segfaults instead. alloca uses the size-limited execution stack, which makes it terrible for use for parsing large temporary sets or in recursive functions. If EL continues slowly transitioning towards C++, scope-local containers will be able to handle most, if not all, of the use cases of alloca cleanly anyway. Most people don't know about alloca, and thus may either a) assume that it's a general-purpose allocator in the EL code or need to look it up, raising the barrier-to-entry to the codebase. PS: What's the deal with the first link, anyway? I know it covers general tenets about optimization, but unless you're calling a function to generate path names in an inner loop somewhere, alloca will not supply a quantifiable performance boost. EDIT: Oh, I see. You perhaps meant to point to http://www.fefe.de/dietlibc/diet.pdf ?

Wow Nardo you are prolly the oldest player who isnt a dev... Don't go entirely by member numbers. Everyone had to re-register after the old forum was replaced on the 20th, and some took longer than others to do so . Probably the first ~150 members registered on the forum had accounts before the change was made.

That means you started playing in March of '06, in case you were curious.

Why not use the native package manager? Distros such as archlinux and gentoo already have Eternal Lands, and I think a .deb or .rpm package (if not already available) would be much more useful than a script to install it without package management, possibly causing uninstall problems, version conflicts, or shared library dependency problems down the road.

I've learned that people tend to lie about how long they've been ingame. I can usually tell, since I actually HAVE been ingame to see these people Yeah, didn't the last topic of this type actually have someone (in mid-2007) claim to have been playing for five years? I seem to recall something like that, but I might be misremembering. I've been around here 4+ years myself (five by October 8th), and I often wonder how I missed so many people from a time when players online was often around seven.

It's actually affected most by free radicals and reactive substances (NO, CL, Br, and other halogens), of which CO2 is definitely not one. In fact, CFCs have been regulated since the Vienna convention of 1985, and data since 1995 seems to be showing a general upward trend in the amount of atmospheric ozone . According to most current extrapolations, it should return to normal by the end of the century.

Just like they did with AIDS? Right. The power that be are not almighty, and certainly not infallible - plus elected officials are more beholden to current corporate profits than possible scientific predictions as a rule of thumb. Of course, when you consider them as a statistic, the current powers that be will likely have lived to a ripe old age before any of the predicted consequences occur anyway. Does only looking for a conspiracy count as homework? If the IPCC _is_ a political organization, why don't they behave like one? Printing retractions when your models were off enough to colour your extrapolations, though not your conclusions, thus lending to rampant cries of 'conspiracy!' is hardly the accepted behavior of political organizations, but rather that of a scientific one. I suppose that you may respond that they're leading me, but if we want to go that rather I may very well be living in the Matrix. This is not an easy topic to determine who is right or who is wrong, and I prefer to err on the side of caution. CO2 is continually released from inside the Earth, through volcanism and associated processes - the Earth apparently didn't form with a complete atmosphere. Of course, if we discard our knowledge of the past and of geology as flawed, your theory has merit, though I can find no support for humans being alive during the Cambrian period, during which our current knowledge indicates atmospheric CO2 concentrations were highest. Anyway, I don't worry about global warming myself - the extrapolations made by scientists forget that we're running out of economically viable sources of fossil fuels anyway - we may or may not have hit peak oil recently, though it will be impossible to tell for years down the road. Even with the rosiest predictions, we'll stop burning fossil fuels long before we've re-released all of the carbon into the atmosphere. Conserving limited fossil fuels until we switch to alternatives is more my concern, given the huge economic impacts that the loss of a few oil wells can have at present.

We said the same thing about the cod, but then again, only hindsight is 20/20. In defense of real power savings, they should help keep the brownouts down in the future. Uh, no... if it happens many of our Nova Scotian cities will be under water. I live dead in the center of the province, on top of a hill, and I'm still barely above sea level. That's what I like to hear. Lighting may be a major factor if, like many businesses, you have a lot of 100W incandescents, and have them on all the time, but on a personal level it's a tiny factor (at 8PM, the only light I usually have on is a 7W LED array.) We'll be far better off if people choose energy efficient appliances when the time for replacement comes, and consider alternative approaches (ie. my house is passive solar, and even during the winter only ~500 square feet of it is heated.) Earth Hour is fine and dandy, but I have the suspicion too many others will turn out their lights for an hour, and fail to make any changes to follow up. The clean energy sources _aren't_ extremely expensive, but rather it is expensive to phase out and replace any generating infrastructure (even one coal plant for another). Additionally, many require specific sites to produce to full capacity, and others such as solar power generation require more R&D before they reach their full potential, all of which make them difficult choices until one is creating new infrastructure.

And simply counting the results of a search proves what exactly? Exactly as much as posting a link to a search, which was the whole point. Instead of linking to google searches, use links to articles instead.

Senator McCarthy, I presume? I actually don't see any communist states in the world, unless you count those one-party states which are as 'communist' as the recent Kenyan Presidential Election is believed to be 'democratic'. In any case, putting a social ideology in context with human slaughter and suffering is simply outlandish. I couldn't quite understand that (first) video though - not only is what they were doing to the animals awful, some of it would also have been extensively damaging to their furs. Neither a humane nor an efficient way to run an industry.

Thats a mistake TigerDirect has a very bad reputation. Go NewEgg If we're to go by the judgment of google, you would appear to be wrong. The best solution is usually to buy from a local retailer, because shipping mistakes are common no matter who you order from.

I think I can probably help you out here, but to confirm my suspicion of what the update code does, can you post the output your error_log.txt after trying to run the client to grab the custom update? I *suspect* that your problems are due to the fact that those mirrors are expected to be mirrors, and not independent servers, thus either one will suffice for any request. You would likely have better luck setting your private server to sync from the main server itself (rarely, of course), and removing the 'official' server from your mirrors list. (As described in the thread you linked to.)

Are you certain you have the most recent version from CVS? Those lines no longer have mutex manipulation calls, and those errors were reportedly resolved about a week ago.

See platform.h, line 33.

Nice patch, I like the new version. Just a few small comments now though - since elpathwrapper.c only uses the extern definition of user_data_dir, and nothing else should use it, in my opinion you could simply place the extern definition at the top of elpathwrapper.c instead of putting it in elconfig.h and #including it. However, that is simply a matter of personal taste. On less of an opinion basis, you may want to remove the line in the patch to elconfig.c where user_data.h is included, since that file no longer exists, and user_data_dir should likely be initialized as char user_data_dir[90] = ""; so that user_data_dir[0] is guaranteed to be '\0'. Additionally, you might want to check the logic in get_path_config_base - what might be preferrable is something like the following to prevent returning an invalid path, and ensure the static buffer is used properly: if (locbuffer[0] != '\0') { return locbuffer; } else if (user_data_dir[0] != '\0') { if (mkdir_tree(user_data_dir, 0) == 1) { strcpy(locbuffer, user_data_dir); return locbuffer; } }

Patch: I assume it is https://developer.berlios.de/patch/?func=de...p;group_id=1256 Question: How (why?) does it work? I can't understand how passing a function address to add_var for the variable to modify, and the negation function change_var as the callback could possibly work. I tried to test it, but unfortunately the framebuffer has begun to crash the drivers for my old nvidia card. (Trying to find out why, though a 'cvs bisect' command certainly would be useful here.) For comparison: data_dir: add_var(OPT_STRING,"data_dir","dir",datadir,change_dir_name,90,"Data Directory","Place were we keep our data. Can only be changed with a Client restart.",MISC); user_dir: add_var(OPT_STRING, "user_data_directory", "user_data", &set_user_data_dir, change_var, 1, "User data directory", "Sets where user data, such as chat log and map markings, are saved", MISC); As you can see, the version I copied from the patch passes the address of a function as the variable to modify, the boolean negator change_var as the function to use (which means 'set_user_data_dir = !set_user_data_dir', which I can't see being what you want), and the 'default' parameter as one, which _should_ be the length of the input buffer. Suggestions: * You may want to check if that line is _really_ doing what you want, as well as whether those two functions need their own source file (they are the same type of functions as defined in elconfig.c) - in fact, change_dir_name is likely what you'd want as a callback over set_user_data_dir. In line with that, perhaps data_dir should be a buffer instead of a pointer? Ideally, this seems like it should be defined and behave in much the same way datadir does. * Remove the whitespace change in check_var, and before dir_exists. * Check whether you should have a global variable defined in a header file (99.9% of the time 'no', it should be extern instead), and whether you really meant to have a #ifndef guard which is different from the #define following. * Consider implementing this so that it doesn't conflict with using the configdir in $HOME, and so that it doesn't require a #ifdef feature guard. One solution might be to check whether data_dir has been set (ie. give it an empty default value), and set it to the default $HOME/cfgdir otherwise.

I'd say it isn't worth creating a new header file just to hold a single extern definition.

Well I can't answer to the usefulness in the code, given I'm unsure of the nature of the problem alvieboy is trying to solve, but let's examine the memory footprint, shall we? Given a decent hash table implementation, a single pointer is mapped to each slot, and the fill rate will be between 33% and 66%. This means that for each filled slot, there is between one and two empty slots, giving a memory occupancy of between two and three words of memory per used slot. If we consider mapping the encyclopedia, given the 650 pages in the english version, with a power of two table size (1024, in this case, the size doubling at 682), we would waste exactly 1496 ([1024-650]*4) bytes of space on a 32-bit machine, which is only considered a lot on the smaller end of embedded controllers. Contrast this to the 88 bytes wasted for every unfilled encyclopedia page in the static allocation of 1000 pages, whereas only 650 are currently used, leaving a total of about 30800 bytes unused on the same machine. I have my doubts that either of these is a valid memory concern, but if you want to quibble bytes... On the other hand, if you approach this from the point of view of preventing creeping featuritis, then such a view may well be valid - an O(n) solution is certainly acceptable if n for the solution to the problem alvieboy is working on is guaranteed to be small enough. I personally would rather see the patch before considering right or wrong though, and having an implementation (even if not built or used) could be useful if/when O(1) lookup is important.

I noticed months ago, but I somehow always find something much more productive to do. Plus, my name is on that page twice already. EDIT: Or maybe I'm just blind, and somehow aways overlooked my name because of the underscore. (Pattern-matching eyes, anyone? Weird that I'd read Crannog's name without noticing my own.)

And here I was thinking that someone had finally noticed that I was MIA (from the "past moderators" section) after all this time.