Lachesis

Wrong quantities in inventory are very probable to be a client bug.

Do you have the # sign in front of data_dir in el.ini? Is el.ini found in $HOME/.elc/ or in the working directory of EL? P.S. I would highly appreciate if mod messages could be separated from normal PM. But I wouldn't want anything to be forced to go into all views. The tabs are always highlighted when you receive a message, and if decided to have PM/mod messages in a separate tab and you don't react on the tab being highlighted, well, it's your fault. I don't see any reason for forcing people. Let's make sensible defaults and good option descriptions, players are responsible for their changes. We're a development team and no player nurses.

So, um diesen Thread mal wieder etwas zu beleben möcht ich Euch doch mal was zum Diskutieren geben ^_^ Edit: War wohl doch nicht besonders gesprächsanregend. ^_^ Na, vielleicht fällt ja noch jemandem was ein

Heavy rain makes you see much less than in sunshine. The server doesn't take this into account yet and always sends the same range of objects to the client. Actually, this would even be quite difficult, because the visible range depends on the camera position, not the actor's position (like requested), and thus changes whenever you rotate your view or zoom in or out. I've been using a TNT2 M64 with EL, it wasn't much fun But it wasn't as a pain as a ProSavage KN 133 I used some day too. Looking at prices and features, I would have probably bought a Radeon too if ATI's linux support wasn't that lousy.

These are enlightening articles, thank you for the links, Lyanna Unfortunately, nothing was said about the implications of a multiuser environment. I think some analysis of them could be inestimably worthful for a game like EL. Currently, especially when looking at quests, EL actually is designed like a single-player game. We can have up to one thousand people interacting with each other, but make almost no use of it. I don't know whether a massive-multiuser environment is a means that can enhance the game, or how it could achieve that, I only would like to point on some potentially overlooked capacity here.

Hi, I'm back, and ... I'm only working on the lines offset Weird, I remember about that problem and I thought it already had been fixed, at least it worked for me .

I'll make my own implementation P.S. Theoretically the UTF-8 algorithm is capable of encoding characters of up to 36 bits length, however the official RFC only covers the range that can be reached by UTF-16, which is 0x000000-0x10FFFF. That's why using it to encode 26-bit numbers is actually an extension. P.P.S. Using five bytes for a colour code is actually quite a waste, is there any available range of 28 consecutive characters in the two byte encodable range 0x080-0x7FF?

It should be possible to use the multitexture mechanism we use for shadows for fog, too. This will be a much worse looking but also much faster alternative for people with performance issues. P.S. I bought my card for 70 € about three months ago. I don't have $ 400 for a graphics card either. P.P.S The rain is rendered in one large GL_LINES block using glVertexPointer() and should not have any performance issues on any system. It consumes about 0,6 MB memory.

I'm sorry, I committed the books directory a little in hurry ... yes, parser.h was missing, I added it now. Sorry for the inconvenience.

Color codes will not be supported in book display. You will have to use the facilities of the visual data format to achieve colored display. For chat, if it ever is supposed to come (I've been told UTF-8 support not possible to do on the server, which I have to believe as I can't verify it), I planned to extend UTF-8 a little to support four trailing bytes and use range 0x03000000-0x03FFFFFF for full 24 bit RGB colors. The nice effect of this choice is that the leading byte will have the value 0xFB making color codes very easy to detect. Additionally, the high range is very unlikely to ever intersect with official unicode.

With the same argumentation I remember banging my head against a brick wall ... But you're right IMO, especially on slow machines it might be an issue. On the other hand, I don't like the image of players disabling fog just so that they can see more. That's the reason why I haven't put such an option yet. Additional note: You can zoom in to see more, too, and on the new server only very few rainfalls will be as heavy as those on the main server now. This is a server issue, the rain display depends on what the server sends to the client. There are big caves. Dungeons and night maps have darker fog. Maybe it's not dark enough yet, I will try to tweak that. Since there are big dungeons, I'm not sure if disabling is such a good idea. You have "isometric" in Video, which lets you enable or disable orthographic projection. If you disable it, you will have perspective. The settings in advanced video are for users that are not satisfied with the perspective angle (perspective setting) or the clipping (near plane setting). These are advanced settings, please read the hints in the config window and in el.ini.

Addition to step 4: if you don't want to look up the source, you can use the "list" command to show the adjacing code lines or other portions of the source: list 41 { 42 int done = 0; 43 Uint32 key = 0; 44 Uint32 flags = 0; 45 46 if (event->type == SDL_NOEVENT) return 0; 47 48 mod_key_status = SDL_GetModState(); 49 50 if (mod_key_status & KMOD_SHIFT) shift_on = 1; (gdb) list 41 36 } 37 } 38 } 39 40 int HandleEvent (SDL_Event *event) 41 { 42 int done = 0; 43 Uint32 key = 0; 44 Uint32 flags = 0; 45 (gdb) bt #0 HandleEvent (event=0xbfffed40) at events.c:46 #1 0x0807c56e in start_rendering () at main.c:91 #2 0x0807c813 in main (argc=1, argv=0x1) at main.c:213 (gdb) list main.c:91 86 SDL_Event event; 87 88 // handle SDL events 89 while( SDL_PollEvent( &event ) ) 90 { 91 done = HandleEvent(&event); 92 } 93 94 //advance the clock 95 cur_time = SDL_GetTicks(); With regards Lachesis

