GnollHack Bug Reports and Issues

hothraxxa

New member
You can also report bugs and issues on this forum, if you prefer to do so.
I prefer to do so.

I just completed sokoban, playing as a samurai. Every time there was a monster on the other side of a boulder, I automatically squeezed past without an opportunity not to do so. This happened six times, each time with a luck penalty. Surely this can't be intended behaviour. Please fix, thanks.
 

Janne Gustafsson

Administrator
Staff member
Hi, this is the way vanilla NetHack works. However, carrying capacity is higher in GnollHack, so squeezing can happen easier. Nevertheless, we will add a yes/no question to choose whether one wants to squeeze as a new feature in the next version of GnollHack, as you suggest.
 

Janne Gustafsson

Administrator
Staff member
Just to confirm, I already implemented the yes/no question for this, and the feature will be part of the next version of GnollHack.
 

hothraxxa

New member
I'm not sure if this is a bug or my lack of understanding of how two-weaponing works. I am a samurai. I have wielded two weapons for a long time with considerably more successful hits than I would need in vanilla, but I am still unskilled. What am I missing?
 

Janne Gustafsson

Administrator
Staff member
Hi, in GnollHack, advancing with two-weapon fighting is currently implemented so that you need to hit successfully 20 times with you left-hand weapon to advance to basic level. In vanilla, this may work differently. I tested this with a samurai in debug mode and it seemed to work as intended. However, if you have a poor skill in your left-hand weapon, you might generally miss with it, compared to successful strikes with your right hand weapon, which do not count in GnollHack.
 

hothraxxa

New member
Hi, in GnollHack, advancing with two-weapon fighting is currently implemented so that you need to hit successfully 20 times with you left-hand weapon to advance to basic level. In vanilla, this may work differently. I tested this with a samurai in debug mode and it seemed to work as intended. However, if you have a poor skill in your left-hand weapon, you might generally miss with it, compared to successful strikes with your right hand weapon, which do not count in GnollHack.
Thanks, I'll try that.
 

hothraxxa

New member
I ascended this morning and bhaak tells me he can't find the xlogfile. Please help, thanks.

Apparently the ttyrec and dumplog indicate a crash before the xlogfile was written. Please fix, thanks. Even if it means a manually created xlogfile. I'd hate to lose the first week of junethack to this bug.
 
Last edited:

Tommi Gustafsson

Administrator
Staff member
I ascended this morning and bhaak tells me he can't find the xlogfile. Please help, thanks.

Apparently the ttyrec and dumplog indicate a crash before the xlogfile was written. Please fix, thanks. Even if it means a manually created xlogfile. I'd hate to lose the first week of junethack to this bug.
We are investigating this matter. It seems that the process crashed in the middle of writing the dump log file without any clear cause. It was able to write the last word as "Leve" and crashed at that point, which is very strange. But we will manually write your data into the xlogfile.
 

Tommi Gustafsson

Administrator
Staff member
@hothraxxa We added manually the ascension now there. We did not know exact points, since the dumplog file was cut off and put 150000 there. Otherwise most of the fields could be discerned from the surviving dump log file fragment.
 

Janne Gustafsson

Administrator
Staff member
@hothraxxa Hi, we will ask our server specialist to look into the root of the problem. It seems almost as if the server run out of disk space, but there's plenty of it left, so it really can't be the reason and thus it is hard to say yet what happened. It seems very odd that the dumplog file could be cut off like that.
 

hothraxxa

New member
I thank you for fixing the xlogfile. The score was not important. I hope to find some time to write a short review in your Initial Impressions thread. even though it says Alpha. Overall, I enjoyed playing but there are some frustrating issues, at least for me.
 

Tommi Gustafsson

Administrator
Staff member
Hi! I checked the dumplog file creation by taking the backup save game file of @hothraxxa's game and replicating the end game in the wizard mode on my local Linux installation. The game was running in the debugger all the time. It worked perfectly each way I tested it:
  1. directly quitting
  2. completing the game by entering the elemental planes and the astral plane and offering the amulet
It did not crash on the dump log file creation and the xlogfile was also written correctly. So, before we can get more ideas what went wrong, it is impossible to fix this bug. The only trace is the error munmap_chunk(): invalid pointer, which was the last message before the crash. It is usually caused by the free function. The only places where I found the free function was this code in end.c starting at line 1541.

Code:
         /* list valuables here */
        for (val = valuables; val->list; val++) {
            sort_valuables(val->list, val->size);
            for (i = 0; i < val->size && !done_stopprint; i++) {
                int typ = val->list[i].typ;
                long count = val->list[i].count;

                if (count == 0L)
                    continue;
                if (objects[typ].oc_class != GEM_CLASS || typ <= LAST_GEM) {
                    otmp = mksobj(typ, FALSE, FALSE, FALSE);
                    discover_object(otmp->otyp, TRUE, FALSE);
                    otmp->known = 1;  /* for fake amulets */
                    otmp->dknown = 1; /* seen it (blindness fix) */
                    if (has_oname(otmp))
                        free_oname(otmp);
                    otmp->quan = count;
                    Sprintf(pbuf, "%8ld %s (worth %ld %s),", count,
                            xname(otmp), count * (long) objects[typ].oc_cost,
                            currency(2L));
                    obfree(otmp, (struct obj *) 0);
                } else {
                    Sprintf(pbuf, "%8ld worthless piece%s of colored glass,",
                            count, plur(count));
                }
                dump_forward_putstr(endwin, 0, pbuf, 0);
            }
        }
It has free_oname(otmp); and obfree(otmp, (struct obj *) 0);.

The error must be before line 1609, where there is dump_close_log();.
 
Top