Subject: Some problems to report!
Date: Tue, 17 May 2005 07:01:40 -0700 (<email deleted>
<email deleted>
Hi. I'm a sourcediver but not a source compiler.
I use the Mac carbon port under Mac OS X. But enough
about me; I noticed these things:
Polyself/Anatomy Bugs:
- Mimics are amorphous, so they should have jelly
parts rather than animal parts.
- Piercers, trappers and lurkers above have animal
parts, including "head," but they are M1_NOHEAD.
- All elementals have vortex body parts. This should
only be the case for air elementals.
(Remember: stalkers, unlike the other elementals, have
heads.)
- Krakens ought to have tentacles, like jellyfish. ("A
gush of water hits the kraken's left fin!")
- Worms have snake body parts, but they shouldn't have
scales.
[...]
This patch:
- adds worm_parts
- gives krakens tentacles
- ensures that stalkers have a head
This patch alters wiz_identify so that it displays an
inventory menu with all items shown identified
without actually identifying them.
You can just press ^I (or whatever the wiz_identify command
is) a second time, while the menu is displayed to actually identify
them (tested with TTY menus only).
Pat Rankin wrote:
> Won't the players who notice this immediately ask why they
> can't see the same information for fully ID'd tins during play?
It wasn't clear to me whether Pat wanted the info shown on
fully ID'd tins during play, or whether he didn't want the info
displayed at all.
This withdraws the end-of-game tin details until clarified.
Reveal more tin details at end of game disclosure.
b - an uncursed carrot
c - an uncursed tin of broiled kobold meat
d - an uncursed tin of stir fried fox meat
e - 4 uncursed tripe rations
f - 4 uncursed food rations
g - an uncursed cream pie
n - 4 uncursed tins of spinach
o - 3 uncursed tins of pureed newt meat
p - an uncursed homemade tin of fox meat
Note that in the case of homemade and rotten
it sounded better to have the term before the
word tin, rather than after:
homemade tins of newt meat
rather than:
tins of homemade newt meat
The wishing code should probably be
changed to reflect this so people can wish for
a "homemade tin of newt". As it stands, they must
wish for a "tin of homemade newt" which differs
from the final display. That is not included.
<Someone> noticed the leftover zeromextra, this removes it.
Using memset() on a possibly failed mextra allocation was inapprorpriate,
so replace the newmextra() macro with a function.
Prevent a crash in christen_monst() if mextra was not initialized.
Note: The CVS repository was tagged with NETHACK_PRE_MEXTRA
prior to application of this patch to allow easy withdrawal if necessary.
Adds a new mextra structure type that has a set
of pointers to various types of monster structures
including:
mname, egd, epri, eshk, emin, edog
Replaces the mextra bits in the monst structure
with a single pointer called mtmp->mextra of type
(struct mextra *).
The pointer can be null if there are no additional
structures attached. The mextra structure is not
adjacent to the monst structure.
Reduces the in-memory footprint of the monst that
has no other structures attached, at the cost
of adding 6 extra long ints per monster to
the save file
The new mextra structure has the mextra fields
independent of each other, not overlapping as was
the case with previous NetHack versions.
This patch doesn't do anything to capitalize on
that difference however.
Consolidates vault.h, epri.h, eshk.h, emin.h and edog.h
into mextra.h
Adds a macro for checking for whether a monster has
a name:
has_name(monst)
This fixes the magic trap panic
expels() -> spoteffects() -> dotrap() ->
domagictrap() -> tamedog()
because the monst no longer varies in size so no
replacement is required.
<Someone> wrote:
> Some keypad input tweaks for Smartphone port:
> - added "Type Cmd" command that allows to type arbitrary commands using
> phone keypad
> - added Q(quiver) command to "Attack" layout
> - fixed F command to prompt for direction
>
>
>>2) I can't find a way to do the equivalent of d<number><item> and the
>>same for picking up (for example when multiple rations are on top of each
>>other and you can only afford 1)
>>
>>3) I can't find a way to change the quiver (the Q command)
o Add support for zlib compression via ZLIB_COMP in config.h (ZLIB_COMP
and COMPRESS are mutually exclusive).
o rlecomp and zerocomp are run time options available if RLECOMP and
ZEROCOMP are defined, but not turned on by default if either COMPRESS
or ZLIB_COMP are defined.
o Add information to the save file about internal compression options
used when writing the save file, particularly rlecomp and zerocomp
support.
o Automatically adjust rlecomp and zerocomp (if support compiled in)
when reading in an existing savefile that was saved with those options
turned on. Still allows writing out of savefile in preferred format.
o In order to support zlib and not conflict with compress and uncompress
routines there, the NetHack internal functions were changed to
nh_uncompress and nh_compress as done in the zlib contribution received
in 1999 from <Someone>.
I tagged the sources NETHACK_3_5_0_PREZLIB prior to applying these
changes.
Support negation syntax to restrict unwanted race, role, gender, align
options:
OPTIONS=role:!knight, role:!tourist, race:!orc
prevents them from being picked randomly or
appearing in the pick lists at the start of the game.
On Mon, 03 Jan 2005 12:04:29 +0000, <email deleted> wrote:
> Dear NetHack win32 developers,
>
> This bug does not affect the win32 binaries that you distribute but it
> does affect NetHack 3.4.3 if I build it from source. The difference may
> be due to different compilers or whatever. I'm using mingw32-gcc v3.2
>
> I don't quite understand what's going on (I never was much good at
> win32 programming), but it appears that the WM_KEYDOWN message for
> AltGr-4 is being translated into a WM_CHAR message with a wParam of
> 128. I don't understand why that should be, but anyway. The problem
> then occurs when NetHack casts wParam to char which, since char is
> signed, gives -128. onListChar() then passes -128 to isdigit() which
> causes the crash. The fix appears to be to simply drop the cast:
Also
> <email deleted>
> Newsgroups: rec.games.roguelike.nethack
> Subject: Changing tile set for item list?
> Date: 1 Jan 2005 20:03:08 -0800
> <email deleted>
>
> I'm using the windows interface for Nethack 3.4, and I've successfully
> changed the tileset used by changing defaults.nh. The only problem is,
> the item list (i.e. The list that comes up when I press "i") still uses
> the old tiles. Is there any way to change the list so it uses the new
> tiles? I've searched the guidebook to no avail. I'm debating if it is
> even possible.
>
> Thanks for the help,
> -Zmann
trunk patch:
- menu: display custom tiles if map is not ASCII
- menu: display '-'/'+'/'#' in place of a tile if map is ASCII
- fix isdigit() crash on AltGr-4 with mingw
It looks kinda weird with huge tiles (e.g. absurd96) but that could
be just me. Comments/suggestions are welcome.
-<Someone>
- always write plname into save file, no longer conditional
- add 'selectsaved' wincap option to control the display of
a menu of save files for ports/platforms that support it.
- add support for win32 tty using normal nethack menus.
- the win/tty/wintty code is generalized enough that any
tty port could support the option if the appropriate port-specific
code hooks for wildcard file lookups are added to src/file.c
specifically in the get_saved_games() routine. There is posix
code in there from Warwick already, and there is findfirst/findnext
code in there from win32. Warwick has the posix code only
enabled for Qt at present, but with wintty support, that could be expanded
to other Unix environments quite easily I would think.
Here is what the tty support looks like:
NetHack, Copyright 1985-2005
By Stichting Mathematisch Centrum and M. Stephenson.
See license for details.
Select one of your saved games
a - Bob
b - Fred
c - June
d - mine3
e - Sirius
f - Start a new character
(end)
The following files existed in the NetHack SAVEDIR directory
at the time:
ALLISONMI-Bob.NetHack-saved-game
ALLISONMI-Fred.NetHack-saved-game
ALLISONMI-June.NetHack-saved-game
ALLISONMI-mine3.NetHack-saved-game
ALLISONMI-Sirius.NetHack-saved-game
Note that despite the file names, the actual character name
is drawn from the savefile.
The WIN32CON support passes
USER-*.NetHack-saved-game
to findfirst/findnext where USER is your login name of course.
Since the trunk breaks savefile compatibility anyway,
remove some code that was inappropriately loading a boolean
with multiple values in order to preserve savefile compatibility in 3.4.x
[Note: this patch increments EDITLEVEL rendering existing bones
and save files obsolete]
This is a minor addition to Pat's doorganize() patch.
This just allows you to press '?' in the midst of an #adjust command
to see what letters are already in use. It is a PICK_NONE menu for
viewing only, because your actual response to the #adjust must not
be limited to the letters already used. It helps to be able to see
what's already consumed without having to terminate the command,
inventory, then start it again.
Bug Report:
>> Status of the doppelganger (neutral): Level 13 HP 1433(1433) AC 5.
>> [See the HPs!! ]
Michael:
> I used a debugger and traced this massive hit point growth
> to this line in mon.c, function newcham(). (I watched the mhp
> jump from 58 to 567 with this one calculation!
>> Ah, I see that this problem is fixed in the trunk but still present in
>> the branch. This seems serious/abusive enough to warrant the fix to be
>> applied to the branch too, doesn't it?
Pat:
> I don't think it's all that important but you're welcome to
> extract and adapt the patch if you like.
On Sat, 18 Dec 2004 14:07:14 +1300, <email deleted> wrote:
> Adding one of several candles to a candelabrum which already has six
> gives an ungrammatical message.
<Someone> wrote:
> From the mkclass() comments:
>
> /* Assumption #2: monsters of a given class are presented in ascending
> * order of strength.
> */
>
> And monst.c:
>
> * Rule #2: monsters of a given class are presented in ascending
> * order of strength.
>
> * Rule #4: monster subclasses (e.g. giants) should be kept
> * together, unless it violates Rule 2. NOGEN monsters
> * won't violate Rule 2.
>
> Inspecting my monster-difficulty spoiler, I see the following places
> that these precepts are violated: do they cause potential problems?
> (Insofar as occasionally incorrectly miscalculating the probabilities
> for monster generation is a "problem", that is...)
>
> SPECIES DIF
> ~~~~~~~~~~~~~~~~~~~~~~ ~~~
> d dog 5
> d large dog 7
> d dingo 5
>
> d warg 8
> d winter wolf cub 7
> d winter wolf 9
>
> u white unicorn 6
> u gray unicorn 6
> u black unicorn 6
> u pony 4
>
> H frost giant 13
> H storm giant 19
> H ettin 13
>
> P black pudding 12
> P green slime 8
>
> S pit viper 9
> S python 8
> S cobra 10
>
> Z giant zombie 9
> Z ghoul 5
>
> @ nurse 13
> @ soldier 8
> @ sergeant 10
>
> & horned devil 9
> & succubus 8
>
> & balrog 20
> & sandestin 15
>
> (I've just realised that these may have already been fixed, and
> waiting on a file-compatibility-breaking release; if so, ignore me :-)
<Someone> wrote:
>> If the previous character was non-neutral, the unicorn would have
>> started off as hostile. When a bones file is loaded, I don't think
>> hostiles are made non-hostile, although the reverse is certainly true
>> (pets of the deceased are usually hostile).
>
> In the general case, they are, or rather their hostility is
> re-evaluated with respect to the new character; see the peace_minded()
> call in getlev(). However, co-aligned unicorns always being created
> peaceful is a special case in makemon(), _not_ part of peace_minded(),
> so they'd just have the usual chance of being made peaceful or not
> depending on alignment strength, as for any other co-aligned monster
> not explicitly declared always peaceful or always hostile.
<Someone> wrote:
> The "/* Fix up the quest nemesis */" code in role_init()
> adds M3_WAITFORU but _doesn't_ remove M3_CLOSE;
> since the Master of Thieves as the Rogue Quest Leader is
> defined with that flag, he keeps it when acting as the Tourist
> Quest Nemesis. Thus, when STRAT_WAITFORU
> is cleared by your actions, STRAT_CLOSE may stay in
> place making him stay meditating when another Nemesis
> wouldn't.
<email deleted> wrote on Friday, December 10, 2004:
> I was in a barracks with the soldiers sleeping. I started fighting one soldier
> and threw a potion of acid on him. I got the "The soldier shrieks in pain!"
> message, but none of the other soldiers in the barracks woke up.
<Someone> complained that his compiler was giving these
warnings:
cmd.c:2119: warning: declaration of `expl' shadows a global declaration
dungeon.c:292: warning: declaration of `rand' shadows a global declaration
exper.c💯 warning: declaration of `exp' shadows a global declaration
files.c:278: warning: declaration of `basename' shadows a global declaration
hack.c:1102: warning: declaration of `expl' shadows a global declaration
pickup.c:2081: warning: declaration of `select' shadows a global declaration
role.c:1060: warning: declaration of `conj' shadows a global declaration
<Someone> complained that his compiler was giving these
two warnings:
weapon.c:835: warning: `static' is not at beginning of declaration
version.c:132: warning: `static' is not at beginning of declaration
[Attention: This patch increments EDITLEVEL in patchlevel.h, rendering all
previous save and bones files obsolete.]
Here's the first cut at the two recommended flags lknown and cknown.
I've attempted to stay close to Pat's recommendations:
"Containers ought to have two new flags: lknown for lock status known,
and cknown for contents known (ie, `secret'). Formatted box and chest
descriptions should include locked/unlocked/broken when that is known
and empty/nonempty (or something like "holds N items") when contents
are known. The contents indicator would also apply to nonlockable
containers."
I probably overlooked a place where a flag should be adjusted, but this
should give us a good starting point.
I wasn't sure what to do with the case of the auditory feedback for
magical locking "Click" and "Clunk". The question that came to my mind
was: Should those reveal the locked or unlocked status of a box?
I suppose if you knew the type of wand you were zapping or the spell
you were casting, you could argue that they should.
In the end, I opted for setting lknown right off the zap/cast effect
for anyone playing a Wizard role, and not setting it for anyone else,
thus advancing class differentiation a little bit too.
I haven't checked the cknown results under all flags.menu_style options
at this point, only MENU_FULL.
Fix for first issue reported in this bug report:
<email deleted>
Sent: Thursday, December 09, 2004 7:13 AM
Subject: Two wrong messages
I would like to report two cosmetic issues:
1. "its gaze is reflected by the invisible [pet]'s shield."
Wrong capitalization.
2. The message given when decapicating an ettin {,zombie} with the Vorpal
Blade fails to mention the second head. This could be pretty tricky to
fix, but, per <Someone>'s suggestion, the easiest explanation would be
to say that the blade's wielder cuts off both heads at once.
The patch would look similar to:
*dmgptr = 2 * mdef->mhp + FATAL_DAMAGE_MODIFIER;
> if(mdef->data==&mons[PM_ETTIN]
> ||mdef->data==&mons[PM_ETTIN_ZOMBIE)
> pline("%s goes through both necks of %s at once like butter!",
> wepdesc, mon_nam(mdef));
> else
pline(behead_msg[rn2(SIZE(behead_msg))],
wepdesc, mon_nam(mdef));
otmp->dknown = TRUE;
(and the same for youdefend)
<Someone> Cced from rgrn:
<email deleted> (<Someone>) writes:
[killed by a boulder trap, left bones]
> Then I realized... there's no boulder. Did the boulder disappear
> because I died from the attack, thus bypassing the code that moves the
> boulder to its intended destination? Did the creation of the bones
> file destroy the boulder? Do boulder traps sometimes get
> "deactivated" when bones files are loaded?
The first of these. If you look at launch_obj(), there's an
obj_extract_self() early on, then all the tracking its trajectory,
then a place_object() when it comes to rest; since the thitu() call
kills you during the trajectory part, the boulder never gets re-placed
onto the map. This is, I think, a bug (and one that will apply to any
monster-thrown object that kills you, as well); reported to the
DevTeam.
- can shift into fog clouds, vampire bats, and vampire lords into wolves
- after being "killed" in shifted form, they transform back rather than get
destroyed, and you must take them on in vampire form to defeat them
- can deliberately shift into fog clouds to pass under closed doors
This is a foundation patch for patches to follow.
- use a full short index for mon->cham field.
- The current system of providing CHAM_XXX values
was limited to the 3 bits allocated in the bitfield and invalidated
save/bones if the field was expanded.
- The current system didn't provide an easy backwards change
if multiple monster types wanted to use the bit, there was a one
to one mapping: For instance, if you wanted a CHAM_VAMPIRE,
and you wanted vampires, vampire lords, and Vlad to use it, you
would have to have CHAM_VAMPIRE, CHAM_VAMPIRE_LORD,
and CHAM_VLAD defined to achieve that with the one-to-one backward
mapping.
- This new way just uses the mon[] index in the mon->cham field and
eliminates the need for CHAM_XXX (CHAM_ORDINARY is still used).
- no longer requires the cham_to_pm mappings
<Someone> wrote:
>It seems silly to have two flags being used for counting djinn and
>ghosts, now that there's mvitals.born...
This does not break save and bones compatibility in the 3.4.x branch,
it changes the code, but leaves the obsolete fields in flags.
<Someone> wrote:
>It seems silly to have two flags being used for counting djinn and
>ghosts, now that there's mvitals.born...
This does not break save and bones compatibility in the 3.4.x branch,
it changes the code, but leaves the obsolete fields in flags.
"<Someone>" on January 8, 2004, wrote:
> A Valkyrie on the Quest home level, wearing an
> amulet of magical breathing, enters a fire trap
> out on the ice:
>
>> A tower of flame erupts from the ice!
>> The ice crackles and melts.
>> You fall into the water. You sink like a rock.
>> But you aren't drowning. You touch bottom.
>> A cascade of steamy bubbles erupts from the bottom!
>
>Should the trap really be being triggered twice, once on ice and
>once underwater, when I've only moved onto the location once?
As From a bug report, if you couldn't see a rolling boulder
fall into a pit, you only heard the sound if you were blind.
Also fixes the article used in the message.
<Someone> reported:
>> The marilith wields 5 daggers!
>> The marilith thrusts her dagger. The marilith misses.
> Shouldn't she thrust her daggerS?
Change to:
"The marilith thrusts one of her daggers." in that case.
on Sunday, April 4, 2004 at 20:27:06:
> On occassion when restoring a game where the
> character is wielding Sting, floor glyphs
> will show up before the --more-- prompt.
> These floor glyphs usually correspond to the
> location of monsters (sometimes they are just
> cavern features such as walls). Some of these
> floor glyphs are not in the character's line
> of sight upon restoring.
Also in this patch is a restore of Sting's ability
to glow blue.
This patch increments editlevel making existing save and bones files useless.
Add polywarn() code to grant the ability to detect certain monster
types while polymorphed into other specific monster types.
If you polymorph into a vampire or vampire lord, you are able to
sense humans.
And just for fun, if you polymorph into a purple worm, you are able to
sense shriekers :-)
Give more information about your attributes in debug mode
via Control-X.
I'd like to see some way of getting bits of this info to the
player during the game (from the Oracle or something),
but this patch keeps it limited to debug mode.
Move the counter for the next attribute check to the context
structure.
This increments patchlevel so previous save and bones
files are unuseable after applying.
nethack.allison