Dungeoneers list updates
Ingo Paschke provided Amiga updates to get the port working
for the release to follow 3.6.7. He used the gcc-15.2 branch
of bebbo's Amiga toolchain on Linux.
G. Branden Robinson contributed several updates and suggestions to
help ensure that the *roff documentation production remains viable.
armorstatus, and terrainstatus
This adds three special status items to show at a glance what the hero
is wielding, wearing, and standing on.
Each of the three items has its own boolean option rather than try to
fix them in with the existing opttional status conditions. After a
lot of testing, I think the weapon and armor ones will prove useful
but the terrain one probably won't be.
Presently it is implemented for tty and curses. When I developed it
six years ago, it was also working for X11 but I'm not able to test
the resurrection of that part so have left it out.
This removes or updates several true rumors that have become
misleading or inaccurate due to changes to the mechanics they were
describing, and adds several new rumors describing mechanics that
are either new, or are intended to be a larger part of the game
than they were in previous versions.
More oracularities describing the new mechanics are needed, but I
haven't managed to get into the write frame of mind to write in the
Oracle's voice yet...
When playtesting NetHack heavily, I observed that most of the time
it wasn't placing much strain on my wrists, but Sokoban was an
exception: travel, farmove, etc. can normally be used to avoid the
need to spam keys, but they don't work while pushing a boulder, and
the boulders often need to be pushed along precise routes, so you
have to tap out every movement. This becomes particularly straining
when pushing in the last few boulders, as you have to push them a
long way along the goal corridor.
This commit adds rolling boulder traps to Sokoban that will
automatically roll boulders along the goal corridor, meaning that
you don't have to push them there manually. This considerably
reduces the number of keystrokes needed to solve Sokoban, without
making any significant change to the difficulty of the levels.
Some of the designs had to change slightly in order to make room
for them, but not in a way that meaningfully changes the solution.
- bmp2iff_host: convert nhtiles.bmp to Amiga IFF tile files. Uses
the AMIV UI palette in pens 0-15, remaining pens filled with tile
colors sorted by frequency.
Usage: bmp2iff_host -planes N input.bmp output.iff
- xpm2iff_host: convert XPM to IFF for tomb.iff (RIP screen).
Adapted from xpm2iff.c, Copyright (c) 1995 Gregg Wonderly.
- Auto-select tiles32.iff (5 planes) or tiles16.iff (4 planes)
based on screen color depth at runtime.
- Fix NO_GLYPH in amiv_lprint_glyph: return early to prevent
blitting with uninitialised data (caused black spots).
- Add AmigaFont symbol set to dat/symbols for AMII text mode.
Add a new parameter to des.monster, m_lev_adj, which is a level
adjustment for the monster. This only applies to the monster's
level, so basically only affects the spellcasting, it does not
change the monster's hit die or inventory.
Change one of the shamans in Orctown to be 3 levels higher.
Change 'v' from #versionshort to #chronicle.
Change 'V' from #history to #versionshort.
History can still be accessed either directly with the extended command,
or via the help menu.
Versionshort now accepts the m-prefix, and then shows the longer version.
As of the change to allow for item probabilities that don't add up
to 1000, it's become a little difficult to figure out the exact
probabilities from the source code, which makes it hard to balance
item generation. Adding a tool to list the probabilities helps.
Part of the problem is that changing an item's probability without
balancing it elsewhere is usually wrong: doing that would in effect
take the probability equally from (or add the probability equally
to) all other items in the class, which might break the balancing
of those items due to the probability change.
As such, it is usually better to make an intentional decision about
which items should be less and which items should be more likely to
generate, then change them in a balancing way (meaning that the
probabilities of objects that weren't intentionally changed remain
unchanged). Doing a complex such change makes arithmetic errors
fairly likely, though, so it's useful to have a command that verifies
that it's been done correctly.
This command is primarily intended as a development aid, so it's
included only in debug builds and pre-release builds (the same as
other similar commands like #wizmondiff).
These are displayed in discoveries, and a new 'price_quotes' option
allows them to be displayed for un-IDed objects in other contexts
too (the idea is that you turn on the option while identifying
objects and off for general play).
Invalidates existing save files.
This adds a "reroll" option that lets players reroll their
character's attributes and starting inventory. Although I generally
think doing this makes the game worse, a) some players are going to
do it regardless and b) if a player is going for a challenge game,
rather than to win, it may be required. So in the absence of an
option like this, players repeatedly start and quit games instead,
creating a large number of junk logfile entries and generally
causing problems for other players on the same shared machine
(because repeatedly reloading the game is very CPU-intensive).
This should in theory be windowport-agnostic (although in practice
it may not be). Tested on tty, X11 and curses; on tty and X11 it
works fine (although X11 treats the change in attributes as
something that needs a status highlight), on curses it is slightly
jankier in terms of what other windows are drawn in the background
(but still plays correctly and I suspect this is a pre-existing
bug).
To form a complete implementation, we will need to consider the
following:
- Should there be a delay on a) starting the game and/or b)
rerolling? If so, what should it be (maybe configurable via
sysconf?)
- Should we take more steps to discourage players from rerolling?
It would be bad if players see the option exists and turn it on
just because it exists, or (worse) treat it as condoning the
particular style of play.
- Should we take steps to detect that players are rerolling
manually and a) tell them to use the option instead, b) tell them
that this is not an intended way to play (and may make the game
less enjoyable and/or prevent them getting the practice they need
to eventually win)?
Breaks save and bones files.
Data typo affecting '?' command's "longer explanation of game options".
Change the indication of menu_objsym's default value from [5] to [4]
since 4 is the actual default value in the code and the Guidebook.
Add some basic spellcasting stuff to the tutorial: read a spellbook,
cast a spell. If the hero doesn't have enough energy, just adds
a note saying so.
Remove/restore the known spells when entering/leaving the tutorial.
Seems like several new players did not find the "hidden" stairs.
Add iron bars to show a glimpse of them - the hero still needs
to find the secret door in to the room.
Francium-223