|Anonymous | Login | Signup for a new account||2019-02-23 16:58 CET|
|Main | My View | View Issues | Change Log | Wiki | Tavern | News|
|Viewing Issue Simple Details|
|ID||Category||Severity||Reproducibility||Date Submitted||Last Update|
|0004638||[DCSS] Bug Report||minor||have not tried||2011-09-28 22:55||2015-02-16 20:55|
|Status||resolved||Product Branch||0.10 ancient branch|
|Summary||0004638: MONS equipment added too late for spawn messages|
The way MONS: specs are currently handled, by first spawning a monster with random equipment, and only replacing the equipment after that if some was specified, presumably works fine for normal vaults and such: there's nobody around to see what's happened.
It doesn't work very well for monsters dynamically spawned in view of the player, though: they come into view holding their original equipment, not whatever is specified in the MONS spec.
To see this, just try the wizard mode command "&Morc ; nothing": it looks odd, and it's also rather confusing to those who don't know how it works.
I'm guessing that there will soon be non-wizmode ways that monsters could be spawned in full view of the player from MONS specs. Presumably this sort of thing would be unacceptable for them?
It would probably be a good idea to have place_monster() permit a list of items to be specified in the first place, rather than making dgn_place_monster() back-patch them after the monster has already potentially come into view...
|Tags||equipment, wizard mode|
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.
Also questionable in place_monster:
// Special case: must update the view for monsters created
// in player LOS.
This is also happening before the items are given, so the display could be inaccurate at that point.
|Same applies to a number of other initialization parts, not just weapons.|
|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()|
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.
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 [^]
|Dunno when this was fixed but it was (compare &mdeep elf blademaster to &mdeep elf blademaster ; nothing, for a better example).|
|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|
|Mantis 1.1.8[^] Copyright © 2000 - 2009 Mantis Group|