Malaclypse

That's a great idea. I would love this Finally going around and looking for the animal or monster to kill instead of boring waiting on the spawn till it respawns. This is a good idea! And the ones in the camps/caves will spawn as before, but the partolling ones are spawning randomly - in large numbers Like this Have a horde of goblins, spawning at the empty huts in the northern mm swamp, surrounded by a bunch of randomly spawning guards Together with the building of groups/hordes it can be a good challenge to beat them I suppose it's even some fun for powerplayers if someone suddenly meets a group of 10 cyclopses

I managed to compile a windows binary using a mingw cross compiler Unfortunately I can not test it yet Anyone, I can send the binary to for testing?

Well, it's Ent's and Roja's game, they don't need to legitimate this decisions, I suppose.

So far, a skeletal documentation has been added to any header file. Some files are partially documented, some only have the skeleton by now. This needs to be finished next. Currently any undocumented function has this documentation header in front: /*! * \ingroup <group> * \brief * * Detail * * [\param <parm> <desc> (where applicable, for any parameter)] * \return None|<type> */ The ! in the first line of the comment inidicates this as a special block to doxygen and gets processed. Ignore the \ingroup tag for now, this gets covered later. The \brief tag should contain a short one-liner of what the functions does. You can refer to the name of any parameter <parm> using the syntax \a <parm>. That is, assume we have a function declaration like void foo(int i) you can refer to parameter i using \a i. For example \brief foo increases \a i by 1 After this comes a text block with a more detailed in-depth description of the function. You can use the \a tag here as well to refer to function arguments. Additionally you can use a \see <ref> tag to refer to any function, variable and data type that is documented. Assuming, void bar() is declared (and documented) elsewhere you can use \see bar to include a link to the documentation of this function. The list of \param tags must match the function's signature excluding return-type. It's a doxygen error if they do not match. The <desc> might be empty and the <parm> must match the name of the argument. The foo function therefore needs a line \param i desc for i in the comment block. The syntax of the \return tag is \return <desc>. Currently we use the term None if the return type is void. Instead of using \return <type> we should use the syntax \retval <type> <desc> if the functions return-type is anything but void. After \return there can be additional tags. Commonly used is a list of \sa <ref> tags (meaning "see also") that links to related documentation. If the function's behaviour is more complex, a \callgraph tag should be added here too. If you want to add more advanced documentation ask me about what you want to do, I might be able to help, or look at your local doxygen documentation. Most global variables aren't documented yet. We want to document them after their declaration using the special C comment block extern int global_var; /*!< description of variable */ Note the extra !< characters at the begin of the comment. You can refer to other variables, functions and data types using \see or \sa tags here too. This is also the way how members of data types likes structs or enums get documented, although this has mostly been done. All documentation is grouped in modules (also called Modules on the generated documentations navigation bar). The tag \ingroup <group> tells to add the documentation for this function to the group <group>. You can get a list of all groups by looking at the generated modules page. If you hover the links, strip of the "group__" from the filename and replace any double underscore "__" with a single underscore "_" you get the name of the group that you can refer to. The groups are defined in the file docs/groups.doxy. The grouping of functions isn't finished yet, that is, not any function is known to be in the group it belongs to. To build all the graphs, generated by default, you need to have graphviz installed. You can disable this by using either doxywizard or by changing the HAVE_DOT line in docs/Doxyfile, in case you can't have graphviz installed for whatever reason. Global callgraph support is subject to change, for this reason it's important to add a \callgraph tag to any applicable function. All documentation is currently subject to review. Devs are encouraged to document the functions they know well, where possible and take part in the review of the documentation. Any support is welcome. If you want to add to this subject, feel free to pm me either in this forum, or pm any of my in-game chars

You use windows xp, which is still lacking full support for 64bit. If you install an operating system that fully supports 64bit you can compile the game from source to a native 64bit executable, I guess.

Not only at rain, but at heat too has to be looked at. People working in kamara desert or another dry region of seridia should suffer from drain and have food rate increased to compensate the loss of water

Servus zusammen, gestern gabs einen schoenen artikel zu oesterreichischen slang und entwicklung von sprache bei heise: http://www.heise.de/tp/r4/artikel/19/19524/1.html Den wollt ich niemand vorenthalten

It's better to open a new topic, not to reply to some random topic This is already implemented. You can set it in el.ini. Change #show_stats_in_hud = 0 to #show_stats_in_hud = 1 If there's no '#' character in front, put one there.

Additionally try to temporarily set #poor_man = 1 in your el.ini file. This may give you the chance to at least do anything in the game, so that we can see where the problem is.

I didn't disregard the other possibilities. Maybe you misunderstand my post. This was just an example of how I decided which gender to play in only one particular case. And personally I'm not interested why someone plays a male or female char, nor am I interested if the chosen in-game gender is also the rl gender. At least not in the beginning. Maybe if I know this person very good, or if I feel my belly is filling up with butterflies more and more But I understand that someone may be interested in the psychological backgrounds of such a decision. To help you gain some insight in such possible backgrounds I posted here. This is of course only one of possibly infinite reasons why someone choses a particular gender. If I see a woman in-game it IS a woman for me, and if I see a man it IS a man for me. Period.

Yes, the window manager can have a big impact on the client. While testing before the last update, I noticed some strange behaviour that didn't happen before. I talked with wytter about it in the game and we came to check what I installed/updated that day. I found then it was the e17 window manager that caused the troubles, going back to e16 or using gnome with metacity anything was working as expected.

