inkydoo

I'm also running under linux with a 9700, and just as a data point, I'm not seeing the walking bug in this morning's cvs. I added the following debugging code before and after the ati-workaround code to test though: printf ("pre-workaround mouse coords: (%d,%d,%f)\n", mouse_x, mouse_y, mouse_z); printf ("post-workaround mouse coords: (%d,%d,%f)\n", mouse_x, mouse_y, mouse_z); Standing outside portland storage, I get the following results when I walk around a bit: pre-workaround mouse coords: (863,470,0.002039) post-workaround mouse coords: (863,470,0.521928) pre-workaround mouse coords: (769,715,0.001871) post-workaround mouse coords: (769,715,0.478886) pre-workaround mouse coords: (267,664,0.001905) post-workaround mouse coords: (267,664,0.487740) pre-workaround mouse coords: (497,316,0.002141) post-workaround mouse coords: (497,316,0.548162) which indicates that the workaround "fix" is performing correctly. If it isn't behaving properly (like when I remove the line from el.ini) the final value (z) is the same post-workaround as it is before.

I removed the ELW_DROPSHADOWS (and the |) from line 1042, so it now reads: ground_items_win= create_window("Bag", game_root_win, 0, ground_items_menu_x, ground_items_menu_y, ground_items_menu_x_len, ground_items_menu_y_len, ELW_WIN_DEFAULT); Everything compiles fine and runs now. I'll see if it causes any in-game bugs.

When I compile under Linux, I get the following error on items.c: items.c: In function `draw_pick_up_menu': items.c:1042: error: `ELW_DROPSHADOWS' undeclared (first use in this function) items.c:1042: error: (Each undeclared identifier is reported only once items.c:1042: error: for each function it appears in.) make: *** [items.o] Error 1 and then it bails.

