Reported by entrez: fake player monsters on the Astral Plane level
were giving "<role> suddenly appears!" feedback if they could be
seen or sensed when the hero arrived on that level.
They're generated separately from the level itself so the message
suppression in place during level creation didn't guard against it.
This is a large iteration on a previous implementation of making
nh.getmap() parse its coordinates as relative to the last defined map or
room rather than absolute to the entire level. Now, everything in the
nh.* and obj.* functions interprets coords as relative rather than
absolute. (By default; if no map or room has been defined, or if the lua
code is executing after level creation is done, they will interpret the
coordinates as absolute).
The general motivation is basically the same - routines that use
absolute coordinates are difficult to use in level creation routines,
because then the designer has to remember to convert the relative
coordinate to an absolute one (and that was impossible before
nh.abscoord was added, particularly in themed rooms). And once
nh.getmap() takes relative coordinates, it would be very strange to have
all the other functions (setting timers, burying objects, etc) remain
with absolute ones.
In a couple places, code is changed to account for coordinates that are
relative to a *room* (which uses g.coder->croom->[lx,ly] as an offset,
instead of relative to a *map*, which uses [xstart,ystart].
Specifically, selection.iterate did not account for this, and without
this the ice themed room timer was not being started in the proper
place.
All tests are updated to respect the new behavior. Most of the modified
functions are not actually used anywhere in level files; the one
exception is starting a timer in a themed room, and that has been
adjusted.
Documentation updated as well to clarify when various things are tossing
around relative and absolute coordinates, both in comments and in
lua.adoc.
There are many possible use cases for nh.getmap during level creation,
but it's rendered mostly unusable by virtue of always returning data
about the exact x,y coordinate in g.level.locations. (In particular,
it can't currently be used in themed rooms at all, because the themed
room could be anywhere on the level.) This is inconsistent with how most
other coordinate-based functions work following a des.map, which use
coordinates relative to the 0,0 point of the map.
This changes it so that during level creation only, if nh.getmap is used
following a des.map statement, it will look up the coordinates relative
to the origin of the map, consistent with the other functions.
delivered across level change checkpointing
Reported by entrez. Simplest test case: give level 1 a short
annotatation, level teleport to level 2, and level teleport back to
level 1. The message window will show
|You materialize on another level. You remember this level as <note>.
but ^P message history will show
|You materialize on another level.
| You remember this level as <note>.
Spaces inserted to separate two messages that fit together on the
top line become part of the second message when saving a checkpoint
during level change flushes the top line into message history.
Change insurance checkpointing to record the full message history
without flushing the current top line so that toggling 'checkpoint'
doesn't affect what shows up on the screen or in message recall.
Fix a bunch of "suggest braces around initialization of subobject"
warnings from clang. If gcc didn't warn about these before, it might
start complaining about too many braces now.
It doesn't attempt to do anything about missing field initializers
because I'm not seeing any warnings for those.
Formatting became strange when '#ifdef WIZARD' became unconditional
several years ago, then the bitmask testing code itself became a bit
strange when amnesia got changed a couple of years ago.
(unconnected to the current dungeon branch, that is)
Level teleporting allows you to type in the name of a level instead of
its number. This normally only works for levels within your current
dungeon branch (main dungeon <-> Gehennom levelports are the exception):
entering "medusa" as a destination won't work while the hero is in the
Gnomish Mines, but it will work fine to get to the Medusa level from
elsewhere in the main dungeon.
Teleporting to a particular branch entrance didn't apply the same
restriction. The teleport would still happen even if the destination
branch was unreachable from the current branch, and in such a case the
game would just try to get the hero to the depth of the branch entrance,
within the current branch. For example, entering "quest" as a
destination within the Gnomish Mines would bring the hero to Mines' End,
since that's the closest depth-wise it's possible to get to the quest
portal level. Apply the same rules to branch entrances as exist for
named levels, excluding destinations that are unreachable from the
current branch.
The sections of the dumplog can be broadly organized into two
categories: 'current state' and 'game overview'. Current state includes
information about what exactly was happening when the game ended: the
map, recent messages, current inventory, and current attributes. Game
overview is more like a history of the game up to that point: vanquished
monsters, extinct species, conducts, and dungeon overview.
All the current state sections are listed first, followed by the game
overview sections -- I'm not sure if this was a deliberate move to break
the dumplog into two distinct 'chapters', but it's convenient for
readers who may only want to know the circumstances of a death without
seeing the nitty-gritty details of the entire game up to that point.
The one section that wasn't ordered with its category was major events,
which was positioned near the top of the 'current state' group, above
the inventory listing. This commit moves it into the 'game overview'
group. I put it at the top, since it can serve as a sort of summary of
the game for those who are interested but don't care about some of the
details of monsters killed, etc.
I was never too happy with how this was a silent effect that required
you to watch the map to see if anything changed. It might count as
an accessibility issue as well, not sure.
This change adds specific feedback for all the possible things that
might get revealed by detecting unseen. If you reveal a secret door or a
trap, you now get a message indicating that.
One slight behavior change here: if the only thing detected is invisible
monsters, the game previously did not return a result of "detected
a non-zero number of things" to the caller of findit(); now it does.
(This allows the wand to be automatically identified when it prints a
message about detecting invisible monsters.)
If you had both warning and ESP, you would get the message "Your danger
sense causes you to take a second look close by" when moving next to a
monster that is technically "undetected" (according to mundetected) but
was actually apparent to the player via ESP. For instance, moving next
to an eel hiding in the water would produce this.
Since there was no follow-up message ("You find a <monster>".) and no
new information being given to the player, the "danger sense" message
was pointless, and so I removed it in this case when the warning doesn't
lead you to find anything new.
When a monster did something trying to get out of a boulder fort,
it usually meant teleporting or going down stairs or a hole.
The code didn't check for the action return value, and resulted
in a migrating monster being able to throw a potion at hero.
When you were busy with an occupation, such as digging with
a pickaxe, and a prompt showed up to ask you enter something,
the game just hung with infinite loop.
Remove the occupation check returning a NUL from the input
function. I didn't notice any side effects, but I would not
be surprised if something comes up ...
I didn't investigate which commit caused this, but I suspect my
rhack or parse changes.
initoptions(), including initoptions_finish(), was running to
completion with the default window system before windowtype from the
command was parsed and activated. When the default window system
is tty without MS-DOS the map type gets set to ascii; command line
--windowtype:X11 doesn't switch it back to the X11 default of tiled.
So,
| NETHACKOPTIONS=windowtype:X11 nethack
ran nethack in tiles mode but
| nethack --windowtype:X11
ran it in text mode (assuming .nethackrc left tiles vs text with the
default setting).
I think this fix is quite iffy but it seems to work as intended....
It reclassifies '--windowtype' as an "early option" in unixmain.c,
and the options.c code ultimately processes it twice.
Some discrepencies between glyph_is_cmap and glyph_to_cmap
arose after b14b830b because the change resulted in
glyph_is_cmap matching on zap beams which weren't accounted
for in the glyph_to_cmap macro. It is unlikely that
glyph_to_cmap will ever be used on such a glyph, but at least
have glyph_to_cmap return a sane value rather than drop through
to the last-resort value (currently NO_GLYPH) which is far
outside the range of the defsyms[] array indices.
begin_burn() was called before the quantity of wished lit candles was
restricted which meant that the light source radius could depend on a
larger quantity than the final object actually had.
Enable 'debugging' function calls, including error(), from the lua files
called by the wizard-mode #wizloadlua command. Without enabling them,
calling error() still produces an error but with a message like
"attempt to call a nil value (global 'error')" instead of the one
specified in the lua file.
I think this is the right way to do this without just enabling
everything across the board (which I assume would contradict the goals
of NHL_SANDBOX), but I will admit to being a little confused by trying
to understand exactly how the sandbox permissions work, so it's possible
this isn't the right solution.
Incidentally, I am probably misunderstanding this, but considering a lua
error still occurs when error() is called, just with a different error
message, is the function really "disabled" successfully by NHL_SANDBOX?
- Add bounds, so that we don't process any locations outside
as those locations are known to be unset
- The bounds are only recalculated if needed
- Replace instances of selection_not where we actually want
a new selection with all locations set
Issue #838 from clausecker, relayed by copperwater: old workarounds
for lack of type 'time_t' from pre-standard days aren't suitable any
more. One of the instances was incorrect (diagnosed by entrez) and
no one had noticed for years (or possibly just ignored a compiler
warning).
Remove most of the old cruft from hacklib.c and some from system.h
but put in commented workarounds in unixconf.h in case someone needs
to resurrect it. It would have been better to do things this way
back in the old days.
Resurrecting some non-Unix port might need to clone the unixconf.h
bits in its own *conf.h, but that probably won't be necessary for a
standard C compliant system.
Closes#838
Make #migratemons command be unconditional. The show existing
ones part is now always present. Compile-time DEBUG_MIGRATING_MONS
controls whether the create N new migrators part is available.
Fix creating new ones from the Castle level. It knew how to find
the next level (Valley) but wouldn't send monsters there because of
its Is_botlevel() check.
- Don't show attacking a peaceful or tame monster, as
that is actually swapping places with them - so add that.
- Don't show naming a hostile monster - it's usually not
wanted, and this way when clicking a hostile monster, the
only entry is the attack, so will be executed automatically.
This makes it much more usable.
Previously the mouse clicklook mentioned every tile that matched
the character symbol, leading to overload of information and
if playing with tiles, it was mostly useless. Also the most
important bit - the tile info - was last in the text.
Now mouse clicklook only reports the exact tile information
that was clicked on.
If there are any migrating monsters, #migratemons offers a chance
to view them; display the list in arrival destination order rather
than the arbitrary migrating_mons order. Doesn't change the list's
order and doesn't apply to viewing 'c' (mons aimed at current level)
or 'n' (mons aimed at next level), just to 'o' (other, neither 'c'
nor 'n') and 'a' (all migrating mons).
A typo in the code added to #migratemons resulted in bad output when
listing a subset of migrating monsters if there were any aimed at the
next level. Didn't affect listing 'a'll because the incorrect code
wasn't reached in that situation.
If the map is big enough so that makerooms generates the maximum
allowed number of rooms for the level, the last room will "overflow"
into the subrooms array.
The rooms array assumes the last entry has hx = -1, and add_room
changes the next room hx to -1 but because the subrooms array
is right after the rooms array, this change actually touches
the first subroom on the level.
This has been present since who knows how long, but because
the levels are normally small enough, the room limit is never hit.
My change to allow binding the mouse buttons made getpos
push the mouse commands into a command queue, so when you
were asked for a map location, clicked on it with a mouse,
you'd first get the expected effect, and then (most likely)
immediately traveled there.
Change getpos to clear the commands bound to the mouse buttons,
and restore the binds afterwards.
Engulfing pets were getting a double chance to get an intrinsic from a
digestion attack, because they got the mon_givit call in mhitm_ad_dgst
and then also the one in mdamagem.
There is a bit of inconsistency here, in that mhitm_ad_dgst requires
corpse creation to grant nutrition, but the non-nutrition effects of
eating a corpse like polymorph, extra health, etc, in mdamagem don't
have any such requirement. As a result, one of the mon_givit calls
required a corpse to be "created" before granting an intrinsic, and the
other didn't. In choosing which one to remove, I figured intrinsic
granting is probably closer to those special effects than providing
nutrition (and also putting it in mhitm_ad_dgst is not ideal w/r/t
message ordering: it causes the 'intrinsic granted' message to appear
before the monster kill message).
When moat and lava use the same screen symbol and color is Off, lava
is rendered in inverse video. It used to be similar for floor and
ice, but that got broken last year. Fix inverse ice, and now that
fountain and sink might be same symbol (recent IBMgraphics change),
render sinks in inverse if they match fountains and color is Off.
I started to give sink its own mapglyph flag but then got lazy and
used the same value as ice. That can be amended if some interface
wants to use some more elaborate distinction than inverse video.
Instead of hardcoding mouse button actions, allow the user to
bind mouse buttons to extended commands. For example the new
defaults are:
BIND=mouse1:therecmdmenu
BIND=mouse2:clicklook
Currently a bit rudimentary; the defaults should be OK, but
documentation is bit lacking, and in-game binding and option
saving are missing.
Allowed commands to bind are "nothing", "therecmdmenu", "clicklook",
and "mouseaction". Clicklook replaces the "clicklook" boolean option,
and mouseaction does what mouse 1 button used to do - a context sensitive
action.
By temporarily changing the type definition for each of xint16 and
coordxy to int32_t, the compiler was able to find several places where
the type definitions were wrong.
Redo the fix for using doset(#optionsfull) to toggle perm_invent
under curses. Move it to curses code and let the core be unaware
of it. It does the perm_invent update twice when creating the
window for that.
dump_create_nhwindow() has been returning a bogus value. In the past
that didn't make any difference but after some recent perm_invent
changes, it started triggering a panic when writing the inventory
portion of DUMPLOG.
The changes to invent.c just avoid attempting to create a window that
won't be used.
