From a bug report,
August 12, 2002 at 11:37:10
When I am polymorphed into a purple worm (didn't check other forms)
and bite a green slime I turn to stone (not slime).
three new features for the message window we discussed:
- Graying out lines that are old -- slightly cleaner than <Someone>'s version.
- Message concatenation.
- --More-- prompt if there are more messages this turn than fit in the
window.
As a by-product of these changes, some other things have changed, too:
- The message lines array is now used in a round-robin way, i.e. the
messages are no longer copied one line up when adding a new message.
- clear_nhwindow no longer redraws the window, which significantly
reduces screen flicker.
- A caret bug was fixed.
- The last line is no longer highlighted, as this seems unnecessary
since the most recent messages are in a different colour
- A bug was fixed that caused two lines too many to be drawn on each
paint.
> [Cast a healing spell in a shop where no mimic was visible] So,
> "The small mimic looks better.". However, my picture still looks
> the same. Either the mimic should be shown, *or* I shouldn't get
> any message about the mimic healing. Both solutions seem equally
> valid to me.
If the mimic was mimicing the "strange object", then the healing causes
them to start mimicing something else with no message (the observant
player could notice however).
If the mimic was already mimicing a real object, a message similar
to this one results:
"The crude dagger seems a more vivid black than before."
Add syntax that <Someone> introduced for the Mingw Makefile.gcc
to make it easy to use unix-style path separation throughout
the Makefile.
Put all the .exe files into ../util
Put all the .obj files into o/
Problem was due to the use of obj
in the caller (bhito), after delete of
the obj within animate_statue().
map_object(obj * 0x0000ff00, int 1) line 254 + 3 bytes
newsym(int -18, int -2) line 702 + 102 bytes
bhito(obj * 0x002f6c00, obj * 0x002f7398) line 1665 + 21 bytes
bhitpile(obj * 0x002f7398, int (obj *, obj *)* 0x0055220b bhito(obj *, obj *), int 37, int 11) line 1701 + 11 bytes
bhit(int 0, int 1, int 10, int 0, int (monst *, obj *)* 0x0054e0e0 bhitm(monst *, obj *), int (obj *, obj *)* 0x0055220b bhito(obj *, obj *), obj * 0x002f7398) line 2707 + 29 bytes
weffects(obj * 0x002f7398) line 2434 + 51 bytes
spelleffects(int 3, char 0) line 824 + 11 bytes
docast() line 552 + 11 bytes
rhack(char * 0x005b6034 in_line) line 1813 + 3 bytes
moveloop() line 405 + 7 bytes
main(int 3, char * * 0x002f2b10) line 93
to work with any call to getdir().
When cmdassist is set, instead of the
message:
"What a strange direction!"
you get a screen of help showing the valid direction keys.
!cmdassist will suppress the extra help information.
Provide some command assistance for newbies, but
suppress it with !cmdassist in the config file.
If someone misinterprets the Guidebook ^D, ^T
type command notation, this will pop up some
further information to possibly assist them and
explain the notation.
Several flags added since 3.4.0 were destined for flags
(to be saved with the game) but were placed in iflags for
savefile compatibility. These include:
boolean lootabc; /* use "a/b/c" rather than "o/i/b" when looting */
boolean showrace; /* show hero glyph by race rather than by role */
boolean travelcmd; /* allow travel command */
int runmode; /* update screen display during run moves */
This patch has no effect unless you define this in your port's
XXconf.h file.
#define SAVEFILE_340_CONVERT /* allow moving of some iflags fields to flags
without destroying savefile compatibility */
Without it, the new flags remain in "iflags." With it, the flags are moved to
"flags" and the structures are converted when the save file is read. There
is no reverse compatibility. If you save the game after conversion, you
can't load the savefile on 3.4.0, only 3.4.1.
"It was hidden under a green mold corpse! It bites!"
Never seen corpse from a never seen monster can be
revealed by the hider.
-problem is that the corpse of the monster is
always created with dknown set to 1 when make_corpse() finishes,
even in the case where you never knew what it was while alive.
can't just blind yourself with a cream pie in your inventory
directly by applying it or by throwing it.
On 27 Jul 2002 14:11:06 GMT, <Someone> wrote:
> <email deleted> wrote:
>> <email deleted> (<Someone>) hypothesised:
>>
>> [cream pie]
>>> So I a)pply the pie. What I want to do is to hit MYSELF in the
>>> face with the pie, thereby blinding me and giving me T-P for
>>> just a few turns.
>>
>> Not a bad TTDTDTO ("Thing The DevTeam Didn't Think Of," which is
>> subtly different to a YANI, and not a bug; sorry, I seem to be
>> on a neologismathon today.)
> I tried throwing a cream pie upwards, hoping it would blind me,
> but no luck:
>
> "A cream pie hits the ceiling. What a mess!"
>
Change the message for paying off consumed items to
"You paid for a xxxx at a cost of nnn gold pieces."
to distinguish it from objects that you still have in your inventory which is
"You bought a xxx for nnn gold pieces."
Warwick's plname files.c addition broke the
build on both win32 and CE because NAMES_MAX
wasn't defined.
In win32 it was defined in limits.h, but only
when _POSIX_ was defined.
In CE it just didn't exist in any of the
header files. Since it was also complaining
about strdup(), I #ifdef'd Warwick's code out
under CE.
Allow single character variations in player names
to remain unique in file names by encoding rather
than substituting.
"plnam one", "plnam_one", and "plnam~one" at the
"Who are you?" prompt get unique filenames after this patch.
> It's probably best to empty
> mswin_update_inventory() in win\win32\. If I
> remember correctly there is some code in there now
> which probably behaves badly if perm_invent is
> switched on
for now at least, until there is more time to look into it.
<email deleted>
> Yet more nitpicking about potions of oil being lit by sparks from axed
> statues, I'm afraid.
>
> Konosja's potions of oil catch light!
> "That will cost you 66 zorkmids (Yendorian Fuel Tax)."
> "That's in addition to the cost of Konosja's potions of oil themselves, of
> course."
> You snuff the lit potion.
>
> a) why is the Fuel Tax on (in this case) six potions the same as on one?
>
> b) if you a)pply-light a potion, it's just "in addition to the cost of
> the potion". Is Yname2() the right name-function for catch_lit() to
> be using? It's odd for Konosja to be talking about herself in the
> third person.
>
> c) Grammar on the snuffing message is wrong for multiple potions.
Since -s doesn't function properly under the WIN32
graphical interface as yet, disable it altogether.
Also clean up nhusage() so that it does work with
the WIN32 graphical interface.
<Someone> writes:
Why do you "feel transparent" when you gain see invisible from a
fountain when blind and _not_ invisible? Transparency usually refers
to _being_ invisible.
Another try.
<Someone> writes:
Why do you "feel transparent" when you gain see invisible from a
fountain when blind and _not_ invisible? Transparency usually refers
to _being_ invisible.
Good point. I think this may have been what was intended, but it's
been like this for quite a while.
<Someone> writes:
I can accept that losing gold into a fountain recharges it to make it
possible to find a gem in it in future (however weird that is). What
_does_ seem wrong is that receiving a warning about a Minetown
fountain prevents finding gems and gold there.
This does not fix a reported bug where you
can't attack a hidden creature that is
co-located with a boulder, but it might
assist the player in understanding what is
going on.
> The intention is, I believe, to cater for the situation where you, a
> chest, and a dungeon-trap are all on the same square; previously
> (C340-71), you wouldn't have been able to check the chest for traps
> because an #untrap in direction '.' would always have tried to disarm
> the dungeon trap. However, since you can't trap-check containers on
> adjacent squares, it'd wouldn't hurt if the question was dispensed
> with when you specify a direction that isn't your square.
>
> (Note that "you cannot deal with traps while trapped!", so there's
> still several situations when you can't trap-check a chest on a
> trap-square, even though you can loot it, until you've untrapped
> yourself; is this really consistent? Should the if(u.utrap) check
> be moved to the "case y:" branch of the switch?)
> > On Saturday, 6 Jul 2002, <Someone> wrote:
> > What's the rationale behind using "money" for what used to be
> > "gold" (as in "The hill orc picks up some money" or "You notice
> > you have no money!")? Has the zorkmid been devalued?
[...]
> At least let *leprechauns* pick up gold. Unlike orcs, they're not the
> kind to pick up just "money".
Nethack crashes when you are riding a flying monster over a
pool/moat and some engulfing monster plucks you off your saddle.
After falling into the water you'll get the normal message
sequence (sink like rock ... phew, that was close; you also get
chance to teleport if you can). After the last message the game
will crash with a segmentation fault.
- reproducible; null pointer dereference in swallowed()
The crash results because dismount_steed() calls float_down(), which
calls drown(), which calls teleds(), which clears u.ustuck. So when
gulpmu calls swallowed after dismount_steed(), this line attempts to
derefernce a null pointer:
swallower = monsndx(u.ustuck->data);
This patch bypasses the float_down() in dismount steed() altogether.
That routine is meant to return the hero to the floor, and that
isn't appropriate if a purple worm just plucked you off the steed
anyway.
While this fixes the crash, a problem still exists. The
way swallowing works, the swallowing monster's location
switches to that of the hero. Since that location is
over water, the purple worm ends up drowning almost
immediately after you are swallowed, while you are
swallowed. The purple worm's death is not revealed
to you since the "The purple worm drowns." message is
conditional. This patch also adds a message when
the purple worm dies, but should this guaranteed
drowing take place?
save process, after the save file had already been written by
forcing execution of an interrupt handler at one of the
termination prompts. This resulted in "You were not healthy
enough to survive restoration" and worse.
This clears program_state.something_worth_saving immediately
after the save has been completed.
<email deleted>
Sent: Sunday, June 30, 2002 6:30 PM
Subject: Sparks from statue-axing
> First, the message given when your axe-handle vibrates is a little
> ambiguous; I'd be explicit and include the name of obj.
>
> More seriously, potions of oil catching light from the sparks are a) a
> great idea, but b) slightly broken. They catch light fine, but
> snuffing them produces a "del_light_source: not found"
> impossible(). (This probably means the same applies to being lit by
> fire_damage(), but that's rare enough this hasn't been caught before.)
>
> (Also, a)pplying a potion of oil to light one identifies its object
> type, so lighting one by this means probably ought to as well. And
> oughtn't it to be charged for if you don't own it, as light_cocktail()
> does?)
<email deleted>
Sent: Thursday, June 13, 2002 12:03 PM
Subject: Beta 1 comments
> The description of Y monsters will be updated in the Guidebook
> 'monsters' option list to match mon_explain[], I assume? (Yes, yes,
> documentation :-)
<email deleted>
Sent: Thursday, June 13, 2002 12:03 PM
Subject: Beta 1 comments
>A minor thing, but it'd be nice if the "trapped" now in lookat()
>had a defsyms[trap_to_defsym(tt)].explanation to tell you _how_
>the monster's trapped.
<email deleted>
Sent: Thursday, June 13, 2002 12:03 PM
Subject: Beta 1 comments
> Headstone writing still uses the adjective "weird" when engraving with
> a wand of digging.
<email deleted>
Subject: Beta 1 comments
> Is "You swing your axe through thin air" the right message to give
> when you try to use it to chop through a statue or boulder? Relatedly,
> this line in dig() looks as if it needs updating to the new dig_typ
> indices:
> Below is the result of your feedback form. It was submitted by
> <email deleted> on Tuesday, June 4, 2002 at 21:04:54
> After alt-Q or F)ile, Q)uitting, it is still possible to F)ile, S)ave your
> game. By doing this after you are shown your inventory [fully identified] and
> attributes (It must be done before the last "Do you want to view your %1"
> dialog is answered--usually conduct), which means you can know what you are
> holding-- although it won't be officially identified. But you can use it to
> avoid putting on, say, an amulet of strangulation by mistake.
The NOCWD_ASSUMPTIONS conditional code allows readonly
parts of NetHack to be separated from areas that require write-access.
This allows the recent panic log needed a prefix.
In item-selection menus, as you know one can press "=" to select all
rings, say. This doesn't work if the letters run out before you get to
the rings, however (because there are so many items).
Menu code did not check group accelerators on items without assigned letters
(if the letters run out). Fixed.
Moves the remaining platform-specific options
to their own section of the Guidebook and documents
the "video:autodetect" option required for tiles on MSDOS.
nethack.allison