Ezeril

I'm running WinXP Pro... mainly because, thanks to the CS dept. at my old university, and the MS developer network, I got it completely free! *evil laughter* Haven't bothered changing the theme though heh.

The server sends back GET_ACTOR_HEAL with argument -5. The client code reads this number as an 8-bit unsigned integer, which translates to 251 ( 0xFB = -5 signed = 251 unsigned). (Edit: apparently I've lost the ability to do basic arithmetic in my head <_< )

I hear ya, Alox... during my last year or so in college I was considering giving up technology and living in the Himalayas. Well... ok, so not really... but I sure wasn't about to write any more code than I had to. Now I just have way too much free time.

I checked Restoration for the bug (with the help of a blessing from Unolas ), and you can heal yourself for a negative amount with Restoration also.

I'm a recent graduate and unemployed... figured I'd post even though I'm not really one of the developers for the game (OpenGL code tends to make me spew profanities at my monitor ) Still looking for that first career job...

I'm pretty sure this bug happens just because the get_actor_heal() function reads the quantity to heal as an unsigned 8-bit number, which means it reads -5 as 251, hence the huge health bar appearing in the client. Just change the get_actor_heal() function prototype and definition to use a signed type instead of Uint8 and the bug disappears. Or, change the server code so that you can't heal yourself for a negative amount The negative heal happens when your current health is higher than your max health, and you heal yourself with the basic Heal spell. This problem does not occur if you are healed by Remote Heal. I haven't been able to verify if the same happens with Restoration (mainly because my magic level is only 19 )

There isn't much of a client-server protocol for "storage" atm The client builds the NPC dialogues with the appropriate options, and sends a response when the user clicks on an option. If you withdraw/deposit something, the server sends back a REMOVE_ITEM_FROM_INVENTORY message if the deposit completely removes an item (i.e, you deposit all of that item that you have), or a GET_NEW_INVENTORY_ITEM message otherwise. A client-side-only implementation of a new storage system wouldn't really be the best option, but I think it could be done... First, you'd have to check every SEND_NPC_INFO message from the server to determine if it's for a storage merchant (this is the first message received when opening a dialogue), by the name sent back. If it is for a storage merchant, then you'd have to catch the next message (NPC_TEXT), and display the new storage screens instead of a normal dialogue window. The next message (NPC_OPTIONS_LIST) could be left alone, since letting build_response_entries() parse the data in this message is probably best. The array it works with could then be used by the new storage screenies, just like normal dialogues do. The most impractical part is sending back the appropriate RESPOND_TO_NPC messages, since they would have to follow the same flow as if the client were still using the old dialog storage system. This means that you either have to somehow catch, insdie the click handler, the NPC_OPTIONS_LIST response for each RESPOND_TO_NPC message sent to the server, so you could obtain the next set of response_ids from it and know what to send back, or you would have to figure out the response_ids for every possible option, include these ids in the client somehow (either in an external file or by hard-coding them), and send off the RESPOND_TO_NPC messages while ignoring the responses (which may not be a good idea). All in all, this just isn't worth it for a new storage system. I think it would really be best to wait until the devs have time to provide server-side support for the new storage system. (On a more positive note: I like that design as well, MoonShadow) BTW: I could be wrong about some (or all) of this, I'm by no means an expert on the client code, this is just what I think goes on, from reading the code and doing some tracing with the client running.

Thought about that too, but then some newer players might think it's all one quickbar at first... Anyways, here's what that would look like: It does look nice, I'm just concerned about usability for new players... they may not use the magic quickbar that much (or at all) as newbies, but they might use the items one. Then again, it might not be a problem at all *shrug*

Ya... that will happen for lower resolutions (I'm guessing you run at 800x600 windowed mode?). I could cram both quickbars into the original hud frame, I just thought it would put the quickbars too close together. Here's what it would look like: Of course, if you run at 640x480 (windowed or full-screen) it's not a problem, because the exp bar doesn't show up at all, even with the normal hud frame width

Actually, that error will appear in your error_log.txt even if you have the e3dlist.txt file, provided you visit Isla Prima. The reason that error appears is that the Isla Prima map (startmap.elm) references the grass5.2d0 object for some reason. (IP is the only map that references this object, I went through every map file with a hex editor and checked). The fact that it's missing isn't a critical error though. Whoever wrote the part of the client code dealing with loading all of the .2d0 files a map needs (I won't post exact code unless someone asks), made sure that missing .2d0 files would not crash the client. I'm not saying that new people having problems shouldn't check to see if they have the e3dlist.txt file... I'm just saying that this file is not the reason for the "Error: Can't load 2d object: ./2dobjects/ground/grass5.2d0" message.

The game actually crashes because of this error? I looked through the source code for versions 1.0.0 and 0.9.9, the fact that this file is missing will not cause the official client to crash. Does the program window just close immediately after you run EL, or does an error dialog also pop up (something like "This application has performed an illegal operation and must terminate.. yadda yadda")? (BTW: I'm also running WinXP, Pro edition, EL works fine with it). Of course, this raises a vaguely interesting question... why is the Isla Prima map referencing an object that doesn't exist? I went through every map with a hex editor, IP is the only map that uses this object. Was it removed/replaced at some point and someone simply forgot to edit the IP map accordingly? It's not a critical issue, I'm just curious.

I apologize for all this mess (flaming CVS n00b here). Did my homework this time, made a diff the proper way, then tested it against a fresh copy of the source from CVS (checked it out to a new directory with CVS, applied the diff with patch, compiled it, ran it from the main EL directory). There was one failed hunk but it's not critical... in fact, it's not even a real change... Anywho, the new patch is up on BerliOS, and the two new files (quickcast.c and quickcast.h -- things the quickbar needs that seemed out-of-place in hud.c) can be found here. (Edit: I've been working on this code in VS.NET (compiling as C code), don't know if that's going to be a serious issue for those working in Dev-C++.)

*sigh*... it appears my photobucket kicked the bucket... but I did just discover that my University lets alumni keep their old web directories, so, once again, here's the texture file.

If you switch video modes while playing, init_peace_icons() is called and will add more icons onto the end of the current set instead of redrawing them. This is easy to fix however. This line just needs to be in init_peace_icons() (at around line 247 in v1.58): icons.no=0

Ok, the patch is up on BerliOS now. I had to make the hud frame just a tiny bit wider to fit the magic quickbar in. I also rewrote init_quickbar and display_quickbar_handler so that they can be used for both quickbars. click_quickbar_handler was just too different to try and make generic, so the magic quickbar still has its own separate click handler. Also, here is the .bmp for the spell icon textures (this should go in the textures folder), and I'm posting the contents of the text file containing the spell information below (this file goes in the main directory): 14 Heal 0 2 3 23 Remote_Heal 1 3 9 3 23 Magic_Protection 2 3 19 17 21 Shield 3 3 19 15 21 Poison 4 3 5 4 24 Teleport_to_Range 5 4 7 0 8 2 Harm 6 2 22 23 Restoration 7 2 1 24 Bones_to_Gold 8 3 6 0 15 Teleport_to_Portals_Room 9 4 7 0 9 2 Life_Drain 10 3 7 0 24 Magic_Immunity 11 4 19 3 17 21 Heal_Summoned 12 4 8 2 23 14 Smite_Summoned 13 4 8 2 22 24 The first line is the total number of spells (so I can dynamically allocate the array of structs holding all this junk) The format of the following lines is: name image_id number_of_sigils sigil1 sigil2 [sigil3...] The sigil numbers are the same numbers sent in a CAST_SPELL message. The name is there for future use, since it might be nice to have the name of the spell in a quickbar slot appear as a tooltip. (Edit: changed the link for spells.bmp to a copy on a less-flaky server.)