Lachesis

Also the history section needs more information. What were the moments of fate in EL, and what people were involved in them? Summarizing this needs the help of many people, so the different perspectives can add up to a story. Also someone with some writing skill that knows many of the people needs to melt it all together.

Background loading is not planned because the updater is intended to be a separate piece of software that runs while the client is shut down so that it can overwrite the executable if applicable and necessary. Once it's done, of course you are free to improve it so that it can run simultaneously with the client. If you want to work it the way you described though, you will have to modify the client too so that it can reread all data files without restart, which is not trivial.

Please thank kl4Uz, he took it up, and I just polished it a bit. Hmm, just noticed I didn't mention that in the first post. (edited)

Hi Lhibou, I applied patch #639. Sorry for being picky, but if I had committed the new behavior (patch #596) without the team's blessing I would have gotten the bashings. Please make a new thread for patch #596 so everyone can comment. Thank you for it all! With Regards Lachesis

You don't need commit access for cvs add, it only affects your local repository.

This is only necessary if they are not visible at the moment, otherwise it's rather annoying. Can you change it so that it works that way? Thank you With Regards Lachesis

cvs add minimap.h cvs add minimap.c cvs diff -Nu With Regards Lachesis

I agree with Roja, normal maps can improve the model look but certainly not reduce the number of triangles any further.

Sorry I don't get it. If waterfall particles fall down, what's wrong with their reflection "falling" up? You know Radu, the exact same particle system can be used, the turning upside-down is done by simple camera movement.

I put Derin's colours into the client.

Yes you're right. Background loading is not planned though.

Wrong in what way? Btw, the particles are far from being perfect, the additive blending obviously doesnt work with fog, and the constant size regardless from distance makes them look odd when very close or very far.

:lol: But seriously, any color is doable, we just need the numbers.

@@ -360,18 +370,17 @@ void display_storage_menu() { ... - vscrollbar_add_extended(storage_win, 1200, NULL, 130, 10, 20, 192, 0, 1.0, 0.77f, 0.57f, 0.39f, 0, 1, 10); + vscrollbar_add_extended(storage_win, 1200, NULL, 130, 10, 20, 192, 0, 1.0, 0.77f, 0.57f, 0.39f, 0, 1, 30); vscrollbar_add_extended(storage_win, 1201, NULL, 352, 10, 20, 192, 0, 1.0, 0.77f, 0.57f, 0.39f, 0, 1, 28); } else { int i; ... @@ -151,6 +153,14 @@ Â storage_items[i].quantity=0; Â } Â + if ( (cat-12) > 0) + { + Â vscrollbar_set_pos(storage_win, 1200, cat-12); + } + else + { + Â vscrollbar_set_pos(storage_win, 1200, 0); + } Â vscrollbar_set_pos(storage_win, 1201, 0); } These hunks don't belong to this patch, please remove them. - strncpy(var->shortname, shortname, 5); + strncpy(var->shortname, shortname, 7); Please don't introduce new buffer overflows -- You have to change the size of the shortname field as well. Btw, we need a volunteer to replace these integer constants in favour of sizeof(). Anyone interested? With regards Lachesis

Hmm, at first look I like the idea of using the updater a lot, as it enables you to keep the newspaper on client and to use links (client books can have links, like in ency ... some day :blushes:), yet at a second look that's not perfect because the updater us not intended to be run in the background, however forcing users to download the newspaper (even if they dont read it) before they can enter the game isn't something desirable. P.S. Are server books really rendered or just parsed on server? I will have a look at the client P.P.S. The client gets a serialized binary representation of the parsed book and renders it itself. Only if the book contains images these images are sent to the client.

