For Qt with 'popup_dialog' On, fix number entry when user types
a digit (or '#') directly onto the dialog instead of clicking
inside the Count box and then typing. Before, that first typed
digit was starting out as selected, so typing the next digit
replaced the selection instead of getting appended to the string
of digits being constructed. Fixed by moving the relevant code
to the KeyPress handler instead of re-executing the dialog.
Also, if a keypress is just a modifier, ignore it. The next
event should be the actual character. Prevents treating <shift>
(and <caps lock>!) as useless dialog responses. Before this,
attempting to type '#' to initiate a count wouldn't work because
the <shift> part of shift+3 ended the dialog. Now '#' works
(and is still optional; starting with a digit suffices).
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.
Noticed when testing something unrelated: for menustyle=traditional
and =combination, when using 'D' to drop multiple items, if the
player only supplied '$' for the list of object classes of interest
then that list remained empty and all classes were processed.
Caused by retaining an old special case for gold which isn't needed
any more.
I think that it only mattered for 'D'. Other callers of ggetobj()
don't include gold as applicable so player can't pick gold hence
can't pick just gold to trigger this.
Support MSGTYPE=stop by having qt_display_nhwindow(WIN_MESSAGE,TRUE)
issue a tty-style --More-- prompt. For popup_dialog Off, the prompt
gets appended to the most recent message; for popup_dialog On, it is
issued via a popup and not displayed in the message window.
It accepts <space>, ^J, ^M, and ^[ (ESC) to dismiss. There's no way
to dismiss it with the mouse (for !popup_dialog) which might need
some fix....
Several adventures along the way. The '^C-in-parent-terminal triggers
infinite loop repeatedly complaining about "event loop already running"'
is now a one-shot complaint. It isn't fixed but the severity of
having it happen is greatly reduced.
... on the floor, in monster inventory, and in hero's inventory.
Items in your inventory being ignited produce a message even if you're
blind - you can see the lit-state by viewing inventory anyway, so just
give player the message.
(via xNetHack)
The short exclamations ("Gasp!", "Why?", &c) led to ambiguity
about which monster was vocalizing them. Use full sentences
which refer to the speaker. It can become quite a bit more
verbose but is less likely to lead to confusion. Perhaps it
should cut those off after a modest number of them have been
issued?
"When a room is created and passed down to a contents function in
Lua, the width and height properties of that room are computed by
subtracting lx from hx and ly from hy, which means e.g. a room
which is 8 floor squares wide and 5 tall appears to the contents
function as having a width of 7 and height of 4. This patch fixes
that off-by-one."
I don't understand the details here: should a room's dimensions
include its boundary walls or just the inner amount? This change
didn't seem to cause any problems so I've put it in.
Closes#345
For Qt, experience points weren't shown when enabling 'showexp'
option because they were conditional upon '#if EXP_ON_BOTL'. That
got eliminated prior to 3.6.0 so wasn't defined for qt_stat.cpp.
When displayed, show Exp as Level:Xp/Exp instead of as a separate
status field. This has the intentional side-effect of omitting it
when hero is polymorphed and status shows HD instead of Xp.
Label the six characteristics in mixed case instead of all upper
case: Str, Dex, and so forth.
As reported in https://github.com/NetHack/NetHack/issues/391
if make was invoked with -j, makedefs instances could end up running in
parallel and could trample on each other's grep.tmp tempory files.
Default to using mkstemp(); allow a port runtime library implementation
that lacks mkstemp() to define HAS_NO_MKSTEMP to revert to the old behaviour.
Provide a work-alike mkstemp() implementation for windows Visual Studio build
in mdlib.c so there is no requirement to define HAS_NO_MKSTEMP there.
Fixes#391
The code for peaceful monsters witnessing the hero attack another
peaceful monster and getting angry had a 20% of making them gasp in
surprise or exclaim "why?" in shock. It was only requiring them to
have humanoid shape rather than checking for speech capability, so
peaceful zruty or minotaur, possibly other animals, could exclaim
comprehensibly. Other things which shouldn't talk, like mummies,
would behave similarly.
This categorizes how a bunch of MS_foo types should react. It has
only been lightly tested.
The previous teleport scroll fix was mislabeled with this pull
request number. Too late to fix that now; should have been
Closes#307
Now... Interaction between voluntarily busy hero (resting,
searching, and so on) with approaching monsters to decide whether
to stop had some inconsistencies.
Really closes#386
Since teleporation gives a "you matrialize" message even when
arriving close by, the old behavior of not learning a scroll of
teleportation when you land quite close to your original spot
no longer made sense. Always [almost] discover teleport scroll
when reading it.
Also adds one-shot teleport control when reading a blessed scroll
of teleportation. I changed that to be prevented when hero is
stunned, same as with full-fledged teleport control.
I reworded or reformatted several of the comments. And removed
the EDITLEVEL increment in patchlevel.h; save and bones file
contents are not affected.
I've also added an unrelated comment about reading mechanics to
doread().
Closes#386
Qt's map hadn't been updated to draw unexplored locations with
the unexplored glyph so was still using solid stone instead.
Column 0 should be removed but I'll leave that for someone more
adventurous; I did it for curses and for X11 but am going to
pass here. It's very noticable after magic mapping but is only
"bad" (by wasting space) if clipping is being performed.
Similar to how the pick-an-attribute menu for menu colors and
status highlights shows the attribute names using the attribute
so that you can see how it looks (or whether it is supported),
have the pick-a-color menu show the color names in the
corresponding color. Does so by temporarily removing any
user-specified menu colors and setting up another list of such
for matching color names.
Forces the 'menucolors' option On while the pick-a-color menu is
in use, then restores the previous setting along with the user's
menu colorings. Might need some way to avoid setting that for a
configuration where colors don't work.
In addition to 'true', 'yes', 'on' and 'false', 'no', 'off',
accept 1 and 0 for the value of a boolean option. Other numeric
values are rejected rather than treated as non-zero.
Relax the parsing for true, false, yes, no to accept one or more
letters instead of requiring at least three for true and false
and full word for yes and no. Full word is still required for
on and off.
Don't report two errors for the same mistake:
|% NETHACKOPTIONS='legacy:flase' ./nethack
| * Illegal parameter for a boolean.
| * Unknown option 'legacy:flase'.
|2 errors in NETHACKOPTIONS.
is changed to
| * 'legacy:flase' is not valid for a boolean.
|1 error in NETHACKOPTIONS.
Report described this as a panic triggered by the sanity_check
option, but that's because it was running under the fuzzer, which
escalates any impossible() to panic(), rather than because nethack
panicked.
I couldn't find anything wrong--which doesn't mean that there
isn't something wrong--with place_worm_tail_randomly() and
random_dir(). They use xchar for map coordinates which should be
fine as long as no negative values are generated and I couldn't
discover any such. The suggested fix of changing xchar to int
might indicate a compiler bug (although the odds of that are low).
The bogus coordinate of -15000 in the report suggests that
typedef short int schar;
(which changes xchar too) is being used in the configuration but
I don't recall having any problems attributable to that.
This switches from xchar to int as a side-effect of replacing the
offending code entirely. The new code might produce an 'ny' of -1
before goodpos() rejects it, so xchar would be inappropriate now.
The old code is commented out via #if 0 _after_ changing it from
xchar to int.
This also adds an extra sanity_check for worm tails, unrelated to
the current bug. I'm not aware of any instance where it fails.
EXTRA_SANITY_CHECKS needs to be defined for it to do anything.
Part of pull request #308: when using des.terrain to set terrain,
default for lit state becomes 'unchanged' rather than 'unlit'.
des.replace_terrain already operates that way. Replace lit state
magic numbers -1 and -2 with SET_LIT_RANDOM and SET_LIT_NOCHANGE.
Also change SET_TYPLIT() to not operate on map column 0 and move
it from rm.h to sp_lev.h. It never belonged there, is only used
in sp_lev.c, and now because of the SET_LIT_ macros it couldn't be
used anywhere else unless sp_lev.h gets included too.
Eliminate the feasibility of micro-managing ring hunger by swapping
back and forth between a pair of rings of slow digestion. Wearing
one at a time causes normal ring hunger (wearing both at once just
increases such hunger), but being able to put on the second ring
and take off the first just before the 1 out of 20 turns where it
affects hunger, then vice versa a few turns later, is an insanely
tedious way to avoid any hunger at all, made possible by the 'time'
option. Make the turns where extra hunger get imposed be randomized
so that that can't be done reliably.
Also closes githib issue #336: hunger caused by melee attacking
adds ring and amulet hunger a second time for that turn. That has
always been intentional behavior; now the amount varies for any
given attack due to the randomization, but on average is the same
as before.
Closes#336
Enable existing wc_popup_dialog option. Use it in yn_function()
instead using a mystery value which apparently used to live in Qt
Settings but isn't there anymore so couldn't be turned on or off.
Also replaces conditional USE_POPUPS which isn't defined anywhere
either so presumably came from CFLAGS and only supported "yn?",
"ynq?", and "rl?" with hardcoded Qt popups rather than using
NetHackQtYnDialog.
Doing that revealed that the popup dialog for ynaq was in pretty
bad shape. It's functional but still needs a lot of work, beyond
the limited Qt/C++ capability I possess. The KeyPress issue which
accepts <shift> as input, thereby preventing <shift>+<character>
from being typed during ynaq prompting, is particularly nasty.
Append the ynaq dialog's response to the message line containing
the corresponding prompt similar to what's now done for regular
yn_function().
Add getlin() prompt+response to the message window.
Core issue noticed while working on some Qt stuff. If hangup
occurred while prompting for "right or left?" ring finger, the
hangup yn_function() would return ESC and the accessory-on routine
would not see '\0', 'r', or 'l' so reprompt. Endlessly.
The Qt interface highlights the last message issued (using a
mechanism for selection, as if for copy+paste or similar operation)
but it was staying highlighted until another message was eventually
given. Having an old message seem to stick around is annoying and
is particularly bad when the message is a prompt. If the player's
answer doesn't cause a message to be shown then it seems as if the
prompt is still pending.
This removes the highlighting (by bulk unselecting) once the player
gives another input keystroke or mouse click.
It would be much better if the selecting/highlighting was for all
messages issued since last time highlighting was cleared. Figuring
out how to do that correctly is more effort than I want to expend.
Make ASCII control characters ^[, ^\, ^], ^^, and ^_ work on Qt,
at least partly. Mainly for ^[ to be treated as ESC, which works
if you're aborting a count on the map but doesn't cancel out of
menus [yet?]. I didn't attempt to make ^@ send NUL.
Also, fix the hardcoded macros (activated by F1: rest 100 turns,
F2: search 20 times, and Tab: ^A to do-again). The first two sent
'n' before the count so wouldn't work as intended with number_pad
off, and the third was executing twice as if Tab sent two ^A's
instead of just one. Resting and searching might have been getting
duplicated too; I don't know how to simulate the relevant keys.
(I temporarily swapped definitions for F2 and Tab to test the
number_pad fix but hadn't done that earlier when I discovered the
Tab bug.)
Menus have [ok], [cancel], [all], [none], [invert], and [search]
buttons across their top but the [all], [none], and [invert] choices
didn't redraw the menu after making changes to the pending selections
so it seemed as if they weren't doing anything. Subsequently picking
[ok] revealed otherwise.
[search] is broken (instead of accepting a search string, the letters
I type are being used to toggle individual entries as I type). This
doesn't attempt to address that.
The turn-to-slime countdown is one of the ones that uses turns/2
to stretch the sequence out longer and it was displaying the hero
as green slime when there was another turn before it happened.
(In theory anyway. I could not get my hero to be shown as slime
and still have one move left, even when hasted.)
Make the hero mimic green slime starting on the last turn before
being polymorphed instead of next to last.
Fixes#380
Infrastructure bits: Qt tombstone uses a short buffer; make sure that
the plname value fits instead of relying on snprintf() to truncate it.
A warning about gold, if any, was iffy but this should guarantee no
reason for future complaint. Year was safe but a compiler sensitive
to buffer overflows wouldn't know that.
Actual bugs: Qt used money in inventory for gold amount on tombstone;
that overlooks gold in containers and will be 0 by tombstone stage if
bones get saved. Year was recalculated from current date+time instead
of using the value that gets passed in--blindly flagging that variable
as UNUSED was a mistake.
Qt is capable of using an ascii map, and does so on the rogue level.
So failing to load tiles doesn't need to quit; it can continue in
text mode.
Not extensively tested. This disables the paper doll when the ascii
map is forced (either via options settings or due to tiles loading
failure, but not when simply on the rogue level) rather than trying
to display it with object class characters.
When items in the paper doll inventory subset (primary worn and
wielded items) have known BUC state, indicate what that is. It
now draws a one pixel wide white border around each doll tile,
and if BUC is known, that border gets its color changed (red for
known cursed, yellow for known uncursed, cyan for known blessed).
That isn't very visual so the first pixel inside the tile is
overwritten with the same color, and alternating pixels are also
overwritten for the second rectangle within. The 2..3 pixel wide
border is visible without cluttering the tile for 'normal' sized
paper doll. The tiles are allowed to be scrunched down to as
small as 6x6 so there won't be much left after 1 or 2 around the
edge are replaced.
Initially I was going to try to highlight welded items but the
more general BUC highlighting is simpler and usually more useful
to the player.
The qt_map.* bits are just reformatting. I was looking at pet
and pile annotations as a way to do BUC annotations but decided
not to attempt that.
During hallucination, actions which triggered update of persistent
inventory made Qt's display of map tiles for equipped objects have
those tiles switch randomly, but ordinary move-by-move fluctations
applied to floor objects left them alone.
Initially I took out hallucination of inventory items altogether,
but ended up putting that back and changing the floor hallucination
to affect Qt's paper doll too. The display.h change isn't needed
but I've left it in.
Enhance the "Qt Settings" dialog box to provide control over the
paper doll subset of inventory displayed between the message and
status windows (above the map). A ton of flailing about for a
fairly small but useful change in functionality.
Old dialog (no title):
| [ ] Zoomed -- check box
| "Width:" [ ] -- number entry spinner
| "Height:" [ ] -- ditto
| "Font:" [ ] -- Huge:18pt, Large:14, Medium:12, Small:10, Tiny:8
| [ Dismiss ] -- button
New dialog:
| "Qt NetHack Settings"
|
| "Map:" [ ] "Zoomed" -- check box
| "Tile Width" [ ] -- number entry spinner
| "Tile Height" [ ] -- ditto
| "Invent:" [ ] "Shown" -- check box
| "Doll Width" [ ] -- number entry spinner
| "Doll Height" [ ] -- ditto
| "Font:" [ ] -- Huge:18pt, Large:14, Medium:12, Small:10, Tiny:8
| [ Dismiss ] -- button
The inventory subset can now be suppressed. When shown (the default),
its size can be set independently of the map tiles' size. I've set
the default to be 32x32 tiles instead of 16x16 used for the map.
The settings are saved and restored automatically by Qt, and persist
not just across save/restore cycles but into new games. (That's not
a change, just a reminder.)
The revised options processing from however long ago broke using
'O' to change 'symset'. ('roguesymset' worked ok.) Picking it
in the main 'O' menu behaved as it nothing had been picked. The
symset-specific submenu wasn't offered to the player because a
two-line block of code was omitted.
It seems amazing that no one has noticed in all this time.
The end of game disclosure for inventory was passing want_reply==True
to the inventory display routine. I don't know why because you can't
select anything. This resulted in Qt disclosure showing inventory
with the [Ok] button disabled and blank boxes instead of object
glyphs beside the inv letters. Changing to want_reply==False fixes
both aspects of that.
It has no apparent effect on tty or curses; on X11 (where [Ok] was
already enabled) it disables the [Search] button, a plus. I don't
know whether it might mess up final disclosure for inventory on
WindowsGUI. Or whether any interface which uses perm_invent window
for final inventory disclosure (if there are any) will be adversely
affected.
In case you haven't seen it, the Qt screen layout is (a bigger
instance of):
+--------------------+------+--------------------------------+
| messages |invent| status |
| |subset| |
| | | |
| | | |
+------------------------------------------------------------+
| map |
| |
...
| |
+------------------------------------------------------------+
where some status fields include an icon and the inventory subset is
a miniature map showing a paper doll-style display of object tiles
for worn and wielded items. The two separating lines in the top half
can be dragged to resize the three windows there. The default message
window width to too small to see full text of some messages but can
be scrolled left and right. The window for the equipped subset of
inventory is unconditionally present; 'perm_invent' is a no-op.
Paper doll inventory layout (view with fixed-width font...):
Old New two-hand dual-wield
x H b x H b x H b . H b
S " w S " w W " W X " w
G C G G C q G C q G C q
= A = = A = = A = = A =
. U . l U L l U L l U L
. F . . F . . F . . F .
Legend:
'.' = blank, b = blindfold, '"' = amulet, '=' = left and right rings,
w/W = primary weapon, x/X = alternate/secondary weapon, q = quiver,
H = helmet, S = shield, G = gloves, C = cloak, A = suit, U = shirt,
F = boots, l = leash, L = active light source (lamp/candle/Sunsword).
Slots which don't have something equipped are shown blank.
'q' was missing; 'G' used to be shown on both sides. 'l' and 'L' are
new; for either, it picks the first one in inventory that's in active
use. The 'S' and 'x' slots vary depending upon weapon situation
since wearing a shield, wielding a two-handed weapon, and engaging in
two-weapon combat are all mutually exclusive.
Noticed while working on Qt's version of persistent inventory
window (paper doll-style display of equipment in use), leashing
or unleashing a pet wasn't updating persistent inventory. Leash
descriptions format differently when in use so immediate update
is warranted.
The Qt menu entries which were executing nethack's help command
(the '?' menu) were doing so because their command keystroke was
a meta-character and such characters are being converted to '?'
to indicate an error in conversion to Latin1 character set. The
old Qt3 code didn't perform any such conversion.
This fix feels fragile because there are two different places
deciding how to disambiguate partial extended commands (the code
for Qt's '#' handling and a new routine in the core). Qt menus
now send '#' and enough letters to satisfy '#' handling for any
command which uses M-c or has no regular keystroke nor M-c one.
(If it were to send the full extended command name, the letters
after the unambiguous prefix would be left in the input queue to
be processed as subsequent commands.)
There is a fundamental problem that this doesn't address: if
the player uses BIND directives in the run-time config file, the
Qt menu bindings will break unless the BINDs are all done before
selecting windowtype. Qt's menu bindings translate a click on
a menu entry into the keystroke used to invoke the corresponding
command, so using BIND to change that after the menus are set up
will result in the wrong commands being executed.
Changes affecting everybody (using Qt): rename game->Save to
game->Save-and-exit and game->Quit to game->Quit-without-saving.
OSX-specific changes: add separate nethack->Quit and change
game->Quit-without-saving to game->_Quit-without-saving to prevent
that from being hijacked for the nethack menu. nethack->Quit menu
entry works. Command+Q is a keyboard shortcut for it. They bring
up a menu with choices of "Quit without saving" and "Cancel and
return to game". It's not the same as the handler for the window
Close button, which used to offer "Save" or "Cancel" (with the
latter triggering an infinite loop) but now offers "Save and exit"
or "Quit without saving". They don't share any code. The
game->_Quit-without-saving entry doesn't work; it runs nethack's '?'
command like a bunch of other broken menu entries. If it did work,
it would give nethack's "Really quit?" prompt and proceed from there.
The "Quit without saving" response for nethack->Quit confirmation
bypasses that and just quits.
Also OSX, add a second 'about' entry. The first one is hijacked and
added to the nethack menu, the second is help->_About_Qt_NetHack_
and avoids hijacking. Both nethack->About and help->_About_ bring
up the same dialog box showing version and assorted other info.
A lot of flailing about with for relatively small amount of progress.
Menu hackery: change a couple of menu entry names on OSX to
control where they end up.
Move nethack's 'O' command from its hijacked position (due to name
"Options") of "nethack->Preferences..." to "Game->Run-time options".
Move persistent Qt settings on OSX from "Game->Qt settings" to
"nethack->Preferences...".
The Qt settings dialog (now accessed as Preferences...) desperately
needs a title and/or other explanatory text but I haven't figured
out how do to that. The values set with it are persistent, with
apparently quite a few choices for where to save them for future
runs. I used it to increase the size of text in the status window,
and found my settings stored in binary file
~/Library/Preferences/org.nethack.NetHack.plist
The subdirectories ~/Library and ~/Library/Preferences are
standard OSX per-user things. The file name is derived from values
set up in main routine: qt_main.cpp is setting OrganizationDomain
to "nethack.org" and ApplicationName to "NetHack". I've added a
value for ApplicationVersion but don't know whether anything cares
about it.
An earlier change resulted in place_worm_tail_randomly() sometimes
removing a long worm from the map unintentionally. It was still on
the monster list so if wizard mode sanity_check option was On, there
would be warnings of a monster which isn't on the map.
The change which triggered this was necessary so I'm inclined to
blame place_worm_tail_randomly() laziness.
This is a superset of the pull request's fix.
Fixes#377
Instead of an additional options file directive to end the last
section of a CHOOSE directive, simplify by using an empty-name
section, [], instead. So
...
CHOOSE one,two
[one]
...
[two]
...
[]
...
As with the short-lived END-CHOOSE directive, if no [] is present
then the rest of the file is part of the last choice.
Add an optional way to terminate the last section after a CHOOSE
directive in the run-time options file so that it's possible to
revert to common options. If no END-CHOOSE directive is present
then the last CHOOSE section continues until the end of the file.
(All existing uses of CHOOSE already behave that way.)
Change the Guidebook to refer to OPTIONS=x, AUTOPICKUP_EXCEPTION=y,
CHOOSE=z, and so on as "directives" rather than "statements". It
just feels like a better fit.
Add ^X (as "Attributes (extended status)") to the "Info" drop down
menu, also Overview, and Annotate.
Attributes and Overview work, Annotate results in running southeast.
Existing entries Conduct, Adjust, and Skills execute nethack's '?'
command so I didn't bother holding back on adding Annotate. Other
existing entries (Inventory, Discoveries, Spells, and Name) work.
If there's any sort of pattern involved, I'm not seeing it.
The Game menu has "Save", which shows up and works, but that's
supposed to be followed by "Quit" which doesn't show up when the
menu is used. This doesn't attempt to deal with that.
Command+q keystroke, which should close the application, behaves
the same as previously mentioned "quit nethack" in nethack menu:
runs nethack's '?' command and then resumes play.
Prevent an infinite loop that occurred if player clicked on the
close window button and then tried to cancel out of that in the
dialog it brings up.
I don't know whether Qt interface on platforms other than OSX
need this but they're getting it. The choices are changed from
"Save" or "Cancel" to "Save and exit" or "Quit without saving".
Since save allows subsequent restore, not being able to cancel
out of the application shutdown should only be an inconvenience.
Unresolved issues:
I don't know whether there's any other way to bring up that dialog,
where Cancel might be a viable choice. If so, handling that might
be tricky. Quit should definitely be available as an alterative
to Save, but that type of dialog doesn't seem to allow more than
two choices.
Picking "nethack" from application menu and then "quit nethack"
from the resulting pull down menu results in executing nethack's
help command (the '?' menu) and then just resumes play.
Add Michael's fix for control+x.
The enum name of the argument suggests that option+x should have
been sending control characters but that wasn't the case for me.
Before this fix, both control+x and option+x behaved like dead
keys, not transmitting anything for nethack to use. After this
fix, control+x sends ^X as desired but option+x is still dead.
options.c gave some unused variable warnings in the 'msg_window'
parsing if compiled without having tty enabled.
The 'msg_window' option should be available if either tty or curses
is the interface in use, hidden otherwise. The code to parse it
was included if TTY_GRAPHICS is enabled, so it worked in curses for
a tty+curses binary but not curses without tty one. This fixes that.
It is still displayed by 'O' when X11 or Qt is in use if the binary
also supports tty or curses. I've left that as is.
Testing some hints revisions resulted in some bafflement which
turned out to be caused by 'make spotless' in the dat subdirectory
not removing 'options'. It wasn't removing several other generated
files either. That used to work but got clobbered when the lua
special levels replaced levcomp and dgncomp.
