tung / dynahack Goto Github PK

Sokoban prizes are colored bright magenta in UnNetHack, but here this is done by sending a "sokoprize" flag with the object on the map, which the UI recolors. The true object appearance ID is still sent, so a custom client could easily show it without the bright magenta.

What should happen instead is that Sokoban prizes should send the appearance ID of a special Sokoban prize graphic of the object's type, which would happen to be bright magenta.

Non-Gehennom monsters can sometimes appear in corpse/statue/figurine/egg form in Gehennom.

Topi Linkala believes this to be C343-207: "Certain items that should never be created in Gehennom can be created there."

http://koti.welho.com/tlinkala/nethack/src/mkobj_c.html#line_212

Unrelated, but on the same linked page, about halfway down, the special_corpse() macro used by mkcorpstat() should probably include Cthulhu as well, given that the Riders are there.

For example, taking off armor could show something like "You finish taking off your armor. (5 turns)" It'd also help to show people the dramatic difference in time between soft engraving and hard engraving, or how long they searched or waited.

Alternately or in addition, the number of turns since the last player input could be shown in the turn counter of the 3-line status area, like "T(5):12345" where "(5)" is the delta. It'd be easy to add to the existing system for tracking and coloring attribute changes.

comparestmt in lev_comp.y of changeset 442 notes that the opcode it should return is SPO_JG and not SPO_JGE, otherwise something like "[90%]" will instead have a 91% chance of occuring, due to the use of rn2(), which returns random values starting at 0, not 1.

In NetHack, this is denied with the message, "You cannot name gold."

It's possible that other actions should not allow gold to be selected, but it's difficult to figure out what actions those are exactly from code of either NetHack or UnNetHack.

For example, zapping a giant turtle with a wand of make invisible makes a point near the giant turtle still cast a shadow. It's most noticeable when tested in a cleared-out big room. This bug may exist in UnNetHack, but I haven't tested it there yet.

Normally I'd hunt this down right away, but NetHack's vision logic is some real mind-twisting stuff. Hopefully it's just a couple of missing unblock_point() calls and I won't have to go there.

Sometimes the caves of the new level compiler will push so far to the left that there's no room for the left-most walls, resulting in rather odd looking gaps in the walls that are there. Deserves looking into.

The title of the menu may be of size BUFSZ, but it can only handle size QBUFSZ without imploding on itself.

I've noticed this happening sometimes after travel as well... are they related somehow?

This depends on how much needs to be modified to add a new char accel field to nh_listitem.

The frame borders should be drawn in orange when HP < 50% and red when HP < 25%, a bit like the old Dragon Quest games. It should also make other fiddly HP notification options less necessary.

For example, choosing to wear body armor should take off any existing body armor first, and choosing to remove a shirt should remove any covering cloak and body armor before and put it back on afterwards.

A confirmation prompt might be needed so players aren't surprised by the number of turns switching equipment takes. Maybe that could be limited to when body armor is involved.

This is actually a future TODO mentioned in a comment in the NetHack source code, but it seems like nobody ever got around to doing it.

a6d9021 - CS448: lev comp: unhardcode quest mon gen (Spork)

1501d6f - lev comp: Simplify mon gen save/restore code

Monster generation tuples are stored in-memory as a linked list. When saved in the binary save file format, they're saved from head to tail. However, when restored, each entry is added to the head of the restored list, effectively reversing it. The code that uses this monster generation list rolls a random number to choose from that list in its current order, so the monster chosen this way may differ in-game from a replay of the same moment, causing the RNG to derail and breaking the replay entirely.

_Note: Any code that saves and restores linked lists in this way may have the same problem!_

That list is unreasonably long to not at least have a few short cuts. It may even deserve an object class picker in front of it.

I don't pretend to understand how this really works, but this change would be in line with the surrounding code, which is the next best thing.

NitroHack's build system doesn't show these warnings for some reason.

The check for whether an object is unwieldable when adding the wield command needs to be fixed. This is particularly noticeable for the convict, who starts with a ball chained to them.

