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.
botl.c - unused argument in #if STATUS_HILITES code.
mkmaze.c - "clang version 7.3.0 (clang-703.0.31)", or whatever version
of gcc it's based on, warns that ''#define register /*empty*/''
hides a keyword. '-Wkeyword-macro' isn't mentioned in the recent gcc
manual I checked, but it is being enabled by specifying '-pedantic'
(rather than -Wall or -W) to the preprocessor. It could be turned
off via '-Wno-keyword-macro' but this removes all mkmaze.c's register
references instead. (Sean wanted that, and this might be why....)
I saw a lich in solid wall at one of the spots which gehennom.des
marks with a pool (so that baalz_fixup() can find the two spots that
need post-wallification fixup). I could understand the special level
loader placing a swimming or flying monster there, but don't know
whether it might do that for a lich (which doesn't need to breathe)
so am not sure whether this actually fixes what I observed.
The lich was there for far too long to have been a shapechanger, but
when I went back to the save file it was no longer there, producing
another puzzle.
Quite a bit of special case code for something so inconsequential.
Tweak the baalz level layout a little to make it be a bit more
interesting, and perform custom wallification on it so that the
beetle layout becomes clearly visible. It looks great with
DECgraphics (and presumably IBMgraphics). It's recognizeable but
not as interesting with ordinary ascii because corner walls use
'-' or '|' so don't join up nicely. It looks a little weird
with tiles; the square aspect ratio of individual tiles makes it
end up being very elongated compared to character cell map it was
designed for.
As far as the level layout goes, the pair of secret doors into
Baalzebub's chamber have been give a random alternative. The two
right-most accessible columns were diggable--I don't know whether
that was intentional; it's been reduced to one right-most column.
The middle pair of legs were asymmetrical; this fixes that. The
beetle also now has eyes and an entry door in its mouth.
This happens when levelporting to the first Sokoban level in wizard mode
before visiting the level, causing the branch stairs to not appear until
the space it is in comes in sight of the player.
The issue was that levels flagged premapped would cause the special
level coder to call sokoban_detect() before fixup_special() had a chance
to place the branch stairs properly.
Fix from Dynahack by Tung Nguyen.
