4.0.2 Bugs

[Werbaer]

Auotload character from command line:

In 3.5.0, in main_win.c:

static void check_for_save_file(LPSTR cmd_line)
{
    [...]
	/* Set the command now so that we skip the "Open File" prompt. */
	cmd.command = CMD_LOADFILE;
}

In 4.0.0, in main_win.c:

static void check_for_save_file(LPSTR cmd_line)
{
    [...]
	/* Start game */
	game_in_progress = TRUE;
	Term_fresh();
	play_game(FALSE);
	quit(NULL);
}

But take a look at the caller win_main() in main_win.c:

	/* Did the user double click on a save file? */
	check_for_save_file(lpCmdLine);

	/* Set command hook */
	cmd_get_hook = textui_get_cmd;

	/* Set up the display handlers and things. */
	init_display();
	init_angband();

	textui_init();

	initialized = TRUE;

check_for_save_file() is called before the various intialisation functions are executed. The was ok in the past, when it only set a command variable. Now that it tries to run the game immediately, this call needs to be moved after the initialisation is complete.

[Werbaer]

on Windows 7 if I try to automatically load a character by giving a command line of lib\user\save\CharacterName I immediately crash back to the desktop with "angbande.exe has stopped working." Same save file works fine if loaded with the Open command.

I can confirm this behaviour in Windows 10, whether a full path or relative path is given. Moreover, double-clicking on the savefile and then selecting angband to open it with comes up with "Cannot find required file", which looks like file_exists is failing (somewhat disappointing, since we started with the file).

To be able to find the file, you have to use the relative path as command line parameter

lib\user\save\filename

Using the full path, or using just the save file name, or using any file/path combination surrounded by "" doesn't work, and never worked (checked with 3.0.5).

But whether or not the file is found, angband crashes afterwards.

[Nick]

3.5.1 loaded save files through the command line just fine and I think I remember whichever 4.0 beta version I tried doing the same. 4.0.2 is trying to do something with the command line because it shows an error message "cannot find required file: CharacterName" if the specified path/file doesn't exist. Would it be difficult to re-add this function?

OK, I'm up to speed now

I can confirm this behaviour in Windows 10, whether a full path or relative path is given. Moreover, double-clicking on the savefile and then selecting angband to open it with comes up with "Cannot find required file", which looks like file_exists is failing (somewhat disappointing, since we started with the file).

My suspicion is that this is some arcane permissions issue - Windows is usually pretty good with not changing its API, but from 7 on they got more strict with where stuff could be run from, and we may be falling foul of that. Or something.

In any case, I think I'm going to have to file it as a bug, and tell you for now to just use the open dialogue, unless someone comes up with a better solution. I'm sorry if that messes up some system or other.

[troycheek]

As I understand it the Windows port isn't designed to take command line input.

3.5.1 loaded save files through the command line just fine and I think I remember whichever 4.0 beta version I tried doing the same. 4.0.2 is trying to do something with the command line because it shows an error message "cannot find required file: CharacterName" if the specified path/file doesn't exist. Would it be difficult to re-add this function?

Edit: Okay, in main-win.c there's a section for static void check_for_save_file(LPSTR cmd_line) which appears to extract the savefile name from the command line, validate the savefile, and start the game. The code is identical to that which loads a savefile from the in-game menu. I think. I haven't done any serious C coding since the 1980s.

From check_for_save_file:

/* Validate the file */
validate_file(savefile);
/* Start game */
game_in_progress = TRUE;
Term_fresh();
play_game(FALSE);
quit(NULL);

From process_menus, the Open command (case IDM_FILE_OPEN):

/* Load 'savefile' */
validate_file(savefile);
/* Start game */
game_in_progress = TRUE;
Term_fresh();
play_game(FALSE);
quit(NULL);

[Nick]

I don't know if this is new or not, but on Windows 7 if I try to automatically load a character by giving a command line of lib\user\save\CharacterName I immediately crash back to the desktop with "angbande.exe has stopped working." Same save file works fine if loaded with the Open command.

As I understand it the Windows port isn't designed to take command line input.

[troycheek]

I don't know if this is new or not, but on Windows 7 if I try to automatically load a character by giving a command line of lib\user\save\CharacterName I immediately crash back to the desktop with "angbande.exe has stopped working." Same save file works fine if loaded with the Open command.

[PowerWyrm]

Just a little hidden bug when inspecting food. For example:

- a ration of food has a "NOURISH" effect dice of 6000, which increases food counter by 6000
- description is "When eaten, it feeds you for 6000 turns."
- in process_world(), player digests turn_energy(player->state.speed) * 2 food units every 100 game turns
- a player turn occurs every 100 / turn_energy(player->state.speed) game turns
- this means that a player digests 2 food units every player turn
- the description should then be "When eaten, it feeds you for 3000 turns."

