Preparing for 4.2 release

[Nick]

Originally Posted by emar

Yeah, it does--it also fixes the pathfinding halting when it encounters a visible trap square by treating it as invalid path square.

(Also, please let me know if I did anything wrong in the process; I'm new to contributing to projects.)

All looks great. I'm going to do an updated build fairly soon, and I'll pull your stuff in then.

[Nick]

New builds now up on the nightlies page and angband.live with the following changes:

• Shockbolt tiles for the new foods (if someone wants to do something about the other tilesets, great)
• Fixes to SDL2 submitted by fumsoft
• Several fixes to pathfinding - thanks emar
• Finished updating help (apart from thanks, which gets done right before release)
• Adjust high elf XP factor to 145% (vs 100 for humans and 120 for everyone else)
• Make the trap immunity rune register properly
• Enlarge the character display for resists, abilities etc in both 'C' screen and character dumps
• Correct some unique drops (thanks Voovus)
• Don't display XP for killing monsters which only appear as a shapechange in monster lore (Voovus again)
• Make !Surprise actually capable of scrambling stats (thanks Chud, and sorry if I spoiled anyone's surprise)
• Fix dead monster display bug (thanks PowerWyrm)
• Make =Escaping only +2 speed, ,Shadows more common

Interested as always in opinions, especially on the character display.

[Vorczar]

I like the new character expanded screen.

I picked up a wicker shield on Angband.Live with "makes you slow to recover hit points".
I would expect a + in the ImpHP but nothing was there.

[Nick]

Originally Posted by Vorczar

I like the new character expanded screen.

I picked up a wicker shield on Angband.Live with "makes you slow to recover hit points".
I would expect a + in the ImpHP but nothing was there.

It seems the shield has the "impair hitpoint recovery" curse, which gives an item the "impaired hitpoint recovery" property. Both curse and property are runes you can learn; it is the property that displays on the ImpHP line.

What *should* happen is that when you learn the curse you learn the property. Could you check the knowledge menu ('~') for runes and se whether you have both? The curse is under "Curses", the property under "Other".

[Vorczar]

Originally Posted by Nick

It seems the shield has the "impair hitpoint recovery" curse, which gives an item the "impaired hitpoint recovery" property. Both curse and property are runes you can learn; it is the property that displays on the ImpHP line.

What *should* happen is that when you learn the curse you learn the property. Could you check the knowledge menu ('~') for runes and se whether you have both? The curse is under "Curses", the property under "Other".

Thanks!
I didn't know about the Runes knowledge menu. Cool.
They're both there.

[PowerWyrm]

I thought I'd post this here. It's a little function that I added while porting the struct loc refactoring to PWMAngband to make some code clearer. Here it is:

bool loc_iterator(struct loc *iter, struct loc *grid1, struct loc *grid2, bool strict)
{
    iter->x++;
    if (iter->x == (strict? grid2->x: grid2->x + 1))
    {
        iter->x = grid1->x;
        iter->y++;
        if (iter->y == (strict? grid2->y: grid2->y + 1)) return false;
    }
    return true;
}

This allows to change the following code:

for (y = y1; y < y2; y++) {
for (x = x1; x < x2; x++) {
foo(y, x);
}
}

into:

loc_copy(&iter, &grid1);
do {
foo(&iter);
} while (loc_iterator(&iter, &grid1, &grid2, true)); (or "false" to do "<=" instead of "<")

I've removed most of the ugly x/y loops that way.

[Nick]

Originally Posted by PowerWyrm

I've removed most of the ugly x/y loops that way.

What a great idea! Now I can go and implement that all over the place instead of fixing bugs

[takkaria]

Originally Posted by PowerWyrm

I thought I'd post this here. It's a little function that I added while porting the struct loc refactoring to PWMAngband to make some code clearer. Here it is:
...
I've removed most of the ugly x/y loops that way.

Nice. Though I think it would be clearer if split into loc_iterate_inside and loc_iterate instead of passing a flag. (Also, you can just write iter = grid1 instead of loc_copy, surely?)

[Kusunose]

It's nice but I think something like this is nicer because you can keep using for loop, though bit wordy.

struct loc_iterator {
	struct loc cur;
	struct loc begin;
	struct loc end;
};

struct loc_iterator loc_iterator(struct loc begin, struct loc end)
{
	struct loc_iterator iter;
	iter.cur = iter.begin = begin;
	iter.end = end;
	return iter;
}

bool loc_iterator_test(const struct loc_iterator* iter)
{
	return iter->cur.y != iter->end.y;
}

void loc_iterator_next(struct loc_iterator* iter)
{
	iter->cur.x++;
	if (iter->cur.x == iter->end.x) {
		iter->cur.x = iter->begin.x;
		iter->cur.y++;
	}
}

This code

	for (y = y1; y < y2; y++) {
		for (x = x1; x < x2; x++) {

can be translated as

	for (struct loc_iterator iter = loc_iterator(loc(x1, y1), loc(x2, y2));
		loc_iterator_test(&iter); loc_iterator_next(&iter)) {
			/* use iter.cur */
			int x = iter.cur.x;
			int y = iter.cur.y;

and this

	for (y = y1 - 1; y < y2 + 1; y++) {
		for (x = x1 - 1; x < x2 + 1; x++) {

can be translated as

	for (struct loc_iterator iter = loc_iterator(loc(x1 - 1, y1 - 1), loc(x2 + 1, y2 + 1));
		loc_iterator_test(&iter); loc_iterator_next(&iter)) {

Values for initializers and conditions can be directly translated, provided conditions are exclusive (if inclusive, add +1 for x and y for loc end).

[Pete Mack]

Too bad C doesnt have anonymous functions. Then you could package up the loop contents in a function, and execute the whole thing with a single subroutine call.