Implementing the restructure changes

[PowerWyrm]

Only the v4 effect descriptions to merge, then it's intensive test time. Beta version should follow as soon as the MAngband forums are back online.

[PowerWyrm]

Everything from 4.0 is now ported to PWMAngband. It took me only eight months...

Now it's time to fix the innate PWMAngband bugs, in particular the ones related to object index hacks that I had to add to be able to transfer object data between client and server.

[Nick]

descend_to is set to dungeon_get_next_level(player->depth, 1), which is not correct for force descent. It should be set to (player) max depth + the increment: dungeon_get_next_level(player->max_depth, 1). The check vs (dungeon) max depth is done in dungeon_get_next_level(), so the second one is not needed.

Oh, yeah, right.

[PowerWyrm]

For this one descend_to is already set, and we also need to do the max_depth check properly, so I think it should be:

	/* Warn a force_descend player if they're going to a quest level */
	if (OPT(birth_force_descend)) {
		if (is_quest(descend_to) &&
			!get_check("Are you sure you want to descend?"))
			return;

		/* Don't overshoot */
		descend_to = MIN(descend_to, z_info->max_depth - 1);
	}

The others were all spot on, thanks - I especially liked the failed trap door message

descend_to is set to dungeon_get_next_level(player->depth, 1), which is not correct for force descent. It should be set to (player) max depth + the increment: dungeon_get_next_level(player->max_depth, 1). The check vs (dungeon) max depth is done in dungeon_get_next_level(), so the second one is not needed.

[Nick]

- do_cmd_go_down(): force_descent will make you go down to (max_depth + stair_skip) by recall, but here (by stairs) it's set to (max_depth + 1)

	/* Warn a force_descend player if they're going to a quest level */
	if (OPT(birth_force_descend)) {
		descend_to = dungeon_get_next_level(player->max_depth, 1);
		if (is_quest(descend_to) &&
			!get_check("Are you sure you want to descend?"))
			return;
	}

For this one descend_to is already set, and we also need to do the max_depth check properly, so I think it should be:

	/* Warn a force_descend player if they're going to a quest level */
	if (OPT(birth_force_descend)) {
		if (is_quest(descend_to) &&
			!get_check("Are you sure you want to descend?"))
			return;

		/* Don't overshoot */
		descend_to = MIN(descend_to, z_info->max_depth - 1);
	}

The others were all spot on, thanks - I especially liked the failed trap door message

[PowerWyrm]

Just a note. The link in your signature line isn't working.

I know. I'm using MAngband forums, which are currently down because the server hosting them crashed. While MAngband admins fix the problem, you can use roguebasin's PWMAngband page.

[Ingwe Ingweron]

Just a note. The link in your signature line isn't working.

[PowerWyrm]

Commit e86784 (stair skip):

This has a couple glitches, I'll give a proposed fix for each one:

- dungeon_get_next_level(): test for max depth is made on z_info->max_depth, which is max depth + 1 (128)

	/* Don't allow levels below max */
	if (target_level > z_info->max_depth - 1) 
		target_level = z_info->max_depth - 1;

- do_cmd_go_down(): force_descent will make you go down to (max_depth + stair_skip) by recall, but here (by stairs) it's set to (max_depth + 1)

	/* Warn a force_descend player if they're going to a quest level */
	if (OPT(birth_force_descend)) {
		descend_to = dungeon_get_next_level(player->max_depth, 1);
		if (is_quest(descend_to) &&
			!get_check("Are you sure you want to descend?"))
			return;
	}

- effect_handler_TELEPORT_LEVEL(): another check on player->max_depth + 1

	int target_depth = dungeon_get_next_level(player->max_depth, 1);

	...

	/* No forcing player down to quest levels if they can't leave */
	if (!up && is_quest(target_depth))
		down = FALSE;

- effect_handler_TRAP_DOOR(): if on a quest level, nothing happens, you should not get any message

bool effect_handler_TRAP_DOOR(effect_handler_context_t *context)
{
	int target_depth = dungeon_get_next_level(player->depth, 1);
    
        if (target_depth == player->depth)
        {
            msg("You feel quite certain something really awful just happened...");
            return TRUE;
        }

        msg("You fall through a trap door!");
	if (player_of_has(player, OF_FEATHER)) {
		msg("You float gently down to the next level.");
	} else {
		int dam = effect_calculate_value(context, FALSE);
		take_hit(player, dam, "a trap");
	}
	equip_notice_flag(player, OF_FEATHER);

	dungeon_change_level(target_depth);
	return TRUE;
}

