Reported by Umbire:
|You kill SpaceMannSpiff! SpaceMannSpiff puts on a dwarvish cloak.
|SpaceMannSpiff puts on a dwarvish iron helm.
|The seemingly dead SpaceMannSpiff suddenly transforms and rises as
| a Vampire.
This was tough to reproduce but I finally managed it. The issue
text mentions that it was fixed by copperwater in xNetHack with
commit 8c4af50f0aa3e72522f3eb98df039ff25c2a1ea0 to the repository
for that variant. My attempt to cherry-pick that failed--I'm not
even sure whether it should have been expected to work--and some of
the code has been impinged upon by changes, so I ended up applying
the contents of that commit manually.
The commit changes how/when monsters put on new armor rather than
anything directly related to vampires. Circumstances similar to
the example above now yield:
|You kill SpaceMannSpiff!
|The seemingly dead SpaceMannSpiff suddenly transforms and rises as
| a Vampire.
on one turn, then on the next turn the revived vampire produces:
|SpaceMannSpiff puts on a dwarvish cloak.
My test case only had one item of interest; I assume that the second
item of armor gets worn on a subsequent turn rather than at the same
time as the first one.
Fixes#843
Format a horn of plenty whose charge count is unknown but is known to
be empty as "empty horn of plenty" like is done for real containers.
This was too easy; I must have missed something....
Require a free hand when tipping a container into another container.
Presumeably you need to open the destination container and possibly
keep holding it open.
If you try to tip a carried container into an unknown bag of tricks,
apply the bag (once) instead of performing the tip. (To 'open' the
destination as above.) Possibly slightly confusing if bag is empty.
When tipping a container, always ask for the destination instead of
doing that only when carrying other containers. Confirming floor
as destination can be annoying but having to do that sometimes and
skipping that sometimes is aggravating because it is error prone.
And floor is preselected so can be chosen with space or return.
(I wanted to change the selector letter for floor from '-' to '.'
and then keep '-' as an unseen group accelerator, but the latter
doesn't work for PICK_ONE so I've left '-' as-is.)
Don't display "monsters appear" after tipping a bag of tricks.
Monster creation gives feedback these days. (Comparable to recent
"summon nasties" fix.)
Previously, the tetris-shaped rooms were always either
normal rooms, or turned into shops or other special rooms
in NetHack core. Now, the themed room lua code first picks
the themed room (which can be a themed or shaped), and some
of those will then pick a random filling (eg. ice floor,
traps, corpses, 3 altars).
Adds a new lua binding to create a selection picking locations
in current room.
The content-function in special level regions now get passed
the room data as a parameter.
make pmatchregex regex_error_desc return type match cppregex.cpp and
posixregex.c
make the extern declaration for loadsyms[] in options.c match the
one in symbols.c.
For tipping purposes, a horn of plenty is treated like a container.
But using one as the source container in a container-to-container tip
wasn't supported. Implement that.
Also, #tip was offering carried bags of tricks as candidate containers
to tip some other carried container into. Only do that for ones which
aren't known to be bags of tricks (so when type not discovered yet, or
specific bag not seen yet due to blindness).
isaac64.c includes <math.h>. yn() is a non-STDC math function in
<math.h> and that conflicts with nethack's yn() macro or vice versa.
If other source files begin using <math.h> this will probably need
to be handled differently.
When tipping a magic-bag exploder from a sack or box into a bag of
holding, the choice of whether to call useup() or useupf() was
backwards. But nothing bad happened which is fishy.
Reported by k2: tipping one container's contents directly into
another container allowed transferring a wand of cancellation (not
mentioned: or a bag of holding or a bag of tricks) into a bag of
holding without blowing it up.
That's now fixed. There are other issues that this doesn't touch:
I think it's odd that you can transfer stuff from one carried
container to another but not from a carried container to a floor
container nor from one floor container to another one at same spot.
I didn't test shop billing so an not sure what happens when #tip
blows up a bag of holding and there are some unpaid items involved.
Using #tip on horn of plenty treats it like a container, but doing
that when it's carried doesn't offer the chance to tip its contents
directly into a carried container.
Tipping a carried container does not require free hands or even
limbs (for playability) but tipping such into another container
should require at least one free hand.
Fixes#872
Renaming got_from_config[] (something that was done in the past)
to set_in_config[] (something to do in the future) is sufficient to
remove any confusion about why it is being set from 'O'. Since that
is the name of an enum value, use opt_set_in_config[] instead.
The definition of enc_stat[] got changed by a pull request nearly a
year ago ('const char *enc_stat[]' -> 'const char *const enc_stat[]')
but the separate declarations for it weren't changed to match.
Make the same change for hu_stat[]. Not sure why the pull request
didn't include it since the old declaration and the usage are same.
The curses one is in code that isn't used.
Reported seven and a half years ago: if you are in a vault but not
carrying any gold and the guard arrives, you're told "Follow me."
Then if you pick up gold while the guard is still in the wall breach
rather than out in the corridor, you would be told "I repeat, drop
that gold and follow me!" "Repeat" refers to the follow part but
sounds as if it refers to the drop-gold part which isn't actually
being repeated. Keep track of whether the guard has issued a drop
gold demand and use that to vary the wording of subsequent "I repeat"
message.
Modifies monst->mextra->egd so save and bones files are invalidated.
When fuzzing, noticed a trap generated inside a wall. Culprit
was one of the themed rooms that generates a rectangular room and then
puts freestanding wall columns inside. Note in somexy that it can
return a non-accessible location, and change the places that used
it and absolutely needed a space to somexyspace.
For a compound option's value that uses getlin(), cancelling with
ESC wasn't dismissing the menu and could eventually result in a
"No window slots!" panic. Clean up properly after ESC.
doset() and doset_simple() were sharing a format string but those
weren't the same if the longest option name differed. Stop sharing.
doset_simple() didn't support menu_tab_sep. Now it does. (Tested
with Qt; really needs to be tested with WinGUI. Enabling that is
expected to produce strange looking results with tty or curses.)
While testing the secret door message handling, I wanted to phaze
through solid rock to get near some secret corridors. Instead of
polymorphing into a xorn, I used #wizintrinsic to get temporary pass
through walls. That let me move orthogonally through rock but not
diagonally. Polymorph to xorn did allow diagonal movement. I think
the difference was gaining 18/100 strength in that form.
Have wall phazing override narrow diagonal checks.
When zapping a wand of secret door detection or casting spell of
detect unseem instead of displaying
|You reveal secret doors.
|You reveal a secret corridor.
|You reveal traps.
|You reveal a hidden monster.
show
|You reveal 2 secret doors, a secret corridor, 3 traps, and a hidden monster.
as a single message.
Detecting invisible monsters is still a separate message; those get
re-mapped as "remembered, unseen monster" but not actually revealed.
The pull request included some changes that were neither accidental nor
unintentional, so only a subset of the changes from pull request #869
submitted by klorpa were manually applied.
behaviour -> behavior
speach -> speech
knowlege -> knowledge
incrments -> increments
stethscope -> stethoscope
staiway -> stairway
arifact -> artifact
extracing -> extracting
The uses of "iff" were left alone.
Close#869
Move the guts of doset_simple() into a separate routine. Initially
that was just to avoid having to increase indentation when replacing
'goto' with 'do { ... } until ()'. It ends up making the flow of
control easier to see.
doset() and doset_simple() each had their own static flag indicating
whether 'fmtstr_doset' had been assigned a value. Redundant
assignment produced the same value so it wasn't an actual problem.
doset_simple() probably needs to add menu_tab_sep support for WinGUI.
Qt is able to get by without it, but that's because it forces use of
fixed-width font when any line in a menu or text window has 4 or more
consecutive spaces. I don't think WinGUI does that.
Wizard-mode command to cast any spell without checks that would
prevent casting, and with no energy use.
Mainly to allow the fuzzer to exercise the spell code paths.
Some static analyzers flagged the last-resort values as
out of bounds (which they were).
There's a small number of other complaint-suppression items in here too,
but nothing drastic.
The menu for #herecmdmenu includes "look at map symbol" but if you
choose that it auto-picks the hero's location. Looking at your own
'@' isn't particularly useful so only include that menu option if
the symbol or tile being displayed isn't the normal one.
Avoid potential impossible "obfree: deleting worn object" warnings
when entering the endgame.
The code to get rid of items migrating to non-endgame levels passes
those items to obfree(). It needs to clear obj->owornmask first
because that's used for migration flags (undelivered orctown loot
has a non-zero value).
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.
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.
