Add threshold relationships <= and >= so that the change to make <
and > perform their expected comparison can be resolved. "Point
release shouldn't force players to update their config files" does
not carry sufficient weight given that they already had to do that
to turn on status highlighting when going from 3.6.0 to 3.6.1. The
3.6.2 release notes can warn them about the need to update their
status highlight options if they're currently using '<' and/or '>'.
Entering new hilite rules via the 'O' command accepted '=' prefix
for numbers, but rules from config files did not. Now they do.
The '=' prefix is optional in both situations.
With 'O', percent rules and absolute rules had separate menu entries
so picking one was already choosing the rule type, but entering a
numeric value without percent sign (for percent) or with one (for
absolute) would change the type on the fly. If someone has already
picked percentage they shouldn't be required to append '%' to the
digits, so that is now optional. If explicitly included with the
number after having picked absolute, the value is rejected. It is
trivial to back up in those menus and choose the alternate type if
someone changes his/her mind part way through.
If a status field has both persistent (percent, absolute, always)
and temporary highlights (up, down, changed), give the temporary one
precedence when the value has changed. To do that with 3.6.1, the
rules for temporary had to follow the ones for persistent highlights
since whichever matched last was the one used. Now their order
relative to each other doesn't matter. If a value increases and
there is both an 'up' rule and a 'changed' rule, the more specific
'up' takes precedence, regardless of their relative order; likewise
for decreases and 'down' vs 'changed'.
There were a couple more tweaks needed to support negative values;
I overlooked the 'O' menu handling before. >-1% and <101% now work
for both the config file and interactive adding via 'O' methods of
defining highlight rules, although new >=0% and <=100% will be
clearer to anyone examining a rule set.
'enum relationship' was forcing LT_VALUE to be -1 but that fact was
never utilized anywhere, and the code was using magic number -2 to
mean "no relationship yet". This adds NO_LTEQGT to replace the
latter and gives it value -1. EQ_VALUE is still 0 so effectively
the default if a highlight hasn't been fully set up yet. LT_VALUE
is now just another positive value along with GT_VALUE, LE_VALUE, &c.
The Guidebook hasn't caught up with the code yet.
The rule choosing code used when deciding how to highlight something
only supports 'int' fields and relies on 'long' having the same bits.
It needs to be extended to support 'long' properly. Fixing should
be straightforward (except maybe for the initialization of min/max
best fit handling) but this doesn't address that. Also, data type
for encumbrance/carrying-capacity should be changed from unsigned to
plain int so that no extra handling for just one field will be needed.
Negative AC needed one extra change to support >-N since there was
a place in the code that assumed 0 was the lowest possible value.
(My earlier testing was with <-N which didn't have that issue.)
Make '/<N/' work as 'val < N' instead of 'val <= N', and />N/ work
as 'val > N' instead of >=. The <= and >= behavior might have been
intentional but the only support for that I could find was that
the 'O' menu used "N or less" for '<' and "N or more" for '>' when
setting up 'absolute' rules. If we actually want <= and >= (and we
probably do...), we should add them as more relationship operators
instead of misusing < and >.
Simplify the is_ltgt_percentnumber() case when parsing options
since input has been fully validated by the point that that test
passes. Among other things, /<-0/ and />-0' are now accepted (as
synonums for 0; -0 doesn't mean anything special) instead of being
silently rejected and then discarding the rest of the config file.
(That bad behavior is a separate issue not dealt with here.)
The code to choose a likely target when applying a polearm was
basing its decision on visible spots which contained monsters,
so could expose the location of a hidden monster if there was
only one such spot within polearm range. Not mentioned in the
report: it also wouldn't pick remembered, unseen monster unless
there was a monster still at that spot.
I've changed it to choose candidate location based on the glyphs
shown rather than on the presence of monsters.
Orc heroes get an extra food item ("to compensate for generally
inferior equipment") and it could randomly be lembas wafers (or
cram rations), and Ranger heroes always started with cram rations
even when they're orcs. Fixing the latter was simple, but the
normal race-based substitutions weren't applied to randomly
generated items, so the fix for the former required a bit of code
reorganization in ini_inv().
Elf heroes already get lembas instead of cram; do the reverse for
dwarves (although I don't think this case can happen--no role gets
lembas wafers and only orcs and always-human tourists get random
food); give orc heroes tripe instead of either lembas or cram.
> [1. perm_invent is kept in flags so persists across save/restore, but
> perm_invent capability can change if player restores with a different
> interface--or same one running on a different-sized display--so it
> ought to be in iflags instead.]
Not addressed here.
> 2. perm_invent window does not get updated when charging a wand (or
> other chargeable item presumably), with a scroll of charging.
Most scrolls rely on useup() -> update_inventory(), but charging uses up
the scroll early so that it will be gone from inventory when choosing an
item to charge. It needed an explicit update_inventory() after charging.
> 3. update_inventory(), is called from setworn(), which is called from
> dorestore(), when loading a save. Segfaults have been observed in
> variants based on this code (though not yet in vanilla 3.6.1), so it's
> possible this may be unsafe. The update_inventory() call in setworn()
> could be protected with "if (!restoring) ..."
tty doesn't support perm_invent, so this might be a win32 issue.
I've made the suggested change, but a better fix would be to turn off
perm_invent as soon as options processing (new game) or options restore
(old game unless/until #1 gets changed) has finished setting things up,
then turn it back on at the end of moveloop()'s prolog when play is
about to start.
= =
Most of the read.c change is reordering prototypes to match the order
of the corresponding functions. I did this when adding a new static
routine, then ended up discarding that routine.
There was a prior report about this but I can't find it; maybe it
didn't go through the web contact form. Anyway, status_hilite
threshold numeric values wouldn't accept a minus sign before the
digits, preventing negative AC values from being tracked.
The 'O' menu's 'list' for MSGTYPE settings showed truncated versions
of really long message strings but didn't show anything except the
hide/stop/norep setting for ordinary length ones. 3.6.0 showed the
latter correctly but suffered buffer overflow for the former; the
fix for that had a typo/thinko in it.
Noticed while testing the fix for the recently reported clairvoyance
bug. I saw a '1' move onto an 'I', then when it moved again the 'I'
reappeared. The remembered unseen monster couldn't be there anymore
if the warned-of monster was able to walk through that spot, so
remove any 'I' when showing a warning (digit) to stop remembering an
unseen monster at the warning spot.
Nobody has ever reported this so fixing it isn't urgent, but fixing
it is trivial so I'm doing it in now (without the clairvoyance fix).
I think this is needed to avoid inevitable questions/confusion.
Having the git hash in the version string of official binaries
is a very good thing, however.
Instead of replacing the check for DRAWBRIDGE_UP with one for
DRAWBRIDGE_DOWN, the correct fix is to check for both because
replacing either one with water breaks the two-square dbridge.
H7074 1311
> When moving from a pit into an adjacent pit, you "fall into" the pit and take
> damage. This happens even when you are walking back and forth between two pits,
> repeatedly, where you should have no way to fall.
>
> The intent seems to be that you can move into the adjacent pit without having
> to climb out of the first one, and this works properly - the only problem is
> that the pit gets triggered when you ought to have no distance to fall.
This is really just stumbling over uncleared clutter, not a pit fall.
There was already a way to clear the clutter between adjacent pits.
The #wizwhere command (formerly ^O) has given the location of the
invocation position when on the relevant level for ages. It was
extended in 3.6.0 to give magic portal location when on the any
of the four elemental plane levels. Extend it again to show the
location of any magic portal when on a level which has one (so an
extra line of feedback at end of ^O output for quest entry, quest
home, Ft.Ludios entry once that's been assigned, and Ft.Ludios).
Allow the 'm' prefix for wizard mode level teleport command. Using
it skips the initial prompt for level destination and goes directly
to the menu of special level locations that you get when answering
'?' to that prompt.
Some github feedback pointed out that getting annotation input from
the player behaved differently from similar input for naming of
monsters and objects. The complaint stated that hitting <return>
without supplying any input removed the old annotation, where other
naming would leave the old name intact. 3.6.0 did misbehave that
way; current code does too if EDIT_GETLIN is disabled but behaves
as desired when it's enabled. (There's nothing that I can spot in
donamelevel() to explain why. I'm confused. Is tty_getlin()
returning the default answer instead of empty if that default text
is deleted at the prompt and no new text entered prior to <return>?)
Make donamelevel() work like mon/obj naming. Empty input leaves
existing annotation, if any, intact.
Having the autodescribe feature enabled and moving the cursor onto
a statue yields "statue of a <mon>" under normal circumtances, but
when done while hallucinating the feedback was just blank (because
the lookat() code couldn't find any monster at statue's location).
Now it will be "<random mon>" (not "statue of a <random mon>")
instead, same as when moving cursor over glyphs of actual monsters.
