Lachesis

Yeah I know but it's really simple and the code looks very neat and readable And I would like it to be used by others than me as well. I invented it because it was a performance issue in the book parser, and there were many other approaches in the client before, like using many if's (command parsing) or hashes (key.ini parsing). But in new code, I'd like this variant to be used, because of it's readability and scalability and also in order to promote the code amongst client developers so that they don'T reinvent the wheel.

I know that, and it's ok to use this kind of "translation" inside map_io.c, but add_particle_sys also is called with a string literal as particle file, and I would like to have that kind cleant. The current version classifies as so-called spaghetti code, because there is no obvious reason why a call to add_particle_sys("particles/foo.part", ...) should do anything else than loading particles/foo.part. It's a map-format related problem, so I'd like to keep the kludge inside map_io.c. The map format rarely changes and the kludge is probably going to stay there for a long time, so I would like as little confusion to be caused in the meantime as possible. You can define the enum at map_io.h as you pleases. Note that there also exists a symbol table "class" defined in symbol_table.h that you can use for an easy and fast conversion from strings to numbers (even when there's a huge number of strings with little differences) without using lots of if's. For example usage, you can check books/symbols.c and books/parser.c P.S. Alternatively to using an enumeration, it would also be possible to remove the eye candy code from add_particle sys, and keep it as it is apart from that, then #ifdef mask each call to it, switching to ec_create_* if EYE_CANDY is defined. Then, the "translation" in map_io.c would only be done if EYE_CANDY is defined, leaving the old code exactly as it is. You can still use an enum here like in books/parser.c in order to avoid the many, hard-to-read if's. This may be a cleaner method, maybe you like that one better?

Sure, it's just a hint, and I know those rules very well The client performs really bad on my system (see main thread), however CPU usage is quite low, so it can't be related to this.

Hi Karen! Sorry for stepping in that late, but I have another plea for you. The current hook-in of eye_candy in add_particle_sys() is kinda a hack. I'd suggest to get rid of this function entirely and use something like void add_particle_sys (enum EffectType type, float x_pos, float y_pos, float z_pos[, unsigned int dynamic]) then do a switch statement and based on #ifdefs call create_particle_sys or eye candy code. The return code of add_particle_sys is ignored on all 6 calls,* so using a void function is appropriate. Of course, these 6 calls have to be adjusted too but with grep it's done in a blink. Thank you! With regards Lachesis *) Strictly, they're 12 if you count #ifdef branches. Also, add_particle_sys_at_tile will need to undergo similar changes, but that's no problem either.

Hi Karen, here's a tip about eventually significant speedup, dont bash me if you're already using something like this: you can adopt the client's mechanisms for visibility tests to the collision tests. There are two models: the old model uses sectoring. The map is divided into sectors of 8x8 height map tiles (4x4 metres), and obstruction information is looked up only in the four nearby sectors. This can easily be done without using the existing code, which may be preferrable because it may soon be removed from the client. the new model uses AABB trees, which can also be used (and may be preferrable). For details, best contact the author, xaphier (that's also his BerliOS name). Using these methods, not only there may be noticeable speedup, but the algorithm scales well (ideally, logarithmic instead of linear) with the number of obstructions. That way, you can add a lot of obstructions for more detail. With Regards Lachesis

Passen die überhaupt alle auf ein Bild

Greetings dear EL friends, Eternal Lands is continuously growing, and so is the amount of information about the game. Each new story, new quest, new feature, new NPC, new place adds more content to the book of EL, some of it just entertaining, but most of it vital in order to play the game or keep stories, quests and other information consistent. Currently, all these informations are scattered across various resources, be it the game itself (ingame books, NPC dialogues, encyclopedia) official web pages (storylines), numerous reference sites hosted by contributors and fan sites. Especially for authors and editors, but also for developers, moderators, newbie helpers and players, a common hypermedia reference for these various types of information would be of inestimable value. Such a resource could be a wikicity, driven by all of the above mentioned groups, containing important information about places, people, creatures, items, historical and periodical events, and maybe even EL stories and fan fiction. Unlike official sites, it is intended to be a place from and for the community, including, but not limited to all the people involved in development and maintenance of EL. The initial content will certainly be provided by only a few people, yet we should not try to fully control the content; if players want to add spoilers about quests and secrets, there is no need to stop them; nobody is forced to read those articles (after all, big parts of that information is necessary for editors and authors anyway). With Regards Lachesis (your opinion goes here:) ^_^

Dear visitor, this thread is for the German EL localization team to coordinate their work, thus it will be run in German. With Regards Lachesis