Hi, I think, current way of distributing EL needs a bit more support. I have the following ideas about this topic. I put this in programming, because I think it's best placed here. If you think different, please move to the appropriate place As I already implemented a configure script for the client, what do you think of extending this to the whole project? Autoconf/automake works on almost any platform, including windows if you have cygwin or mingw installed. This could enable us an uniform building process, largely independant of the underlying platform, as long as the platform itself is supported by el. And we can enable/disable building of components, like mapeditor using command line parameters to configure. The package maintainer, that is the person who build packages and distributes them for other people to download, will have to setup a particular directory layout, with an el root directory, containing several subdirectories for client and mapeditor sources, game data and probably other stuff, like gtk elconfig client from wytter. This el root directory will contain the configure script. We need to provide a script for maintainance purposes, which will bring all files in sync with the requested release tag. We need to ensure proper tagging of all files for releases. AFAIK the current sources are not tagged for the 1.0.1 release, only for the 1.0.0 release, but files have already been added to cvs that are targeted at 1.0.2 release. Requirements for the packagers machine would be: GNU make GNU autoconf GNU automake gcc cvs client of your choice bash or similar shell, also cygwin shell After configuring the built will be done by a simple 'make dist', which will compile any necessary targets, installs them into a virtual root and packages them together into an archive. Those packages will be platform dependant and would contain only the files needed, that is no el.x86.linux.bin on windows and no el.exe and *.dll files on other platforms. This is only a very general setup for binary distribution, but can be implemented for virtually any platform we are interested in. One step further, would be to provide packages that are more on the needs of various platforms, like a windows installer, rpm and deb packages, and general purpose tar archives, as well as additional support for source distributions, like Gentoo (which is already supported quite well). What do you think of this? It's only a rough picture, but I hope you got it Didn't want to make the post too long

Aitrus this thread is about creating a distributable package from the source code and the data, not about actually distributing it.

If they want only that less members, let them be. There may be not much sense in making a one person guild, because a guild is about a team actually, but hey, if they like to make one for their own, let them be. I don't understand the problems you have here. It is imho quite some nazi style: you don't like it, so kill it. There was a period in the past of europe where this was done to a nation and it should not repeated, not even in such little topics like this (little compared to real big issues, affecting all or big parts of the world). My humble thoughts

No that's not the case. First this patch only applies to the errors.c file, not to the header file, and second the errors.h file isn't yet documented

ha noi des gibds jo edda i wois loider ned wia e dia scheene schwaebische o's uf meira taschdadur nakriag, abr i be vom neggrdaele. direggd neabam adomgrafdwerg in neggrweschda ufgwachse. emmr am straala :lol:

What xorg and nvidia-kernel/-glx versions do you use? I am using gentoo 2004.3 with xorg 6.8.0-r4 and nvidia 1.0.6629-r3 kernel and -r5 glx (also using geforce 3). I also get those messages, but they should be mostly harmless and I don't have the problems. Also others running gentoo don't seem to have it. Can you try to attach a debugger to the client and try to figure out where it crashes?

What I have found in my time working since 1985, when I started my job training, is that economic laws or the economic as it is used in capitalism/market economics has greatly failed. It only works for about 5% of the worlds population. The other 95% are merely not more than slaves, imho. They go working all the day, for the good of some other people, not for their own good, getting only a little fee, while the other 5% got all the income, and get more and more and more and more.... For this reason I don't count on economic laws. Of course, this is just my personal experience and maybe there's noone on this forum sharing this opinion, but instead of trying to adapt real world economics in a game, I find it more suitable to construct and/or try out alternative approaches to economy, and see how and if they can work. At the end, in-game economics will never be like real life economics, no matter how well they are designed. Sorry for being a bit off-topic, but I still haven't managed to not get angry when I have the feeling someone wants to tell me how well economics works and how good it actually is.

Hehe, nur dass ich nicht aus bayern komme, sondern ein waschechter schwoabaseggl bin

Ich finds auch schoen, wenn sich hier leute wohlfuehlen, deren muttersprache eben nicht deutsch ist Ausserdem gibt dann immer wieder mal ein paar lustige posts Hat mich auch angenehm ueberrascht @Ryuu das liest sich wunderbar mit einem verschmitzen laecheln und ist darueberhinaus auch verstaendlich Ein herzliches willkommen an alle gaeste

No this probably won't work, because he's still using the environment of the user he logged in initially. To get this command working you need to use user@workstation home $ su - that is put a - (minus sign) after the command, which will also re-initialize the environment to be roots one, thus adding /sbin, /usr/sbin to the path, so the shell is able to find telinit or init.

Ok, I submitted the patch.

I think it would be much cleaner if only one version is used throughout the code, whether it be the standard versions or the my_ versions doesn't really matter imho.

I have a quick question about this. Why don't you use the my_ string functions throughout the code, i.e. my_strcp instead of strcpy, my_strncp instead of strncpy and my_strcat instead of strcat? Also you use my_strncompare at the beginning (of the patch file), but later down you use strcmp. Do the my_ functions not work for you here?

So I suppose this to be a bug. Only collapsing cavern walls cause more than 30 material points of damage. And imo, they shouldn't appear anymore with flowers, since the last update, because of the reason, a newbie can die too easily.