612755bfb5
Name already in use
Commits on Aug 4, 2011
-
Partial rewrite of escapes(), mostly changing its if-then-else logic so that end-of-string can be checked once instead for each case. The previous version had a bug if the input string ended with backslash and one decimal digit (due to being lumped together with the handling for trailing \X or \O).
nethack.rankin committedAug 4, 2011
Commits on Aug 3, 2011
-
fix exploitable security bug in options processing
From a bug report, the function escapes(), which is used during options parsing for various options that accept string values, is given user-controlled input that could end with a backslash or caret (or two character "\M"). Such a malformed escape sequence would make it consume the input's end-of-string character and then keep processing whatever followed. That meant that it could generate more data than its output buffer was prepared to hold, making nethack be vulnerable to stack overflow issues. His example that was supposed to clobber the stack didn't trigger any trouble for me, and I didn't bother trying the second one that can allegedly cause the Win32 binary to run another program. But the bug itself is clearly real.nethack.rankin committedAug 3, 2011
Commits on Jul 28, 2011
-
Sleeping vs Sleepy (trunk only)
While looking at fixing the mfrozen issue for monsters (there's no way to tell whether it's been caused by sleep or paralysis, necessitating that some messages be vague or suppressed when actions impact monsters who can't move), I noticed a drawbridge bug for the hero. It was using the misleadingly named Sleeping intrinsic incorrectly. When that is nonzero, the hero is prone to falling asleep at random intervals, not necessarily asleep right now. I've always intended to rename it to something that's not misleading, but hadn't ever gotten around to doing so, until now: change the SLEEPING property to SLEEPY and the Sleeping intrinsic/attribute to Sleepy. This may be moot for the drawbridge. I can't remember any hero ever jumping to safety instead of being crushed by either the bridge or its portcullis, and I'm sure sleepiness hasn't been a factor. So I haven't included any fixes entry about misusing Sleeping when it meant u.usleep (or better yet, unconscious(); or even better, Unaware [a post-3.4.3 pseudo-property that tests both unconscious() and fainted() when checking whether hero is incapacitated]).nethack.rankin committedJul 28, 2011
Commits on Jul 26, 2011
-
mark jabberwocks as M1_NOHANDS
Jabberwocks are flagged as animals hence won't use items, or else this would have been obvious long ago. They weren't flagged as no-hands, so a hero in their form could wear gloves and/or wield a weapon (or a cockatrice corpse, whose ineffectiveness when used with a claw attack which followed a bite attack led to the discovery of this oversight). I'm not sure what a jabberwock ultimately looks like, but am pretty sure that it shouldn't have usable hands, particularly ones which are only usable by a poly'd hero and not by jabberwock monsters.
nethack.rankin committedJul 26, 2011 -
polyself weapon attack (trunk only)
From the newsgroup: hero poly'd into various monster forms would be incapable of turning a target to stone when wielding a cockatrice corpse. Monster forms with a claw attack as their very first attack (second for incubus and sucubus, handled as a special case) would have that be converted into a weapon attack. But some monster forms start with bite attacks and have their claw attacks later; a hero poly'd into such form wouldn't use his/her wielded weapon. This fixes that, but it's actually academic (or about to become so). The only monster capable of wielding a weapon which would then be ignored was jabberwock, and I think leaving NOHANDS off the jabberwock definition is a bug in itself (next patch...).nethack.rankin committedJul 26, 2011
Commits on Jul 23, 2011
-
calculating shop price adjustments (trunk only)
Fix the second of a couple of minor things I noticed when viewing that guy's ttyrec about a hidden inventory item which turned out to be scrolls of scare monster on the used-up items section of his shop bill. He had a lot of scroll prices which started as $X00 and were changed to $Y99 due to integer division roundoff when being hit with a 1/3 price increase for unID'd items followed by 1/2 price increase for low charisma: 100 -> 133 -> 199 200 -> 266 -> 399 Forcing things to round up instead of truncate would help in some cases but yield $Z01 in others. Rather than doing that, this accumulates the adjustment factors and then uses them to make one calculation which gives a better result: 100 -> 200 200 -> 400 Other values and/or other adjustments might not work out so well, but I don't think they'll ever become prices which look worse than before. For a single increase of 1/3, 100 still yields 133 but 200 now gives 267 (so ends up differing from the combined price for two 100->133 items).nethack.rankin committedJul 23, 2011 -
shop credit feedback (trunk only)
Fix the first of a couple of minor things I noticed when viewing that guy's ttyrec about a hidden inventory item which turned out to be scrolls of scare monster on the used-up items section of his shop bill. Be more precise when a shopkeeper gives the hero credit for dropped gold. Instead of just displaying N zorkmids are added to your credit. show either You have established N zorkmids credit. when you had no previous credit, or N zorkmids added to your credit; total is now X zorkmids. when adding to existing credit.nethack.rankin committedJul 23, 2011
Commits on Jul 21, 2011
-
Remove debugging output that was ending up inside a plist file.
keni committedJul 21, 2011
Commits on Jul 17, 2011
-
fix #H2384 - ceiling hiding by poly'd hero (trunk only)
From a bug report, a hero hiding on the ceiling while poly'd into a piercer or lurker-above could be moved long distances when a monster attacked his location, because when the attacker moves into hero's spot, hero's new location is chosen before the attacker had released its own spot. If things are crowded, the nearest open space can be quite far away, including beyond nonpassable walls. Fix by taking attacker off the map before choosing hero's destination, so in crowded conditions they will likely end up trading places. This also prevents eels and sharks from moving onto land when the hero has hidden on the ceiling next to their pool. They'll miss without moving into hero's spot, but the hero will become unhidden so they'll be able to make ordinary water-to-shore attack on their next turn. Lastly, when the attacker is a long worm, the spot chosen for hero might be filled by its tail by the time hero actually moves. So double check and possibly re-select target spot after moving a worm's tail.nethack.rankin committedJul 17, 2011
Commits on Jul 16, 2011
-
fix #2382 - temp Dex loss becomes permanent when dismounting
From a bug report, if you dismount from a steed whose legs are wounded, you won't recover the point of dexterity which was removed when they becme injured. He noticed the case where the steed had just died, but it happens for voluntary dismount too (actually any dismount except one which wounds the hero's legs in the process: DISMOUNT_THROWN or DISMOUNT_FELL). It seems rather odd that the hero temporarily loses Dex when the steed becomes injured, but I haven't changed that.nethack.rankin committedJul 16, 2011
Commits on Jul 9, 2011
-
fix shop ownership of saddle dropped by dead pet (trunk only)
From a bug report, you could obtain a saddle for free if it was dropped (while worn) by a dying pet inside a shop. That's intentional, but it was happening even when the hero was not in the shop, which doesn't seem right. Change things to only set it no_charge if hero is within the same shop (including standing in the doorway or a temporary wall breach, not just when all the way inside) at the time of the drop.
nethack.rankin committedJul 9, 2011
Commits on Jun 16, 2011
-
fix #H2326: support window resize on linux
From a bug report. Applied the suggested change to enable window resize support by default on linux.
cohrs committedJun 16, 2011
Commits on May 23, 2011
-
I hadn't tried the build script vmsbuild.com in a long time.... vmsbuild.com wasn't compiling src/sys.c; vmsbuild.com and Makefile.src+Makefile.utl had some linking discrepancies; Makefile.top, Makefile.dat, Makefile.doc - replace old SCCS id/date/rev comment with current cvs one (done for .src & .utl a month or so back); config1.h - running DEC C in VAX C compatability mode to test linking yielded a diagnostic about signed in the schar typedef for every file.
nethack.rankin committedMay 23, 2011
Commits on May 12, 2011
Commits on May 10, 2011
-
fix #2276 - unlightable candelabrum
From a bug report, applying unlit Candelabrum of Invocation when its candles had 1 turn's worth of burning left would give a message that the candles were burning but not actually light them if done anywhere other than the invocation location. Their burn time is cut it half when not at that spot, and dividing an age of 1 yielded 0, confusing begin_burn(). They wouldn't light and they couldn't be replaced since they'd never get used up. The problem is real, but the chance of it actually happening in normal play is just about zero. This applies his suggested fix of rounding the halved burn time up instead of down so that it can't yield 0. It also applies his suggestion that the Candelabrum treat the invocation spot like any other location once invocation has produced stairs there, just as the Bell and the Book do.nethack.rankin committedMay 10, 2011
Commits on Apr 29, 2011
-
extra additional paranoia (trunk only)
When requiring "no" to reject in addition to "yes" to confirm one of the paranoid_confirmation prompts, only loop a handful of times before giving up and rejecting (in case there's some hangup-like situation that isn't hangup enough to switch over to using ESC for further input). There's no "that's enough tries" feedback; after 6 tries it just stops asking for a yes or no answer and behaves as if it had gotten no.
nethack.rankin committedApr 29, 2011 -
nroff didn't care, but groff gives "warning: can't find font i".
nethack.rankin committedApr 29, 2011
Commits on Apr 25, 2011
-
additional paranoia (trunk only)
A couple of extensions to the paranoid_confirmation option: 1) add paranoid_confirmation:Confirm -- setting this means that any prompt where the other paranoid_confirm flags have been set to require a yes response instead of y to confirm also require explicit no rather than arbitrary non-yes to reject. It will reprompt if you don't answer "yes" or "no" (unless you use ESC, which is treated the same as "no"). 2) add paranoid_confirmation:bones -- control whether the "save bones?" prompt in wizard mode requires yes instead of just y. The original user- developed paranoid_confirm patch required yes unconditionally here, and I left that out thinking it was undesireable. But after testing the "your body rises from the dead as <undead>..." fix a couple of days ago, where you now get an extra message and consequent --More-- prompt just before "save bones?", I've changed my mind about its usefulness, provided that it's settable rather than unconditional. Handling paranoid_confirmation:bones outside of wizard mode is a bit tricky. Right now, it can still be seen via 'O' if it has been set in NETHACKOPTIONS, but it won't show up in the menu if you use 'O' to interactively change the value of paranoid_confirmation. I'm not sure whether that's the right way to go; it might be better to let non-wizard users uselessly toggle it on and off rather than only partially hide it. Or maybe it should be hidden from the current value even when it's set. Or decline to set it in first place, despite external option settings.nethack.rankin committedApr 25, 2011
Commits on Apr 24, 2011
-
paranoid_confirmation indentation cleanup
Pat confirms this is the intended behavior.
keni committedApr 24, 2011 -
sort of/kind of support PANICTRACE on VMS (trunk only)
I don't think this is useful enough to recommend ordinary users enable it, but it's close enough to being useful that I don't want to leave it to become subject to bit rot like umpteen other unfinished patches. Anyone running in wizard mode who has a panic already gets pushed into the debugger on VMS, although it doesn't work for what might be considered the most important configuration (a secure playground, as opposed to the wide-open one I've always been content to leave mine at).
nethack.rankin committedApr 24, 2011 -
fix #H2259 - rising from dead message gives away info (trunk only)
From a bug report, receiving the message "Your body rises from the dead as an <undead>..." gives away the fact that bones are being created (and its absence when applicable undead kills the hero gives away the fact that bones aren't being created). Not very interesting for single player installations where 5-10 seconds later the player is going to check the playground for new files, but matters on multi-user installations where players don't have access to the directory and sometimes race each other to juicy bones, such as nethack.alt.org. At the end of disclosure, give the message whether bones are being saved or not (for cases where it would have happened when bones are created). Player won't know whether new bones are becoming available. Also, prevent risen undead-from-hero from being given random monster inventory, but explicitly give mummy-from-hero a mummy wrapping if the hero isn't already carrying one. It will end up being worn; that's the only armor mummies are allowed to put on.nethack.rankin committedApr 24, 2011
Commits on Apr 23, 2011
-
number_pad formatting fix for Guidebook.tex
Fix the alignment issue Pat noted (this is different than the suggestion I mailed out - installing latex so I could test it proved it was wrong).
keni committedApr 23, 2011 -
Enable SYSCF_FILE for VMS, and simplify option initialization in the process. I still need to put a template into the playground directory during initial install, and the one in sys/unix/ probably isn't appropriate.
nethack.rankin committedApr 23, 2011 -
SYSCF/PANICLOG fix (trunk only)
files.c wouldn't compile if SYSCF was defined and PANICLOG wasn't. Also, a couple of PANICLOG option sanity checks treated 0 as an error but then said that the value had to be 0, 1, or 2. I went with the message and changed it to treat 0 as ok. Unfortunately the numeric value is derived via atoi() so you get 0 from bogus input. Perhaps it should use sscanf(string,"%d%c",&number,&dummy)==1 to try harder to make sure it actually gets a number.
nethack.rankin committedApr 23, 2011
Commits on Apr 21, 2011
-
Noticed while working on the "lava inconsistencies" patch: it was possible for lava_effects() to be called recursively, despite a patch five and half years ago which was supposed to prevent that. That patch handled the case where the hero dies and gets life-saved, but it didn't deal with a hero who survives due to water walking boots and then has those burned away. [Not an issue in 3.4.3 because Boots_off() didn't call spoteffects() for lava then, but it does in post-3.4.3 branch as well as trunk. fixes34.4 has an entry about fixing an "object lost" panic for this but I don't think it's accurate. I think that the panic only became possible after the post-3.4.3 "handle lava when removing or losing water walking boots" fix was introduced.]
nethack.rankin committedApr 21, 2011 -
fix #H2247 - lava inconsistencies (trunk only)
From a bug report, if you move into lava, die, and are life-saved or leave bones, your potions will remain intact, whereas if you have fire resistance and survive, they'll be subjected to destroy_item() and usually be destroyed (not always, because stacks of more than 1 don't always destroy the whole stack). Also, wooden ring will be destroyed even if it happens to be ring of fire resistance. This addresses both of those bugs. He also thought that all vulnerable armor should be destroyed rather than just boots in the case where you have fire resistance and survive, but I didn't change that. It is a little odd, but presumeably only your feet are in lava at first (although later sinking further into lava doesn't actually burn up any other stuff).nethack.rankin committedApr 21, 2011 -
avoid mkclass() infinite loop (trunk only)
Back on Feb 28, I committed a patch to prevent the special level loader from generating mail daemons for levels which specified random demons. It had a pair of copy+paste mistakes that could result in mkclass() looping forever. It was looking at the same monster every time and if that monster was one which mustn't be generated, it would just keep repeating.
nethack.rankin committedApr 21, 2011
Commits on Apr 20, 2011
-
fix #2142 - skipping levels when climbing with Amulet
From a bug report, when climbing out of Gehennom while carrying the Amulet, you could skip a handful of levels by taking the magic portal into the Wizard's Tower, dropping the Amulet, zapping it with a wand of teleportation--possibly more than once--until it lands outside the tower. Then take the portal back out of the tower and level teleport--feasible now that you're not carrying the Amulet any more--back to the tower level and retrieve the Amulet. Overall probably not much of a savings unless you're having really bad luck with the mysterious force sending you back whenever you try to go up. The hero and monsters can't teleport from inside the tower to the outside or vice versa; this gives the same limitation to objects.
nethack.rankin committedApr 20, 2011
Commits on Apr 19, 2011
-
altmeta Alt key hack, mainly for unix (trunk only)
Some time ago we received a patch submission which attempted to handle the Alt key for terminals or emulators which transmit two char sequence "ESC c" when Alt+c is pressed, but I can't find it. I don't remember the details but recall that it had at least once significant problem (perhaps just that it was unconditional, although it may have been implemented in a way which interferred with using ESC to cancel). This patch reimplements the desired fix, making the new behavior be conditional on a boolean option: altmeta. That option already exists for the Amiga port, where it deals with low-level keyboard handling but essentially affects the same thing: whether Alt+key can be used as a shortcut for various extended commands. This one affects how the core processes commands, and is only available if ALTMETA is defined at compile time. I've defined that for Unix and VMS; other ports don't seem to need it. (I'm not sure whether "options" created by makedefs ought to mention it. So far, it doesn't since this isn't something users are expected to tweak. The setting of the non-Amiga altmeta option doesn't get saved and restored, so won't affect saved data if someone does toggle ALTMETA and then rebuild.) When [non-Amiga] altmeta is set, nethack's core will give special handling to ESC, but only during top level command processing. If ESC is seen while reading a command, it will be consumed and then the next character seen will have its meta bit set. This introduces a potential problem: typing ESC as a command will result in waiting for another character instead of reporting that that isn't a valid command. Since it isn't a valid command, this shouldn't be a big deal, but starting a count intended to prefix your next command and then typing ESC after deciding to abort that count runs into the same situation: nethack will wait for another character to complete the two character sequence expected for "ESC c". There's not much that can be done with this, other than have the Guidebook mention that an extra ESC is needed to cancel the pending count, because digits followed by ESC could actually be a numeric prefix for Alt+something rather than an attempt to abort the count.nethack.rankin committedApr 19, 2011
Commits on Apr 15, 2011
-
fix #2253 - shk dismissing kops from other level (trunk only)
From a bug report, if you rob a shop, let the angry shopkeeper catch up with you outside his shop, escape to another level with adjacent shk tagging along, then pacify the shk by paying him off, he will dismiss kops on the present level and return to his shop but when you return to his shop level there'll still be kops chasing you there. This fix adds an extra flag to the eshk structure so that kops can be dismissed a second time when the shk migrates back to shop level. The first dismisal (on the "wrong" level) still takes place in case any kops are around. Neither dismissal actually occurs if there happens to be another angry shk present on the level where dismissal is being done.
nethack.rankin committedApr 15, 2011
Commits on Apr 13, 2011
-
vms Meta key hack (trunk only)
I can't figure out how to make PuTTY use the Alt key to function as a Meta key and set a character's high bit, so I used this hack to test the M-5 fix just committed. This lets me specify a character to be used to force the next character to have its high bit set, so I can fake the Meta key with a two character sequence. (I used the back-tick/accent, since nethack doesn't do anything special with it.) Conceivably something like this should be promoted to the core; this just affects VMS, and only when vmstty.c is compiled with DEBUG defined.
nethack.rankin committedApr 13, 2011 -
fix #2251 - M-5 operation with number_pad:2
From a bug report, using Alt+5 when number_pad mode is set to MSDOS compatibility (where Alt+5 is supposed to function as the 'G' movement prefix) didn't work correctly. The code that did M-5 to G conversion was being executed after the code which should have gotten G's direction, resulting in strange behavior, probably using stale values for u.dx and u.dy. (With current dev code, I evidently had u.dx==0 && u.dy==0 so was getting "You can't get there from here..." which is actually pretty amusing in the current context. 3.4.3 didn't have that feedback so I'm not sure what happened in it; possibly just silent refusal to move.)
nethack.rankin committedApr 13, 2011
Commits on Apr 9, 2011
-
fix #2236 - bag of holding weight
From a bug report, the weight of a non-cursed bag of holding would be off by 1 when the weight of contents was a multiple of 2 (for uncursed) or of 4 (for blessed), since the round off handling added 1 when it shouldn't in those cases. Mainly noticeable when empty; the extra 1 unit made it be twice as heavy as it should have been. Probably never noticed in actual play. He has implemented a patch which shows weights as part of an object's formatted description, making this stand out. Supposedly the Vulture's Eye interface also added a patch like that a farily long time ago; I wonder why nobody using it ever noticed. (Maybe the weight was suppressed for bags of holding there?)nethack.rankin committedApr 9, 2011 -
magic cancellation/Protection revamp (trunk only)
Optimize yesterday's new code. When calculating magic cancellation, avoid calling protects() for hero's inventory; the information it's providing is already available via u.uprops[PROTECTION]. That part of the inventory scan is only needed for monsters.
nethack.rankin committedApr 9, 2011
Commits on Apr 8, 2011
-
nethack.rankin committed
Apr 8, 2011