Can you make that screenie without rain so that I can see what you mean? :> Btw, the screenshots are not very meaningful with the new highly-transparent rain drops. You hardly see them in screenshots, their full effect is only visible in animation I wish I could take screen films P.S. I walked there and saw what you mean. It's not really the end of the world, just the map author did not add enough water tiles. Did I maybe accidentally increase the max zoom? Since it's the same in isometric view. I hope we'll be able to fix the map issues soon

What bugs? :>

I think having both would be too confusing, also we'd have to check how both values add up to the final scaling so that we don't get more than 4x zoom. But maybe an options flag which mode to use or a float value between 0 (plain zoom) and 1 (plain camera movement) would be desirable? The gradient alpha is a great idea, however it'd mean that I cannot use a single glColor4f() call for all drops anymore. Since they're rendered using glVertexPointer(), I'd either have to split that up into a loop or use a color or tex coord array. So that'd be the usual niceness / performance / memory consumption tradeoff. Not sure which solution to choose here. What would you do? Update: Implemented a configurable distance between clipping plane and your actor (see above). Info: This patch has been merged into CVS. That means it'll be probably included in the next release. With regards Lachesis

If you are standing and sea level (0.0), this shouldn't happen. The min zoom was changed to avoid that, maybe these hunks of the patch failed with you? If you are in the mountains, this is because you are moving the camera inside the mountains. I changed the zoom to true camera movement on request, unfortunately this is the one of its effects. If it wasn't too expensive in development and processor time I would prevent moving the camera inside objects. Yet we have to choose between camera movement and zoom. Camera movement means looking inside objects, zoom means objects behind camera are drawn. Any position between these extremes is possible, like drawing objects that are not more than a certain distance behind camera, but the tradeoff remains. Sorry Update: the distance of the clipping plane is configurable now. Set it to 40.0 for the old behavior (no clipping), and to 1.0 for the modified behavior (full clipping), or experiments with values between.

Update: The rain is way more transparent now. Hi everyone, I have updated the patch and incorporated some of the suggestions mentioned here. Please see BerliOS for full details of the changes, or just check them out yourself With regards Lachesis

Unfortunately, the camera position is at your actor's eyes, which didn't matter for orthographic projection. For perspective, of course I had to move the camera back a little (exactly 33.0) to achieve the same scale of your actor. However, that messed the shadows up completely, and also most of the scene disappears in the fog. Let's assume I can fix the shadows. Then I have to reduce fog. But because all of the scene is that far away, the fog blending value is almost the same, so it just looks like gray curtains. The problem is that the fog equation is fog_alpha = 1 - exp(-density*z)^2 What we'd need would be fog_alpha = 1 - exp(-density*(z-33.0f))^2 for it to look good, so that the fog doesn't start in front of the actor. I tried linear fog which has a near distance, but it looks like crap. The experienced eye requests exponential falloff it seems. So I have to make the z coordinate attain zero at the actors position. But that causes objects between the camera and the actor to be fogged. No idea how to work around. :/ Update: found a trick

I have 30-50% performance drop when fog is enabled. Without: 34-36 FPS With: 18-25 FPS Chipset: nVidia GeForce FX 5200, 128 MB RAM PC3200 Platform: AMD Athlon XP 1800, 256 MB RAM PC2100 But please don't clutter the thread with such information now. If we have five examples that's enough. Lachesis

Darker fade at night This is already implemented, I'm using the current ambient and diffuse light as well as the rain strength to determine the fog color (check weather.c:render_fog()). I even give a penalty on diffuse light at night and in dungeons because there is less lighting overall. Maybe I should mix the sky color in, too. Update: done Full reflections Yes, actually the water surface should be messed up by the rain. Especially light rain is a problem here because it distorts the reflections but doesn't completely hide them. And even for heavy rain we need new textures and animation mechanisms. Maybe we can add that in a later patch. There we can remove the clouds, too. Foggy objects close to the camera This is because the fog is not calculated with respect to the camera, but your actor's view. Objects very close to the camera are as far from your actor as objects very far from the camera, thus they look as foggy. Changing this would require quite a bit work because we had to keep the projection matrix at identity and put the projection into the modelview matrix, or we'd have to use a more expensive alternative to glFog(). It may look a little unfamilar at first, but I think it's better to leave it the way it is, so you see what your actor sees. Update: Fog is now relative to camera position. This means your actor will be fogged if you zoom out in heavy rain! Parts of the scene missing Please give me some more informations on that, maybe a location where I can see it and a screenshot. The number of ground tiles drawn has already been changed, maybe we need to modify nearby objects a little or zoom a little further in. Bigger objects in front of the camera This is typical for perspective view and I wouldn't want to avoid it, because it's what makes you feel to be right there in that foreign world If it disturbs you in gameplay, you can switch back to orthogonal projection at any time using the "isometric" config option. A greater viewing distance would not help much here unfortunately, because only more objects would appear in front of your actor. A smaller viewing distance might help though. Update: Moved the clipping planes to cut off objects behind camera. Camera movement should look more realistic now. Update: You can set the distance for the clipping plane in the config window now (see below). With regards Lachesis

Idea: let's use a 3D noise function, compute it and use it as a 3D texture? Then we can move the the texture through the plane and create interesting effects

Changed.

I'm planning support for unicode characters in the XML files for 1.0.3, however they still won't be available for chat.

Just name the chars you want to be added and their position in the ANSI character set. If they aren't in, unfortunately there is no way to add them yet.

So you are updating the rules, I though you were traslating them. My mistake, sorry. Yes, splitting them is probably an option then. Try to get the Gods' blessing before you commit it though.