0004638: MONS equipment added too late for spawn messages

(0014926)
mumra (developer)
2011-09-29 12:57

The culprit could be here, in _place_monster_aux in mon-place.cc and it's actually been commented that it needs fixing:

        // FIXME: This causes "comes into view" messages at the
        // wrong time, since code checks for placement
        // success before printing messages.
        handle_seen_interrupt(mon);

http://gitorious.org/crawl/crawl/blobs/master/crawl-ref/source/mon-place.cc#line1883 [^]

Also questionable in place_monster:

        // Special case: must update the view for monsters created
        // in player LOS.
        viewwindow();

This is also happening before the items are given, so the display could be inaccurate at that point.

(0014927)
KiloByte (manager)
2011-09-29 12:58

Same applies to a number of other initialization parts, not just weapons.

(0014928)
galehar (administrator)
2011-09-29 13:12

I wonder if it's really needed. How about just removing it and let the monster be announced on the next call to update_monsters_in_view()

(0014929)
galehar (administrator)
2011-09-29 13:28

Also, I had this idea to improve monster greetings and more prompts. mpr doesn't actually print the message, it just buffers it. handle_seen_interrupt doesn't announce the monster right away, but puts it in an array.
When we go back to input, we go through the monster array and announce all the monsters that are still in view. Then, we flush mpr's buffer and handle more prompts.

We can also keep track of monsters doing visible actions (like shouting). For those monsters that come into view and leave LOS in the same turn, we can ignore them if they didn't do anything, or announce them and then announce that they have "moved out of view" at then end of the mpr flush.

(0014934)
mumra (developer)
2011-09-29 14:17

I feel the whole monster generation code could be simplified and a lot of duplication removed. We have both mons_spec and mgen_data which are doing almost the same thing (and mons_spec gets first mapped to an mgen_data before the monster is actually created).

Also, this bug is possibly related to: https://crawl.develz.org/mantis/view.php?id=4498 [^]

(0028497)
wheals (administrator)
2015-02-16 20:55

Dunno when this was fixed but it was (compare &mdeep elf blademaster to &mdeep elf blademaster ; nothing, for a better example).

Issue History
Date Modified	Username	Field	Change
2011-09-28 22:55	SamB	New Issue
2011-09-28 22:57	SamB	Tag Attached: equipment
2011-09-28 22:57	SamB	Tag Attached: wizard mode
2011-09-29 12:57	mumra	Note Added: 0014926
2011-09-29 12:58	KiloByte	Note Added: 0014927
2011-09-29 13:12	galehar	Note Added: 0014928
2011-09-29 13:28	galehar	Note Added: 0014929
2011-09-29 14:17	mumra	Note Added: 0014934
2015-02-16 20:55	wheals	Note Added: 0028497
2015-02-16 20:55	wheals	Status	new => resolved
2015-02-16 20:55	wheals	Fixed in Branch	=> 0.16 development branch
2015-02-16 20:55	wheals	Resolution	open => done
2015-02-16 20:55	wheals	Assigned To	=> wheals

Notes
(0014926) mumra (developer) 2011-09-29 12:57	The culprit could be here, in _place_monster_aux in mon-place.cc and it's actually been commented that it needs fixing: // FIXME: This causes "comes into view" messages at the // wrong time, since code checks for placement // success before printing messages. handle_seen_interrupt(mon); http://gitorious.org/crawl/crawl/blobs/master/crawl-ref/source/mon-place.cc#line1883 [^] Also questionable in place_monster: // Special case: must update the view for monsters created // in player LOS. viewwindow(); This is also happening before the items are given, so the display could be inaccurate at that point.

(0014927) KiloByte (manager) 2011-09-29 12:58	Same applies to a number of other initialization parts, not just weapons.

(0014928) galehar (administrator) 2011-09-29 13:12	I wonder if it's really needed. How about just removing it and let the monster be announced on the next call to update_monsters_in_view()

(0014929) galehar (administrator) 2011-09-29 13:28	Also, I had this idea to improve monster greetings and more prompts. mpr doesn't actually print the message, it just buffers it. handle_seen_interrupt doesn't announce the monster right away, but puts it in an array. When we go back to input, we go through the monster array and announce all the monsters that are still in view. Then, we flush mpr's buffer and handle more prompts. We can also keep track of monsters doing visible actions (like shouting). For those monsters that come into view and leave LOS in the same turn, we can ignore them if they didn't do anything, or announce them and then announce that they have "moved out of view" at then end of the mpr flush.

(0014934) mumra (developer) 2011-09-29 14:17	I feel the whole monster generation code could be simplified and a lot of duplication removed. We have both mons_spec and mgen_data which are doing almost the same thing (and mons_spec gets first mapped to an mgen_data before the monster is actually created). Also, this bug is possibly related to: https://crawl.develz.org/mantis/view.php?id=4498 [^]

(0028497) wheals (administrator) 2015-02-16 20:55	Dunno when this was fixed but it was (compare &mdeep elf blademaster to &mdeep elf blademaster ; nothing, for a better example).

Relationships