Tested with a 4.0.2 character, he goes from Hungry to Hungry again in 3000 standard (player) turns after eating a ration.

Note: this doesn't take into account other influences on food consumption like regen or slow digestion, which also influence the turn count.

Note that all the describe_food() code is now obsolete, since food value is now handled by the effect code.

[PowerWyrm]

equip_notice_after_time() induces useless equipment refreshes and has code that does nothing:

		for (flag = of_next(f, FLAG_START); flag != FLAG_END;
			 flag = of_next(f, flag + 1)) {
			if (!of_has(obj->known_flags, flag)) {
				/* Message */
				flag_message(flag, o_name);

				/* Notice the flag */
				object_notice_flag(obj, flag);

				if (tval_is_jewelry(obj) &&
					 (!object_effect(obj) || object_effect_is_known(obj))) {
					/* Jewelry with a noticeable flag is obvious */
					object_flavor_aware(obj);
					object_check_for_ident(obj);
					apply_autoinscription(obj);
				}
			} else {
				[B]/* Notice the flag is absent */
				object_notice_flag(obj, flag); <-- does nothing because of_has(obj->known_flags, flag) is TRUE[/B]
			}
		}
	}

	/* Notice new info */
	[B]event_signal(EVENT_EQUIPMENT);<-- should only be done if something is noticed[/B]

I would then change this code as follows:

bool redraw = FALSE;

...

		for (flag = of_next(f, FLAG_START); flag != FLAG_END;
			 flag = of_next(f, flag + 1)) {
			if (!of_has(obj->known_flags, flag)) {
				/* Message */
				flag_message(flag, o_name);

				/* Notice the flag */
				object_notice_flag(obj, flag));
                                redraw = TRUE;

				if (tval_is_jewelry(obj) &&
					 (!object_effect(obj) || object_effect_is_known(obj))) {
					/* Jewelry with a noticeable flag is obvious */
					object_flavor_aware(obj);
					object_check_for_ident(obj);
					apply_autoinscription(obj);
				}
			}
		}
	}

	/* Notice new info */
	if (redraw) event_signal(EVENT_EQUIPMENT);

[Timo Pietilä]

You should regen at half the rate - which is what I am seeing in testing.

That's change from when they were introduced. Halving regen rate is OK, makes them useful again.

[Nick]

Ring of Open wounds does not impair HP recovery. I regen HP just fine with one of those on.

You should regen at half the rate - which is what I am seeing in testing.

[Timo Pietilä]

Ring of Open wounds does not impair HP recovery. I regen HP just fine with one of those on.

[PowerWyrm]

Finding Ingwe: "You see a Pendant <+3,+4>." Inspecting it gives info about stats and activation. This doesn't happen with other arts like Arkenstone. Why is jewelry treated differently?

[Nick]

And the hack is unneccessary, since the bug is obvious: monster is not recorded in the temporary message history list when the message is already stored.

Not obvious to me, apparently

Fix implemented.

[PowerWyrm]

OK, this is great. This bug only occurs with multiple meteors hitting multiple monsters of the same type (and for the record, one Dracolich was counted once, and the second one four times). I'm currently working out a fix that doesn't involve a major rewrite of the monster message code

And the hack is unneccessary, since the bug is obvious: monster is not recorded in the temporary message history list when the message is already stored. Fix should be trivial:

	/* Query if the message is already stored */
	for (i = 0; i < size_mon_msg; i++) {
		/* We found the race and the message code */
		if ((mon_msg[i].race == mon->race) &&
			(mon_msg[i].mon_flags == mon_flags) &&
			(mon_msg[i].msg_code == msg_code)) {
			/* Can we increment the counter? */
			if (mon_msg[i].mon_count < MAX_UCHAR) {
				/* Stack the message */
				++(mon_msg[i].mon_count);
			}

	[B]/* record which monster had this message stored */
	if (size_mon_hist >= MAX_STORED_MON_CODES) return (TRUE);
	mon_message_hist[size_mon_hist].mon = mon;
	mon_message_hist[size_mon_hist].message_code = msg_code;
	size_mon_hist++;[/B]
   
			/* Success */
			return (TRUE);
		}
	}

[Nick]

Looking at the latest code, this (gear_excise_object called on an equipped item) can only happen in a specific case: when an equipped torch runs out of fuel.

Could also happen when selling an equipped item, in fact, and possibly other uses of gear_object_for_use(). No need to check, though as your fix covers it all.