nethack-gwaa-kiwi/nethack
1
0
Fork 0
Code Pull Requests Activity

bogus status updates

Browse Source 
I finally figured out why status gets updated periodically even if
none of the fields have changed.  Once a temporary highlight times
out, it starts a cycle of timeouts every 'statushilites' turns.  When
I worked on this before, it was convoluted but not this convoluted.

In moveloop, if 'context.botl' call bot; in bot
  call evaluate_and_notify_windowport;
  for each field, call evaluate_and_notify_windowport_field:
    call hilite_reset_needed and set 'reset' to the result;
    if 'reset' is True then do status_update
      and set 'curr->chg' and 'prev->chg' to True.
Then in moveloop call status_eval_next_unhilite:
  for each field
    if 'curr->chg' set 'curr->time' to moves+hilite_delta;
    on the call after hilite_delta ('statushilites') moves,
      call hilite_reset_needed which returns True if there is any
      rule for temporary highlight and set 'context.botl'.
Go back to start.  If multiple fields had temporary timeouts and
they were activated on different turns so expired on different turns
you could conceivably end up with context.botl being set every turn.

My first writeup trying to explain all this was wrong.  I won't
testify about the accuracy of this one in court....

This extends the highlighting data structure to track the current
rule that's in use.  And for that to make sense, it eliminates the
merging of settings from multiple matching rules.  So anybody with
 hit-points/up/inverse
 hit-points/up/green
 hit-points/up/bold
will need to manually merge their rules like
 hit-points/up/green&inverse+bold
or else whichever rule matches last will be the only one in effect.

There are a lot of miscellaneous changes made as I flailed about.
The three most significant ones are that there is no guesswork over
what kind of highlight rule is in effect, status_eval_next_unhilite
will only set a timeout value if the current rule is for a temporary
highlight, and hilite_reset_needed will only return True if a timeout
is for a temporary highlight (probably moot after the _next_unhilite
change).
This commit is contained in:
PatR
2019-03-31 00:33:33 -07:00
parent 4ca8f6428b
commit c63d3fbfbb
2 changed files with 165 additions and 167 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
doc/fixes36.2
View File

@@ -1,4 +1,4 @@
$NHDT-Branch: NetHack-3.6.2-beta01 $:$NHDT-Revision: 1.290 $ $NHDT-Date: 1553904170 2019/03/30 00:02:50 $
$NHDT-Branch: NetHack-3.6.2-beta01 $:$NHDT-Revision: 1.291 $ $NHDT-Date: 1554017610 2019/03/31 07:33:30 $
This fixes36.2 file is here to capture information about updates in the 3.6.x
lineage following the release of 3.6.1 in April 2018. Please note, however,
@@ -403,6 +403,9 @@ Valkyrie quest was supposed to have a 50:50 chance that northern drawbridge
lowered: 3/8, S down+N up: 3/8, N down+S up: 1/8, both raised: 1/8
shorten the getpos prompt for teleport destination so that it won't yield a
--More-- prompt for the help hint (--More-- still possible when riding)
once a status highlight for a temporary rule ('up', 'down', 'changed') timed
out, further spurious status updates (evaluating all fields) would
occur every 'statushilites' turns even if no fields had changed
Fixes to Post-3.6.1 Problems that Were Exposed Via git Repository