4.0.2 Bugs

[Estie]

Great! Time to load up another game. Thanks.

[MattB]

There are still a few outstanding bugs. I won't be doing much on them in the next couple of weeks, but after that am planning to clean them up (along with any new ones) and release 4.0.3.

What about the age-old bug of the game forgetting how big your tiles are every time you load up (certainly for Shockbolt at least)? Not a biggie, by any means, but mildly irritating.

[PowerWyrm]

My latest findings (see http://angband.oook.cz/forum/showthread.php?t=7196):
- didn't find commit f9d645 from pull request #400 in the latest source (fix monster movement up-is-down issue), intended?
- pull requests #401 and #403 are still there, but changes seem to have already been implemented
- "command_menu" in ui-context is never freed
- commit 8e96eb changed balance drakes from color 'v' to 'V'; why not use color 'P', which is used for Great Wyrm of Balance?
- in player_outfit(), the cost of the added object is deducted from the starting cash, which could crash if for any reason the object is absorbed
- copy/paste error in parse_room_height(), the width is checked instead of the height
- if you stand on a pile of items, select one (with 'e' or 'i' and then '-') and press 'g' from the context menu to pick it up, the game asks you again which item on the floor you want to pick up
- effects like fire ball from a wand of fire balls are IDed even when blind
- effect projection is partly shown when blind
- if you have nothing in your quiver and you press 'e' then '|' then an arrow key (up or down), the game hangs

[PowerWyrm]

#1846: Empty quiver should show

On 'i' and 'e' commands, '.' is an option for show quiver, but it silently does nothing if the quiver is empty.

Sorry, but the new behavior is IMHO a bug, not the old one. If you have nothing equipped or in the inventory or in the quiver and you press 'e', 'i' or '|', you get a message. If you have nothing in the quiver (or on the floor for the same reason), nothing should be shown. Currently, you get an ugly empty screen (or worse, a screen full of nothings that crashes if you move inside). The option should not even be shown in the prompt.

[dnabgnayalpem]

Crash Bug in 2-12-gaf73c58 nightly

Have there been any Crash Bugs that have been fixed as of nightly 4.0.2-12-gaf73c58?

I just experience one at DL9 with the above nightly, while looking at a green wisdom damaging jelly. Was just reading the text, don't know why it crashed.

If no crash bug has been fixed since that nightly, I'll post a crash dump next time it happens. But this is what I copied:

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000001aa2
Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   org.rephial.angband           	0x00000001000a95a8 target_set_interactive_aux + 3672
1   org.rephial.angband           	0x00000001000a7dbf target_set_interactive + 2911
2   org.rephial.angband           	0x0000000100091108 do_cmd_look + 24
3   org.rephial.angband           	0x000000010008a86b textui_process_command + 251
4   org.rephial.angband           	0x000000010008a8be textui_get_cmd + 14
5   org.rephial.angband           	0x000000010008abaa play_game + 266
6   org.rephial.angband           	0x00000001000b8fe4 +[AngbandContext beginGame] + 1668
7   org.rephial.angband           	0x00000001000bc19d -[AngbandAppDelegate applicationDidFinishLaunching:] + 29
8   com.apple.Foundation          	0x00007fff8642cad5 _nsnote_callback + 167
9   com.apple.CoreFoundation      	0x00007fff85f6afd0 __CFXNotificationPost + 1008
10  com.apple.CoreFoundation      	0x00007fff85f57548 _CFXNotificationPostNotification + 200
11  com.apple.Foundation          	0x00007fff86423a36 -[NSNotificationCenter postNotificationName:object:userInfo:] + 101
12  com.apple.AppKit              	0x00007fff89a6844a -[NSApplication _postDidFinishNotification] + 100
13  com.apple.AppKit              	0x00007fff89a6837f -[NSApplication _sendFinishLaunchingNotification] + 66
14  com.apple.AppKit              	0x00007fff89b3335d -[NSApplication(NSAppleEventHandling) _handleAEOpen:] + 219
15  com.apple.AppKit              	0x00007fff89b32fd9 -[NSApplication(NSAppleEventHandling) _handleCoreEvent:withReplyEvent:] + 77
16  com.apple.Foundation          	0x00007fff8645b0d6 -[NSAppleEventManager dispatchRawAppleEvent:withRawReply:handlerRefCon:] + 360
17  com.apple.Foundation          	0x00007fff8645af06 _NSAppleEventManagerGenericHandler + 114
18  com.apple.AE                  	0x00007fff8158b32b aeDispatchAppleEvent(AEDesc const*, AEDesc*, unsigned int, unsigned char*) + 162
19  com.apple.AE                  	0x00007fff8158b224 dispatchEventAndSendReply(AEDesc const*, AEDesc*) + 32
20  com.apple.AE                  	0x00007fff8158b12b aeProcessAppleEvent + 210
21  com.apple.HIToolbox           	0x00007fff8756a619 AEProcessAppleEvent + 48
22  com.apple.AppKit              	0x00007fff89a38095 _DPSNextEvent + 1191
23  com.apple.AppKit              	0x00007fff89a37801 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 155
24  com.apple.AppKit              	0x00007fff899fd68f -[NSApplication run] + 395
25  com.apple.AppKit              	0x00007fff899f63b0 NSApplicationMain + 364
26  org.rephial.angband           	0x00000001000bc559 main + 9
27  org.rephial.angband           	0x0000000100000f94 start + 52

...

Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x0000000000000000  rbx: 0x0000000000000352  rcx: 0x00000000000000aa  rdx: 0x000000000000000b
  rdi: 0x000000011b317918  rsi: 0x000000000000000a  rbp: 0x00007fff5fbfe3e0  rsp: 0x00007fff5fbfe060
   r8: 0x00007fff5fbfde90   r9: 0x00007fff5fbfd290  r10: 0x00007fff5fbfde92  r11: 0x00007fff5fbfda90
  r12: 0x00000000000000ab  r13: 0x00007fff5fbfe4a0  r14: 0x0000000000000102  r15: 0x0000000000000002
  rip: 0x00000001000a95a8  rfl: 0x0000000000010246  cr2: 0x0000000000001aa2

[Nick]

If no crash bug has been fixed since that nightly, I'll post a crash dump next time it happens. But this is what I copied:

That's plenty; in fact, from these OSX crash dumps, the informative bit is from the beginning to the end of the lines in the "Thread 0 crashed" section which are labelled org.rephial.angband.

PowerWyrm: You are awesome, and I will get on to those when I am back to my development machine.

[Ingwe Ingweron]

Nightlies b662e89 - Nexus Q still teleports @ around even though @ has rNexus. I thought this wasn't supposed to happen when @ had rNexus covered.

[Timo Pietilä]

Nightlies b662e89 - Nexus Q still teleports @ around even though @ has rNexus. I thought this wasn't supposed to happen when @ had rNexus covered.

Nexus Q teleports are just teleports. Nothing to do with nexus element. Kind of misleading name.

[PowerWyrm]

Just a minor glitch: when you pick up missiles on the floor, the equipment subwindow is not immediately refreshed (only the count in the inventory subwindow is).

[Werbaer]

Crash bug in 4.0.2 windows version.

Digging through rubble. Light goes out the moment the digging is done.
Edit to add: Light source was a torch. Auto-pickup is on.

Assertion failed!
Program: ...
File: obj-pile.c
Line: 134
Expression: pile_contains(*pile,obj)

Last messages:

Your light is growing faint.
You dig in the rubble. <17x>
You have removed the rubble.
Your light has gone out!

[PowerWyrm]

My variant just crashed while processing objects. Found out the following loop is faulty:

	while (obj) {
		struct object *next = obj->next; [B][I]<-- crashes here[/I][/B]

		/* do something */

		/* Delete the object */
		object_delete(&obj);
		obj = next;
	}

When leaving the loop, "next" being local to the loop is freed, "obj" points to nowhere...

Found the following occurences in 4.0.2 code:
- delete_monster_idx()
- monster_death()
- process_monster_grab_objects()
- push_object()
- project_o()
- store_maint()
- monster_death_stats()

[kandrc]

When squelching coins, Creeping * coins are completely undetectable until @ tries to move into their cell. A low-level mage who inadvertently melees a Creeping Adamantite coins is in trouble. Ordinarily, if I see a pile of coins that could be a monster that could kill me in a round or two (Creaping adamantite coins for a low-level mage), I attack it from range so that I can safely identify it, and have enough turns to kill it.

It's not clear what the solution to this should be. Perhaps detect monster discerns monster from real coins? But that would actually give a small advantage those who squelch coins, as all visible coins will be monsters, while for most, the game would revert to the old (as in a few years ago) behavior. Perhaps the solution is simply to restrict generation of coin monsters when coins are squelched. I can't see as that would actually change the game in any meaningful way.

EDIT: To be clear, this is most prominently an issue for low-level ironman games, because nobody else is squelcing coins, especially adamantite, in the early game; however, I expect that many, perhaps most, squelch coins in the endgame. There, you'll set up a battlefield, plan an escape route, and inadvertently lose a turn in a dangerous situation because you attack an undetectable monster.

[Carnivean]

When squelching coins, Creeping * coins are completely undetectable until @ tries to move into their cell.

Potion mimics have the same problem I believe. I'd still propose that detect monsters shows that it is a monster. If it can find invisible monsters it should also be able to mimic monsters, as both are otherwise unseen. Squelching would only be a slight advantage, as non-squelchers would have the monster on their monster list.

[Ingwe Ingweron]

When squelching coins, Creeping * coins are completely undetectable until @ tries to move into their cell.

This is true for all mimics, regardless of type. If you have "ignored" the item, its mimic will not show. This is, I believe, the desired behavior, although I do understand the frustration.

The reason it IS the desired behavior is that if the mimic were still visible even though the item is "ignored", the fact the mimic shows would be an information leak. E.g., one could, theoretically, approach a suspicious scroll and use the menu to ignore all scrolls. If the scroll were still there - it is a mimic.

So, one of the costs of the convenience of "ignoring" items is that occasionally you will run across a mimic that you won't know about until bumping into it or it casts a spell.

[redlumf]

My variant just crashed while processing objects. Found out the following loop is faulty:

	while (obj) {
		struct object *next = obj->next; [B][I]<-- crashes here[/I][/B]

		/* do something */

		/* Delete the object */
		object_delete(&obj);
		obj = next;
	}

When leaving the loop, "next" being local to the loop is freed, "obj" points to nowhere...

Found the following occurences in 4.0.2 code:
- delete_monster_idx()
- monster_death()
- process_monster_grab_objects()
- push_object()
- project_o()
- store_maint()
- monster_death_stats()

Loop looks solid to me. The "next" is local, but is used as temporary store for the object pointer. It gets assigned back at obj prior to "next" going out-of-scope and thus deallocated from stack.