4.0.4 bugs

[Pete Mack]

Nick-how'd you get rid of the flicker?

[Nick]

Nick-how'd you get rid of the flicker?

The problem was cross-platform, and it was that the player was being drawn on moving (followed by redraw), and then the panel was shifted and the whole map redrawn. The answer was to test for if the panel was going to shift, and not do the redraw after the player move in that case. A bit hackish, but it seems to work.

[spara]

I'm unable to reproduce this, in the SDL port, either with tiles or ascii, and with various sized windows.

It's only a cosmetic thing anyway. If it's of any use, the font is 8x16x, tile width 4 and tile height 2.

[Hurin]

I'm unsure this is a bug, or I'm doing something wrong, for I'm rather new at the game (platform: Windows 8.1).

When at stores, I can only buy items that are listed to be 2 or more. I.e., only the "buy one" option works, while simple "buy" (option "d") has no effect. "Examine" option always works.

The same at home: if I leave there a single object, I cannot have it back; and if I leave there a number of the same objects, I can then get back all of them minus 1. I.e., again, "take" (option "d") doesn't work, while "take one" and "examine" work.

It is the same both by clicking the option or by typing the letter.

[Pete Mack]

Somewhat repeatable bug:
shooting pebbles at Uvatha, I get failed assertion at line obj-pile.c line 220. I "repeated" it by:
1. Kill Nar in combat.
2. Get breathed on (sound) from out of sight; move 1 square from corner to safety.
3. Teleport away from an Ancient Gold Dragon as it rounds corner.
4. Quaff speed, take on Uvatha with pebbles in ammo slot 0. (I first used !speed, !hero, some phase door, rod of light, rod of illumination.) Crashed on 2nd or 3rd shot.

[Pete Mack]

OK, I have found out what is happening., but not why The integrity check is comparing what is clearly improperly cleared memory of known object and seeing it is not null. Some further values:

i = 128
known_object = 0x202020202020202
cave_k->obj_max = 255

I note as an aside that 128 the overflow value if at some point a char were used as an index in this array. The actual shot has nothing to do with this, since it corresponds to a real value. Rather, it is something that happened elsewhere, and happens to be validated now. Further validation shows that cave_k->object[129] = 0x202020, and further values (i = 130 and beyond) are uncorrupted. Also, 127 is zero while 126 is valid. It's just these two values that are corrupt with what looks like uninitialized memory.
{cut}
Edit: That was NOT the bug. I didn't read the code sufficiently carefully. The bug persists.

[AnonymousHero]

OK, I have found out what is happening., but not why The integrity check is comparing what is clearly improperly cleared memory of known object and seeing it is not null. Some further values:

i = 128
known_object = 0x202020202020202
cave_k->obj_max = 255

I note as an aside that 128 the overflow value if at some point a char were used as an index in this array. The actual shot has nothing to do with this, since it corresponds to a real value. Rather, it is something that happened elsewhere, and happens to be validated now. Further validation shows that cave_k->object[129] = 0x202020, and further values (i = 130 and beyond) are uncorrupted. Also, 127 is zero while 126 is valid. It's just these two values that are corrupt with what looks like uninitialized memory.
{cut}
Edit: That was NOT the bug. I didn't read the code sufficiently carefully. The bug persists.

It might be of interest that 0x20 is 32 which is the space character in ASCII/UTF-8. So maybe some "clear string"-type function is scribbling over known_object?

[Nick]

Somewhat repeatable bug:
shooting pebbles at Uvatha, I get failed assertion at line obj-pile.c line 220. I "repeated" it by:
1. Kill Nar in combat.
2. Get breathed on (sound) from out of sight; move 1 square from corner to safety.
3. Teleport away from an Ancient Gold Dragon as it rounds corner.
4. Quaff speed, take on Uvatha with pebbles in ammo slot 0. (I first used !speed, !hero, some phase door, rod of light, rod of illumination.) Crashed on 2nd or 3rd shot.

Just to clarify - this is in master, not 4.0.4, right?

[Pete Mack]

Yes, it's in master. I should have been clear about that. I will see if I can put a watch point on the array to find out where it becomes corrupt.

[geoff_tewierik]

In 4.0.4, standard Trident was wielded and used to determine it's +'s and found to be a normal item, so it was about to be sent to squelch, but on squelch it came back with this.



As you can see from the dialogue box down the bottom left, it's not an "excellent" weapon.

[Nick]

In 4.0.4, standard Trident was wielded and used to determine it's +'s and found to be a normal item, so it was about to be sent to squelch, but on squelch it came back with this.

This is correct (if counter-intuitive) behaviour - you don't have pseudo-ID on it yet, so it is still technically possible that it's an ego item with (+0, +0).

[spara]

This is correct (if counter-intuitive) behaviour - you don't have pseudo-ID on it yet, so it is still technically possible that it's an ego item with (+0, +0).

This has confused me too, so how would the next idea sound:

* If an item is not thoroughly identified, the ignoring dialogue only gives the possibility to ignore the particular item.

[Nick]

This has confused me too, so how would the next idea sound:

* If an item is not thoroughly identified, the ignoring dialogue only gives the possibility to ignore the particular item.

That sounds sensible.

[Pete Mack]

OK, I found the bug. Can't believe I didn't see it immediately. In obj-pile.c:

@@ -260,15 +260,15 @@ void list_object(struct chunk *c, struct object *obj)
        obj->oidx = c->obj_max;
        for (i = c->obj_max + 1; i <= c->obj_max + OBJECT_LIST_INCR; i++)
                c->objects[i] = NULL;
        c->obj_max += OBJECT_LIST_INCR;        /* If we're on the current level, extend the known list */
        if (c == cave) {
                cave_k->objects = mem_realloc(cave_k->objects, newsize);
                for (i = cave_k->obj_max; i <= c->obj_max; i++)
[COLOR="red"]-                       c->objects[i] = NULL;[/COLOR]
[COLOR="PaleGreen"]+                       cave_k->objects[i] = NULL;[/COLOR]
                cave_k->obj_max = c->obj_max;
        }

 }

Yes, it's in master. I should have been clear about that. I will see if I can put a watch point on the array to find out where it becomes corrupt.

[bertoid]

Door creation bug?

I poked around a bit, but didn't see anything about this: when my ranger is casting "Door creation", a closed door appears in the same square as, and beneath '@'. It remains closed when I move off the square. It also removes any runes of protection, etc. Items are pushed off as normal.

Monsters in adjacent squares are detected, as expected, and no door is created on or under them. I suppose the code is not properly detecting the player's position when creating the door?