Enable 'debugging' function calls, including error(), from the lua files
called by the wizard-mode #wizloadlua command. Without enabling them,
calling error() still produces an error but with a message like
"attempt to call a nil value (global 'error')" instead of the one
specified in the lua file.
I think this is the right way to do this without just enabling
everything across the board (which I assume would contradict the goals
of NHL_SANDBOX), but I will admit to being a little confused by trying
to understand exactly how the sandbox permissions work, so it's possible
this isn't the right solution.
Incidentally, I am probably misunderstanding this, but considering a lua
error still occurs when error() is called, just with a different error
message, is the function really "disabled" successfully by NHL_SANDBOX?
Make #migratemons command be unconditional. The show existing
ones part is now always present. Compile-time DEBUG_MIGRATING_MONS
controls whether the create N new migrators part is available.
Fix creating new ones from the Castle level. It knew how to find
the next level (Valley) but wouldn't send monsters there because of
its Is_botlevel() check.
- Don't show attacking a peaceful or tame monster, as
that is actually swapping places with them - so add that.
- Don't show naming a hostile monster - it's usually not
wanted, and this way when clicking a hostile monster, the
only entry is the attack, so will be executed automatically.
This makes it much more usable.
Previously the mouse clicklook mentioned every tile that matched
the character symbol, leading to overload of information and
if playing with tiles, it was mostly useless. Also the most
important bit - the tile info - was last in the text.
Now mouse clicklook only reports the exact tile information
that was clicked on.
If there are any migrating monsters, #migratemons offers a chance
to view them; display the list in arrival destination order rather
than the arbitrary migrating_mons order. Doesn't change the list's
order and doesn't apply to viewing 'c' (mons aimed at current level)
or 'n' (mons aimed at next level), just to 'o' (other, neither 'c'
nor 'n') and 'a' (all migrating mons).
A typo in the code added to #migratemons resulted in bad output when
listing a subset of migrating monsters if there were any aimed at the
next level. Didn't affect listing 'a'll because the incorrect code
wasn't reached in that situation.
My change to allow binding the mouse buttons made getpos
push the mouse commands into a command queue, so when you
were asked for a map location, clicked on it with a mouse,
you'd first get the expected effect, and then (most likely)
immediately traveled there.
Change getpos to clear the commands bound to the mouse buttons,
and restore the binds afterwards.
Instead of hardcoding mouse button actions, allow the user to
bind mouse buttons to extended commands. For example the new
defaults are:
BIND=mouse1:therecmdmenu
BIND=mouse2:clicklook
Currently a bit rudimentary; the defaults should be OK, but
documentation is bit lacking, and in-game binding and option
saving are missing.
Allowed commands to bind are "nothing", "therecmdmenu", "clicklook",
and "mouseaction". Clicklook replaces the "clicklook" boolean option,
and mouseaction does what mouse 1 button used to do - a context sensitive
action.
The #name default key was 'N', but that gets bound to #runsoutheast
when not using number_pad. Swap around the default #name key to M-n,
and bind the 'N' to it in commands_init instead.
The number_pad option wasn't getting saved because it has a separate
handler - mark the option as changed even if the value did not change
so it will be saved to the config.
Remove 'I' for remembered, unseen monster if it is successfully killed
as well as when a kill attempt reveals that there is nothing there.
When killing engulfer, don't report it to be "unseen" since hero is
able to recognized it by touch.
Preceding #options or the key bound to that with m runs 'advanced'
options. Implement the inverse: preceding #optionsfull or the key
bound to that with m now runs 'simple' options.
Update the menu for the help command to change
"i - using the 'O' command to set options"
to
"i - using the '#optionsfull' or 'm O' command to set options"
(examples assume default key bindings but the actual help menu shows
currently bound keys; the "or 'foo'" part is omitted if #optionsfull
is bound to a key).
dat/opthelp should probably be updated to describe how doset_simple
works since that is different from normal menus and explicitly
contradicts the existing description for boolean settings being
deferred until the menu gets dismissed. Any changes need to make
sense if displayed in the context of picking '?' in #optionsfull.
Maybe a separate help file and separate entry for it in '?' menu?
This replaces the old pushq/saveq arrays (which were used to save
the keys pressed by the user for repeating a previous command)
with a new command queue. This means there's no hard-coded limit
to the saved keys, and it can repeat extended commands which are
not bound to any key.
Entering a count to repeat an action stopped working for counts greater
than 2 after 93db2a8: the unconditional call to reset_cmd_vars at the
top of rhack was resetting many more variables than had previously been
cleared at that point, including g.multi (which in this context tracks
how many more times the requested action should be repeated). As a
result any count would perform the requested action twice at most.
Reduce the list of variables zeroed out at the start of rhack back to
what it was before 93db2a8.
M-<key> shortcuts with altmeta enabled weren't working when preceded by
a count (e.g. 2 M-j for "jump twice"): g.program_state.getting_a_command
determined whether <esc> should be read as staring a potential meta key
combination, and was being reset by readchar on the first digit entered
without being reactivated for subsequent input. As a result, by the
time the player entered the actual command to be modified by the count,
readchar wasn't bothering to look for M-<key> sequences.
Add a #saveoptions extended command, to allow saving configuration
settings from within the game. This is still highly experimental,
and gives plenty of warnings before asking to overwrite the file.
Lack of option saving is one of the biggest complaints new players
have, so this should help with it. More experienced players with
highly customized config file should not use this feature, as it
completely rewrites the file, removing all comments and non-config
lines.
Make the default options menu only show the most important
options, split into categories. The full, traditional menu
can be accessed by using the m-prefix.
Extend the wizard mode #migratemons command. Instead of just asking
for how many random new monsters to be sent to the next level, first
describe how many migrating monsters there already are, then if that's
non-zero ask whether to show them. Choices are 'c' for ones scheduled
to arrive at the current level if hero leaves and returns, 'n' for
ones aimed at the next level, 'o' for ones that aren't in either of
those two categories, 'a' for all migrating monsters, and 'q' to skip.
After that, ask how many to make for the next level. The default for
that is still zero.
For the 'o' and 'a' cases, they're displayed in the reverse order of
when they went onto migrating_mons, not sorted by destination level.
The new test in m_detach(mon) to check whether mon was already detached
is being tripped for trolls who died, revived, and died again. Clear
out the MON_DETACH bit when saving montraits.
Check for the possibility of dead monsters on fmon when removing
everything from fmon. Mustn't pass a pending dead monster to
mongone() and get rid of it twice.
The bookkeeping for number of dead or removed monsters got out of sync
if a shopkeeper, temple priest, or vault guard on the migrating_mons
list who was scheduled to return to the current level got passed to
mongone() when #wizmakemap destroyed the current level in order to
replace it.
When getting rid of such monsters, first put them on fmon. Once 'gone'
they'll still be on that list and dmonsfree() will include them in the
tally of dead or removed monsters and hopefully the count will match
the number it thinks were pending.
This works for a vault guard; I didn't try for shopkeeper or priest.
Ditch pet(s) so that they won't kill stuff and open up map spots while
you're waiting for guard activity; enter vault away from the wall
nearest to 'civilization'; fill the level with lichens or other junk;
wait for guard to arrive; don't drop gold. After a short while the
guard will try to teleport next to you but with the level full will
end up in limbo instead (migrating, scheduled to come back to current
level). Then perform #wizmakemap. Prior to this patch, there will be
an impossible about N removed not matching N+1 pending; after it, no
such impossible.
... unless there's some other form that would override the choice,
such as a worn dragon armor, lycanthropy, or vampirism.
The polymorph will be in effect for 10-24 turns.
back into play with bad data
I don't have a test case to verify the fix, and I'm not absolutely
certain that the cause has been correctly diagnosed, but I think the
problem was caused by a guard being sent into limbo because the map
was too full to place it, then while it was on the migrating monsters
list waiting for a chance to come back the fuzzer executed #wizmakemap.
If the hero left the level and subsequently returned, the guard would
arrive back but monst->mextra->egd contained data for the previous
incarnation of the level that's invalid for wizmakemap's replacement.
Treat any shopkeeper, temple priest, or vault guard who is not on his
'home' level like the Wizard has been treated since 3.6.0. When
leaving the level they're on, put them on the migrating monsters list
scheduled to return to present position instead of stashing them in
the level's data file. That way they can be accessed from any dungeon
level, so wizmakemap can pull ones for the level it's replacing off
the migrating monsters list when removing the old level's monsters,
handling both migration-pending and already-arrived-on-another-level.
Bonus fix: put monsters who are on the migrating_mons list solely in
order to be accessible from other levels back first when returning to
the level they're on so that pets and the hero can't hijack their spot
when those arrive. The Wizard has been vulnerable to that.
Not fixed: #wizfliplevel command needs to flip parts of shk->mextra->
eshk and priest->mextra->epri for shk or priest on migrating_mons.
Vault guards don't contain anything flippable when migrating, but do
have coordinates that need fixing up while they're maintaining a
temporary corridor to/from the vault.
Change u.{dx,dy,dz} from schar to int and get rid of unused u.di.
Remove just added getdir_ok2click; it was declared as int but being
assigned booleans. Rename getloc_click to getdir_click and have
getdir() use it for both input and output.
A simulated mouse is becoming quite a nuisance for something which
will probably never be used by anyone in actual play.
When getdir is given '_' as a direction, it calls getpos to get a
map location rather than just a direction. Have getdir()'s caller
explicitly enable that so using '_' for other than #therecmdmenu
doesn't produce a delta that's farther than one step away.
One of the drivers of this change was that screen coordinates require a
type that can hold values greater than 127. Parameters to the window
port routines require a large type in order to be able to have values
a fair bit larger than COLNO and ROWNO passed to them, particularly for
their use to the right of the map window.
This splits the uses of xchar into 3 different situations, and adjusts
their type and size:
xchar
|
-----------------------
| | |
coordxy xint16 xint8
coordxy: Actual x or y coordinates for various things (moved to 16-bits).
xint16: Same data size as coordxy, but for non-coordinate use (16-bits).
xint8: There are only a few use cases initially, where it was very
plain to see that the variable could remain as 8-bits, rather
than be bumped to 16-bits. There are probably more such cases
that could be changed after additional review.
Note: This first changed all xchar variables to coordxy. Some were
reviewed and got changed to xint16 or xint8 when it became apparent that
their usage was not for coordinates.
This increments EDITLEVEL in patchlevel.h
(user-side decisions really, but as it stands right now
user-side decisions/options are made and processed by the core)
add a parameter to add_menu so color can be passed
release_hold() checked for (Upolyd && sticks(g.youmonst.data)) before
checking for (u.uswallow) and it could set u.ustuck to Null while
u.uswallow remained set to 1. dmove_core() was accessing u.ustuck->mx
and u.ustuck->my after that, resulting in a crash.
This fixes that particular case but there might be others that also
assume sticky poly'd hero should be handled before swallowed hero.
Being swallowed/engulfed needs to be handled first.
If is mon not sensed or seen and you use #wizkill to kill it, report
"You kill an unseen mon." rather than just "You kill the mon." Also,
override hallucination when identifying the victim.
apply.c:495:22: warning: variable 'optr' set but not used [-Wunused-but-set-variable]
struct permonst *optr;
^
1 warning generated.
cmd.c:4577:26: warning: variable 'how' set but not used [-Wunused-but-set-variable]
const char *dothat, *how;
^
cmd.c:4578:29: warning: variable 'viawindow' set but not used [-Wunused-but-set-variable]
boolean prefixhandling, viawindow;
^
2 warnings generated.
The old code to supply a list of directions if a prefix was followed
by a non-direction didn't work as intended anymore. Add some more
precise feedback for gGF mis-use and comment out some code that never
gets executed.
A number_pad user can get a complaint about 'G' when using '5' followed
by a non-directional command. Too bad for them.
Supersedes pull request #803
