Bongo

This guide is for anyone who wants to be able to compile the Eternal Lands client for Windows in Linux. Step 1: Installing MinGW and the client's dependencies I've made this really easy. Download this bash script to a directory with at least 250M of free disk space. This script will download, compile and install the MinGW runtime environment and toolkit as well as all the client's dependencies. Open build-xmingw.sh in your favourite text editor and change the PREFIX variable to whatever you want. This is where everything will be installed. The default is $HOME/xmingw. If you're happy with this setting you won't need to change anything. Don't change anything else in the file unless you know what you're doing. Run it. It'll take 5 to 30 minutes or so. Step 2: Get the client's source code I'll assume explaining this is unnecessary. Step 3: Compile it Download this Makefile to the directory where the client's source code is. If you changed $PREFIX in step 1 you'll need to change $XMINGW_PREFIX in Makefile.xmingw. Run "make -f Makefile.xmingw". The executable will depend on crusadingknight's Cal3D DLLs, so copy them to your EL folder and include them along with el.exe if you want to share your build with others. If you run into problems, reply to this post.

This patch counts the number of creatures and players that your character kills and displays them thusly: Players are shown in red: I attempted to register at berlios.de but never received the activation email, so the patch is here: http://www.freepgs.com/bane/downloads/kill...ll_counter.diff There may be no actual demand for this feature, but I'll leave it to your consideration. Bongo [edit: I eventually received the activation email from berlios and the patch is now there.]

I haven't had the time to look into these bugs yet (well, I have, but I always found something better to do), but thanks to Bahrain and Kindar Naar, I see that both bugs can be solved easily. I'll post a patch within the next few days, unless someone beats me to it (please do, I'm tired of this code and want to forget about it).

I was hoping this would happen so infrequently that it would be a non-issue. I didn't want to specifically add a check for Chimerans because it would have to be updated if other Chimeran-like creatures were added.

void increment_death_counter(actor *a) { actor *me = get_actor_ptr_from_id(yourself); if (!me || !me->async_fighting) { return; } if (a != me) { increment_kill_counter(me, a); } else { actor *me, *them; me = a; The assertion a != me means that the else clause asserts a == me. The problem is, after asserting that a == me, it assigns me = a. Since me is already a, why make it a again? Ah, yes.

I think I can explain this. pf_get_our_actor() used to parse the whole actors list too. Then someone wrote get_actor_ptr_from_id() because pf_get_our_actor() was only made available to pathfinder.c. Then your_actor was added and pf_get_our_actor was made a wrapper. Then I used get_actor_ptr_from_id() in counters.c because I didn't notice that your_actor (a much better way of doing it) was added. *Whew* actor *me, *them; should be actor *them; It's not a big problem though. [Edit: maybe you meant something else? I can't see any other problems though.]

I'll fix this and the total wipe bug this weekend. I hope these are the last two bugs in my patch, because this weekend will probably be my last free weekend before the update.

And now I don't think there is such a bug. I haven't been able to make it happen again and nobody else has reported it. Maybe it had something to do with all the client versions I've been testing.

Rostogols and other things found while harvesting are not counted, but enriched essences and modable weapons are.

Here's a fix: diff -Nru elc/counters.c elc_fix/counters.c --- elc/counters.c 2006-05-09 00:22:29.000000000 +0100 +++ elc_fix/counters.c 2006-05-10 03:35:27.000000000 +0100 @@ -564,7 +564,7 @@ { actor *me = get_actor_ptr_from_id(yourself); - if (!me->async_fighting) { + if (!me || !me->async_fighting) { return; } Can someone apply this to CVS, please? Weird. I don't see why get_actor_ptr_from_id(yourself) would fail here.

Yes, however the client crash for me everytime i exit thru alt-x. And this started when counters.c/h was added yesterday or if it was the day before that. I cant debug it either to see whats wrong, cause i just updated to MSVC2005 and havent properly configured it yet. I have also tested deleting the counter_something....dat file. One suggestion: save the counter data atleast once per hour. To see if the counters code is to blame, try compiling the client without -DCOUNTERS and see if it still crashes. Edit: D'oh! There is a bug that causes the data to be lost. It just happened to me. I can't understand it though. I'm too tired to root out the problem now, but watch this thread.

Unfortunately that will happen. The data is saved when the client is closed cleanly, or when you log in again after disconnecting. This isn't a bug in itself, it's a side effect of other bugs in the development client.

Another problem besides FPS is that i can still only click and walk within a small area, anyone know if this could be extended? It must be possible if you can click the other side of the map and walk there. Yes, it can be extended by using pf_find_path() in place of MOVE_TO.

Yes. It just was. Sorry, I forgot to do that after doing a cvs update.

go_to_url_thread = SDL_CreateThread (go_to_url(url), 0); Yes, that's where it's crashing. A quick fix would be to replace that with: go_to_url_thread = SDL_CreateThread (go_to_url, url); It's Torg's code, so ask him to fix it.

Ok, here's a windows build, but be warned that there are bugs in there that have nothing to do with my patch.

An ear of corn. 'e'

Thank you, Electric . My ignorance is to blame here. I assumed that the windows qsort function behaved similarly to the GNU version (which behaves sanely), but apparently it doesn't. It swaps items of equal value. I'll fix it tomorrow. I guess I'll be writing a new quick sort function. Forget that, there was an easier way to fix it. Nobody else who tested my build reported this. It was a CVS build anyway, and somehow I don't think the counters code was to blame. Ok, quite a few people have tested it over the last week. Just two little bugs cropped up which have now been fixed. The first bug involved column sorting; items of equal value would get moved around. This was due to the way some implementations of qsort behave. The second was a harvesting bug. When a rare stone was found without space to carry it, the harvest counter would be erroneously decremented.

blood? That would be it. The "second" letter of each word. Well done, Bharain.

Lorck reads Slashdot (Score:5, Insightful)

I voted yes. Already it looks like most people want this. People are probably already starting to hoard their cash. I assume I won't be in the top 200 :-).

Thank you, Electric . My ignorance is to blame here. I assumed that the windows qsort function behaved similarly to the GNU version (which behaves sanely), but apparently it doesn't. It swaps items of equal value. I'll fix it tomorrow. I guess I'll be writing a new quick sort function.

Yes, that would work. I'll do it that way. Thanks, Learner. Sorry, bone powder. Right, done that. The patch is updated. Here's a windows build. There are no bugs in this version (*crosses fingers*).

Someone brought this one to my attention earlier. Actually anything after the first spell will show up without a name, and the client will probably crash on exit. I've fixed the patch, but not my build. Use ttlanhil's build. Thanks for reporting it though. It was a mistake on my part. I changed some things (array bases) that meant I had to change other things. I forgot some of them.

Yes, that would work. I'll do it that way. Thanks, Learner. Sorry, bone powder.