RallosZek

Just something I noticed on main, the fountain behind pv storage is giving me a headache, cause fps drops to 12 or less. I already cap it at 30, which solved most speed problems including the portals room and does not affect the game playability. However, I cannot reproduce this on test and I think it is because there's no one else there. That's hardly ever the case at pv storage. So as a quick fix, would it be possible to 'enable/disable' fountains under eye candy, cause this is the only spot where it's really noticable, so turning off eye candy would be too much.

Hello I wasn't playing at the time and don't feel like reading an entire thread of flames and all, so over the months I've gathered that summons are now proportionally loosing health because of a/d and magic experience exploits. However, the current implementation makes them useless for a very valid use of summons, which is to hunt lower creatures with them, for their meat/bones/furs/horns/whatever. At present, they die way too quick, before you have a decent amount of furs, you're out of heal summoned essies - which already assumes you can even cast it and I know my alt with mid 20's summon and same magic can't. I never understood why summons should give a/d exp in the first place and since reducing the amount of exp it gives is an existing technology, why not reduce it to 0.1%. As for the life drain exploit, frankly I think leveling magic is hard enough, but if this needs fixing, then only allowing life drain to be cast at summons in PK maps, would give the same risk as using a player life-drain partner. And then revert the HP loss to it's old state. I think this is a more to the point solution and restores the ability to use summons for drops hunting.

that's always been that way. No worries, it's not PK there, just keep 'attacking' yourself to see where the bounderies are.

It's actually NEW_ACTOR_ANIMATION that introduces the delay in actor definition. DYNAMIC_ANIMATION was added in nov 2006 and I haven't seen any changes to actor fighting speed and never compiled my cvs clients with it. So, if there's any speed change, without DYNAMIC_ANIMATIONS, then NEW_ACTOR_ANIMATION must be missing as well.

You can make teams with guilds and using the war system you can even do it on non-pk maps, object capturing and rostos are at your own discretion. What you're proposing would need instance maps (maps that are exclusive to a specific group going in), I don't see that happening anytime soon.

And this was bad, because of PK? Cause right now, you can't keep them alive. If PK is the reason, why not leave it this way in PK areas and outside PK back to the old format. If I recall correctly, the old format looses 6HP per minute, so a 300HP sslessar lives 50 minutes @ ~3.5k gc, giant 100 minutes @ ~23k.

That message about the features, needs -DGL_EXTENSION_CHECK, which isn't in Makefile.linux or make.defaults as of 3 hours ago. Adding it to OPTIONS in top of Makefile.linux enables it, or in your CFLAGS env variable. [19:38:01] Your graphic card supports more than thedefault requirements for the next el release.

EQ/Champions of Norrath, isn't hack-n-slash. They are D&D-originated MMO RPG. They however use a class system, where EL uses a nexus system. In the core it's the same thing, only restrictions aren't forced by choosing a class/race but pp distribution.

I see a pattern Especially since my card is older, but has higher OpenGL version: [13:57:49] Video card: GeForce4 4200 Go/AGP/SSE2 [13:57:49] Vendor ID: NVIDIA Corporation [13:57:49] OpenGL Version: 1.5.8 NVIDIA 96.31 I also don't have framebuffers, by the way and not experiencing the blackouts. My intel chipset is 82801DB/L/M, which has ICH4 audio and the 915 has ICH6 HDA, so defenitely older.

For reference, mango did further testing and it turned out to be a different manifestation of the shadow bug. AAA.... after reading this I did the same and guess what it worked for me as well... Hmm, two major changes are the default client size and shadowmap size. If you change: #video_mode= 6 to: #video_mode = 4 Does that help? Otherwise, it's probably in the new settings

That is the installer. No idea why that crashes. If you mean the el.exe is that is installed by that, then try changing: #shadows_on= 1 to #shadows_on= 0 in el.ini, in that folder. If you disable blood under Eye Candy in options, do you still crash?

Same here, no more shadow crashes after commenting out glEnableClientState in shadows.c. Vial table bug in Anitora fixed as well. However, a bit further (You are in Port Anitora [230,195]) the 2nd shield from the left on front of the table flickers and disappears under certain angles. More with daylight (was there for day/night change) but still very noticable at night, not affected by shadows. Just noticed on main server, minor typo fix: English: Today there is an increased chance to triger random harvesting events. Should be trigger.

I will retest too, tomorrow. 96xx branch is latest for my card (nvidia 4200 go), cause nvidia dropped support for that range in the newer drivers. This is the latest version in FreeBSD ports (which is currently in freeze) and my kernel/base system is 6.2-STABLE as of Mar 16. @ttl: did you compile your entire system with debugging to get that detailed info or just libraries that el links with?

