This unifies the two separate special-room-stocking code paths, one in
the standard dungeon generator and one in the special level generator
(neither of which reacted to themed rooms, which is the reason for this
commit) into the end of makelevel(), placing the special room stocking
as the very last step of level creation.
Under the new system, when a regular or special level decides to create
a special room, it sets that room's rtype, but the room is not stocked
until later. It already worked this way for special levels, so the main
difference here is in the normal level generation, where the mkroom
family of functions identifies and marks a room as a special room, but
stops short of filling it. (I suppose perhaps the mkroom, mkzoo, mkshop
family of functions would be better off changing their names to
"pickroom" and so on.)
This also restructures makelevel() itself a bit, but the only real
change is that the paths that call makemaz don't return immediately
afterward; they continue to the special room stocking code. Also, this
code was lifted from fill_special_rooms, which is now not used
anywhere, so it has been deleted.
I don't really like how fill_ordinary_room is in mklev.c and
fill_special_room is in sp_lev.c; they seem like they'd be better off in
mkroom.c, but in the interest of not making unnecessary code changes,
I'll just recommend it.
The plan is to unify special room filling code and cause special rooms
to be filled as the very last stage of level creation. Since this will
occur after fixup_special, it was necessary to address the one remaining
piece of code in there that affects special room filling. (The Medusa
code remaining in there doesn't have to do with special rooms.)
There is code in fixup_special for stocking Medusa's lair with statues
of players from the leaderboard. It makes two assumptions: that there
will always be at least one room defined on Medusa's level, and that
the statues should be placed in the first room defined. In the process
of removing prefilled, some of these rooms suddenly became non-rooms,
and this caused problems. This commit ensures that the regions for
turning into rooms to hold the statues are present and come first.
In the process of writing this commit, I discovered a bug: the statue
stocking code for medusa in fixup_special naively chooses the spot at
which to place its final statue by selecting independent x and y
coordinates with somex and somey. This is responsible for a statue
occasionally being embedded in a wall or in iron bars on medusa-2 and
medusa-4: the rooms defined to receive statues are irregular, and some
of the possible coordinates happen to be walls, bars, and water.
The proper fix here is to add lua functionality so that the level
designer can specify that they want a leaderboard corpse or statue, and
remove the medusa special case from fixup_special, but that's rather
out of scope for what I'm doing here.
The fill_special_rooms function was only stocking two types of rooms:
top-level rooms in g.rooms, and their immediate subrooms. If there were
a special room 2 or more levels down, it would not get filled. (No
special levels currently define such a special room, so this bug is
latent.)
To address this, I changed fill_special_rooms to iterate only through
the top level rooms, and fill_special_room to recurse through all of its
subrooms (if any) before filling itself.
The existing system was a confusing mess of competing names (filled,
needfill, prefilled, etc) that had varying semantics, with prefilled
being the worst offender as it meant at least three different things in
various contexts. This commit unifies everything in the code under
"needfill", and everything in Lua under "filled", which defaults to 0
everywhere.
This also removes the second argument to fill_special_room; that
function now just checks the needfill of the room it's passed. As
before, a filled == 2 value is used for a special room to indicate that
the room should set the appropriate level flag, but shouldn't actually
be stocked with anything (for instance, King Arthur's throne room); the
difference is that this now comes directly from the lua script instead
of being manipulated within sp_lev.c.
The prefilled argument had one use case that is occasionally used in the
level files: if the level designer had specified an ordinary region with
prefilled = 1, it would become a room to control monster arrivals on a
level -- monsters that arrive within the bounds of a room are supposed
to stay there.
However, not all of the places where the comments indicated this was
being used were using it correctly; I tested this by letting a few
monsters fall through the knox portal (they're supposed to be
constrained to the entry room) and waiting a hundred turns, then going
through the portal; they were not constrained to the room and had
"wandered" through its walls.
Instead of trying to maintain this special case, I have added an
optional "arrival_room" boolean argument to des.region, which forces it
to create a room for the purposes of constraining monster arrival.
I have gone through and replaced occurrences of prefilled in lua files
with the appropriate filled option (or arrival, as needed). In some
cases, that resulted in questionable regions such as a filled ordinary
area in a non-themeroom (I just dropped the filled=1), or an area which
didn't do anything, not even lighting (which I deleted).
No code in this function would actually do anything if it were called on
a themed room, but since it is pretty clearly intended for the "regular"
special rooms, it's probably best to explicitly avoid themed rooms as
well.
I noticed that any subrooms created within a themed room were bare -
they never had any monsters, objects, traps, or anything really,
regardless of whether filled = 1 was set on them. As a result, they're
pretty boring.
It turns out that the code in makelevel() responsible for stocking
ordinary rooms with stuff only looped through g.rooms, and completely
ignored subrooms. (Subrooms would not get stocked with items by virtue
of being part of the larger room; I tested this by dialing the item
generation in rooms way up, and none of those items ever got placed in a
subroom.)
To fix this, I've extracted the code that populates an ordinary room
into its own function, fill_ordinary_room, and made it recurse into its
own subrooms. (I also renamed fill_rooms and fill_room to include the
word "special" in their names, because they only deal with special
rooms.) Note that since special rooms follow a separate codepath, an
ordinary subroom of a special room won't get stocked; perhaps these
functions should be unified in the future.
The fill_ordinary_room code is pretty much a verbatim cut and paste from
makelevel, so there is not currently any consideration for the size of
the subroom or the fact that it is a subroom with respect to how many
monsters, traps, objects, etc get placed.
I'm not sure whether other things such as stair selection will ever
select themed room subrooms, or whether they too only look at g.rooms.
This commit is intended to fix the bug where a pet will get fixated on
an unmoving monster and stop moving itself. I described the cause in the
github issue; the gist is that the pet AI chooses the unmoving monster
as its ranged target, doesn't do anything when it calls mattackm
(because it doesn't have ranged attacks), then returns a value
indicating it didn't move and can't take further actions.
I initially implemented a fix that refactored mattackm to distinguish
between "attacker missed" and "attacker did nothing", which the pet AI
could then use to determine whether the pet could continue doing things.
But then I realized that if mattackm is called with non-adjacent
monsters, a return of MM_MISS more or less unambiguously indicates that
the attacker did nothing (because the ranged functions it calls like
breamm don't actually check to see whether the target was hit, just
whether the monster initiated the attack.) So, this only really needed
to check whether mattackm returned with MM_MISS.
I also found a probable bug in mattackm, in that the thrwmm call isn't
treated the same as breamm or spitmm. In the latter two, mattackm
returns MM_HIT even though it doesn't check whether the ranged attack
actually hit its target. But there was no logic doing the same for
thrwmm, so this commit also adds that. (Otherwise, a pet could possibly
use a ranged weapon attack and then get to keep moving on its turn.)
The short exclamations ("Gasp!", "Why?", &c) led to ambiguity
about which monster was vocalizing them. Use full sentences
which refer to the speaker. It can become quite a bit more
verbose but is less likely to lead to confusion. Perhaps it
should cut those off after a modest number of them have been
issued?
"When a room is created and passed down to a contents function in
Lua, the width and height properties of that room are computed by
subtracting lx from hx and ly from hy, which means e.g. a room
which is 8 floor squares wide and 5 tall appears to the contents
function as having a width of 7 and height of 4. This patch fixes
that off-by-one."
I don't understand the details here: should a room's dimensions
include its boundary walls or just the inner amount? This change
didn't seem to cause any problems so I've put it in.
Closes#345
As reported in https://github.com/NetHack/NetHack/issues/391
if make was invoked with -j, makedefs instances could end up running in
parallel and could trample on each other's grep.tmp tempory files.
Default to using mkstemp(); allow a port runtime library implementation
that lacks mkstemp() to define HAS_NO_MKSTEMP to revert to the old behaviour.
Provide a work-alike mkstemp() implementation for windows Visual Studio build
in mdlib.c so there is no requirement to define HAS_NO_MKSTEMP there.
Fixes#391
The code for peaceful monsters witnessing the hero attack another
peaceful monster and getting angry had a 20% of making them gasp in
surprise or exclaim "why?" in shock. It was only requiring them to
have humanoid shape rather than checking for speech capability, so
peaceful zruty or minotaur, possibly other animals, could exclaim
comprehensibly. Other things which shouldn't talk, like mummies,
would behave similarly.
This categorizes how a bunch of MS_foo types should react. It has
only been lightly tested.
The previous teleport scroll fix was mislabeled with this pull
request number. Too late to fix that now; should have been
Closes#307
Now... Interaction between voluntarily busy hero (resting,
searching, and so on) with approaching monsters to decide whether
to stop had some inconsistencies.
Really closes#386
Since teleporation gives a "you matrialize" message even when
arriving close by, the old behavior of not learning a scroll of
teleportation when you land quite close to your original spot
no longer made sense. Always [almost] discover teleport scroll
when reading it.
Also adds one-shot teleport control when reading a blessed scroll
of teleportation. I changed that to be prevented when hero is
stunned, same as with full-fledged teleport control.
I reworded or reformatted several of the comments. And removed
the EDITLEVEL increment in patchlevel.h; save and bones file
contents are not affected.
I've also added an unrelated comment about reading mechanics to
doread().
Closes#386
Similar to how the pick-an-attribute menu for menu colors and
status highlights shows the attribute names using the attribute
so that you can see how it looks (or whether it is supported),
have the pick-a-color menu show the color names in the
corresponding color. Does so by temporarily removing any
user-specified menu colors and setting up another list of such
for matching color names.
Forces the 'menucolors' option On while the pick-a-color menu is
in use, then restores the previous setting along with the user's
menu colorings. Might need some way to avoid setting that for a
configuration where colors don't work.
In addition to 'true', 'yes', 'on' and 'false', 'no', 'off',
accept 1 and 0 for the value of a boolean option. Other numeric
values are rejected rather than treated as non-zero.
Relax the parsing for true, false, yes, no to accept one or more
letters instead of requiring at least three for true and false
and full word for yes and no. Full word is still required for
on and off.
Don't report two errors for the same mistake:
|% NETHACKOPTIONS='legacy:flase' ./nethack
| * Illegal parameter for a boolean.
| * Unknown option 'legacy:flase'.
|2 errors in NETHACKOPTIONS.
is changed to
| * 'legacy:flase' is not valid for a boolean.
|1 error in NETHACKOPTIONS.
Report described this as a panic triggered by the sanity_check
option, but that's because it was running under the fuzzer, which
escalates any impossible() to panic(), rather than because nethack
panicked.
I couldn't find anything wrong--which doesn't mean that there
isn't something wrong--with place_worm_tail_randomly() and
random_dir(). They use xchar for map coordinates which should be
fine as long as no negative values are generated and I couldn't
discover any such. The suggested fix of changing xchar to int
might indicate a compiler bug (although the odds of that are low).
The bogus coordinate of -15000 in the report suggests that
typedef short int schar;
(which changes xchar too) is being used in the configuration but
I don't recall having any problems attributable to that.
This switches from xchar to int as a side-effect of replacing the
offending code entirely. The new code might produce an 'ny' of -1
before goodpos() rejects it, so xchar would be inappropriate now.
The old code is commented out via #if 0 _after_ changing it from
xchar to int.
This also adds an extra sanity_check for worm tails, unrelated to
the current bug. I'm not aware of any instance where it fails.
EXTRA_SANITY_CHECKS needs to be defined for it to do anything.
Part of pull request #308: when using des.terrain to set terrain,
default for lit state becomes 'unchanged' rather than 'unlit'.
des.replace_terrain already operates that way. Replace lit state
magic numbers -1 and -2 with SET_LIT_RANDOM and SET_LIT_NOCHANGE.
Also change SET_TYPLIT() to not operate on map column 0 and move
it from rm.h to sp_lev.h. It never belonged there, is only used
in sp_lev.c, and now because of the SET_LIT_ macros it couldn't be
used anywhere else unless sp_lev.h gets included too.
Move clearing of polearm context from migrate_to_lev() to lower
level relmon(). Add missing transfer of polearm context from
old mon to new mon in replmon(). These days it seems to only be
used for creating a monster from saved traits, so polearm context
in it should be moot.
Eliminate the feasibility of micro-managing ring hunger by swapping
back and forth between a pair of rings of slow digestion. Wearing
one at a time causes normal ring hunger (wearing both at once just
increases such hunger), but being able to put on the second ring
and take off the first just before the 1 out of 20 turns where it
affects hunger, then vice versa a few turns later, is an insanely
tedious way to avoid any hunger at all, made possible by the 'time'
option. Make the turns where extra hunger get imposed be randomized
so that that can't be done reliably.
Also closes githib issue #336: hunger caused by melee attacking
adds ring and amulet hunger a second time for that turn. That has
always been intentional behavior; now the amount varies for any
given attack due to the randomization, but on average is the same
as before.
Closes#336
Core issue noticed while working on some Qt stuff. If hangup
occurred while prompting for "right or left?" ring finger, the
hangup yn_function() would return ESC and the accessory-on routine
would not see '\0', 'r', or 'l' so reprompt. Endlessly.
The turn-to-slime countdown is one of the ones that uses turns/2
to stretch the sequence out longer and it was displaying the hero
as green slime when there was another turn before it happened.
(In theory anyway. I could not get my hero to be shown as slime
and still have one move left, even when hasted.)
Make the hero mimic green slime starting on the last turn before
being polymorphed instead of next to last.
Fixes#380
Infrastructure bits: Qt tombstone uses a short buffer; make sure that
the plname value fits instead of relying on snprintf() to truncate it.
A warning about gold, if any, was iffy but this should guarantee no
reason for future complaint. Year was safe but a compiler sensitive
to buffer overflows wouldn't know that.
Actual bugs: Qt used money in inventory for gold amount on tombstone;
that overlooks gold in containers and will be 0 by tombstone stage if
bones get saved. Year was recalculated from current date+time instead
of using the value that gets passed in--blindly flagging that variable
as UNUSED was a mistake.
During hallucination, actions which triggered update of persistent
inventory made Qt's display of map tiles for equipped objects have
those tiles switch randomly, but ordinary move-by-move fluctations
applied to floor objects left them alone.
Initially I took out hallucination of inventory items altogether,
but ended up putting that back and changing the floor hallucination
to affect Qt's paper doll too. The display.h change isn't needed
but I've left it in.
The revised options processing from however long ago broke using
'O' to change 'symset'. ('roguesymset' worked ok.) Picking it
in the main 'O' menu behaved as it nothing had been picked. The
symset-specific submenu wasn't offered to the player because a
two-line block of code was omitted.
It seems amazing that no one has noticed in all this time.
The end of game disclosure for inventory was passing want_reply==True
to the inventory display routine. I don't know why because you can't
select anything. This resulted in Qt disclosure showing inventory
with the [Ok] button disabled and blank boxes instead of object
glyphs beside the inv letters. Changing to want_reply==False fixes
both aspects of that.
It has no apparent effect on tty or curses; on X11 (where [Ok] was
already enabled) it disables the [Search] button, a plus. I don't
know whether it might mess up final disclosure for inventory on
WindowsGUI. Or whether any interface which uses perm_invent window
for final inventory disclosure (if there are any) will be adversely
affected.
Noticed while working on Qt's version of persistent inventory
window (paper doll-style display of equipment in use), leashing
or unleashing a pet wasn't updating persistent inventory. Leash
descriptions format differently when in use so immediate update
is warranted.
The Qt menu entries which were executing nethack's help command
(the '?' menu) were doing so because their command keystroke was
a meta-character and such characters are being converted to '?'
to indicate an error in conversion to Latin1 character set. The
old Qt3 code didn't perform any such conversion.
This fix feels fragile because there are two different places
deciding how to disambiguate partial extended commands (the code
for Qt's '#' handling and a new routine in the core). Qt menus
now send '#' and enough letters to satisfy '#' handling for any
command which uses M-c or has no regular keystroke nor M-c one.
(If it were to send the full extended command name, the letters
after the unambiguous prefix would be left in the input queue to
be processed as subsequent commands.)
There is a fundamental problem that this doesn't address: if
the player uses BIND directives in the run-time config file, the
Qt menu bindings will break unless the BINDs are all done before
selecting windowtype. Qt's menu bindings translate a click on
a menu entry into the keystroke used to invoke the corresponding
command, so using BIND to change that after the menus are set up
will result in the wrong commands being executed.
An earlier change resulted in place_worm_tail_randomly() sometimes
removing a long worm from the map unintentionally. It was still on
the monster list so if wizard mode sanity_check option was On, there
would be warnings of a monster which isn't on the map.
The change which triggered this was necessary so I'm inclined to
blame place_worm_tail_randomly() laziness.
This is a superset of the pull request's fix.
Fixes#377
Instead of an additional options file directive to end the last
section of a CHOOSE directive, simplify by using an empty-name
section, [], instead. So
...
CHOOSE one,two
[one]
...
[two]
...
[]
...
As with the short-lived END-CHOOSE directive, if no [] is present
then the rest of the file is part of the last choice.
Add an optional way to terminate the last section after a CHOOSE
directive in the run-time options file so that it's possible to
revert to common options. If no END-CHOOSE directive is present
then the last CHOOSE section continues until the end of the file.
(All existing uses of CHOOSE already behave that way.)
Change the Guidebook to refer to OPTIONS=x, AUTOPICKUP_EXCEPTION=y,
CHOOSE=z, and so on as "directives" rather than "statements". It
just feels like a better fit.
When there was only one supported interface included in the program,
feedback of
|Supported windowing system:
|"tty" (traditional text with optional line-drawing)
was missing the intended final period. When there were more than
one, the clause describing the default could be preceded by a
spurious space.
|Supported windowing systems:
|"tty" (traditional text with optional line-drawing) and "Qt" , with a
|default of "tty".
There was a fixup for " , " but it only worked as intended when
that was on the last line, not when the default's text spanned lines.
This adds description of "Windows GUI" to the mswin entry. X11 could
have its formal name "The X Windows System" as the description but I
didn't add that since it just seems like extra verbosity. Apparently
Qt doesn't stand for anything else so still has no extra description.
options.c gave some unused variable warnings in the 'msg_window'
parsing if compiled without having tty enabled.
The 'msg_window' option should be available if either tty or curses
is the interface in use, hidden otherwise. The code to parse it
was included if TTY_GRAPHICS is enabled, so it worked in curses for
a tty+curses binary but not curses without tty one. This fixes that.
It is still displayed by 'O' when X11 or Qt is in use if the binary
also supports tty or curses. I've left that as is.
Assuming you have the prerequisite packages, You can specify the
window ports to include on the make command line:
make WANT_WIN_QT=1 WANT_WIN_X11=1 WANT_WIN_CURSES=1 WANT_WIN_TTY=1 all
Prequisites for window ports beyond tty:
(some sample homebrew commands to obtain them shown but that is not the
only way):
xquartz for x11 support
brew install xquartz
Qt for Qt support
brew install Qt
When chatting to the quest leader to try to gain access to the
rest of the quest, if your experience level is good enough but
your alignment strength isn't, in wizard mode you'll get prompted
about whether to have piety boosted. Normally you would answer
'y' and be able to go to lower quest levels. But if you answer
'n' you'll immediately be prompted a second time. Not because
the no response didn't register but because the if/else-if/else
logic checks twice for whether your alignment is inadequate and
if you answered no the first time it will still be too low the
second, with the first answer not carrying over.
Fixes#376
When hunger state is "not hungry" (so omitted from the status line),
say so in the status section of ^X output. Mainly so that wizard
mode can append the internal nutrition value without inserting an
entire line that [previously] wouldn't be present in regular play.
Show an internal value for encumbrance too, although that would be
better if it also included some indication of the amount where the
encumbrance state changes. Encumbrance is confusing and I didn't
pursue that.
I noticed that Qt status showed both Lev and Fly at the same time
when they should be mutually exclusive (Levitation overrides Flying).
I wasted a bunch of time trying to track down a Qt problem but it
turned out to be a core issue. If Flying is set first (which won't
happen if both are set in the same #wizinstrinsic operation), setting
Levitation via #wizintrinsic was attempting to update the flag that
indicates that Flying is blocked, but doing so too soon and failing.
Setting Lev via other means while Fly was already set didn't have
this problem so it wouldn't occur during normal play.
Also, #timeout lists timed properties which can have a timeout value
in normal play, then a separator, followed by properties that can
only become timed due to #wizintrinsic. Move Displacement from the
second group to the first now that it can be obtained as a timed
value by eating a displacer beast corpse.
The check for mon's max HP being at least as high as its level
turns out to be wishful thinking. Just disable it. Maybe we'll
flag critters who got or gave up HP during cloning and let them be
exceptions, then turn it back on, but not now. Or maybe reduce
mon->m_lev when cloning. That would weaken them though.
Keep the 1 extra HP that an earlier fix for this check gave to
monsters who rolled the minimum possible value while being created
(Nd8 that yielded N boosted to N+1, 1d4 for 1 boosted to 2).
Tin handling code used tin->cknown to indicate that the variety
(soup, deep fried, pureed, &c) was known, but neither object
identification nor end of game disclosure was setting cknown for
that type of object.
^I behaves as if cknown is set, so the problem was hidden during
times when anyone was likely to be paying attention.
Adopt the suggestion that candy bar stacks which get split should
keep the same wrapper text for both halves of the stack. The patch
stuck with using obj->o_id to manage the wrapper which prior to the
patch wasn't a factor in merging and splitting. Switch to obj->spe
instead, comparable to tin varities, so mergability is already
taken care of.
End of game disclosure tacks on T-shirt text to formatted items.
Do the same for candy bar wrappers.
Recently combat between monster mind flayer and headless monster was
changed to skip extra tentable-for-drain_intelligence attacks after
hitting with one for no effect. Do the same for monster mind flayer
against headless poly'd hero and for hero poly'd into mind flayer
versus headless monster. As before, it only applies to additional
actions during the current attack. As soon as the attack is over,
the ineffectiveness of intelligence drain upon target is forgotten.
Give better feedback if reading a scroll of identify when it is the
only item in inventory (making that empty when scroll is used up).
Reading a cursed scroll of identify used to always ID 1 item besides
itself. Change it to behave like confused identify--only identifying
itself--if read when the scroll hasn't been discovered yet. Same as
before when scroll has already been discovered: identify 1 item.
