bluap
-
Content count
2985 -
Joined
-
Last visited
Posts posted by bluap
-
-
RC 2
in General Chat
- Knowledge window: some titles overlap, and moving the mouse near the right border highlight the wrong book: this is due to the use of 240 as "magic" number in knowledge.c (line 139, 161, 188); something like 280 would fix it, or could be better to use the variables containing the stats window size: (STATS_TAB_WIDTH-20)/2 (20 is the scrollbar width *I think*)
Ah, that looks bad. The hightlight should be easy to fix. The overlap more tricky. A bigger window is one option but its already rather big. May be if the title won't fit, it can be but on a line by it's self. That should be doable.
Sorry, misunderstood what you said. Your new numbers fix both issues. Will be in CVS shortly. Thanks.
-
RC 2
in General Chat
- Knowledge window: some titles overlap, and moving the mouse near the right border highlight the wrong book: this is due to the use of 240 as "magic" number in knowledge.c (line 139, 161, 188); something like 280 would fix it, or could be better to use the variables containing the stats window size: (STATS_TAB_WIDTH-20)/2 (20 is the scrollbar width *I think*)
Ah, that looks bad. The hightlight should be easy to fix. The overlap more tricky. A bigger window is one option but its already rather big. May be if the title won't fit, it can be but on a line by it's self. That should be doable.
- Windows on top: if I move some windows (like inventory, ...) and then change the "windows on top" option (doesn't matter if on or off, and happens with the alt+w shortcut too), all the windows go back to their original position
The windows need to save their positions when they get moved (like the url window does). Should be able to fix that one.
- Notepad window: the position of the notepad window is not saved on exit, it always go back to the upper-left corner
That will require changing el.cfg file structure which is easy enough but can cause problems when reading an old format file. I'll happily have a go it we want to do this now.
Edit: All three fixed in CVS now.
-
Can you try to get the values...
Thanks Grum. It's always the second call to draw_water_quad_tiles() that causes the crash and always the three values are all zero. I guess that breaks your conditions. Interestingly, all three values of zero do not always cause a crash and can occur for both calls. The crash only happens on the map change. I added a check for your conditions and could not cause the crash any more. I think you're on to something
-
io/zipfilesystem.hpp
fix:
#include <string.h>
Weird, compiles fine in Linux but looking at the code, it should be there. Anyway, updated in CVS now, thanks.
-
What else needs to be done with the minimap? Or is it finished?
I hope ttlanhil will not mind me jumping in here, he's obviously the expert.
Anyhow, I've been using it walking around and it looks to be working nicely. Previously, there were problems with bits of map getting blanked but that looks to be fixed now. The most obvious things that could easily be finished are to include the fog-of-war circle bmp in the client data package and add a HUD icon to open/close the window. The icon will be a problem on the lowest resolution as we're out of space. The option to keep the window above others is not yet implemented and I could not see any code to display mine information as suggested.edit: Note to self, check others have not posted since starting to reply then going off for tea...
-
If you'd like this change or something similar done, let me know and I'll work on cleaning it up tomorrow.
Well I worked on cleaning it up anyway
I've submitted it as a patch so people can have a look and see if its wanted.
If the storage is open using an NPC, there is no difference.
If it is opened using "#sto" several things are done.
- The inventory is not opened, though it remains open if it was already.
- The window title has (view only) appended to the end.
- The items grid is coloured grey.
- Left clicking to pick up an item is disabled, it just acts like a right click.
- Dragging from the inventory does nothing. Though a sound is played - alert1.
-
For now, I think that the easiest way to ake the client not open the items window is to check if the storage has a "quests" category. That's kind of a dirty hack, but I don't want to change the protocol yet again for this update, since we do not send any flags right now.
I've been experimenting with this and its simple to do. In addition to not opening the items window, you can disable picking up items from storage and also set the title name to something else. I've currently added "(readonly)" to the title bar if it was open using "#sto". Almost all this new code can remain unchanged if another method is used to detect the two types of storage. If you'd like this change or something similar done, let me know and I'll work on cleaning it up tomorrow.
-
Same with imps. I killed one close to NC storage and got the dieing sound. Then i entered storage, left storage, heard the dieing sound again. entered, left, again dieing sound. And so on until the imp respawned.
Piper
The same effect if you walk away from the body until you can't see it then walk back again.
-
This shows that things are fine until size gets big. Here's the last few lines of debug output. Size is mostly zero, often 1 or 5 but can't cope with 19 or more it would appear.
More testing. I've had a crash with size=1. I also note that size can be big and things are fine while walking around the top cave. Size may not be important...
-
While running valgrind chasing another issue I came across use of uninitiated memory in the intersect[].flags array of bboxtree.c. Initialising the array in build_bbox_tree() fixes valgrind but is this the correct thing to do?
Index: bbox_tree.c =================================================================== RCS file: /cvsroot/elc/elc/bbox_tree.c,v retrieving revision 1.49 diff -a -u -r1.49 bbox_tree.c --- bbox_tree.c 1 Aug 2007 17:53:33 -0000 1.49 +++ bbox_tree.c 3 Nov 2007 22:34:40 -0000 @@ -1262,6 +1262,7 @@ bbox_tree->intersect[i].size = 8; bbox_tree->intersect[i].count = 0; bbox_tree->intersect[i].items = (BBOX_ITEM*)malloc(8*sizeof(BBOX_ITEM)); + memset(&bbox_tree->intersect[i].flags, 0, sizeof(bbox_tree->intersect[i].flags)); } bbox_tree->nodes_count = 0; bbox_tree->nodes = NULL;
-
I have a repeatable crash when changing maps from Southern Redmoon Mines [171,110] (top of the stairs) back into the main cave. I have to be facing about due west and zoomed fully out. I'm using latest CVS RC build options, in Linux debian etch. My graphics is a GeForce4 Ti 4200. However, the crash also happens on the same machine using Ubuntu 7.10 and even if I run the windows RC145 under wine. It does not happen on my daughters laptop which uses Intel graphics. So I suspect by graphics card is to blame but bare with me. I'm also crash free if I build without CLUSTER_INSIDES defined.
Neither gdb nor valgrind reveal anything useful so I set about sprinkling the code with printf() and finally tracked it down a glDrawArrays() call at line 763 of reflection.c in the draw_water_quad_tiles() function. I added some extra debug:
Index: reflection.c =================================================================== RCS file: /cvsroot/elc/elc/reflection.c,v retrieving revision 1.123 diff -a -u -r1.123 reflection.c --- reflection.c 2 Oct 2007 07:29:23 -0000 1.123 +++ reflection.c 3 Nov 2007 22:01:47 -0000 @@ -760,7 +760,11 @@ } size++; } +printf("draw_water_quad_tiles final glDrawArrays start=%d stop=%d idx=%d size=%d id=%d\n", start, stop, idx, size, water_id ); +fflush(stdout); glDrawArrays(GL_QUADS, idx * 4, size * 4); +printf("glDrawArrays done\n"); +fflush(stdout); } void draw_lake_tiles()This shows that things are fine until size gets big. Here's the last few lines of debug output. Size is mostly zero, often 1 or 5 but can't cope with 19 or more it would appear.
draw_water_quad_tiles final glDrawArrays start=0 stop=0 idx=0 size=0 id=90 glDrawArrays done draw_water_quad_tiles final glDrawArrays start=489 stop=508 idx=0 size=0 id=90 glDrawArrays done draw_water_quad_tiles final glDrawArrays start=0 stop=0 idx=0 size=0 id=90 glDrawArrays done draw_water_quad_tiles final glDrawArrays start=489 stop=508 idx=0 size=0 id=90 glDrawArrays done draw_water_quad_tiles final glDrawArrays start=0 stop=0 idx=0 size=0 id=90 glDrawArrays done draw_water_quad_tiles final glDrawArrays start=489 stop=508 idx=0 size=19 id=90 Segmentation fault
I'm not familiar enough with openGL calls to know how to proceed but will happily add more debug if it helps.
-
The list according to Roja:...
Thanks Torg. Almost the same as I've been using. Pity SKY_FPV_CURSOR & NEW_WEATHER haven't made it this time they are looking really nice.
-
Has it been decided which features are going into the next release? Specifically which build #define options will be the default? As a Linux user, I'm building my RC client from CVS but I'm not entirely sure which options to use. Is it time to set make.default to the proposed release set?
-
There isn't much we can't do from the server side, so I guess the client window should be made a few lines bigger, especially if we decide to send larger messages in the future.
OK. Just committed to CVS a small change to make the message box larger. You can see the full text of the above message now.
-
It's in berlios already, awaiting approval.
Committed to CVS.
-
The text of the message is sent from the server so it could be modified there. Alternatively, making the box bigger looks to be easier and simpler for the user than adding a scroll bar; though it would need to be 4 or 5 lines longer display the full message. The message text is cleared after a few seconds so having to use a scroll bar to view the text could prove frustrating for the user. Is there a maximum size to the message the server might send?
-
the Tailoring skill comes with 42 exp and requres over 1k to get a level (not sure if intended)There is a fix for this pending upload into CVS.
This was due to nobody removing the temporary data (probably so the client could be used on the main server).
Yeah, I knew that was going to be forgotten. I didn't know the RC was about to arrive otherwise I'd have reminded folks. Anyway, I've removed the fixed values in my build and tried Entropy's formula, it works fine and exp advances to the next levels as expected. Counters work fine too.
-
Technically you shouldn't actually get to that code unless you put 2 comma's but apparently you did. Oh well, I just initialised them to "" and it should be all good.
I've not modified anything accept ~/.elc/sound_warnings.txt and that does not contain any double commas. A quick check though sound_config.xml doesn't reveal any either. Weird.....
-
Well I've found the problem and I can make it work but I think the author of the io/elfile.cpp should check this out. The problem occurs in the el_file constructor when an extra path is specified and the file exists in that path. The call to file_exist_in_dir() returns true but the file is never opened. notes.xml appears to be unique in this. Many other tests are made here for other files but they all fail and the code goes on to try all the paths in path_list; eventually succeeding. If you switch file_exist_in_dir() for open_if_exist(), the notes.xml file opens fine.
Index: io/elfile.cpp =================================================================== RCS file: /cvsroot/elc/elc/io/elfile.cpp,v retrieving revision 1.15 diff -a -u -r1.15 elfile.cpp --- io/elfile.cpp 16 Oct 2007 23:56:52 -0000 1.15 +++ io/elfile.cpp 30 Oct 2007 00:03:59 -0000 @@ -160,7 +160,7 @@ if (!extra_path.empty()) { - if (file_exist_in_dir(extra_path + file)) + if (open_if_exist(extra_path + file, uncompress)) { return; }edit: make the change simpler.
-
Hi Torg. Running valgrid, I noticed a couple of uninitialised read errors in sound.c. Thought you might be interested.
.... ==26809== Conditional jump or move depends on uninitialised value(s) ... ==26809== by 0x80EA1AC: parse_item_image_ids (sound.c:6091) ... ==26809== by 0x80EA265: parse_item_image_ids (sound.c:6116) ... ==26809== by 0x80EA443: parse_tile_types (sound.c:6178) ... ==26809== by 0x80EA504: parse_tile_types (sound.c:6203)
I can supply the full output if you want. I guess you could just initialised your temp[] arrays at lines 6081 and 6168 but it's probably more complex than that
edit: sorry, forgot to mention the uninitialised reads were in the atoi() call.
-
Just noticed this. If you have NEW_FILE_IO defined then the notepad will not load, its fine without. The error log says:
notes.xml:1: parser error : Document is empty ^ notes.xml:1: parser error : Start tag expected, '<' not found ^
If you delete notes.xml and let the client create a new one. The file written looks fine but will not load again giving the same error.
I'm using latest CVS with various options normally but tested with just NOTEPAD - which works OK, and with NEW_FILE_IO and NOTEPAD - which gives the error. I'm on Debian stable + a bit of testing. Other xml loading stuff works fine either way. I'm trying to get my head around how NEW_FILE_IO works but its a bit complex so I've not found the problem yet.
This issue may well be related to previous troubles here.
-
Patch is applied.
Thanks Grum
-
...
One thing I did notice while reading through the patch (not related to the patch, it's been like this for a while), is that NUM_WATCH_STAT is #defined as 13, but we're only watching 12 stats. This leads to all sorts of weirdnesses, like arrays being dimensioned [NUM_WATCH_STAT-1]. I have a feeling we should simply lower ot by one, but would have to dig through all its uses to see if that makes sense.
Yeah, that was on my to-do list but I decided to leave it and pick it up if/when I revisit the skills structure->array issue. I could not work out the benefit of doing it the way it is I must admit. Is the original author still around?
-
I've just submitted a patch for the second part of this work - scrolling the skills statsbar. The statsbar is no longer disabled if space is short, instead only a subset of skills are displayed. You can scroll the block of skills up and down to display different skills. As space was short, I have not added a scroll bar but used the mouse scrollwheel or CTRL+LEFT click (up) CTRL+RIGHT click (down). Hopefully these options are OK for MAC users. A suitable tooltip is shown when scrolling is active and you hover the mouse over the statsbar. If you move the quickbar and display less than the max quickspells, then more skills are displayed in the statsbar.
To make the code easier, I have stored pointers to the required skills information in an array. This allows you to loop over the skills rather than repeat blocks of code with only a few parameters different. This saves a lot of code, minimises cut/paste errors and makes it easier to add new skills. I have confined this changed to hud.c but could do similar elsewhere and probably replace the skills structure with an array. This would be a bigger piece of work but I believe it is worth doing. I'll happily make this change but it would probably best be left until after the next client release.
The Minimap
in Programming
Posted · Report reply
I think so too. I've not experienced any problems in use and it provided a useful function.