placebc was triggering an impossible sometimes on the plane of
water
It turned out to be because movebubbles issued an
unplacebc(), but a downstream function called
placebc(), so when movebubbles() issued its own
placebc() there was a problem.
The downstream function that beat movebubbles to the placebc()
turned out to be unstuck(). There could be others.
Even though a goodpos failure in mnearto() would return 0 to
the caller and trigger proper overcrowding handling for mtmp,
the 'othermon' would be left with its mx,my set to 0,0 under
that circumstance and then trigger a mon_sanity_check()
failure and accompanying impossible() message a short while
afterwards.
This also includes the addition of some flags that proved useful
for troubleshooting the mystery sanity_check failure and helping
to understand some of the code paths the struct monst data had
been through. They are only used for inspection when issues are
reported or when debugging, they don't presently control the
code flow. Their setting and use is done in an overloaded way
that should not intrude on the existing use of mspare1 for
MIGR_LEFTOVERS. mon->mstate is just a pseudonym for mon->mspare1
and does not alter save file content.
Make the Plane of Water be water all the way to edge instead of having
stone on left, top, and right. The Plane of Air already has air all
the way to edge (including unused/unuseable column #0) but does so via
code rather than the level description file so Water does that now too.
The edges of the Plane of Air were cloudless (3 columns on the left,
2 rows on the top, and 2 columns on the right; don't recall about the
bottom) and that looked pretty strange. Those rows and columns are
beyond the range of bubble/cloud movement so just make some of those
spots randomly be sight-blocking cloud terrain instead of all open air.
It isn't integrated with the moving clouds but looks fairly good when
the hero moves along the edge of the level.
Using wizard mode to leave Water or Air and later return resulted in
no clouds on the Air level and bubbles as usual on the Water level.
I still don't understand why, but on return to those levels run the
bubble creation routine as if the old discarded bubbles or clouds were
being restored.
This doesn't solve the <0,0> problem but it does prevent mnexto()
from using uninitialized coordinates if enexto() fails. It also adds
several debugging messages.
enexto() was ignoring map row #0 (unlike column #0, row #0 contains
valid map locations). Fixing that doesn't matter for Plane of Water
though since that row is stone there--that's probably a bug. It was
also repeatedly re-testing the top+1 and bottom rows and left and
right columns after they had already failed to be acceptable. It
still does some of that, but less.
Leaving the Plane of Water to return to a previously visited endgame
level didn't free the air bubbles unless/until you visit a new level.
Returning to that level creates a new set of air bubbles, losing track
of the previous set. Likewise with Plane of Air and its clouds. (Not
an issue with actual save and restore when on those levels, or when
just moving forward to not-yet-visited levels.)
Not applicable to normal play where it isn't possible to return to a
previously visited endgame level.
For 3.7, bubble save/restore ought to become part of savlev() instead
of being handled by savegamestate().
Air bubble movement on the Plane of Water manipulated <u.ux,u.uy>
directly when changing hero's coordinates, leaving steed with old
coordinates, resulting in dunking it when the old spot switched from
air to water. Switch to u_on_newpos() which moves the steed with
the hero and also handles clipping when the screen is too small to
show the whole map at once.
Change in meaning of mnearto()'s return value wasn't progagated to
shkcatch(). Make it an int instead of boolean so that it can
communicate both 'moved successfully' and 'moved but had to move
another monster out of the way to do so'.
Under some circumstances, when all the marauding orcs belonging to the
horde operating within the gnomish mines had been provided with their
spoils and placed appropriately, there could still be some pillaged stuff
left-over on the migrating obj chain. Orcs created by regular monster
generation elsewhere would then be susceptable to receiving that stuff
until it was used up. That part is fine, except that the orcs were then
being named as part of the same horde operating within the mines. Now
they will no longer be named as part of the Gnomish Mines horde.
Mythos: There's a good chance that these particular orcs received the
stolen goods from the Gnomish Mines horde.
Clean up quite a bit of minor things found with simple grep patterns:
operator at end of continued line instead of beginning of continuation
(and a few comments which produced false matches, so that they won't
do so next time), trailing spaces (only one or two of those), tabs (a
dozen or so of those), several casts which didn't have a space between
the type and the expression (I wasn't systematic about finding these).
I think the only code change was in the function for the help command.
Remove trailing spaces, and remove tabs from the files that had
trailing spaces.
Also, rndorcname() was using a random value to terminate a loop
and was recalculating a new one each iteration.
Eliminate a few warnings: array name used as boolean is always true,
parameter 'flags' shadows (blocks access to) global struct 'flags',
initializer discards 'const' (assigning string literal to 'char *').
Plus a couple of simplifications.
Changes to be committed:
modified: include/decl.h
modified: include/dungeon.h
modified: include/extern.h
modified: include/hack.h
modified: src/decl.c
modified: src/do_name.c
modified: src/dog.c
modified: src/dokick.c
modified: src/makemon.c
modified: src/mkmaze.c
modified: src/mkobj.c
modified: src/pager.c
This commit is an attempt to address the complaints about
the orc town variation taking away lots of stuff that is
normally available in mine town. The statement in the level
description says "A tragic accident has occurred in Frontier
Town...It has been overrun by orcs."
The changes in this commit attempt to uphold that premise,
while making things a bit more interesting and perhaps
more palatable for the player.
This update does the following in keeping with the mythos:
- While many of the orcs still remain to wander about the
level, many of the orcs took off deeper into the mines with
some of the stuff that they plundered. You may now be
able to hunt some of it down.
- Adds some appearance of this particular horde of marauding
orcs working as part of a larger collective.
- This evolves the Orc Town mine town variation into a
a feature over multiple levels of The Gnomish Mines,
rather than just the single-level "feature" that it was
previously.
- You may have to work longer and a bit harder for some
things than other mine town variations, but at least with
these changes, there is hope that some of it may be found
elsewhere.
Game mechanics notes (maybe spoily?)
- Add mechanism to place objects into limbo (okay, really
place them onto the migrating_objs list for transferring
between levels etc.) and destine them
to become part of the monster inventory of a particular
species. In this particular usage case, it's using the
M2_ORC flag setting to identify the recipients.
- At present, there is no mechanism in the level compiler
for placing objects onto the migrating objects, nor
with more sophisticated landing logic, so a somewhat
kludgy hard-coded fixup and supporting routines were used.
Some day the need for that might change if additional
capabilities move to the level compiler.
This is a NetHack-3.6.2-beta01 update. Please give it a workout.
Fixes#127
Noticed while looking into the TROUBLE_STUCK_IN_WALL prayer bug,
place_lregion() has been using the wrong row for 'low y' in its
whole-level handling, presumeably ever since it was first introduced.
3.4.3 definitely had the same bug; I didn't check any further back.
For maze levels which only consider every other row and every other
column to be viable locations this probably didn't matter. And even
non-maze levels usually don't have anything on row 0, so this fix
isn't likely to be noticeable.
