amd

Shouldn't the god quests also end up under Quest log?

There's also notebook feature in the client...

Aha, yeah.. they had to be in storage..

Nordcarn, Temple, interacting with Baostas the priest for manufacturing god. I have 30 leather pants in my inventory. After saying that I want to advance, I say, sure "I have them". Baostas says "Thank you... " but stuff required to finish the quest stay at my inventory and level stays at 0 So I'm stuck

Is it possible to download these again? I have intel cards on my machines...

Ok, understandable.. But your roadmap lists "highly experimental code"

There are few problems with mouse movement (like trees blocking the way) which is quite annoying on some maps. Also having laptop and playing without external mouse is quite tiresome So, I was seeing whether it is possible to implement WoW-like movement system. (Although I have never played WoW, I just stumbled upon this: http://www.ilovejackdaniels.com/cheat-shee...ft-cheat-sheet/ ) I looked a bit at the protocol code, and it really seems to be impossible with current protocol. [edit: Finished last sentence properly ]

Hey! Today I was experimenting with keyboard movement, but unfortunately stumbled upon the issue that every time you move the character it will always turn its face towards the heading. So am I right that this is not possible with current server-client protocol? ..or did I just overlook something...

I wandered around the WS summoning area. Took a while to get away from there because of this: Program terminated with signal 8, Arithmetic exception. #0 0x081373dc in ec::SummonEffect::request_LOD (this=0xf83d720, _LOD=0) at eye_candy/effect_summon.cpp:973 973 count_scalar = 3000 / LOD; gdb> bt #0 0x081373dc in ec::SummonEffect::request_LOD (this=0xf83d720, _LOD=0) at eye_candy/effect_summon.cpp:973 #1 0x081427a2 in SummonEffect (this=0xf83d720, _base=0x8325ec0, _dead=0x1089453c, _pos=0x10894504, _type=ec::SummonEffect::BROWN_SNAKE, _LOD=0xa) at eye_candy/effect_summon.cpp:612 #2 0x080f74bf in ec_create_summon_brown_snake (x=85.25, y=43.75, z=-1.49011612e-08, LOD=0xa) at eye_candy_wrapper.cpp:1543 #3 0x080f115e in parse_special_effect (sfx=SPECIAL_EFFECT_SUMMON_BROWN_SNAKE, data=0xb08008bc) at special_effects.c:735 #4 0x080ab98e in process_message_from_server (in_data=0xb08008b8 "O\b", data_length=0xa) at multiplayer.c:1670 #5 0x080a277d in start_rendering () at main.c:114 #6 0x080a2a7a in main (argc=0x1, argv=0xbfa6b734) at main.c:239 #Current language: auto; currently c++ gdb> bt full #0 0x081373dc in ec::SummonEffect::request_LOD (this=0xf83d720, _LOD=0) at eye_candy/effect_summon.cpp:973 rounded_LOD = 0x0 #1 0x081427a2 in SummonEffect (this=0xf83d720, _base=0x8325ec0, _dead=0x1089453c, _pos=0x10894504, _type=ec::SummonEffect::BROWN_SNAKE, _LOD=0xa) at eye_candy/effect_summon.cpp:612 No locals. #2 0x080f74bf in ec_create_summon_brown_snake (x=85.25, y=43.75, z=-1.49011612e-08, LOD=0xa) at eye_candy_wrapper.cpp:1543 ret = (ec_internal_reference *) 0x10894500 #3 0x080f115e in parse_special_effect (sfx=SPECIAL_EFFECT_SUMMON_BROWN_SNAKE, data=0xb08008bc) at special_effects.c:735 offset = 0x0 var_a = 0x156 var_b = 0x0 caster = (actor *) 0xfa8cd60 target = (actor *) 0x818c019 x = 170 y = 87 #4 0x080ab98e in process_message_from_server (in_data=0xb08008b8 "O\b", data_length=0xa) at multiplayer.c:1670 text_buf = "\205[trishanna]: \201thx for hosting sway :)\000ve misunderstood\000g in my first contest\000fth :D\00035]C,��Death EsnE��\215\200W\020\215\200W\020\t\000\000\000�O��\225W\030\b0���x���\212ʫ�\234���\225W\030\b\000\000\000\000/wanted]\000ach.\000��0\216<\017�����\226���w��T���\000@\000\000\000\000\000\000����\000\000\000\000"... #5 0x080a277d in start_rendering () at main.c:114 message = (message_t *) 0xb0801598 event = { type = 0x18, active = { type = 0x18, gain = 0xd3, state = 0x9a }, key = { type = 0x18, which = 0xd3, state = 0x9a, keysym = { scancode = 0x3, sym = 2996491064, mod = 3086444881, unicode = 0x77e8 } }, motion = { type = 0x18, which = 0xd3, state = 0x9a, x = 0x3, y = 0x0, xrel = 0xd338, yrel = 0xb29a }, button = { type = 0x18, which = 0xd3, button = 0x9a, state = 0xb2, x = 0x3, y = 0x0 }, jaxis = { type = 0x18, which = 0xd3, axis = 0x9a, value = 0x3 }, jball = { type = 0x18, which = 0xd3, ball = 0x9a, xrel = 0x3, yrel = 0x0 }, jhat = { type = 0x18, which = 0xd3, hat = 0x9a, value = 0xb2 }, jbutton = { type = 0x18, which = 0xd3, button = 0x9a, state = 0xb2 }, resize = { type = 0x18, w = 0x3, h = 0xb29ad338 }, expose = { type = 0x18 }, quit = { type = 0x18 }, user = { type = 0x18, code = 0x3, data1 = 0xb29ad338, data2 = 0xb7f76951 }, syswm = { type = 0x18, msg = 0x3 } } network_thread = (SDL_Thread *) 0xc333df0 message_queue = (queue_t *) 0xc304830 done = 0x0 network_thread_data = {0xc304830, 0x8324a74} #6 0x080a2a7a in main (argc=0x1, argv=0xbfa6b734) at main.c:239 No locals. gdb> list 968 outer_size = inner_size / 15; 969 break; 970 } 971 } 972 outer_radius = outer_size * (LOD + 3) / 10; 973 count_scalar = 3000 / LOD; 974 } 975 976 bool SummonEffect::idle(const Uint64 usec) 977 { gdb> up 1 #1 0x081427a2 in SummonEffect (this=0xf83d720, _base=0x8325ec0, _dead=0x1089453c, _pos=0x10894504, _type=ec::SummonEffect::BROWN_SNAKE, _LOD=0xa) at eye_candy/effect_summon.cpp:612 612 request_LOD((float)base->last_forced_LOD); gdb> list 607 } 608 } 609 outer_alpha = 1.0; 610 611 LOD = 100; // Force refresh 612 request_LOD((float)base->last_forced_LOD); 613 614 inner_color[0] = outer_color[0]; 615 inner_color[1] = outer_color[1]; 616 inner_color[2] = outer_color[2];

I have been using CVS client for a while and when closing the client, it deadlocks with a black screen.. gdb> bt #0 0xffffe410 in __kernel_vsyscall () #1 0xb7ea5f7e in __lll_mutex_lock_wait () from /lib/libpthread.so.0 #2 0xb7ea1dc7 in _L_mutex_lock_88 () from /lib/libpthread.so.0 #3 0xb7ea17bd in __pthread_mutex_lock (mutex=0xb2bff88) at pthread_mutex_lock.c:81 #4 0xb7d1a1eb in _alLockMutex (mutex=0xb2bff88) at al_mutexlib.c:37 #5 0xb7d18dbd in FL_alLockMixBuf (fn=0xb7d3c4b8 "al_source.c", ln=0x9c6) at al_mixer.c:1049 #6 0xb7d1db3f in alSourceStopv (ns=0x1, sids=0xbff929c0) at al_source.c:2502 #7 0xb7d1dc03 in alSourceStop (sid=0x4001) at al_source.c:2358 #8 0x080c8026 in destroy_sound () at sound.c:1649 #9 0x080a14d6 in start_rendering () at main.c:172 #10 0x080a164c in main (argc=0x1, argv=0xbff92be4) at main.c:235 gdb> #8 0x080c8026 in destroy_sound () at sound.c:1649 1649 alSourceStop(music_source); gdb> list 1644 1645 #ifndef NO_MUSIC 1646 music_on = playing_music = have_music = 0; 1647 if(music_thread != NULL){ 1648 int queued = 0; 1649 alSourceStop(music_source); 1650 alGetSourcei(music_source, AL_BUFFERS_QUEUED, &queued); 1651 while(queued-- > 0){ 1652 ALuint buffer; 1653 alSourceUnqueueBuffers(music_source, 1, &buffer); gdb> info locals queued = 0x0 i = 0xbff92af8 error = 0x80e84e9 context = (ALCcontext *) 0xb8bf048 device = (ALCdevice *) 0xb7f4aca0 I hope this information helps, but I have no idea how to fix this locking problem

amd@box770 ~/code/elc $ diff -u Makefile.linux.orig Makefile.linux --- Makefile.linux.orig 2006-06-08 19:35:31.000000000 +0300 +++ Makefile.linux 2006-06-08 19:35:54.000000000 +0300 @@ -39,7 +39,7 @@ _CXXFLAGS=$(PLATFORM) -O3 -fomit-frame-pointer -ffast-math -pipe $(OPTIONS) -LDFLAGS=$(shell sdl-config --libs) $(shell xml2-config --libs) -lSDL_net -lopenal $(XDIR) -lGL -lGLU -lvorbis -lvorbisfile -lcal3d -lm -lpng +LDFLAGS=$(shell sdl-config --libs) $(shell xml2-config --libs) $(shell freealut-config --libs) -lSDL_net -lopenal $(XDIR) -lGL -lGLU -lvorbis -lvorbisfile -lcal3d -lm -lpng _LDFLAGS=$(XDIR) -lGL -lpthread -lz STATICLIBS=libs/libSDL_net.a libs/libSDL.a libs/libopenal.a libs/libvorbisfile.a libs/libvorbis.a libs/libogg.a libs/libxml2.a libs/libcal3d.a libs/libpng.a libs/libasound.a

Hello, Looked into code yesterday and noticed one possible cleanup: only console.c uses list.c which implements doubly-linked lists. I killed the list.c and now use glib-2.0 (yes, it introduces another dependancy, but I have noticed places for other possible cleanups which will use glib). I also tried to clean up the history buffer API and add gtk-doc formatted comments to it. Duh... seems like I tested the wrong thing and accidentaly broke the command functionality. No patch yet. Note: Makefiles for other systems except Linux (which I fixed) need updating. Also, why I would prefer to introduce glib dependency: And I will continue managing my patchset until it gets committed

Hello, as I'm using GCC 4.1 compiler I'm getting lots of source code warnings when compiling the code. Sometimes these warnings are harmless, but sometimes may mask bugs in code... Here is the first take: http://amd.store20.com/files/2006-Q1/etern...c-cleanup.patch