Dear EL friends, repeatedly an offline message system for EL has been requested, but unfortunately it could not be implemented so far. The good news is, a friend of mine kindly released her code for an EL post office bot that can store PM for later retrieval by their recipient. I'm planning to set up an instance of it for public usage. The bot is supposed to be called mailman (no warranty on the name yet), and for now it will be accessible via the commands /mailman #send user text /mailman #fetch user /mailman #fetch all Later on, I'm considering supplying a client patch that automatically sends offline messages when a user is not available and fetches them upon login. Then, you will be able to use PM just like in ICQ or other offline message capable chat systems. With Regards Lachesis

Aw, next time I should research better. Anyway, I still wish all readers a Happy April Fools' Day!

Here's a list of missing teleports on C2/Map18 (caves) I found, along with their assumed correct destination: Location Object Destination 113 743 8025 37 91 * 478 372 7614 91 67 * 445 207 6649 174 140 255 59 8009 260 65 185 61 6636 ? ? 634 293 7093 11 134 * 529 178 6638 348 630 367 330 7615 421 663 296 680 2631 ? ? An asterisk (*) marks destinations on the outside map (cont2map18.elm). For the door 6636 I could not guess where it should lead. Also there were three caves I couldn't enter, so more doors/archs might be buggy. For the door 2631 I'm just unsure whether it really should lead to Bethel. Here's a list of locations with other problems: Location Problem 227 738 height difference too high 249 738 height difference too high These locations belong to a bridge whose ends are too steep, so they can't be crossed without teleporting. With regards Lachesis

I didn't remove anything, I just changed the topic title. With regards Lachesis

Nvidia still lists the Riva cards as supported in their newest drivers but when I last used my (full name) "NVidia Riva Vanta TNT2 M64" card, the 71.xx drivers were already out, and although they all listed the Riva cards as supported, none of them, nor any drivers newer than the 4xxx ones, recognized the card.

The 71.89 driver DOES NOT WORK with TNT cards!! P.S. I've been using a Vanta card for more than one year and you can trust me there.

Discussion about spell icons [1] moved to visual art forum. With Regards Lachesis [1] http://www.eternal-lands.com/forum/index.php?showtopic=23478

Dear encyclopedia volunteers, as you know, the current encyclopedia data format is not comfortable at all to write, maintain and translate. So I decided to implement a new format based on semantic markup. If you like to see the XML subset definitions, you can find them at the Encyclopedia CVS repository in the /dtd directory. For a quick guide on how to use the format, I also created an example file that explains the most important concerns. Of course, it is not normative, for reference please check the XML Schema files or ask. If you encounter odds or weirdnesses in the format, please don't hesitate to tell since it is not finished yet. Once the version bumps to 1.0, I will start writing code depending on the format, and changes will be more difficult. With regards Lachesis Edit: Inserted links, deleted the quote of the example file. Edit: Please also see the post about the visual format

Unfortunately, all uncommitted work has been lost due to a hardware failure. I'm currently working on another project so I can't continue this atm, if someone wants to take it up, all documentation on the formats can be found on freepository and is linked in this thread. The parser part of the implementation is almost done, it does the following things: building an internal representation of the XML tree propagating attribute values according to inheritance rules decoding and interlinking hypertext labels and references (missing) destroying an internal tree representation The code should be pretty self-explanatory. Sorry for the inconvenience, Lachesis

Lachesis

May I ask you to keep pages as small as possible. Scrolling is much more tedious than following links when having to look up lots of scattered information. Thank you

As mentioned before, the repositories were decided to be kept seperate for two reasons: Looser access permissions on the translated files. Avoidance of broken CVS client due to XML failures The latter isn't that big an issue, and doesn't justify the syncing overhead. The former was intended to be solved with upcoming SVN repository, so it was considered a temporary solution. Even though Wytter and Mihai left for another project, it should still be possible to set up a (common) SVN repository with per-directory permissions, even on BerliOS, we just need a trustworthy maintainer. With Regards Lachesis

If you think that certain information should be added to the encyclopedia, feel free to ask for it to be done. If you get approval you can post your patches here and they will be included.

without -DNEW_FRUSTUM: with -DNEW_FRUSTUM: Sorry, couldn't figure out the problem.

Due to system maintenance EL Wiki will be unusuable on Monday, 16th of January 6:30-7:00 GMT. Don't be surprised, my uni is securing the DB server. With Regards Lachesis

Great job so far, please continue your good work guys

Optionally disablable? I can only open up two channels as it is... the third still overflows. Two more buttons will be messy. Buttons, not tabs