4.0.4 bugs

[tprice]

Well i just downloaded the new version onto my Windows 7 machine, copied over my 4.0.3 user directory, and found a repeatable crash bug my first trip back to town.

i was doing a bit of inventory management in town and went to drop a stack of staves of ID inscribed with what i thought was just !k!d!v (aka don't do something stupid) and it would crash the game every time i tried to drop 1 or more of them... Turns out when i looked closer i had a leading space in the inscription. re-inscribing correctly fixed the crash.

error text is
assertion failed!
program: _
File: z-textblock.c
line 115
expression: new_length >= 0

a zip file with the save file and a screenshot of the error is attached.

Thomas Price
aka The Bookworm

[tprice]

lets try that attachment again this time paying attention to the file size limits and cropping the error message screencap

Thomas Price
aka The Bookworm

[Nick]

Thanks for the savefile. Also, thanks for providing the ideal first bug - genuine bug, reproducible, gets the bug thread started, but not going really going to affect the playing of this version too much

[PowerWyrm]

Sorry, but I've found another bug while playing the PWMAngband comp character and I've managed to reproduced it with the Angband code.

First, get a spellcaster which wields a weapon that improves its primary stat (INT for a mage, WIS for a priest...). Then put in your inventory a weapon that does NOT improve its primary stat. Then inspect that weapon. After you get back to the main screen, the character will have its mana reduced...

Looking at the code, this happens because inspecting something calls calc_bonuses() just the same way it calls it while truly updating the bonuses. And calc_bonuses() now calls calc_mana() which modifies max mana. The fix is then trivial, just add a parameter to calc_bonuses() that tells if the subfunctions should alter the player structure (update) or not (object info), and only alter it if that parameter is TRUE.

calc_torch(): don't update the visuals, just calculate state->cur_light
calc_mana(): don't update the mana, just calculate state->cumber_glove and state->cumber_armor

[luneya]

Sorry, but I've found another bug while playing the PWMAngband comp character and I've managed to reproduced it with the Angband code.

First, get a spellcaster which wields a weapon that improves its primary stat (INT for a mage, WIS for a priest...). Then put in your inventory a weapon that does NOT improve its primary stat. Then inspect that weapon. After you get back to the main screen, the character will have its mana reduced...

Looking at the code, this happens because inspecting something calls calc_bonuses() just the same way it calls it while truly updating the bonuses. And calc_bonuses() now calls calc_mana() which modifies max mana. The fix is then trivial, just add a parameter to calc_bonuses() that tells if the subfunctions should alter the player structure (update) or not (object info), and only alter it if that parameter is TRUE.

calc_torch(): don't update the visuals, just calculate state->cur_light
calc_mana(): don't update the mana, just calculate state->cumber_glove and state->cumber_armor

If I'm reading how this works correctly, the workaround until a fix is released is just to reinspect your wis/int-bonus weapon, yes? For that matter, it should hypothetically be possible to abuse this bug by keeping a crappy item with int/wis bonus in inventory and just inspecting it to fool the game into giving you more mana, right?

[PowerWyrm]

If I'm reading how this works correctly, the workaround until a fix is released is just to reinspect your wis/int-bonus weapon, yes? For that matter, it should hypothetically be possible to abuse this bug by keeping a crappy item with int/wis bonus in inventory and just inspecting it to fool the game into giving you more mana, right?

Unfortunately not, because only the max mana is recalculated. So if you have 100/100 mana and you inspect something that drops it to 30/30, once you redraw your screen, you have 30/100 mana. If you have 30/30 mana and you inspect something that increases it to 100/100, once you redraw your screen, it is back to 30/30.

[Ingwe Ingweron]

A very minor bug. When you first encounter a monster, say a sleeping unique, target it and then use the 'l'ook command to figure out what the monster's vulnerabilities and dangers are, the "more" prompt appears in the middle of the title description line for the monster. If you 'l'ook again, the problem has resolved itself. Happens with each new monster encountered.

[Ingwe Ingweron]

This one's not necessarily a bug, but I've never understood it. A drolem (a constructed dragon) fires a missile? @ receives the message, "The drolem fires a large arrow." How is it that a dragon, constructed though it may be, is firing a large arrow?

[Derakon]

This one's not necessarily a bug, but I've never understood it. A drolem (a constructed dragon) fires a missile? @ receives the message, "The drolem fires a large arrow." How is it that a dragon, constructed though it may be, is firing a large arrow?

It has a ballista in its mouth alongside the Zyklon-B dispensers.

[Ingwe Ingweron]

It has a ballista in its mouth alongside the Zyklon-B dispensers.

Ah, got it. Makes perfect sense now. It's not a Frankenstein's monster like the other golems, it's a robotic dragon! Hmm, I bet Debo would have it shooting rockets!

[PowerWyrm]

There's a potential bug I've found while fixing slay/brand power for my variant: slay cache probably doesn't work.

        int tot_mon_power = 0;

        ...

	/* Look in the cache to see if we know this one yet */
	sv = check_slay_cache(obj);

        /* If it's cached (or there are no slays), return the value */
	if (sv)	{
		log_obj("Slay cache hit\n");
	} else {
                ...
                /* Add up totals */
		tot_mon_power += mon->race->scaled_power;
	}

	q = (dice_pwr * (sv / 100)) / (tot_mon_power / 100);

If it's cached, tot_mon_power is not set... so the calculation of q should crash with a division by zero error (that's what's happening in my variant). No idea why it's not the case in V.

[PowerWyrm]

In my code, slay cache doesn't work because the cache is filled/checked from "fake" artifacts which don't have their slays/brands known. I've fixed that simply by calling object_know_brands_and_slays() inside make_fake_artifact().

[PowerWyrm]

In my code, slay cache doesn't work because the cache is filled/checked from "fake" artifacts which don't have their slays/brands known. I've fixed that simply by calling object_know_brands_and_slays() inside make_fake_artifact().

Another reason why the slay cache doesn't work...

s32b check_slay_cache(const struct object *obj)
{
	int i = 0;

	while ((slay_cache[i].brands != NULL) && (slay_cache[i].slays != NULL)) {
		if (brands_are_equal(obj->brands, slay_cache[i].brands, TRUE) &&
			slays_are_equal(obj->slays, slay_cache[i].slays, TRUE)) 
			break;
		i++;
	}

	return slay_cache[i].value;
}

bool fill_slay_cache(const struct object *obj, s32b value)
{
	int i = 0;

	while ((slay_cache[i].brands != NULL) && (slay_cache[i].slays != NULL)) {
		if (brands_are_equal(obj->brands, slay_cache[i].brands, TRUE) &&
			slays_are_equal(obj->slays, slay_cache[i].slays, TRUE)) {
			slay_cache[i].value = value;
			return TRUE;
		}
		i++;
	}

	return FALSE;
}

Cache entry doesn't need to have BOTH slay and brand... so in that case the first function returns an invalid entry and the second one returns FALSE. The fix is trivial, replace "&&" in both "while" statements by "||".

[Nick]

Cache entry doesn't need to have BOTH slay and brand... so in that case the first function returns an invalid entry and the second one returns FALSE. The fix is trivial, replace "&&" in both "while" statements by "||".

That's what happens when I get away from that nice neat 3.5.1 code

Thanks, that will get fixed some time - happily the two bugs cancel each other out and it's only really an efficiency thing for V (if I understand correctly).

[Ingwe Ingweron]

Not a bug, necessarily, but the random name generation starting a new human mage character just popped up "Sauron". Seriously?! Hmmm, maybe the RNG knows something I don't.... Guess it could have been worse, it could have come up with "Morgoth"!