This attempts to make item-actions, #herecmd, and #therecmd be more
robust. When rhack() or yn_function() take queued input off cmdq
and get something unexpected, discard the rest of the queue.
It also fixes the two crash cases that entrez reported. There are
bound to be others though.
I think a lot of actions that can be executed by queued input are
going to need nomul(0) calls to handle repeat counts that should be
ended early if something unexpected happens or something expected
fails to happen. But that clears cmdq so may be tricky to decide
where to use.
Noticed when adding a 'tip container' choice to item-actions for
context sensitive inventory (update pending). Putting items into a
container with menustyle traditional and then takiing them out with
the #tip command while 'sanity_check' is On would produce warnings
once they were on the floor.
askchain() uses object bypassing to be able to cope with multi-drop
potentially changing invent, and it tried to reset that when done.
But it did so with the original object list (invent in this case)
and that doesn't reset individual objects that have been moved to
any other list. The between-turn resetting of bypass bits wasn't
doing so for container contents. The sanity check wasn't--still
isn't--checking those either, so it wasn't noticeable while items
were still inside the container. But taking them out with #tip
doesn't touch any bypass bits, so between-turn reset isn't triggered
and the items that came out of the container with bypass set
continued to have it set while on floor. sanity_check complained.
Change clear_bypasses() to handle container contents, and change
askchain() to call it instead of just clearing bypasses for whatever
is left of its input chain. (The latter probably isn't necessary
now that the between-turn cleanup deals with contents.)
When asking for an inventory subset for one of the meta-classes that
can generate output which spans object classes (so B,U,C,X, and P),
insert a title at the start of the resulting inventory list. (Iu and
Ix produce alternate output that already includes a title.)
Also, stop handling '$' differently for menustyles traditional and
combination from full and partial. 'I$' was running the '$' command
for the first two styles but just showing the inventory entry for
gold for the last two. Change to the latter for all styles.
For menustyles traditional and combination, allow 'IP' to request
inventory listing of just picked up items even if not carrying any
items flagged as just picked up. The not carrying any such items
feedback was already present but couldn't be triggered.
For menustyles partial and full, the special menu entry for 'P'
when only one item applies shows the item instead of the category
"Items you just picked up". [That sort of thing probably ought to
be done for every menu entry rather than just for 'P'.] Rephrase
it from
| P - <item>
to
| P - Just picked up: <item>
in case it is player's first time seeing that category be listed.
Clear the just picked up flag for any item that is dipped or read.
Lots of other actions besides drop or put-into-container probably
ought to do that too. [Maybe even just picking an item with getobj()
could be sufficient so that it wouldn't have to be replicated all
over the place.]
trycall() is a short docall() wrapper that is a no-op if the item is
already identified or the player has called the object type already. For
some reason, many calls to docall() did those same exact checks
beforehand.
This commit eliminates that redundancy by converting those calls into
trycall(), which is now made extern rather than local to do.c. No
behavior should be changed by this commit; I've checked that none of the
affected places could take a different code path now that the
oc_name_known and oc_uname checks are removed.
Lay groundwork for generating a log event when finding an artifact
on the floor or carried by a monster. This part should not produce
any change in behavior.
Move g.artidisco[] and g.artiexist[] out of the instance_globals
struct back to local within artifact.c. They are both initialized
at the start of a game (and only used in that file) so don't need
to be part of any bulk reinitialization if restart-instead-of-exit
ever gets implemented.
Convert artiexist[] from an array of booleans to an array of structs
containing a pair of bitfields. artiexist[].exists is a direct
replacement for the boolean; artiexist[].found is new but not put to
any significant use yet. If will be used to suppress the future
found-an-artifact event for cases where a more specific event (like
crowning or divine gift as #offer reward) is already produced.
Remove g.via_naming altogether and add an extra argument to oname()
calls to replace it.
Add an extra argument to artifact_exists() calls.
I've seen complaints how looting containers is tedious, and
since multiple containers in the same location are now (and have
been for a while) handled with a menu, the yes-no-quit prompt
for a single container doesn't really mean anything.
Remove that prompt, and remove the "open carefully" message too,
so when you're looting a location with a single container, the
command will drop straight into the loot-in-out -menu. Also
adjust one looting message to explicitly mention the container
if there are other objects on top of it.
Removing the prompt means you can't loot a saddle from a tame
monster with plain loot when standing on a container - you need
to prefix the loot command with 'm' prefix in that case.
Log game events, such as entering a new dungeon level, breaking
a conduct, or killing a unique monster, in a new "Major events"
chronicle. The entries record the turn when the event happened.
The log can be viewed with #chronicle -command, and the entries
also show up in the end-of-game dump, if that is available.
This feature is on by default, but can be disabled by
defining NO_CHRONICLE compile-time option.
This also contains "live logging", writing the events as they
happen into a single livelog-file. This is mostly useful for
public servers. The livelog is off by default, and must be
compiled in with LIVELOG, and then turned on in sysconf.
Mostly this a version of livelogging from the Hardfought server,
with some changes.
error 28 in line 4090 of "invent.c": redeclaration of var <adjust_ok> with new storage-class
error 28 in line 4100 of "invent.c": redeclaration of var <adjust_gold_ok> with new storage-class
error 28 in line 610 of "mdlib.c": redeclaration of var <count_and_validate_winopts> with new storage-class
error 28 in line 3846 of "options.c": redeclaration of var <pfxfn_cond_> with new storage-class
error 28 in line 3886 of "options.c": redeclaration of var <pfxfn_font> with new storage-class
error 28 in line 5307 of "options.c": redeclaration of var <determine_ambiguities> with new storage-class
error 28 in line 5343 of "options.c": redeclaration of var <length_without_val> with new storage-class
error 28 in line 6853 of "options.c": redeclaration of var <illegal_menu_cmd_key> with new storage-class
error 28 in line 7708 of "options.c": redeclaration of var <count_apes> with new storage-class
error 28 in line 2686 of "pickup.c": redeclaration of var <stash_ok> with new storage-class
error 28 in line 1008 of "read.c": redeclaration of var <can_center_cloud> with new storage-class
error 28 in line 31 of "rnd.c": redeclaration of var <whichrng> with new storage-class
Instead of returning ECMD_OK, the commands now return ECMD_CANCEL
when user declined to pick a direction or an object to act on.
Note that this can be ORed with ECMD_TIME, if the command still
took a turn.
For now this has no gameplay meaning.
Always give a message when creating a detected monster
during gameplay (as opposed to during level creation).
To prevent the message, use the MM_NOMSG flag for makemon.
Most places already handled their own messaging, but there
were some, such as bag of tricks, create monster magic
and random monsters created during gameplay that didn't.
Instead of returning 0 or 1, we'll now use ECMD_OK or ECMD_TURN.
These have the same meaning as the hardcoded numbers; ECMD_TURN
means the command uses a turn.
In future, could add eg. a flag denoting "user cancelled command"
or "command failed", and should clear eg. the cmdq.
Mostly this was simply replacing return values with the defines
in the extended commands, so hopefully I didn't break anything.
Follow up on some old groundwork. For tty, if the core has designated
a message as 'urgent', override any message suppression taking place
because of ESC typed at the --More-- prompt. Right now, "You die"
messages, feedback about having something stolen, feedback for
"amorous demon" interaction (mainly in case of armor removal), and
exploding a bag of holding are treated as urgent.
The "You die" case is already handled by a hack in top-line handling;
I left that in place so the conversion of 3 or 4 pline("You die.*")
to custompline(URGENT_MESSAGE, "You die.*") was redundant. There
are probably various non-You_die messages which precede done() which
should be marked urgent too.
Other interfaces might want to do something similar. And we ought to
implement MSGTYPE=force or MSGTYPE=urgent to allow players to indicate
other messages that they want have to override suppression. But I'm
not intending to work on either of those. I mainly wanted to force
the magic bag explosion message to be shown since a sequence of "You
put <foo> into <bag>." messages is a likely candidate for --More--ESC.
This started out as just some minor reformatting but ended up including
a couple of new comments and a revision in how the use_container()
decides whether it is feasible to put something into the container.
Behavior isn't changing.
Globs never rotted away but did become tainted after a relatively
short while, which seemed like a contradiction. Change them to never
be tainted but shrink by 1 unit of weight approximately every 25
turns. An ordinary glob (one that hasn't combined with any others)
starts out weighing 20 units, so it takes about 500 turns to vanish.
That's roughly twice as long as a corpse takes to rot away.
Shrinking globs give feedback when in hero's invent or in a container
in hero's inventory, but rarely (when going from an exact multiple
of 20 weight units; that is, from integral number of N globs to
N-1 + 19/20, or if weight reduction triggers an encumbrance change).
When a glob goes away completely, there is feedback for those two
circumstances and also for seeing the glob vanish from the floor.
I haven't touched how much nutrition eating a glob confers. I have
changed formatting of glob names to use "small", "medium", "large",
"very large" instead of "small", [no adjective], "large", &c. You
still need to have at least five globs coalesced together for the
adjective to become "medium", same amount as before.
I don't think EDITLEVEL needs to be modified but have incremented it
anyway to play things safe.
When using a menu to drop or put in items into a container,
allow putting in the item (or items) you picked up previously,
by selecting the 'P' entry from the item class menu
Inspired by the itemcat patch by Stanislav Traykov.
Invalidates saves and bones.
It's redundant with g.moves, so there is no more need for it.
Way, way back, it looks like g.moves and g.monstermoves can and did
desync, where g.moves would track the amount of moves the player had
gotten (and would therefore increase faster if the player were hasted)
and g.monstermoves would track the amount of monster move cycles, aka
turns. But this has not been the case for a long time, and they both
increment together in the same location in allmain.c. There are no
longer any cases where they will not be the same value.
This is a save-breaking change because it changes struct
instance_globals, but I have not updated the editlevel in this commit.
Change how menu choice 'A' (auto-select everything) works. It will
now auto-select all things that match any other choices (object
class(es) or BUCX state(s) or possibly unpaid status). So it still
skips the second menu of specific objects. And it still picks all
objects when it is the only choice or if player uses '.' to select
it along with all the rest of the first menu's possibilities.
This change won't help anyone who picks 'A' without really meaning
to. (Maybe add a paranoid_confirm setting to for full-menu-A?)
Affects container apply/#loot and Drop-multiple. The invent.c part
is just formatting.
The code for doing this (basically an obj_extract_self() call plus
handling if the object was worn or wielded) was duplicated all over, and
inconsistent - for instance, though all of them updated the monster's
misc_worn_check to indicate it was no longer wearing something in
whatever slot, only one call also set the bit that flags the monster to
consider putting on other gear afterwards.
Under a new function, extract_from_minvent, all this extra handling is
checked in one function, which can simply replace the obj_extract_self
call.
A few callers (such as stealing) have some common code *after* the
object is extracted and some other things happen such as message
printing, such as calling mselftouch if the object was worn
gloves. extract_from_minvent does not handle these cases.
This replaces the arcane system previously used by getobj where the
caller would pass in a "string" whose characters were object class
numbers, with the first up to four characters being special constants
that effectively acted as flags and had to be in a certain order.
Because there are many places where getobj must behave more granularly
than just object class filtering, this was supplemented by over a
hundred lines enumerating all these special cases and "ugly checks", as
well as other ugly code spread around in getobj callers that formatted
the "string".
Now, getobj callers pass in a callback which will return one of five
possible values for any given object in the player's inventory. The
logic of determining the eligibility of a given object is handled in the
caller, which greatly simplifies the code and makes it clearer to read.
Particularly since there's no real need to cram everything into one if
statement.
This is related to pull request #77 by FIQ; it's largely a
reimplementation of its callbacks system, without doing a bigger than
necessary refactor of getobj or adding the ability to select a
floor/trap/dungeon feature with getobj. Differences in implementation
are mostly minor:
- using enum constants for returns instead of magic numbers
- 5 possible return values for callbacks instead of 3, due to trying to
make it behave exactly as it did previously. PR #77 would sometimes
outright exclude objects because it lacked semantics for invalid
objects that should be selectable anyway, or give slightly different
messages.
- passing a bitmask of flags to getobj rather than booleans (easier to
add more flags later - such as FIQ's "allow floor features" flag, if
that becomes desirable)
- renaming some of getobj's variables to clearer versions
- naming all callbacks consistently with "_ok"
- generally more comments explaining things
The callbacks use the same logic from getobj_obj_exclude,
getobj_obj_exclude_too and getobj_obj_acceptable_unlisted (and in a few
cases, from special cases still within getobj). In a number of them, I
added comments suggesting possible further refinements to what is and
isn't eligible (e.g. should a bullwhip really be presented as a
candidate for readying a thrown weapon?)
This also removed ALLOW_COUNT and ALLOW_NONE, relics of the old system,
and moved ALLOW_ALL's definition into detect.c which is the only place
it's used now (unrelated to getobj). The ALLOW_ALL functionality still
exists as the GETOBJ_PROMPT flag, because its main use is to force
getobj to prompt for input even if nothing is valid.
I did not refactor ggetobj() as part of this change.
further adjustments to the window port interface to pass a pointer
to a glyph_info struct which describes not just the glyph number
itself, but also the ttychar, the color, the glyphflags, and the
symset index.
This affects two existing window port calls that get passed glyphs
and does the parameter consistently for both of them using the
glyph_info struct pointer:
print_glyph()
add_menu().
The recently added glyphmod parameter is now unnecessary and has been
removed.
add MALE, FEMALE, and gender-neutral names for individual monster species
to the mons array. The gender-neutral name (NEUTRAL) is mandatory, the
MALE and FEMALE versions are not.
replace code uses of the mname field of permonst with one of the three
potentially-available gender-specific names.
consolidate some separate mons entries that differed only by species into a
single mons entry (caveman, cavewoman and priest,priestess etc.)
consolidate several "* lord" and "* queen/* king" monst entries into
their single species, and allow both genders on some where it makes some
sense (there is probably more work and cleanup to come out of this at some
point, and the chosen gender-neutral name variations are not cast in stone
if someone has better suggestions).
related function or macro additions:
pmname(pm, gender) to get the gender variation of the permonst name. It
guards against monsters that haven't got anything except NEUTRAL naming
and falls back to the NEUTRAL version if FEMALE and MALE versions are
missing.
Ugender to obtain the current hero gender.
Mgender(mtmp) to obtain the gender of a monster
While the code can safely refer directly to pmnames[NEUTRAL] safely in the
code because it always exists, the other two (pmnames[MALE] and
pmnames[FEMALE] may not exist so use:
pmname(ptr, gidx)
where -ptr is a permonst *
-gidx is an index into the pmnames array field of the
permonst struct
pmname() checks for a valid index and checks for null-pointers for
pmnames[MALE] and pmnames[FEMALE], and will fall back to pmnames[NEUTRAL] if
the pointer requested if the requested variation is unavailable, or if the
gidx is out-of-range.
Allow code to specify makemon flags to request female or male (via MM_MALE
and MM_FEMALE flags respectively)to makedefs, since the species alone doesn't
distinguish male/female anymore. Specifying MM_MALE or MM_FEMALE won't
override the pm M2_MALE and M2_FEMALE flags on a mons[] entry.
male and female tiles have been added to win/share/monsters.txt.
The majority are duplicated placeholders except for those that were
separate mons entries before. Perhaps someone will contribute artwork in the
future to make the male and female variations visually distinguishable.
tilemapping via has the MALE tile indexes in the glyph2tile[]
array produced at build time. If a window port has information that the
FEMALE tile is required, it just has to increment the index returned
from the glyph2tile[] array by 1.
statues already preserved gender of the monster through STATUE_FEMALE
and STATUE_MALE, so ensure that pmnames takes that into consideration.
I expect some refinement will be required after broad play-testing puts it to
the test.
consolidate caveman,cavewoman and priest,priestess monst.c entries etc
This commit will require a bump of editlevel in patchlevel.h because it alters
the index numbers of the monsters due to the consolidation of some. Those
index numbers are saved in some other structures, even though the mons[] array
itself is not part of the savefile.
Window Port Interface Change
Also add a parameter to print_glyph to convey additional information beyond
the glyph to the window ports. Every single window port was calling back to
mapglyph for the information anyway, so just included it in the interface and
produce the information right in the display core.
The mapglyph() function uses will be eliminated, although there are still some
in the code yet to be dealt with.
win32, tty, x11, Qt, msdos window ports have all had adjustments done to
utilize the new parameter instead of calling mapglyph, but some of those
window ports have not been thoroughly tested since the changes.
Interface change additional info:
print_glyph(window, x, y, glyph, bkglyph, *glyphmod)
-- Print the glyph at (x,y) on the given window. Glyphs are
integers at the interface, mapped to whatever the window-
port wants (symbol, font, color, attributes, ...there's
a 1-1 map between glyphs and distinct things on the map).
-- bkglyph is a background glyph for potential use by some
graphical or tiled environments to allow the depiction
to fall against a background consistent with the grid
around x,y. If bkglyph is NO_GLYPH, then the parameter
should be ignored (do nothing with it).
-- glyphmod provides extended information about the glyph
that window ports can use to enhance the display in
various ways.
unsigned int glyphmod[NUM_GLYPHMOD]
where:
glyphmod[GM_TTYCHAR] is the text characters associated
with the original NetHack display.
glyphmod[GM_FLAGS] are the special flags that denote
additional information that window
ports can use.
glyphmod[GM_COLOR] is the text character
color associated with the original
NetHack display.
Support for including the glyphmod info in the display glyph buffer
alongside the glyph itself was added and is the default operation.
That can be turned off by defining UNBUFFERED_GLYPHMOD at compile time.
With UNBUFFERED_GLYPHMOD operation, a call will be placed to map_glyphmod()
immediately prior to every print_glyph() call.
This got out of hand pretty quickly. can_reach_floor() had
different criteria than trap activation. Objects dropped at a
hole locations that don't fall through were treated as if they
were at the bottom of an abyss, so couldn't be examined or
picked up.
This a bunch of changes; it is bound to introduce some new bugs.
Noticed when fixing 'D$'. Some commands, including D, which should
have been handling venom weren't doing so.
I'm not sure whether I got all the applicable cases.
Prevent corpses left by cancelled trolls from reviving. Their
revival is an innate ability but is clearly a magical one, so make
that be subject to cancellation magic.
Change existing corpses that are scheduled to revive to rot instead
if they get cancelled as objects. Rider corpses are excluded.
Uncancel an ice troll whose corpse is put into an ice box.
Commit e9f53ab7f6 at the end of May
to fix corpses taken out of ice boxes by monsters changed removing
corpses from ice boxes by anybody to always give them rot-away
timers, even for trolls. Make an exception for ice troll corpses:
give those revive timers instead.
Rot and revive timers are turned off when a corpse gets put inside
an ice box. They get turned back on when taken out of the ice box
by the hero but were being left off if taken out by a monster.
That resulted in corpses of arbitrary type behaving like lizard
corpses and never rotting away.
This fixes that. It also changes troll corpse behavior. Once put
in an ice box, a troll corpse will not get a new revive timer when
taken out, just an ordinary rot timer.
while 'mention_decor' is enabled. When stepping onto different
terrain and one or more objects remained on the new spot after
autopickup, describe_decor() was issuing its new-terrain message
right before look_here()'s similar under-the-objects message. If
autopickup grabbed everything or there weren't any objects to begin
with, look_here() doesn't issue any dfeature (terrain) message.
describe_decor() isn't smart enought to know whether that is going
to happen. Give look_here() a new flag argument so that its caller
can ask for the dfeature message to be skipped for the case where a
similar message has already been given.
Losing all of your items in one go is really frustrating.
If you blow up your bag of holding, make the contents scatter around
instead of outright deleting them. This will destroy fragile objects.
Fixes#320
Avoid giving "you are back on the bottom" nearly every step when
moving around underwater.
Avoid "you are back on floor" followed by "you trip over <object>"
when fumbling in case that fumbling was due to being on ice when
taking the step to floor. Done for all fumbling rather than just
one-turn fumbling instigated by ice.
When moving from ice or water to ground, show "you are back on floor"
before listing objects at that spot instead of after.
I think there was at least one more thing but have lost track. At
any rate, 'mention_rate' potentially has a new set of bugs.
Reported 3.5 years ago. Specifying a count for pickup to pick up a
subset of a stack was processed after scrolls of scare monster were
handled, so a whole stack of those got picked up or crumbled to dust
whether you gave a count or not. Also, if you were too encumbered to
pick up the full stack, they still all crumbled or all changed state
to crumble next time, then for the latter case you picked up as big a
subset as you could handle.
Provide a way to communicate additional behaviors and/or appearances
desired from NetHack window port menus.
This is foundation work for changes to follow at a future date.
Allow #tip to do something if you pick your worn helmet instead of
a container. It's mostly just a variation of #chat but probably adds
several new bugs....
Somewhat similar to 'mention_walls', 'mention_decor' is a way to
request additional feedback when moving around the map. It reports
furniture or unusual terrain when you step on that. Normally stepping
on furniture only mentions it when it is covered by object(s). And
moving onto (rather than into) water or lava or ice doesn't bother
saying anything at all. With the new option set there will be a
message. It uses Norep so won't repeat when moving from one water
spot to another or one lava spot to another or one ice spot to another
unless there has been at least one intervening message. There is also
a one-shot message when moving from water or lava or ice onto ordinary
terrain (not Norep, just once since there's no land to land message).
Having the verbose flag Off doesn't inhibit these new messages but it
does shorten them: "A fountain." instead of "There is a fountain here."
The Guidebook gets a new subsection "Movement feedback" of the "Rooms
and corridors" section and it covers more than just 'mention_decor'.
As usual, Guidebook.tex is untested.
'mention_decor' persists across save/restore, so 'struct flags' has
changed and EDITLEVEL is being bumped, hence save files are invalided.
Apply makes a touch_artifact check on the tool being applied, but
autounlock would pick an unlocking tool to use without doing that.
Noticed while fixing that: autounlock took no time.
Since picking an artifact unlocking tool might now blast the hero,
change the tool selection. First choice: any key except another
role's quest artifact; second: any lock-pick except another role's
quest artifact; third: any credit card except another role's quest
artifact; fourth, fifth, sixth: other roles' quest artifact key,
lock-pick, or credit card. The fifth category (artifact lock-picks)
is empty. Rogues will pick non-cursed Master Key over any other
key (special case for first choice). Tourists will pick a key or
a lock-pick over their PYEC (first and second choices over third).
Some new code was using 3.4.3 era formatting (operators at end of
first half of a continued line rather than at start of second half).
Also a few cases of 'g.' prefix making lines be too wide. I imagine
there will be a lot more of these over time.
