Jumping, Newton's 3rd Law hurtling, and throwing an iron ball:
attempting to do any of these in such a way that you would diagonally
pass between boulders/walls causes the Luck penalty. However, none of
these actually get you through the diagonal gap, thus they can't be used
to cheat and the penalty doesn't make sense.
For much the same reason as the horizontal teleport message: various
forms of level teleportation produce no message indication at all that
you just ended up somewhere else.
It's useful to get a message as indication you suddenly moved somewhere.
For instance, MSGTYPE=stop can be used on this to avoid bumbling in the
wrong direction after a spontaneous uncontrolled teleport.
This feature is originally from SliceHack, but the original code
directly edited the monmove code, whereas I thought it was cleaner to
use the existing mtrapseen code. Thus, this commit just marks trapdoors
as "seen" for all non-mindless monsters generated in the Castle level
(the same way all monsters in Sokoban are marked aware of pits and
holes).
This change prevents these Castle monsters from moving onto trapdoors
97.5% of the time. (A determined player can still patiently sit and wait
for everyone in the castle to plunge like lemmings into the trapdoors,
but it will now take 40 times as long.) Also unlike SliceHack, this only
excludes mindless monsters - not all non-humanoids. There are plenty of
intelligent non-humanoid monsters generated right next to the trapdoors,
after all.
This is aimed at better flavor (the inhabitants of the castle should
know about the traps in their own area) and better scenery in the Valley
(doesn't seem as much of a valley of the dead if there are hordes of
soldiers milling around down there).
I considered sticking an in_mklev condition onto this if statement, so
that monsters spawned into the Castle after its creation will fall down
the trapdoors, but ultimately decided against it.
Rather than just informing the player that saving and reloading might
fix the problem, they are now encouraged to report the problem to the
value of DEVTEAM_EMAIL. If the sysconf specifies SUPPORT, that is also
presented as an option.
Message is a reference to The Silver Chair. Most of the other races had
their own messages already, but gnomes would just default to discussing
dungeon exploration, which doesn't make that much sense most of the
times when you would be chatting to them in their own mines.
The quotation is edited from the source to reflect the dungeon
environment, but the sentiment is actually pretty spot-on given the
average player's win ratio.
Note: this doesn't interfere with the South Park gnome speech added to
3.6 a while ago; that only occurs when hallucinating and this only
occurs when not hallucinating.
From SliceHack. Note that this refers to the description of the physical
bottle; it's a substitute for "phial", "carafe", "flask", etc. such as
are seen when a potion crashes on someone's head. They don't obscure the
randomized appearance or actual potion identity.
The SliceHack version evidently went through several revisions; just
take the current one.
The general idea here came from SpliceHack -- give each alignment a
unique effect in what happens to its sacrifices -- but the "puff of
smoke" in Splice seemed too small.
Triggers when you feel more confident in your skills. This is to address
a problem I have heard about several times from newer players: unless
you pay close attention to the guidebook, nothing in the game actually
indicates that you can level up your abilities and how to do it.
Experienced players don't need this message, of course; they can hide it
via MSGTYPE if they really hate it, but I additionally added a clause
that prevents this message from being displayed more than once per game
session. (It didn't seem important enough to make a save field for.)
Backported from TNNT. Only affects dumplog pline history, not any other
form of pline history.
The impetus for this is to avoid dumplogs full of "Unknown command foo."
messages which don't provide any value for people reading the file. In
many cases, these messages crowd out the actual message history, making
it hard to reconstruct what happened.
It's confusing and served no purpose; a spoiled player knew what it is,
an unspoiled player might think it was a hook-hand or something. Now
they all show up as grappling hook.
That message implied something to do with an effect happening to the
hero that causes them to feel cold, such as taking cold damage.
Change it to "You hear a deep cracking sound" instead.
This adds a boolean option, autounlock, defaulting to true. When this is
set to TRUE, messages stating that some door or container is locked are
automatically followed by a prompt asking if you would like to unlock
it, if you are carrying an unlocking tool (key, lock pick, or credit
card).
Architecturally, this extends the pick_lock function to take three
additional arguments (door coordinates or a box on the ground you are
autounlocking).
The code that selects an unlocking tool will always look first for a
skeleton key, then a lock pick, then a credit card. Since curses, rust,
and other attributes don't really have an effect on the viability of the
unlocking device, it didn't seem to warrant making a more complex
function for that.
Add hallucinatory trap names
This adds many funny, realistic, and nonsensical traps to the game, to
be shown when the player is hallucinating.
Architecturally, the biggest change is merging the what_trap macro and
the "defsyms[trap_to_defsym(ttyp)].explanation" pattern into a single
function "trapname", which returns the name of the trap, handling the
hallucination case. There is also a second parameter used for overriding
hallucination in the occasional cases where the actual trap name should
always be returned.
In addition, the what_trap and random_trap macros are now obsolete and
not used anywhere, so they are removed.
reinstate anti-rng abuse bit on hallucination
updates to hallucinatory trap names and fixes37.0 entry
It's a minor annoyance when you forget you can't do this in vanilla and
then get relocated somewhere random on the level. Since it's not a
harmful "trap", just allow the adventurer to teleport directly onto it.
This adds a boolean option, autounlock, defaulting to true. When this is
set to TRUE, messages stating that some door or container is locked are
automatically followed by a prompt asking if you would like to unlock
it, if you are carrying an unlocking tool (key, lock pick, or credit
card).
Architecturally, this extends the pick_lock function to take three
additional arguments (door coordinates or a box on the ground you are
autounlocking).
Because this adds a new field to struct flag, this is not a
save-compatible change. I have not adjusted EDITLEVEL or
VERSION_COMPATIBILITY, though.
The code that selects an unlocking tool will always look first for a
skeleton key, then a lock pick, then a credit card. Since curses, rust,
and other attributes don't really have an effect on the viability of the
unlocking device, it didn't seem to warrant making a more complex
function for that.
This adds many funny, realistic, and nonsensical traps to the game, to
be shown when the player is hallucinating.
Architecturally, the biggest change is merging the what_trap macro and
the "defsyms[trap_to_defsym(ttyp)].explanation" pattern into a single
function "trapname", which returns the name of the trap, handling the
hallucination case. There is also a second parameter used for overriding
hallucination in the occasional cases where the actual trap name should
always be returned.
In addition, the what_trap and random_trap macros are now obsolete and
not used anywhere, so they are removed.
Inadvertently reintroduced in f9f1236. It was just the conditional
that was bad: due to resolving the possible buffer underflow when
comparing to "muskox", the pluralizer now only adds -es when the length
of the string is greater than 5. So for "box" and "fox" the pluralizer
will never add the -es ending, since they are greater than 5.
This commit checks for "does not end in muskox" correctly.
copperwater