And mirror: http://el.beplacid.com/downloads/el_140_rc2_data.tar.gz extracts to el_140_rc2/ MD5 (el_140_rc2_data.tar.gz) = 9f08f058f6cd401103de20dd0f851292 SHA256 (el_140_rc2_data.tar.gz) = 87bf038af8fe3f2ef8172056f2d41681b4be3e771236a6b9979147f068956a0a

revision 1.133 date: 2007/03/23 21:11:30; author: ttlanhil; state: Exp; lines: +12 -16 don't accept keystrokes if we don't have keyboard focus. remove un-needed #ifdef's I think this fixes a problem when typing in an application like yahoo messenger (with always on top?), it's echo'd on el. Seems to only happen on windows, never seen it myself. As for the crash above, I can't reproduce it at night, with or without shadows. Here's the scenario (reproduced twice with daylight): 0. Enable shadows 1. Enter and exit blacksmith in Irinveron [322,544] 2. mapwalk to the forge in the south [248,129] Somewhere along the way (different points) I crashed. From what I can tell, 3 different causes: 1) bug in nvidia's shadow support (nvidia GeForce4 4200 Go/AGP/SSE2, OpenGL version string: 1.5.8 NVIDIA 96.31, FreeBSD 6.2-STABLE) 2) bug in el's shadow support 3) I encountered something along the way, that crashed me two times and didn't see what it was. When I relog in and reenable shadows, I didn't crash again. So I hope someone can reproduce at daylight, with and/or without shadows. Relevant settings: #no_adjust_shadows = 0 #use_shadow_mapping= 1 #max_shadow_map_size = 1 #clouds_shadows = 1 #shadow_map_size = 1

Few more spots: You are in Glacmor - Wave Neck [45,295] You are in Glacmor - Wave Neck [46,294] You are in Glacmor - Wave Neck [47,293] You are in Glacmor - Wave Neck [48,292] You are in Glacmor - Wave Neck [49,291] You are in Glacmor - Wave Neck [50,290] < above ground again. You are in Glacmor - Wave Neck [52,291] You are in Glacmor - Wave Neck [53,292] You are in Glacmor - Wave Neck [54,293] < above ground again. I think that spot goes a bit further, cause a polar just walked outof that rock Update, revisiting some oldies: You are in Irinveron [60,464] Most of the rocks on that border are not solid. Random crashes when walking in irinveron. Now, I normally do not use shadows and both of these happened with shadows on. Will see if I can reproduce without shadows, cause even when run under gdb, the backtrace isn't very useful: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xba33000 (LWP 100164)] 0x29eb0140 in ?? () (gdb) bt #0 0x29eb0140 in ?? () #1 0x29665000 in ?? () #2 0x000001fe in ?? () #3 0x0000002a in ?? () #4 0x082658c8 in meshFaces.3 () #5 0x28e7d74a in _nv001254gl () from /usr/X11R6/lib/libGLcore.so.1 #6 0x08265820 in meshTextureCoordinates.2 () #7 0x082658c8 in meshFaces.3 () #8 0x00000000 in ?? () #9 0x00001e00 in ?? () #10 0x00001e00 in ?? () #11 0x00000000 in ?? () #12 0x00000000 in ?? () #13 0x00000207 in ?? () #14 0x000000ff in ?? () #15 0x00000000 in ?? () #16 0x00000070 in ?? () #17 0x00000004 in ?? () Previous frame inner to this frame (corrupt stack?)

