When mklev() is called multiple times, previous state stored in the
xxstairs_room pointers can be mistakenly used when making decisions about
the new level being constructed. This caused non-deterministic level
creation behavior when replaying from a snapshot.
With 'popup_dialog' On, a prompt which exactly fills the available
width would start the next line with a space (to separate the prompt
from user's answer) and then have the cursor waiting after it. That's
unlike other behavior in the curses interface where the line split
would be instead of the separating space rather than in addition to it.
Old:
|long prompt?|
| X__________|
New:
|long prompt?|
|X___________|
where the X represents the cursor sitting over the start of blank space
waiting for user's answer.
Fixes#202
When swallowed, you can take things from the engulfer's inventory, if
there are any, via pickup. Items might be worn by the engulfer and
when "picked up" those weren't being unworn before being added to
hero's inventory. Then they would be formatted as "(being worn)" and
could trigger warnings or worse.
Conceptually they should be worn on the outside and not be accessible
from the inside, so I've made attempts to pick up worn items fail
rather than fix up the unwearing.
Using ':' when swallowed to look at the engulfer's inventory describes
that inventory as "contents of <mon>'s stomach". That's weird for any
worn items, but the situation is so rare I haven't made any attempt to
deal with it.
Rescue some old code from bit rot. It may be useful if the shop
side of things ever gets fixed. (Itemized billing reveals container
contents. I'm sure that it's in the bugzilla list but can't find it.)
Noticed after building a curses-only binary; configuration setting
"terminal info library" is only of interest as an optional feature
when the build includes tty. There were several other settings that
apply to some interfaces and not others but would be listed if the
feature was defined (possibly after building for an interface which
supported it, then left in place when switching to another which
doesn't).
I left most of those with commented out conditionals in case other
interfaces start supporting them. So you might still get something
like "tiles file in XPM format" for a binary that doesn't support
tiles if USE_XPM has been defined for some reason.
If a player names an object with a name that ends in '\\', drops
that object on the floor nearby and does a look at nearby objects,
then the game will crash. This is caused by stack corruption when
the decode loop skips over the decode string terminator.
Extend support for highlight rules that specify percentages from HP
and spell power to experience level and experience points. For both
of those, the percentage is based on progress from the start of the
current Xp level to the start of the next Xp level. 100% isn't
possible so is used to enable highlighting a special case: 1 point
shy of next level, most likely to occur after losing a level.
This is something I had in mind a long time ago and then forgot all
about until fiddling with the final disclosure of experience points
recently. It turned out to be trickier than expected because it needs
to check whether Xp should have a status update when it hasn't changed
but Exp has gone up. The latter might hit a percentage threshold that
switches to another highlight rule. Fortunately changes to Exp, at
least that aren't part of level gain or loss (which always trigger
status updating), are all funnelled through a single place (I hope).
Highlighting via attributes got broken three months ago. May or
may not have been noticeable depending upon which attributes are
supported. Too many variations of attribute designations...
If you ask for help when wishing, don't leave "help" in the buffer
for EDIT_GETLIN to use as default answer on next retry. It does still
leave anything rejected as unknown so that the player has a change to
review the spelling and conceivably add and/or remove from the end
witout having to retype everything.
When I implemented getmsghistory()/putmsghistory() for curses I was
assuming that DUMPLOG would only be used with tty, but it is interface
neutral and can be used with curses (or others). So curses message
history needs to behave like tty message history and be sure to pass
along messages that bypass pline() and the normal message window.
(Mainly one-line summaries of long quest messages, but also old
messages fetched from a save file and available to be re-saved without
having been shown if new session doesn't generate enough new messages
to flush them.)
Wizard mode shows the number of points needed to reach the next level
(unless already maxxed out at 30) for ^X and end of game disclosure.
Do it in normal play for the latter too. (I think it would ok to do
that for ^X too but haven't gone that far.)
Even when it was wizard mode only, the phrasing for past tense had a
minor grammar bug, and it could make the line a little too long for
tty and curses (not sure about others) when level was high, resulting
in wrapped text. That looked bad for tty, which first tries removing
indentation (just 1 space in this case), making that line outdented
as well as wrapped. So change the phrasing slightly when experience
level is 'too high'. I had a version which formatted, measured, and
re-formatted if necessary but that was overkill; simple hardcoded
rephrasing suffices particularly when measuring was against assumed
display width (80) rather than actual width.
TRAVIS CI added Windows to their platform list in late 2018.
Update the .travis.yml file to include a pair of Windows in
machines in the testing suite, one built with visual studio
command line tools and the other with mingw gcc tools.
The visual studio build is currently using nmake with the
sys/winnt/Makefile.msc Makefile from our distribution,
That's the same process we've been using for building
our binaries, pretty much.
BRH may be able to modernize it over the next couple of
weeks to use the msbuild process instead.
I went with the HINTS environment variable on windows
for consistent self-documenting purposes, even though
the environment variable isn't used on windows.
included:
os: linux
Compiler: gcc C
HINTS=linux
os: linux
Compiler: clang C
HINTS=linux
os: linux
Compiler: gcc C
HINTS=linux-x11
os: linux
Compiler: gcc C
HINTS=linux-qt5
os: linux
Compiler: gcc C
HINTS=linux-minimal
os: windows
language: shell
HINTS=Windows-visual-studio
os: windows
HINTS=Windows-mingw
excluded:
os: osx
Compiler: clang
Xcode: xcode10.2 C
HINTS=macosx10.14
