<Someone> wishes to add a couple of new options to the wince port ("run fullscreen" and "do not use CE software keyboard").
The wincap field was full, so this adds a second field for
additional options.
[B04003 and B04004 are still marked "Reported"]
<Someone>:
> You aren't very skilled at reaching from the saddled blue dragon.
> Continue your attempt to set the land mine? [yn] (n)
> You begin setting your land mine.
> There is the trigger of your mine in a pile of soil below you.
> KAABLAMM!!! The air currents set your land mine off!
> I somehow suspect that it'd be more than the air currents, if I were
> trying to arm a land mine from dragonback while not very good at
> controlling it.
<Someone>:
> What do you want to use or apply? [cmu or ?*]
> You aren't very skilled at reaching from the saddled warhorse.
> Continue your attempt to set the land mine? [yn] (n)
> You begin setting your land mine. You escape your land mine.
> Is "escape" really the right word here?
gcc -c -O -I../include -DDLB -DUSE_TILES -oo/cmd.o ../src/cmd.c
../src/cmd.c: In function `rhack':
../src/cmd.c:1800: warning: case value out of range
../src/cmd.c:1801: warning: case value out of range
Finally got around to installing OpenBSD (rev 3.3) in a vmware partition.
Found that several #if BSD's were inappropriate for modern BSD's. Haven't
installed FreeBSD or NetBSD, but based on reading their man pages,
these changes are needed there too. Mostly due to POSIX time() signature.
Switch the default Linux build behavior to use random instead of lrand48,
since lrand48 exhibits some obviously non-random behavior. random() has
been in glibc for a long time. Even if no other changes are made to
nethack's random number generator, this will improve the Linux behavior.
This is derived from the proposed patch and feedback to it. This applies
the last-position cache behavior without an option, making the behavior
more like it is for interfaces with a mouse, where holding the mouse still
acts the same way as the travel cache. The code is not #ifdef'd either.
This allows the use of the right mouse button to
look at things on the screen when the
'clicklook' option is set.
Concept came from a patch for 3.4.0
that I saw referenced on r.g.r.n
[see http://www.steelskies.com/nethack.php]
but the implementation is different.
A while back, I noticed that there was a custom use of the obj->recharged
flag in mkobj.c for tracking corpses on ice. It's much more obvious for
those of us that don't have the entire source base memorized to follow the
usual convention of adding a #define to obj.h. That's what this change does.
The number_pad option can now optionally hold a value
{0,1, 2 } for {off, on, DOS-mode} but plain number_pad and
!number_pad in config files still work as before.
When number_pad:2 is set, iflags.num_pad_mode is set to 1
which triggers the following behaviour:
> '5', M('5') and M('0') are mapped in rhack()
>in cmd.c, only when they are entered as a command. When used as a
>number, like in the 'n' command, no mapping takes place. '0' is
>already mapped to 'i' by the core. The
>only difference [<Someone>] left in (deliberately) is when you press Ctrl-0;
>this used to map to C('i'), which is an invalid command; now
>keep it '0' (which is interpreted as 'i' by the core.)
I encountered a look vs pickup cockatrice corpse
bug today.
If you looked at a location with ':', you
would instantly get
"Touching the cockatrice corpse is a fatal mistake..."
but if you used "m," you got the full list of
things at the location to choose from.
This patch makes the behaviour consistent
and more informative to the player.
You now get the partial list of things felt
up until the cockatrice corpse is encountered,
and then you get the
"Touching the cockatrice corpse is a fatal mistake..."
Before, the code was never displaying the partially
built list because the feel_cockatrice() call was
happening before the window display call.
Mostly `gcc -Wwrite-strings' complaining about passing string
literals to safe_qbuf(). `gcc -Wformat' didn't catch the type mismatch
of formatting the return value of strlen() with %d, presumeably because
size_t is defined as unsigned int on this system and it treats int and
unsigned int as interchangeable as far as printf/scanf checking goes.
I'm not sure whether the sizeof() values being passed to safe_qbuf()
ought to have casts. Any system where size_t isn't the same width as
unsigned int is bound to support prototypes, but might possibly warn about
the implicit conversion of unsigned long (or even unsigned long long these
days) to unsigned int.
this particular fix has been sitting around my inbox for a while although
we've had reports of FreeBSD build problems for a long time. While it's
untested, it certainly looks like the unfixed system.h had a case that
could not be reached. bsdi seems like it needs to be handled the same way.
This solution is mostly a band-aid. Make sure information set by join_map
that is overlaid by the MAP is cleared out. This ensures that place_branch
will never consider invalid data. A new function, remove_rooms(), with a
helper, remove_room(), takes care of this, but only for rooms created by
join_map, which addresses the only known case that causes this problem.
There's a possibility that some other strange behavior, especially in
minetn-6, will be fixed by this as well. The problem of disconnected caves
on minetn-6 is not yet addressed.
Also, add a check to lev_comp.y to make sure the required fg semantics of
joined levels (fg must be ROOM or CORR) are actually met. Doesn't affect
any levels currently included in the distro, but might address levels
others are trying to make.
add another bit to the flags passed to launch_obj so it can print
the initial "rumbling" message at the appropriate time rather than
having the caller print the message, possibly out of order.
1) killer reason for scattered land mine shrapnel used "a" or "an" prefix
even when multiple projectiles hit as a group -- one of various things
From a bug report.oextra field) --
noticed while investigating #1 and later From a bug report.4.0 due to an unintentional side-effect of missile killer reason
handling in 3.4.1 (removal of redundant "poisoned" prefix by m_throw()
confused the poison handling routine) -- noticed while investigating #3.
> The `prompt' buffer in tty_yn_function still only holds QBUFSZ
> characters. But fixing the tty incarnation wouldn't be good enough;
> all the other interfaces would need to handle it too. I think it
> should be fixed in the core instead. Prompt strings simply should
> not be allowed to become so lengthy.
Another step in the fight against prompt sting buffer overflows.
The goes after the ones that may not have been found yet.
This makes yn_function a real core function and removes
the #define yn_function macro.
The yn_function validates the prompt string buffer being
passed prior to calling (*windowprocs.win_yn_function)(),
and if necessary, truncating it and adding "...".
This won't help if the overflow occurs in the core in
a buffer that is still QBUFSZ in size, but it will help if
a BUFSZ buffer is being passed to one of the query
functions.
This patch gives game and savefile compatibility
whether GOLDOBJ is defined or not.
You can build with GOLDOBJ defined or not, and
still load your saved games. Rebuild with the
opposite, and load the same game.
That way GOLDOBJ can be experimented with
more easily.
1. Leave the "you" struct and the "monst"
struct the same under the hood between
GOLDOBJ and !GOLDOBJ.
2. Always write out gold as an
object on the player and monster
inventory chains.
On a restore of the savefile with GOLDOBJ
not defined, take the gold objects out of
the inventory chains and put it into u.ugold
or mtmp->mgold as appropriate.
On a restore of the savefile with GOLDOBJ
defined, nothing special is done.
<Someone> noticed that is_damageable used the address of is_rottable
instead of calling it. Unfortunately, there doesn't seem to be a good
compiler warning to detect uses of function addresses as booleans.
Another fix to address the complaints about two-handed weapons being
rendered useless by 3.4.1's change to require free hands in order to apply
containers. Some players now fear to wield two-handed weapons because a
curse would make accessing their bag impossible, which is doubly nasty if
that's where they have scrolls of remove curse or potions of holy water
intended to deal with cursed items. The same situation applies for cursed
one-handed weapon combined with cursed shield, so some are now claiming
that 3.4.1 has made two-weapon combat be even more attractive than before.
This implements #tip, a new command that causes a container at the
current location or carried in inventory to have its contents emptied
onto the floor. Hero's hands don't need to be free at the time but tipping
a floor container requires limbs; tipping an inventory container doesn't
need hands or even limbs. The contained items don't pass through inventory
during the process, so don't cause objects (loadstones, crysknives, scrolls
of scare monster?) to go through their special handling unless it's part of
normally dropping to the floor. Tipping a bag of tricks behaves the same
as applying it (one monster is released, and it only becomes empty if
that happened to be the last charge) and items tipped out of a cursed bag
of holding have their normal cursed bag chance (1/13) of being destroyed.
Tipping an inventory container while levitating or during unskilled riding
behaves similar to normal drop--from a height, so some fragile items break.
Players have wanted this feature to get gray stones out of chests or
heavy corpses out of ice boxes but I didn't care much about that; losing
access to your bag is more significant. I'm pretty sure that there was a
user patch to do something like this floating around at one time, but I
couldn't find it when I looked, so I implemented #tip totally from scratch.
Bug? Extended commands which lack meta-key shortcuts are not listed
in the help files displayed by the '?' command....
Move a couple of instances of container contents manipulation into
their own routines. Behavior for items disappearing from cursed bags of
holding isn't quite identical but is effectively the same. I think its
use of stolen_value (or simply the behavior of the latter) is buggy, but
I haven't tried to fix that. (Cursed bag of holding destroying a player
owned bag containing shopped owned items definitely doesn't work well.)
<Someone> noted that if you dropped a box while levitating, nothing would
break. This is true for sacks too, which shouldn't be immune either.
Throwing didn't break contained objects either, not mentioned in his report.
Refactored out the code in kick_object that handled damage for objects
contained in normal containers and added calls in hitfloor and throwit.
kick_object still only calls it for boxes, but other callers will call it
for any object letting it decide if damage is required. BoH objects aren't
affected, since traditionally the inside of the BoH is "somewhere else".
This started out as a change to address the strange sequence of messages if
you remove a blindfold while engulfed in a dust vortex. That is addressed
by a new function that can be called in such situations. Calls to this
function were added in all the cases where the can_blnd() engulfing
conditions end as a result of player action. There are some other cases
that end ucreamed or usleep, but they happen between turns and shouldn't
need extra handling.
While I was at it, I noticed that a unicorn horn or prayer would cure
blindness even while engulfed in a dust vortex. This is useless, because
you immediately get blind again the next turn. So, I added checks to avoid
doing this. Finally, it didn't make sense for eating a carrot to cure your
blindness in these situations either, only for it to return immediately.
> It appears that if showrace is set, and your race is not human, a
> potion of invisibility (or any other form of invisibility) doesn't cause
> your symbol to disappear on screen, even if you don't have see invisible.
1) make two-weapon combat perform two attacks instead of always either
hitting twice or missing twice;
2) address <Someone>'s report of weapon skill to-hit adjustment being ignored
for bare-handed and martial arts attacks;
3) address newsgroup complaints about the intrusive "your armor is rather
cumbersome" message given every time a monk wearing a suit attacks;
this implements the suggestion that it only occur for those times where
you miss because of the penalty involved, suppressing it when you miss
due to other reasons and when you successfully hit;
4) bonus fix: a side-effect of #3 is that the order of the messages "your
armor is cumbersome" and Stormbringer's "bloodthirsty blade attacks" is
inverted, making a sensible sequence instead of implying precognition.
> "A cloud of sangria gas billows from the chest.
> You stagger and your vision blurs."
> When I see the gas billowing from the chest, I'm not yet
> hallucinating. Shouldn't the gas have a normal colour, then?
> Only after my vision blurs should the gas assume a fake colour, I
> think.
>
Prevent burying a ball from ending your punishment.
When you bury the ball, internally NetHack Punishment
ceases, but a new trap type of TT_BURIEDBALL immediately
kicks in (acting similar to TT_INFLOOR in some ways).
You can eventually work the ball free (or teleport, etc.),
but that will just return you back to normal Punishment.
3.4.1 included a change which requires you to be able to use hands
in order to manipulate containers; that makes sense but has introduced
an unintended side-effect. It has become much harder to uncurse a
two-handed weapon or combination of a one-handed weapon and a shield
because you can't get scrolls or potions out of your bag. This adds a
new major trouble for prayer to address that, escalating it above the
normal minor cursed item trouble. It also removes a nonsensical check
for combination of two-handed weapon and shield that I added long ago.
Not related, but same file: add the missing artifact touch checks
for putting on accessories (quest amulets and lenses). I can't remember
if this was From a bug report.
- Move the code for keystroke handling into its own source file.
- Compile and link it as a dynamic link library.
- Dynamically load the keystroke handler at runtime
- Add support for specifying a different handler in defaults.nh
so that internationalization issues can be dealt with without
rebuilding nethack, just supply alternative handlers in HACKDIR.
The following exported functions need to be present in
the keystroke handler .dll:
ProcessKeystroke - returns an ascii value to NetHack
NHkbhit - allows peeking to see if a key/mouse press is waiting
SourceWhere - returns location for souce code for a keystroke handler
SourceAuthor - returns author information for a keystroke handler
KeyHandlerName - returns the full or short name of the keystroke handling dll.
- Version change from 3.4.x
- timed_delay feature ignore in makedefs
- several flags from iflags to flags
- use offsets from mons array entries in save file rather than storing
the ptr and calculating the distance from beginning of array
Reported on RH 7.2 and 8.0. Compilation failed because system headers that
needed _GNU_SOURCE on these Redhat versions got included before it was
defined. To ensure _GNU_SOURCE is defined, added an autodetect for it to
config1.h and removed the need to set it in unixres.c. __linux__ is also
checked elsewhere.
The CE ports use makedefs hosted on another platform,
so the version string generated at build time isn't really
appropriate.
Add a way to add information to the version string
at runtime for such ports.
