mkmap creates mines-style full-level maps, so it should wipe
out all the room numbers in the level away. Also, it uses
temporary rooms for making sure the map is fully joined together;
those temporary rooms were left on the map, but should've
been cleared away.
When putting down map-parts on the level, don't remove the room
data which would be under that map; the map may have holes in them
(using the "x" map char), so a room may still exist there.
I don't think it matters if there is any room data which doesn't
have any room numbers referring to it in the level.
(Usually the special levels use map right after level_init anyway,
so there wouldn't be any rooms in the level)
Calling des.mineralize() with no arguments was equivalent to calling it
and manually specifying gem_prob = 0, gold_prob = 0, etc. Which meant
that no mineralization would actually happen.
Instead, make this match the intuitive behavior, and pass in -1
probabilities as defaults -- which the mineralize() function interprets
as the caller wanting to use the standard probabilities for a level of
that depth, as if it were not a special level.
This change does not affect any special level files since des.mineralize
is not currently used in any of them.
Perennial problem: since Bustling Town consists of a fixed map which was
shorter than the moveable area overlaid onto a cavern fill, sometimes
the cavern fill made spaces above or below the walled edges of the town,
which then got cut off when the town was placed. Since one of the valid
ways to generate a way out of an inaccessible space is to create a door
connecting it to an accessible space, this meant rooms in Minetown,
including shops, could get a second door leading into that tiny space.
And if it was a shop, the shopkeeper could not block exit from the
second door.
This fixes that issue by expanding the map vertically so that it will
overwrite the whole cavern fill in the town area of the map segment
where it might create cut-off spaces like this. (Not the whole area -
since we now have the 'x' mapchar to leave existing terrain in place,
areas adjoining open space where inaccessible pockets won't get
created can retain any existing fill to keep the town from being exactly
the same every time).
Nothing about read_simplemail is incompatible with using const, and the
lack of const required some contortions (copying ADMIN_SERVER_MSG to
another buffer with nonconst() to prevent a compiler warning).
This was the last place nonconst() was used, so I removed it.
Make admin message use urgent_pline so it's less likely to be skipped
and inadvertently missed, make ending punctuation conditional on message
itself not containing any (similar to what's done for T-shirt messages
in read.c), guard against printing an empty message (from a line like
"name:\n"; it does mean that subsequent messages in a single batch will
be discarded, but that's true of the existing guard against malformed
lines as well, and it should make the overwriting of characters past the
'msg' ptr safer).
If the summon nasties spell creates a single monster, the feedback
changes from "Monsters appear" to "A monster appears" but if you
were invisible or displaced it still said "around". Avoid
| A monster appears around a spot near you!
or
| A monster appears around your displaced image!
Reported by entrez: when a monster casts the "summon nasties" spell,
double feedback was given. First it produced "a <monster> appears"
for each visible monster and then "<monsters> appear from nowhere" at
the end. The latter would have been ok at the begining but made it
seem as if even more monsters were arriving when given at the end.
Skip the monster-by-monster feedback and just give the summary at the
end. That's enough information for a blind player to know to check
the map for new monsters.
When summon nasties is performed as randomly chosen harassment after
killing the Wizard, it still gives the enumerated "a <monster> appears"
feedback but does not give the "from nowhere" message at the end.
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.
Like some of the other coordinates in testmove.lua (addressed in
70008fc), the attempt to overwrite the stairs was targeting a spot
one space to the left of the actual position of the stairs, causing it
to have no effect (discussion suggested this may have been a result of
99715e0). Update it so the stairs are properly erased and won't
interfere with movement tests by stopping a running/rushing hero early.
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.
Pull request from entrez: specifying a level teleport destination
by level name allowed non-wizard mode controlled level teleport to
move across dungeon branchs.
Does not affect wizard mode '^V ?' or 'm ^V'.
Closes#857
(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.
After I added '#migratemons' I realized that lots of other, mostly
obscure, wizard mode commands were missing. Some of the descriptions
are vague because I'm not sure what several of them actually do.
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.
I think some of these discrepencies between glyph_is_cmap and
glyph_to_cmap started after b14b830b because the additional
ranges added by that didn't have a corresponding return in
glyph_to_cmap.
There are already pretty solid tests of makeplural, so add some in the
other direction, since it's similarly complicated and has to implement
many of the same special cases and exceptions in the other direction. I
originally tried just running the makeplural tests backwards to this
end, but several of them are tests to guarantee already-plural words
aren't further pluralized, so are not reversible.
These plurals (e.g. "gateau" -> "gateaux") were added to makeplural and
makesingular in 0c0262e, so the test was outdated and failed. I also
added another test for "Federal Bureau of Investigation", since 'bureau'
is an exception to the -eau rule (pluralizes as 'bureaus') and the
exception was originally implemented in a way that would have caused the
"Federal Bureau of Investigation" test to fail -- so it seems like a
good pitfall to test for.
Movement tests weren't working because terrain was being positioned one
square to the left of where it was expected, and the error message
printed something other than the expected coordinates.
I wasn't able to figure out why they were like this in the first place
(referring to one spot to the left of the hero with <u.ux-2, u.uy>), so
it's quite possible that I am missing some context here, but the test
failed consistently for me before making these changes, and now works.
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.
