Pull request from vultur-cadens: some of the quest nemeses death
messages mention releasing noxious gas or noxious fumes so create
a poison gas cloud for them.
Closes#763
When wormgone() takes a long worm off the map, clear its stale mx,my
coordinates. None of its callers need those anymore.
Also a bit of potential long worm clean up that occurred to me when
I looked at object bypass handling. Expected to be a no-op here.
The change to zero out a monster's map coordinates when it is taken
off the map yesterday messed up migration between levels inside the
Wizard's tower. (Didn't apply when accompanying the hero between
levels, so probably unlikely to be noticed.)
Noticed while moving some replicated code into its own routine.
Instead of always retaining a blank spellbook when failing to write a
novel, make 2/3 chance to retain and 1/3 chance to destroy. Same odds
(but separate chance) to attempt to write the Great Yendorian Novel
versus awful fan fiction.
Pull request by entrez: don't create a Pratchett novel by writing
"novel" or "paperback book" on a known blank spellbook with a magic
marker.
Blanking a novel produces a blank spellbook; there isn't any blank
novel. That's intentional. Writing "novel" on a blank spellbook
and getting a randomly chosen Pratchett one wasn't intentional.
Closes#761
The hero's ability to channel Pratchett and write his books with a magic
marker once she had read or IDed at least one of them seemed strange,
especially cases like an illiterate hero doing it as her first
introduction to the written word. Block the hero from writing random
novels with a marker.
The image of the hero sitting down in the dungeon to write a novel is
funny, so it feels like a good spot for a funny message. I'm not
sure if what I have there is perfect, but it can always be changed.
Reported directly to devteam by a hardfought player and also by
entrez. The recent mon_leaving_level() change resulted in objects
dropped by a dying monster not being displayed immediately.
It justed needed the relobj(mon, 0, FALSE) to relobj(mon, 1, FALSE)
change in m_detach() but this does some related cleanup in
mon_leaving_level()'s callers. wormgone() takes a long worm off the
map but leaves its stale coordinates set because some code relied on
that. This takes away the need for that but still doesn't actually
clear them.
This adds redundant 'return' statements at the end of a few void
functions that are longer than fits within a typical screen display.
They make searching for the end of the current routine in an editor
or pager easier without resorting to regular expressions and can
also be used to search for the beginning if/when preceding routine
ends in 'return' too.
I recently captured preprocessor output for a file and the amount of
code being expanded--and subsequently compiled--for canspotmon() was
quite an eye opener. This converts most of the macros it uses into
function calls. The resulting executable generated for OSX (built
for x86_64 and containing four interfaces) is about 5.5% smaller! and
there wasn't any difference in speed that I could notice.
The knowninvisible() macro has been in error for as far back as the
git logs go (which include those for the second cvs repository, so
over 20 years now).
Reported directly to devteam by entrez, the rloc() monst vanishes/
appears nearby/&c message was being given before "satisified, <shk>
suddenly disappears" making the latter redundant. As discussed, the
fix isn't as simple as suppressing one message or the other because
both are given conditionally.
This seems to solve it but has only been lightly tested.
Give more information when magic whistle is already discovered and
applying it affects multiple pets, without much increase in verbosity.
For each of the three categories
1) was already in view and moves to another spot still in view,
2) was out of view and arrives at a spot within view,
3) was in view but gets sent to a spot out of view,
show the pet by name (which might be "your <monst>" if it hasn't been
named) when there is just one, or "two creatures", "three...", "four...",
"several...", or "many..." when there are more than one. The first
category with more than 1 says "creatures". When there are additional
categories with more than 1, their part of the message says "others" if
prior part(s) already mention "creatures", or it says "other creatures"
if the prior part(s) only list pets by name.
For example
|Three creatures appear.
|Fido shifts location and Fang appears.
|Your pony shifts location and two other creatures appear.
|Many creatures shift locations, several others appear, and two others
disappear.
|Two creatures appear and two others disappear.
Restore old behavior of magic whistle causing pets to be moved to
different locations even when already adjacent to the hero.
This lets rloc() give its relatively new, more verbose messages if
a magic whistle isn't discovered yet but suppresses those when
already discovered in order to issue its own message. For a single
pet that starts within view and arrives elsewhere within view it says
"shifts location" rather than "vanishes and reappears". For multiple
pets, it gives one summary message instead of a separate one for each
pet affected by whistling.
original code:
if (linestart && (*cp & 0x80) != 0) {
g_putch(*cp);
end_glyphout();
linestart = FALSE;
} else {
(void) putchar(*cp);
}
new code:
if (linestart) {
if (SYMHANDLING(H_UTF8)) {
/* FIXME: what is actually in that line? is it the \GNNNNNNNN or UTF-8? */
g_putch(*cp);
} else if ((*cp & 0x80) != 0) {
g_putch(*cp);
end_glyphout();
}
linestart = FALSE;
} else {
(void) putchar(*cp);
}
The new code didn't output a character if linestart was true and the character did
not have bit 0x80 set.
fixed code:
if (linestart) {
if (SYMHANDLING(H_UTF8)) {
/* FIXME: what is actually in that line? is it the \GNNNNNNNN or UTF-8? */
g_putch(*cp);
} else if ((*cp & 0x80) != 0) {
g_putch(*cp);
end_glyphout();
} else {
(void) putchar(*cp);
}
linestart = FALSE;
} else {
(void) putchar(*cp);
}
Change table format to handle functions never to be included.
Clean up bit masks and tables of functions.
Remove some old comments and out-of-date code.
The preprocessor directives in win/tty/wintty.c were crossed-up
under MSDOS build. I think I got them straightened out now.
For a crosscompile situation, the tilemap utility (which runs on
the host) needs to produce an output src/tile.c that is compatible
for the target platform.
Don't use ENHANCED_SYMBOLS under MSDOS, for now anyway.