I just killed a black dragon, which left a "black dragon corpse" that was coloured white and granted cold resistance. The colour of that corpse should have been black.

This is somewhat related to the clairvoyance bug described on the NetHack wiki, which also exists in NitroHack:

You can reliably trigger clairvoyance (donation, cornuthaum, Amulet) by far-looking (;) or wall-walking on turns divisible by 15 until your surroundings are mapped.

In NitroHack, the cause is in pre_move_tasks(), which is called between moves, but also by post_init_tasks(), itself called when starting or restoring a game. If game saves/restores aren't logged, the rn2() call in pre_move_tasks() and/or the game state changes in realtime_tasks() would go untracked, causing RNG state deviation in game logs; something that would go unnoticed until trying to watch or restore from a log. Given how often these turns occur and players save/restore, this could be a major source of broken replays in NitroHack.

Side note: I really need to find out how saves/restores and logging interact. I should update this issue once I do.

Check for adding the wield command needs fixing.

1. Start/load a character.
2. Do a few actions that create messages.
3. Save and exit that character, but don't quit the whole game.
4. Start/load another character.
5. End their game somehow, e.g. #quit.
6. Read the last messages in the latter character's dumplog.

The messages from the previous character's game will "bleed" into the latter character's dumplog. A quick look at cscope reveals that the recent messages buffer isn't handled like other game state variables when starting or loading characters, which would fix this issue.

Pretty much any level with corridors doesn't have anything interesting that's diagonally adjacent to a corridor; anything that is is likely a dug-out space by a rock mole or dwarf with a pick-axe, or an actual corridor reachable some other way.

This should also reduce a bit the desire of autoexplore to compulsively sift through the rubble of digging monsters.

If a huge monster blocks drawbridge closing (e.g. with the passtune) and the hero is blind but can sense the monster (e.g. blessed potion of monster detection), the message reads "Something blocks the drawbridge with its weight!" instead of " blocks the drawbridge with his/her/its weight!"

In close_drawbridge() in src/dbridge.c:

/* A huge monster will block the drawbridge. */
if ((m = m_at(level, x, y)) && hugemonst(m->data)) {
    pline("%s blocks the drawbridge with %s weight!",
    canseemon(m) ? Amonnam(m) : "Something",
    canseemon(m) ? mhis(m) : "its");
    return FALSE;
}

I added this code myself, so this message bug doesn't exist in UnNetHack. The problem is probably the use of canseemon() instead of something more appropriate.

This bug exists in CS115: Huge monsters stop drawbridges from closing (2d6201caaa).