Hi everyone, As I mentioned previously, I'd like to move some font handling out of the code and add some convenience and flexibility along the way. The new mechanism will only be used for the new books at first, still I hope we can extend this later. The idea is to define the location and properties of each character in an xml file and use that info in the code instead of modifying the code each time fonts are added or modified. The intended format of that file looks like this: <?xml version="1.0" encoding="UTF-8"?> <fontdef> <font name="default" id="0" linesize="15" baseline="10"> <texture src="font.bmp"> &lt; 1 48 9 9 8 Æ 70 179 12 13 3 &#197; 108 168 13 17 15 &#xF8; 36 174 11 10 8 ç 18 154 10 13 7 </texture> <texture src="mathchars.bmp"> &#221E; 0 0 15 9 10 </texture> </font> <font name="dense" id="3" baseline="10"> <texture src="font3.bmp"> &lt; 1 48 9 9 8 </texture> </font> </fontdef> Note: The UTF-8 encoding is mandatory. The columns are from left to right: character, offset in pixels from the left and the top border of the texture, width and height in pixels, and the offset of the character's baseline to the top of the character in pixels. The font's name will be used in the visual data format to specify the document font. Currently, "default" (font.bmp) and "ancient" (font2.bmp) are defined. The font's ID will be used for internal identification, currently the ID 0 through 3 (font.bmp, reserved [fontv.bmp], font2.bmp, font3.bmp) are used. The font baseline specifies the offset of the text baseline to the upper border (the starting border in block progression direction). It will only be used in horizontally progressing text lines. These predefined entities can be used: &lt; (&#60;) less than (<) &gt; (&#62;) greater than (>) &amp; (&#38;) ampersand (&) &apos; (&#39;) apostrophe (') &quot; (&#34;) quotation mark (") For other characters that you don't want or cannot (because your editor doesn't support UTF-8) include literally into the file you can use their decimal unicode equivalent like &#197; for Å or their hexadecimal unicode equivalent like &#xF8; for ø. Note: The less than (<), greater than (>) and ampersand (&) symbols must not be included literally, they have to be masked using the above entities, otherwise the XML parser will fail to read the document. Benefits of this method: easier addition of characters full unicode range available for display (in books) full freedom how to distribute characters in textures full freedom what characters to support in what font using the same bitmap in multiple fonts possible With Regards Lachesis

I used the text block because I didn't want too much bloat. For parsing it doesnt make any difference and for typing the textual format is easier. In case it ever needs to be converted it is simple enough so that the plain text doesnt make it more difficult. P.S. Of course the format I choose is unambiguous too. P.P.S. I think it's interesting that you start to argue about this now, this has been around as RFC for quite a while, now I have implemented it and so I don't really want to change anything substantial, as you probably understand.

Look at the first post, the width is only one of five attributes that are given for each character.

I know that. But it's very restricted and not very nicely done. I revise it in order to untie fonts and textures and to untie character and position, so that the number of characters per font is less limited, textures can be reused in or shared by multiple fonts, and characters can more freely be placed within textures, altogether saving space and giving more flexibility. Finally I'll make the code more transparent. I refuse to use current font handling for something as complex as the new encyclopedia typesetting P.S. Actually I don't revise anything, I rather implement my own font handling and use it only in books. For easier translation it certainly would be wise to change it everywhere in the client, but I don't think I will have the time for it, and since there is some resistance against UTF-8 on server side, that would not be as useful as it could be anyway.

Here goes the XML Schema: <?xml version="1.0" encoding="ISO-8859-1"?> <!-- Image definitions for encyclopedia --> <schema xmlns="http://www.w3.org/1999/XMLSchema" xmlns:t="http://www.eternal-lands.com/xmlns/fontdef" targetNamespace="http://www.eternal-lands.com/xmlns/fontdef" elementFormDefault="qualified" attributeFormDefault="unqualified" /> <element name="fontdef"> <sequence> <element name="font" minOccurs="0" maxOccurs="1"> <attribute name="name" type="string" use="required"/> <attribute name="id" type="nonNegativeInteger" use="required"/> <attribute name="linesize" type="positiveInteger" use="required"/> <attribute name="baseline" type="nonNegativeInteger" use="optional" default="0"/> <sequence> <element name="texture"> <complexContent> <extension base="string"> <attribute name="src" value="string" use="required"/> </extension> </complexContent> </element> </sequence> </element> </sequence> </element> </schema>

Can we have a link to the Encyclopedia Errata thread in the first post with a short note that errors in Help, Skills or Encyclopedia window should go there? Thank you

It would be nice if you could buy that newspaper in game. Couldn't we use the server books for that?

The German translation is being revised by a group of volunteers atm. I gave one of them read access to freepository, if you don't have any objections I would give him write access too.

Lhibou, if you miss those defines you have an outdated glext.h. You can get a recent one from the SGI webpage: http://oss.sgi.com/projects/ogl-sample/registry/ Though it is probably convenient to put those defines into gl_init.h I have to say I don't like it one bit. Then we can as well ship our own copy of glext.h along with the client sources, which though still not wise at least would be better. P.S. Now after having nagged a bit, can we have reflections of particles?

The compile problem with -DMEMORY_DEBUG was subtle but interesting. We have to be careful when the redefine of malloc & co. takes place, as it shall affect our own files yet only our own. stdlib.h defines prototypes for malloc, free and calloc, which causes compile errors when elmemory.h is included before stdlib.h. I modified global.h to get around this, but we still need to be careful.