Add code to run a fuzz tester, simulating (more-or-less) random
keyboard mashing. There's no option to turn it on, you need to
set iflags.debug_fuzzer on via a debugger or something along
those lines.
Make being trapped in/on/over floor block Levitation and Flying, the
way that being inside solid rock already does, and the way levitating
blocks flight.
Blocked levitation still provides enhanced carrying capacity since
magic is attempting to make the hero's body be bouyant. I think that
that is appropriate but am not completely convinced.
One thing that almost certainly needs fixing is digging a hole when
trapped in the floor or tethered to a buried iron ball, where the
first part of digactualhole() releases the hero from being trapped.
If being released re-enables blocked levitation, the further stages
of digging might not make sense in some circumstances.
I recently realized that being held by a grabbing monster is similar
to being trapped so should also interfere with levitation and flying.
Nothing here attempts to address that.
Save files change, but in a compatible fashion unless trapped at the
time of saving. If someone saves while trapped prior to this patch,
then applies it and restores, the game will behave as if the patch
wasn't in place--until escape from trap is achieved. (Not verified.)
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.
I ended up not using this, but it might as well be included for
potential future use. Extend mlevel_tele_trap() to support forcing
a monster off the current level to make room either for the hero or
some other monster. goto_level() does something similar when the
hero is arriving on a level. This is for situations where the hero
is already there (such as divine aid attempting to fix STUCK_IN_WALL).
mlevel_tele_trap(mon, (struct trap *) 0) will usually move 'mon' off
the level, scheduled to migrate back if the hero leaves the level and
subsequently returns. 'Usually' because it doesn't work in endgame
and certain monsters are excluded regardless of dungeon location, so
caller has to be prepared to try to move another monster (or resort
to goto_level()'s unconditional forced migration).
Requested by one of the beta testers 13 months ago... when a visible
monster becomes invisible and vanishes, mark its map location with
the remembered, unseen monster glyph. (When the player zaps a
monster with a wand of make invisible, that only happens if the wand
type is known. I'm not sure that's right but didn't alter it....)
The request suggested also doing it for a monster who disappears by
teleporting away, but I haven't attempted to implement that.
Make 'zeromonst' global instead of local to makemon.c. Its address
isn't used as a special value like &zeroobj, but it is useful to
have available for initializing various pseudo-monsters.
modified:
include/decl.h
src/decl.c, makemon.c, mkobj.c, mplayer.c, teleport.c
The automated reformatting put a space in casts of the form
'(type)(expression)', yielding '(type) (expression)', but it didn't
do that for '(typedef)(expression)'. There are lots of instances of
'(boolean)(expression)'; (uchar) and (xchar) also occur. I haven't
noticed other types, but I haven't looked in very many files yet.
End of first pass, but '[&|?:][ \t]*$' doesn't catch trailing operater
followed by end-of-line comment so more needs to be done. As with the
past couple of batches, I've removed redundant parentheses from 'return'
statements but only for files that had continuation fix-ups.
I've also removed tabs from comments in some of the files, but didn't
start until part way through this subset of the sources.
Reported for pre-beta, getting "you feel disoriented" when attempting
to teleport within a level while carrying the Amulet, you still ended
up teleporting. Wizard mode allows the disorientation to be overridden
but the logic was wrong. It worked as intended when in wizard mode but
unintentionally always overrode disorientation when not in that mode.
Most of the time, rloc() is used for teleporting monsters and it's not a
big deal if they can't find somewhere to go. In a few cases, it is. I
went through all the callsites and made calls to rloc() not cause
impossible()s if they don't need to.
Fixes a bug/suite of bugs reported by ais523.
I'll push a formatting guide at some point. There may still be
outstanding changes, but please feel free to resolve those as you arrive
a them.
To the best of my knowledge, there is no changes to the actual code
content, but the formatter does have the occasional bug. If you run into
an issue, please fix it!
* Replace variadic debugpline() with fixed argument debugpline0(str),
debugpline1(fmt,arg), and so on so that C99 support isn't required;
* showdebug() becomes a function rather than a macro and handles a
bit more;
* two debugpline() calls in light.c have been changed to impossible();
* DEBUGFILES macro (in sys.c) can substitute for SYSCF's DEBUGFILES
setting in !SYSCF configuration (I hope that's temporary).
Move debugging output into couple preprocessor defines, which
are no-op without DEBUG. To show debugging output from a
certain source files, use sysconf:
DEBUGFILES=dungeon.c questpgr.c
Also fix couple debug lines which did not compile.
This also includes fixes due to Derek Ray to depugpline to work better
on other platforms.
Simplify many of the intrinsics macros from
#define xxx_resistance (Hxxx || Exxx || resists_xxx(&youmonst))
down to
#define xxx_resistance (Hxxx || Exxx)
by setting or clearing an extra bit in Hxxx during polymorph so that the
resists_xxx() check becomes implicit.
Unfornately there were lots of places in the code that treat Hxxx
as a timeout number--primarily for Stunned, Confused, and Hallucination;
Stunned happens to be one of the revised macros--rather than as a bit
mask, so this patch needed a lot more changes than originally antipated.
This might fix the following buglist entry
|Teleporting while using tiles may place you one tile beyond the edge of
|the display screen, and place the crosshair on empty space.
Various bits of code, including teleport, are assigning directly to
u.ux,u.uy instead of calling u_on_newpos(). It wouldn't be an issue for
small tiles where the whole map fits on the screen, but it probably is for
bigger ones where clipping is in operation. Using u_on_newpos() adjusts
the clipped map right away but changing u.ux,u.uy directly won't do so
until control returns to moveloop() and it eventually calls cliparound().
Usually the hero's position only changes by one column and/or row, hence
stays within the clipping margin, but that's not the case for teleport
nor for hurtling (throwing recoil while levitating, &c).
Perhaps all the places that assign u.ux,uy should call u_on_newpos()
instead? Most--all?--of them aren't updating u.usteed->mx,my, but I
guess that monster's coordinates don't matter since it isn't placed on
the map.
From a bug report,
when climbing out of Gehennom while carrying the Amulet, you could skip
a handful of levels by taking the magic portal into the Wizard's Tower,
dropping the Amulet, zapping it with a wand of teleportation--possibly
more than once--until it lands outside the tower. Then take the portal
back out of the tower and level teleport--feasible now that you're not
carrying the Amulet any more--back to the tower level and retrieve the
Amulet. Overall probably not much of a savings unless you're having
really bad luck with the mysterious force sending you back whenever you
try to go up. The hero and monsters can't teleport from inside the tower
to the outside or vice versa; this gives the same limitation to objects.
From a bug report, when reading an unknown
scroll which turns out to be teleportation, if you happened to land on
another scroll of teleportation it wouldn't be discovered yet, even
though you ought to know that type of scroll by then. Fixing it required
moving handling of that scroll into the teleport code, since discovery
depends upon where you arrive and by then it's too late for seffects() to
do anything that affects feedback for any objects you land on.
Also fixes a post-3.4.3 bug where seffects() was making decisions
based on Teleport_control without being aware that Stunned now negates it
during teleportation.
There's some discussion in the newsgroup about an engraving bug, and
while verifying that it's reproducible I've come across an unintentional
change between the current code and 3.4.3. A recent change made engraving
use accessible(), and that routine wasn't yielding an appropriate value
when applied to a raised drawbridge if the terrain in front of it was ice
or floor (ie, moat or lava had been filled in). Several places which used
the ACCESSIBLE() macro instead of the function suffer from same problem.
This doesn't attempt to address the newsgroup bug (which is that an
engraving written on a lowered bridge transfers to the underlying terrain
if the bridge is raised, even when that terrain is water or lava; the
converse case applies too, an engraving on the ground gets transfered to
the bridge when it lowers).
Forwarded from the newsgroup by <Someone>: temple priest might
abandon his post via teleport if conditions are obscure enough. Change
rloc_pos_ok() to only accept spots inside the same shop or temple when a
shopkeeper or temple priest is teleported to a random destination. rloc()
tries rloc_pos_ok() 500 times before reverting to goodpos(), so this will
usually succeed for a large room; it may fail for a small one (reverting
to the current behavior, more or less). Shopkeepers or priests who get
polymorphed into a critter which teleports to the stairs when in need of
healing will still leave their shop or temple if wounded (no change).
Priests resist if the player tries to teleport them, but shopkeepers
don't. So for direct attack by the player, this only affects shopkeeper
destination. But it affects both types as far as being hit by quantum
mechanics (probably caused by player's use of conflict) or if polymorphed
into monsters which steal and then flee (again, probably caused by the
player since those strong monsters won't voluntarily polymorph).
From a bug report, it was possible
to fall from above the quest locate level to below it even though it has
nondiggable floors (hence no trapdoors or holes to pass through). Since
the game can't verify that it is nondiggable (which could vary on a role
by role basis depending upon their quest descriptions) when it is not the
current level, restrict falling past it only when it hasn't been visited
yet. Impose the same restriction for random level teleport. This enforces
proper sequencing of the quest feedback, which was the more significant
thing that went wrong in the reported case (player finally got the full
locate level message on a return visit, when descending from above, after
having already cleared out that level on his way back up from falling).
Once the locate level has been reached or passed, it is no longer a
barrier to falling or random teleport. (When it is eventually visited,
there's no attempt to remember whether it allows holes, since that
information and the corresponding fall check would need to be extended to
every level in the dungeon. Also, controlled teleport is still allowed to
bypass it even when it hasn't yet been visited, so the "enforces proper
sequencing" claim above is an exaggeration.)
Responding with '?' to the "what level?" prompt when using ^V in
wizard mode brings up a menu of special level destinations that lets you
move across dungeon branches. But getting in and out of Fort Ludios
didn't work, and jumping to the endgame forced you to arrive on the Plane
of Earth. Now Fort Ludios will not be selectable in the menu until after
the portal ordinarily used to reach it has been created (so you'll need a
level between Bigroom and Medusa with a vault on it to be created before
you can bypass the magic portal and jump directly to the Fort), and you
can go directly to any of the elemental planes, including Astral, without
stopping at Earth first (the Wizard will be there to greet you, whichever
level you pick). Also, this limits the menu to endgame entries once you
are in the endgame. (Previously, picking a non-endgame level would yield
"you can't get there from here"; you can still get that, if you really
want to see it for some reason, by giving a destination level number
outside the range of -1 to -5 instead of using the menu.)
I hadn't realized that this feature has been around since 3.4.2 until
I couldn't find any new feature entry for in the current fixes file....
Mentioned in passing in the newsgroup: level teleporting in the
endgame--which is only possible in wizard mode--can crash if you're
confused. The change to make confusion sometimes override teleport
control means that sometimes a random destination will be chosen, and
the routine to choose a random level can call rn2() with a value less
than 1 in the endgame, possibly resulting in attempt to divide by 0.
There's something fishy about the min_/max_depth stuff for the
endgame, but I haven't attempted to figure that out. This just makes
the random destination always be the current level when in the endgame
so that the problem can't come up.
For now, the code is conditional on BARGETHROUGH
being defined, while it gets tested further. While behavior is
different with and without BARGETHROUGH defined, savefiles
are the same either way.
After this patch is applied, only the riders have the M3_DISPLACES
bit set, but the Wizard and Vlad probably should too. Any others?
> The new ^V wizmode menu is nice, but it is rather misleading; most of
> the levels it lists are "you can't get there from here". Would it be
> possible either to make it only list levels that can be reached
> directly, or alternatively to allow you to reach the ones you
> ordinarily couldn't (maybe by forcefully changing u.uz.dnum to yoink
> you into the right branch, and even summarily issuing you with an
> Amulet if you ask to teleport to the endgame).[...]; being able to bamf
> quickly to Minetown from DL 1, for example, would be damn useful in > testing stuff.
Allow fairly free roaming of the dungeon via the wizard mode teleport menu.
triggered from newsgroup post:
> ""For you , esteemed lady; only 10 for this large shield." k - a
> large shield (unpaid, 10 zorkmids).
> To what level do you want to teleport? 0
> Go to Nowhere. Are you sure? [ynq] (q) y
> You scream in agony as your body begins to warp... You cease to
> exist.
> Die? [yn] (n) y
> Bayburt comes and takes all your possessions."
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> How? He teleported to Nowhere?
Leave no doubt that your possessions did not go with you...
Allow migrated objects to break on arrival. Added code to obj_delivery to
cause this, along with a flag to keep breakage from occurring. The new
flag isn't used yet, because all the current object migration involve
objects that were moving/dropping. To help make this change, rloco now
returns whether the object was placed or not, so caller can know if an obj
pointer is still valid or not.
Making the breakage messages for MIGR_NEAR_PLAYER objects show up after the
new level is displayed required some effort (rather than while the old level
was still displayed, which was confusing), due to the needs of goto_level.
- obj_delivery now has 2 passes, one for before player arrives, another after,
allowing the two cases to be treated differently
- goto_level calls obj_delivery twice (run_timers is not called twice,
since the run required before the level is displayed will have already run
any timers on migrating object)
- kill_genocided_monsters now kills eggs on the migrating_objs list too
Reported a while back, a (stonable) hiding monster will hide at a location
containing only a cockatrice corpse. While it would be interesting to
allow monsters to try, and stone themselves as a result, I chose the
simpler fix which is to not have monsters hide in such situations. I found
the hiding code was duplicated in several places, so I moved it into a new
hideunder() function that works for both the hero and monsters.