For example, calling all iron skull caps (orcish helms) with any string will never show them on the discoveries list, so whatever you called them can never be seen (TODO: see if it at least appears when trying to change what it's called).

This occurs for many objects in NetHack as well, so I don't know if this is a bug or was intended.

Shouldn't it? I need to test the behavior of this in NetHack to be sure.

One-line pop-up dialogs that exceed the width of the screen wrap around such that the dialog string overlaps the dialog border, which looks ugly. The dialog string should be truncated instead if it gets that long.

This seems to be due to the Grudge patch in UnNetHack. It seems like a bug, but then again maybe it's allowed so that angry quest leaders aren't blocked by their guardians. Then again, most quests don't have that many guardians to begin with, at least not enough that an angry quest leader would be blocked from reaching the player.

Like boolean options do.

Could be a neat little short cut, but it could also introduce inconsistency between the behavior of the very similar looking multi-object inventory picker. It's worth trying, but if it causes problems I may rework or remove it.

Just encountered a shop without a shopkeeper in the regular dungeon, giving me this message when I entered it. I thought I'd squelched all of the weird shkless shops and shopless shks when I fixed level door list handling issues with room sorting during level generation, but apparently not.

Bug found at 1e0f243, but probably traces itself back to 9dcf867 (the new level compiler). It causes a game crash.

I had to test literally a dozen games in wizmode and visit every Gehennom level to get this segfault, but it happens. Here it is:

Program received signal SIGSEGV, Segmentation fault.
0x0820d1ed in worm_known ()
(gdb) backtrace
#0  0x0820d1ed in worm_known ()
#1  0x081428a2 in pronoun_gender ()
#2  0x0820fbae in mon_break_armor ()
#3  0x08140a14 in newcham ()
#4  0x0810a231 in makemon ()
#5  0x0813450c in fill_zoo ()
#6  0x081c36c8 in fill_room ()
#7  0x081c779e in sp_level_coder ()
#8  0x081c7a40 in load_special ()
#9  0x0812d0b6 in makemaz ()
#10 0x08127c2f in makelevel ()
#11 0x08129539 in mklev ()
#12 0x080a5db9 in goto_level ()
#13 0x080a7565 in deferred_goto ()
#14 0x081cedca in level_tele ()
#15 0x0807e36d in wiz_level_tele ()
#16 0x0808a592 in do_command ()
#17 0x080675ec in command_input ()
#18 0x080679c1 in nh_command ()
#19 0x0822f8ad in nhnet_command ()
#20 0x0805e837 in commandloop ()
#21 0x0805ec68 in rungame ()
#22 0x0804ad5a in mainmenu ()
#23 0x0804ae7c in main ()

My interpretation is that a chameleon is turning into a worm, is breaking out of its armor, tries to build an appropriate message and ends up calling worm_known, which is where the segfault happens.

worm_known uses the wtails field of a dereference to the mysterious level global variable; the likely cause of this. Maybe the old level generator set the level global because the new one definitely doesn't. I traced this line back to the matching commit, and in that, just two functions up, count_wsegs refers to wtails via a level through its struct monst pointer. Strange it doesn't do the same; I'll have to find out if that's what Daniel Thaler intended.

Come to think of it, should chameleons even be allowed to become long worms?

Just encountered a chromatic dragon in one of the new UnNetHack castle variants.

More generally, create_monster() in src/sp_lev.c calls mkclass() with G_NOGEN when creating a random monster given a monster class, causing mkclass() to ignore the G_NOGEN flag that chromatic dragons possess in src/monst.c.

pm = mkclass(&lev->z, class, G_NOGEN);
/* if we can't get a specific monster type (pm == 0) then the
   class has been genocided, so settle for a random monster */

This bug exists in UnNetHack too and even in NetHack, minus chromatic dragons; git blame says it goes back to NetHack 3.1.0, released in 1993.

NetHack4 fixes many of these and possibly more:

• cans of grease
• tinning kits
• leashes
• candelabrum
• candles
• lamps and lanterns
• applied potions of oil
• crystal balls
• figurines
• land mines and beartraps
• gray stones

https://gitorious.org/nitrohack/ais523/commit/b00d3fdb2999f76a048eb24bbf4f18e6ec4413f3/diffs

Obstacles like boulders and normal closed doors normally have a 5-step detour threshold. The threshold for doors that are known to be locked should be higher, perhaps 10 or 20. Requires door branding from NetHack4.

When winning a game started with extended conducts by ascending with the Amulet of Yendor, you'll get a high score entry that looks like "Patito-Mon-Hum-Mal-Cha the nude vegan pacifist ascended to demigod-hood."

However, winning the game the atheist way by invoking the Amulet on the high altar of your alignment gives none of the extra conduct information, which it arguably should.

This was introduced with UnNetHack revision 405, and unless this was fixed after that point, it likely still exists there too.

The command that looks up an object in data.base tries to discern objects with proper names from objects whose names are just player notes; the former should query the proper name in data.base, the latter should ignore the name and consult the object's general type name instead.

The current heuristic decides that an object's name is proper if it starts with a capital letter. The problem (at least for me) is that I often have capitalized names for objects that are just notes, e.g. "Res:PCSl" means that I've gained poison, cold and sleep intrinsic resistances.

A better heuristic would check if the name is made only of letters, spaces, "hyphens" (the minus sign) and single quotes, and begins capitalized. I believe all names issued to objects by the game fit in this scheme, while excluding most names given by players, e.g. level numbers for special locations, turn counts, resistance notation, etc.

E.g. selecting "w - wield" from the action menu of a lit lamp gives the message "That is a silly thing to wield" and does nothing even though going through the usual wield command allows it just fine.

Maybe for partial inventory listings too, though I'm not sure how they should appear.

Behavior is present in NetHack. Patch exists in NetHack4.

E.g. the slippery hands message when eating a blue jelly corpse. This may be fixed by importing the message line wrapping from NetHack4.

A few that have burned/annoyed me in the past:

• "lembas" -> "lembas wafer"
• "wand of teleport" -> "wand of teleportation"
• "ring of strength/dexterity" -> "ring of gain strength/dexterity"

This happens in 24-line mode. I think NetHack in the same circumstance puts a "--More--" before showing the inventory, but I'll need to confirm that before I can fix it.

From http://nethackwiki.com/wiki/Talk:Cthulhu

If you fill the room up with them will Cthullu eventually lose his ablity to reform? Ndwolfwood 07:12, 15 June 2011 (UTC)

To answer your questions: [...]

• Filling the level up with acid blobs: It crashes the game, although closing and reloading, he was no longer present. Probably not a good idea, since I don't know if that'll work every time. -Ion frigate 14:03, 15 June 2011 (UTC)

I looked into this, and found that if you kill Cthulhu and fill the level so he has nowhere to resurrect, the game will enter an infinite loop and will not respond to any player input.

The problem is actually two problems:

• revive_cthulhu() in region.c calls enexto() to find a good spot to place Cthulhu, even though that should be done by makemon() when it's called.
• If the above enexto() fails, revive_cthulhu() tells makemon() to place Cthulhu randomly, triggering an infinite loop within the latter when it tries to find a good random location, which it never will on an enemy-filled level.

What should happen is that makemon() should give up after not finding a good spot to make a monster (maybe after an enexto() to ensure no hard-to-find empty space is skipped), and revive_cthulhu() should leave positioning up to makemon().

E.g. selecting "cursed" and "armor" should only present cursed armor in the drop menu, not all cursed objects and all armors.

For example, a starting valkyrie with a small shield counts that shield once for the armorless conduct, but every time the save is restored, the shield is counted again, incrementing the number of times the game thinks the armor has been worn.

The culprit seems to be set_wear() in src/do_wear.c, which is called by nh_start_game() in src/allmain.c, at least in this branch.

This bug also exists in UnNetHack, except the calling function is main() in sys/unix/unixmain.c, and likely the main functions of any other system port.

Is the autoexplore system treating water like it's floor? Is it finding objects in the water the player can't see? Should water be treated like walls for the purpose of autoexplore/travel?

Top-left, to be exact. Fix is in NetHack 4.

Engraving in the dust next to a wall, then attempting to move into the wall will scuff the engraved message, even though it takes no turns. It happens because domove() in hack.c calls u_wipe_engr() before checking if the player actually moves.

This bug also exists in NetHack 3.4.3 and even the latest version of UnNetHack.

I heard a bunch of people were exploiting this in FreeNode's #nethack IRC channel to scum the RNG for super-low turn-count speed runs, so I feel iffy about patching it if it doesn't harm normal games. Maybe I'll consult with other NetHack players/developers and see what they think.

e.g. A player whose name starts with a digit will always have their name refused by a vault guard when they ask. It looks like C343-238; the problem is in the invault() function of src/vault.c at the naming prompt, or rather, after it.

Tangentially, NitroHack allows names with almost any characters, restricted only by whether the host OS's file system allows it as the name of their log file. I can't decide if this is a bug, and if it is, how it should be handled.

... where the rest of the wizard mode debugging commands are defined. Its description should also begin with "(DEBUG)" and be flagged CMD_NOTIME, like the others.