Instead of inexplicably paralyzing the player for the duration of their
engraving. Many a character has died by trying to engrave something and
then sitting there diligently writing it while monsters surround and
attack them. (This was especially prominent back in the 3.4.3 era when
repeated Elbereths were viable, but it still occurs today with e.g.
using a hard stone to engrave Elbereth). There were also some other
oddities - for instance, if something teleported the player away while
they were engraving, they would continue to "engrave" (be paralyzed) on
their new location, but would not produce any text there; the full
engraving would be placed on their initial position.
In this commit, I have converted engraving to use the occupation
framework, which treats it as an interruptible activity. This
necessitated some logical restructuring, mostly involving the engraving
being written out in chunks as the player spends more uninterrupted time
on it.
I've tried to keep this free of regressions except for those inherent to
the occupation system.
What has NOT changed:
- The rate of engraving is still 10 characters per turn, or 1 character
using slow methods.
- The formulas for determining how much a bladed weapon or marker can
engrave before getting exhausted are kept. Though this is a bit
convoluted, and if it's not considered important to preserve the
existing behavior, I would recommend simplifying it by decreasing the
maximum engraving length for weapons by 1 so that each point of
enchantment simply gets you 2 characters' worth of engraving (e.g. a
-2 weapon will only engrave 1 or 2 characters before dulling to -3,
rather than giving it a third "grace character".
- The input buffer is still modified based on confusion/blindness/etc
only at the time when the player inputs it (if they gain a
debilitating status while engraving, it will not affect the text). My
personal preference is to make the text affected in scenarios like
that, but it's not strictly necessary to do here, so I didn't.
- Wand messages such as "The floor is riddled by bullet holes", and
blinding from engraving lightning, still appear before the hero starts
to take any time engraving. As noted above, getting blinded by the
wand still has no effect on accurately engraving the text, unless the
hero was already blind or impaired.
What has changed:
- Moving off the engraving or losing the object being engraved with
causes the player to stop engraving.
- Wands can still engrave an arbitrary amount of text using a single
charge, but if the hero is interrupted and decides to start engraving
again, they will consume a second charge.
As it adds a new field to g.context, this is a save-breaking change.
Update some code from four weeks ago. One of two hold_potion()
calls was followed by update_inventory() but the other wasn't.
Have hold_potion() do that itself. I'm not sure that this is
needed and haven't convinced myself that it's not.
Prevent the "X Error (bad Atom)" situation that causes an
"X Error" panic.
The issue isn't fixed. This fails to implement the intended
functionality of having the X server remember the persistent
inventory window's location across games (until the next time
that the X server restarts). Worse, on OSX the window creeps
each time it is updated (visually it seems to be moving down by
the height of the window's title bar).
That's not as bad as having it move to the pointer's location as
it did in 3.6.1, but prior to the commit which introduced this
code that had been fixed and it stayed put during the current
game, so more work is definitely needed.
2015 commit 27d8b631cd incorrectly altered a test
/* Chop engraving down to size if necessary */
if (len > maxelen) {
for (sp = ebuf; (maxelen && *sp); sp++)
-> if (!isspace(*sp)) maxelen--;
if (!maxelen && *sp) {
*sp = (char)0;
if (multi) nomovemsg = "You cannot write any more.";
was changed to:
/* Chop engraving down to size if necessary */
if (len > maxelen) {
for (sp = ebuf; (maxelen && *sp); sp++)
-> if (*sp == ' ') maxelen--;
if (!maxelen && *sp) {
*sp = (char)0;
if (multi) nomovemsg = "You cannot write any more.";
Fixes#457
tty and X11 honor the menu_xxx options. Qt currently doesn't
support menu manipulation by keyboard. curses does support that
but was only handling the default menu keys.
Somehow several arrays of compound option values ended up in
between defining menu_cmd_t and using menu_cmd_t. Reorder them.
Also, add a terminator to the list of menu commands so that it
could potentially be used manipulated from other source files
that don't have access to the array size.
../win/Qt/qt_main.cpp: In member function ‘virtual void nethack_qt_::NetHackQtMainWindow::closeEvent(QCloseEvent*)’:
../win/Qt/qt_main.cpp:1377:9: warning: variable ‘ok’ set but not used [-Wunused-but-set-variable]
1377 | int ok = 0;
| ^~
option ‘-Wimplicit’ is valid for C/ObjC but not for C++
option ‘-Wimplicit-function-declaration’ is valid for C/ObjC but not for C++
option ‘-Wimplicit-int’ is valid for C/ObjC but not for C++
option ‘-Wmissing-prototypes’ is valid for C/ObjC but not for C++
option ‘-Wmissing-parameter-type’ is valid for C/ObjC but not for C++
option ‘-Wold-style-definition’ is valid for C/ObjC but not for C++
option ‘-Wstrict-prototypes’ is valid for C/ObjC but not for C++
../win/Qt/qt_yndlg.cpp: In member function ‘char nethack_qt_::NetHackQtYnDialog::Exec()’:
../win/Qt/qt_yndlg.cpp:80:9: warning: variable ‘ch_per_line’ set but not used [-Wunused-but-set-variable]
80 | int ch_per_line=6;
| ^~~~~~~~~~~
We have a struct called mkroom and a function called mkroom()
so c++ complains about the mkroom() function hiding the
initializer for the struct.
Similarly, we have a struct called attack and a function
called attack().
There may be a more elegant way of eliminating those two
warnings, but renaming mkroom() to do_mkroom() and
attack() to do_attack() was straightforward enough.