This is not a bug. The Stats in HUD only works with resolutions 1024x768 and greater. This is because the skill list would otherwise overlap with the quickbar. The skill list was recently expanded to include engineering, and therefore the resolution restriction was placed on the stats. I suppose using a smaller font, would be new feature, rather then a bug fix? It's not that I (and others) have small screens, but like stuff around the client, that we use 800x600. It just about fits if you start with y=11 in hud.c:960. I agree it ain't pretty then. Changing the vertical bounding box for the font (and reducing fontsize) to 13 rather then 15 should solve the problem entirely. Fix for today's cvs, when compiling debug build (-Wall -Werror) [edit] found a few more[/edit]: Index: frustum.c =================================================================== RCS file: /cvsroot/elc/elc/frustum.c,v retrieving revision 1.28 diff -u -r1.28 frustum.c --- frustum.c 17 May 2007 00:09:09 -0000 1.28 +++ frustum.c 17 May 2007 21:01:21 -0000 @@ -465,7 +465,7 @@ MATRIX4x4 modl; // This will hold our modelview matrix MATRIX4x4 clip; // This will hold the clipping planes unsigned int cur_intersect_type; - VECTOR3 p1, p2, p3; + /* XXX Unused: VECTOR3 p1, p2, p3; */ if (main_bbox_tree->intersect[INTERSECTION_TYPE_DEFAULT].intersect_update_needed == 0) return; #else Index: gl_init.c =================================================================== RCS file: /cvsroot/elc/elc/gl_init.c,v retrieving revision 1.113 diff -u -r1.113 gl_init.c --- gl_init.c 11 May 2007 05:56:09 -0000 1.113 +++ gl_init.c 17 May 2007 21:01:21 -0000 @@ -1037,8 +1037,8 @@ #endif if(have_vertex_buffers){ - e3d_object * obj; #ifndef NEW_E3D_FORMAT + e3d_object * obj; for(i=0;i<cache_e3d->max_item;i++){ if(!cache_e3d->cached_items[i])continue; obj=cache_e3d->cached_items[i]->cache_item; Index: elwindows.c =================================================================== RCS file: /cvsroot/elc/elc/elwindows.c,v retrieving revision 1.90 diff -u -r1.90 elwindows.c --- elwindows.c 11 May 2007 05:56:09 -0000 1.90 +++ elwindows.c 17 May 2007 21:01:22 -0000 @@ -698,7 +698,7 @@ void destroy_window(int win_id) { window_info *win; - widget_list *widget, *next; + /* XXX Unused: widget_list *widget, *next; */ if(win_id < 0 || win_id >= windows_list.num_windows) return; if(windows_list.window[win_id].window_id != win_id) return; Index: io/e3d_io.c =================================================================== RCS file: /cvsroot/elc/elc/io/e3d_io.c,v retrieving revision 1.12 diff -u -r1.12 e3d_io.c --- io/e3d_io.c 9 May 2007 22:50:04 -0000 1.12 +++ io/e3d_io.c 17 May 2007 21:01:22 -0000 @@ -82,7 +82,9 @@ { e3d_header header; e3d_material material; +#ifdef USE_EXTRA_TEXTURE e3d_extra_texture extra_texture; +#endif char cur_dir[1024]; int i, j, l, idx, mem_size, vertex_size, material_size; int file_pos, indicies_size, float_count, index_size, v_size, m_size; If this is mangled, click while I'm online

If you suspect that, avoid the mouse. As in, use home/delete/insert and drop something to open bag. Is your scenario still valid then?

Then you are definetly using the wrong 3d objects or maps..the one ones will appear that way, not the new in the RC. One pitfall for *nix, you need to verify the data_dir in ~/.elc/el.ini and adjust accordingly. Not so much a bug, but a note of caution: there's only one feather image. Hawk, falcon, cockatrice all have the same feather. Considering the difference in a/d between these, and possibly their value, it could be easy to scam people with it. Dunno how hard it is, but 3 different color schemes would help And the following, about the Aeth Alfan tab map: The tavern is at the blue cross, not the orange dot. It's also 'strategically' wrong, cause it's on the other side of the road

You are in Iscalrith [157,35] - Click the cave: Umm... you can't teleport, there's no nearby open location

Now, I am a bit confused. Are we switching over to NEW_E3D_FORMAT for this release? Yes, see ent's last line of original post. Btw, if you disable AUTO_UPDATE, also disable CUSTOM_UPDATE or you'll get link errors, since these share functions.

Hmm, no. There's a relation: self-spells don't work, target spells do work. Heal, restore (when not on full health) and shield all should give effects. Can you see somebody else casting self-spells?

Are you sure? That worked for celticlady. I see in el.ini that came with the exe, that the default is on. Same spells she had problems with, though.

By default 'Toggle special effects' is off. Turn it on and it should work. ctrl-o => tab 'Details'

Data tarball is available from: http://el.beplacid.com/downloads/el_134_rc1_data.tar.gz Extracts to ./el_134 Does NOT contain pre-compiled binaries, nor the windows dll's or exes. So you will need to compile cvs yourself on *nix/osx or wait for Octane. SHA256: 1be3416523b18e0fc08dff15f483e64ddb065b737ca6fdb82e7238d2269ae4f0 MD5: d6a0a4a5f2f50e80a6644985afadf3ce If you compile yourself, please check make.conf, and make sure FEATURES+= NEW_E3D_FORMAT is uncommented and FEATURES+= AUTO_UPDATE is commented so that files will not be overwritten.