- effect_handler_DEEP_DESCENT(): target depth was changed in process_world(), but not here

	int target_increment, target_depth;

	/* Calculate target depth */
	target_increment = (4 / z_info->stair_skip) + 1;
	target_depth = dungeon_get_next_level(player->max_depth, target_increment);

[PowerWyrm]

What about ON-hand brands/slays? E.g., Gloves dripping with acid. Currently, bare-handed @ combat wearing such gloves makes no difference to the punch damage. You'd think getting hit in the face with a gloved fist dripping in acid would make a difference. So glad you're doing this! Hoping Nick will port it into Angband. Having done a "fists-only" challenge, this is one of the changes for fists that I was begging for. The other is the chance for a critical-hit with fists. A shot to the liver or kidney or throat or taking out an eye should be a critical hit! Maybe by giving fists some pre-defiined "weight" considering momentum would solve this?

PWMAngband has Monks. That's mainly the reason I'll do this. Monks already get special martial arts moves (punches, kicks -- even a special "hit in the groin" attack when facing male opponents) which have specific attack dices and effects (slow, stun...), and I want them wearing brands items give extra damage from those brands.

[Ingwe Ingweron]

- apply offhand brands/slays to barehanded attacks (fists of flame!)

What about ON-hand brands/slays? E.g., Gloves dripping with acid. Currently, bare-handed @ combat wearing such gloves makes no difference to the punch damage. You'd think getting hit in the face with a gloved fist dripping in acid would make a difference. So glad you're doing this! Hoping Nick will port it into Angband. Having done a "fists-only" challenge, this is one of the changes for fists that I was begging for. The other is the chance for a critical-hit with fists. A shot to the liver or kidney or throat or taking out an eye should be a critical hit! Maybe by giving fists some pre-defiined "weight" considering momentum would solve this?

[PowerWyrm]

Everything up to Sep 6, 2015 ported (Angband 4.0.2 release). Almost done...

Once the remaining changes are ported (which should be fast, since most of them come from this thread), I'll start to tackle the problems I've found on the way:

- "your Identify glows yellow" when zapping a rod of identify (special activation message in PWMAngband)
- client crash when drinking from a fountain (PWMAngband)
- pseudo-3d tiles not properly erased when entering a store (PWMAngband)
- prices not shown in magic shop for wands of confuse monster and some other items (no idea why -- not happening in latest Angband)
- options '/', '|' and '-' should not be shown if nothing equipped, in inventory, in quiver or on floor (#1846 -- I think this should be reverted)
- inspecting an item doesn't work on equipment (PWMAngband -- problem with object index on client)
- can't put on a ring with 2 rings already equipped (PWMAngband -- problem with object index on client)
- merge v4 effect descriptions (PWMAngband/Angband v3.5 had different effect descriptions, I didn't port the new ones yet because I kinda liked the old ones)
- apply offhand brands/slays to barehanded attacks (fists of flame!)
- generate new 750ft town (PWMAngband base town is special and I didn't have the opportunity to use the new Angband town layout yet -- I'll use that to create the town at 750ft for ironman servers)
- equipment, inventory and quiver lists are ugly when displayed in shops (I made a special case and didn't use menus while in a shop -- I'll probably switch to menus)
- arrow keys don't switch equipment/inventory/quiver/floor (probably missing something when porting the feature)

[Nick]

Just a little problem with Git commit browser: for the second time after commit ac4af8, I'm unable to see the whole change list for commit 147d55 because it's too big. I'm just gonna assume that this change removes all typedefs for structures and replaces xxx_ptr by something more obvious. For future reference, I think it would be nice to split big changesets so that this doesn't happen.

Assumption correct. I did get a bit carried away with this one - so many of these changes had been done in dribs and drabs I just got sick of it and decided to do the rest in one go. I usually try to restrain myself.

BTW, command line git on linux has no problems seeing those whole commits

[PowerWyrm]

Just a little problem with Git commit browser: for the second time after commit ac4af8, I'm unable to see the whole change list for commit 147d55 because it's too big. I'm just gonna assume that this change removes all typedefs for structures and replaces xxx_ptr by something more obvious. For future reference, I think it would be nice to split big changesets so that this doesn't happen.

[AnonymousHero]

I'm really impressed! I'll be sad when you stop posting to this thread, it's been fun watching your progress...

+1. This has been incredible to lurk along on.

[Nick]

Everything ported up to Jun 28, 2015. This means up to the 4.0.0 release, with only two pages of changes left... I've got a large list of things to fix though, hoping some (or most) of them will be fixed by the latest changes.

OK, I think master now has everything in this thread fixed, aside from #1867 which has been reopened.