Uhm... Yes, yes I did (OK, so I didn't. The process for creating a new, empty, C project could perhaps be made clearer, for those not familiar with Dev-cpp, especially since C++ is the default) Now I encounter an error in cal3dwrap.c where it complains it can't find cal3d/cal3d.h. It's not clear to me whether I need to download one of the cal3d packages from sourceforge, or if I need a cal3d package that's specific to EL.

I tried following the instuctions for using Dev-cpp posted by CK, but ran into problems. I also downloaded the project files provided by sadez and ran into the same errors. The first problem I run into is that paste.h wants X11/lib.h. Looking at paste.h though, it looks like all the functions inside are only for non-windows / non OSX machines. OK, so I remove nearly everything from paste.h and try recompiling. This time, I see numerous "invalid conversion" errors in 2d_objects.c and the make fails on this file. When I go look at the Compile Log window, it doesn't look like it's getting any of the declarations like -DWINDOWS, etc. If I go to Tools->Compiler Options and enter in declarations there, they do show up in the Compile Log. Am I missing a lib (maybe OpenGL or glut, how do I check for these?) or is something else wrong?

Fixed. Thanks.

It segfaults whether I add the -DMULTI_CHANNEL or not. Here's the ouput of running the current CVS version (compiled without the -DMULTI_CHANNEL) through gdb (run with no options): (gdb) run Starting program: /home/shanew/EL-test3/elc/el.x86.linux.bin warning: Unable to find dynamic linker breakpoint function. GDB will be unable to debug shared library initializers and track explicitly loaded dynamic code. [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 17897)] I/O warning : failed to load external entity "languages/en/strings/titles.xml" I/O warning : failed to load external entity "languages/en/strings/titles.xml" [New Thread 32769 (LWP 17900)] [New Thread 16386 (LWP 17901)] [New Thread 32771 (LWP 17902)] [New Thread 49156 (LWP 17903)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 17897)] 0x4046ac35 in mallopt () from /lib/libc.so.6 And here's the last few lines of an strace (run with no options): recv(15, "\0t\1\220Hi, and welcome to Eternal L"..., 8192, 0) = 374 open("/home/shanew/.elc/chat_log.txt", O_WRONLY|O_APPEND|O_CREAT, 0666) = 16 fstat64(16, {st_mode=S_IFREG|0644, st_size=13972, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0 x4b20e000 fstat64(16, {st_mode=S_IFREG|0644, st_size=13972, ...}) = 0 _llseek(16, 13972, [13972], SEEK_SET) = 0 --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++ The only change I made was removing the "-Wdeclaration-after-statement" from Makefile.linux

I got the latest CVS, with your recent changes. I ran it once before changing my el.ini as needed, and got a segfault. Reverted multiplayer.c to 1.100 (since that doesn't appear to be related to the ati issue). That made the seg fault go away, and... Once I add the #ati_click_workaround = 1 to my el.ini, it works. As you say, this is just a workaround, but at least it's a working workaround.

goliath, is this under linux or windows that your ATI cards work? I've tested on three different Dells with three slightly different ATI cards (one is a laptop even), but all of fairly recent vintage (1-1.5 years old). Under windows, EL works just fine* on all three. Under linux, left click to walk is borked on all three. Also, just for the record, I've tried several different version of the official ATI drivers (inasmuch as ATI has recently been releasing ne Linux drivers relatively often), and the problem exists in all of them. Of course, that doesn't mean it isn't a bug in their drivers, I'm just offering it as a data point. Ent, if you want me to test the patches to CVS that would allow such an entry in el.ini, let me know. Thanks to everyone, especially Grum, for taking the time to guide me through this troubleshooting. * Actually, on the laptop (under windows or linux), every so often, the graphics get totally screwed up, flickering wildly in the EL window and causing a static type look on everything outside the EL window. So far, I've found two solutions to this. The easiest is to reboot the machine, but sometimes I've been able to fix it by moving the EL window around the screen repeatedly until it stops (though it can take a lot of moving to do this). Different bug though, and I recognize that laptop video is a nasty beast, so unless someone reeally wants to talk to me about this, I'll drop it now.

Figured I might as well join the conversation directly. I'm more of a unix sysadmin type, so my experience with C is limited to very basic debugging. As such, feel free to laugh hysterically at anything I have to say with regard to programming (at least in C). I inserted the debug code to print the various GL_* variables within init.c at the end of init_stuff(). The values returned appeared to match Grum's. If anyone else wants a look, I'll be happy to post them here as well. I also wanted to point out that I was able to "fix" the problem by making two changes. First, in interface.c, Grum asked me to replace the get_world_x_y() function with the following: void get_world_x_y() { float float_mouse_z, mouse_z, z; Uint32 int_mouse_z; glReadPixels(mouse_x, window_height-mouse_y, 1, 1, GL_DEPTH_COMPONENT, GL_FLOAT, &float_mouse_z); glReadPixels(mouse_x, window_height-mouse_y, 1, 1, GL_DEPTH_COMPONENT, GL_UNSIGNED_INT, &int_mouse_z); mouse_z = ldexp ((float)int_mouse_z, -bpp); printf ("mouse coords: (%d,%d,%f =? %u/2^%d = %f)\n", mouse_x, mouse_y, float_mouse_z, int_mouse_z, bpp, mouse_z); unproject_ortho(mouse_x,window_height-hud_y-mouse_y,mouse_z,&scene_mouse_x,&scene_mouse_y,&z); } Then, in the beginning of the init_video() function, where it tries to establish a value for bpp, it basically looks for 8 or 16 bpp, and then defaults to 32 (line 236 in the 1.47 revision of gl_init.c becomes "else bpp=24;"). If I change that default to 24 and recompile, I can now walk with the normal left-click again. This made me think that maybe if I just added a test for 24bpp righ tafter the test for 16, it might catch it and work. Nope. it goes right past 24 and defaults to 32 as usual. Obviously this isn't a real fix, since I suspect it would totally screw up most people, but maybe it can point someone toward the real source of the problem (or maybe just the place where the problem can be fixed if it turns out the problem is really with the ATI drivers).

I apologize for chiming in a month later, but I wanted to point out that, as goliath mentioned this came up several times under Bugs. For me, the older client (that is, the release previous to this one) had the flickering problem, but I could walk with a regular left-click. The current version has less flickering (not gone entirely though) and I can only walk with ctrl-right click. I have tried both the "stable" version and compiled from CVS, and neither works. As I offered in the Bugs thread, I'll be happy to help debug this if one of the devs can tell me what I need to run and what options to use (I'm a sysadmin, not a coder, so I rarely use debuggers myself, but I've been using Linux for nearly 10 years and can definitely do what I'm told).

I don't really think this is a major change, especially since hhip indicated that it would stop auto-mixing when you run out of food. The reduction in clicks depends on what item your mixing, but once you're at a mid level, it's probably only saving you 5 or 6 clicks. As such, I don't really have a strong feeling one way or the other. So why post? Because I think everyone could use to understand what makes a strong argument and what doesn't. As such, here's a webpage that talks about logical fallacies. Herny should pay particular attention to 'Slippery Slope", which is what his "next you'll want a button that walks and talks and does everything for you" argument is, and ad hominem (or attacking the person) which is what "why are you so lazy" is.

There seem to be a lot more trading bots these days, and while you could dig through the "declare your bots" thread to try and find them all, I figured it would be better to list them all here. If I'm missing one, or have wrong info, let me know. Adarah - Near Raven in WSC [182,151] Buys and Sells ELMarket - Near fruit stand in Nordcarn [122,86] Buys and Sells MadameYes - Near storage in DP [??,??] Buys and Sells Nera - Near the fruit stand in Portland [174,105] Sells only Linux - Near the port in VotD [59,153] - Rarely on anymore Buys and Sells Quartermaster - In the VotD graveyard [19,111] Sells, Buys only from LOVE guild members Salt - Near the port in DP [346,331] Buys and Sells

Thanks for all the comments. A few responses... 1. higher alchemy level to extract mercury - That seems fine to me. Setting it higher means that whatever it's impact on the economy it won't be as major. 2. Leather gloves - I think a pick axe makes more sense mining the cinnabar, both because it's a crystal and I don't think cinnabar itself poses health risks the way free mercury does. As for needing gloves to extract mercury, I'm not sure how I feel. On the one hand, by the time your at that level in the game, having to wear gloves is more a nuisance than anything else. On the other hand, if your gloves "wore out" from too much handling of mercury, it would increase demand for leather gloves. On the gripping hand (see the jargon file if you don't get the reference), the game doesn't currently require you to wear gloves when you make things that require mercury (like death essences), so would that need to change as well? One of the things I thought about was that mercury should have to be kept in vials (and so you'd have to have vials to extract it), but again that's not how it's currently implemented and so it would probably require more coding to change that. 3. Mercury from silver - I'm not opposed to being able to extract mercury from resources already implemented, I just thought the devs might like the realism of cinnabar / mercury better, but I'm all for letting the devs do whatever is easier when it comes to coding. I'm just a perl monkey and bow before their superior C kung-fu. That said, if the devs do want to set up mercury as a product of a resource already implemented, I would suggest gold over silver because in the European alchemical tradition, that's where most of them spent their energy looking for it (read Stephenson's Baroque Cycle for a long-winded but interesting take on alchemy and gold). 4. Economy impact - There are other threads that address this issue much better, and while I know enough to see that the EL economy is flawed, I don't know nearly enough about economics to pretend to understand what impact my suggestions would have on it. I will say that while being able to extract mercury would reduce demand for spirit essences from NPCs it would increase player-to-player trading of both spirit and death essences. As it is, while I can undercut the prices on death essences, I almost have to know I've got a buyer before it's worth making them, otherwise the risk that I'm stuck with them is too high (unless I'm a mage and can use them myself).

So the whole mercury thing is really bugging me (especially after I realized spirit essences only cost 9gc). So, in the interest of trying to help the designers realistically incorporate mercury production into the game, I did some research. The primary source of mercury is a crystal with a variety of names, but usually called cinnabar, usually a reddish brown color. So, create a new mineral: Name - cinnabar Weight - 3 EMU Harvesting Level - 29 or 30 (would fit nicely between silver and gold) Nexus - Inorganic 2 or 3 Exp given - 30 (again, between silver and gold) Requires pickaxe and cinnabar mining research Mercury is extracted from cinnabar by heating it until the mercury vaporizes and then cooling the mercury vapor back into liquid form. So, create a new alchemy process that produces mercury. This would fit along the lines of metal smelting. For instance, squeezing it between magic essence and iron bar Mercury extraction (which would be another book) Alchemy required - 21 or so Food cost - 10 or 11 Required materials - 5 cinnabar, 3 coals, 2 FEs Experience given - 100 or so Obviously, there are already uses for mercury in the game, but I noticed that in certain forms, mercury is very toxic (obvious given the problem of mercury in our food supply), and has been used as a component of poisons in the past. One possibility would be to use mercury as an ingredient in a poison that you could use to create poison weapons (either they always poison, or you "dip" them for one poison attack). Another possibility, though this is starting to get a little complicated and perhaps unnecessary, is that mercury is often used in extraction of other metals (especially silver and gold) from their ores. You could either use mercury to increase the chance of success during metal bar making, or as a way of requiring less of the given ore. In other words, since the mercury would give you better gold extraction during smelting, you would only need 6 gold ore if you had 1 mercury, or with 1 mercury you'd be less likely to lose ingredients. Just some thoughts. For those interested in the details, this page does a good job of summarizing the various aspects of mercury I'm suggesting.