{"ref":"refs/heads/master","commits":[{"author":{"email":"3d0f3b9ddcacec30c4008c5e030e6c13a478cb4f@dthaler.de","name":"Daniel Thaler"},"sha":"8ddde016b785bf675db62d180a62dd39727ea2a7","message":"allow non-letter characters as menu accelerators","url":"https://api.github.com/repos/DanielT/NetHack/commits/8ddde016b785bf675db62d180a62dd39727ea2a7"},{"author":{"email":"3d0f3b9ddcacec30c4008c5e030e6c13a478cb4f@dthaler.de","name":"Daniel Thaler"},"sha":"a5bc53bb3a180e87a9fbbc8f9729dabedbc44bf7","message":"autopickup rules: the replacement for pickup_types and AUTOPICKUP_EXCEPTIONS\n\nThe autopickup rules are only active if autopickup is on. If autopickup\nis on and you walk onto an item, the item is compared to each rule in\nturn until a matching rule is found. If a match is found, the action\nspecified in that rule is taken and no other rules are considered.\nIf no rule matches, the item is not picked up.\n\nEach rule may match any combination of object name, object type,\nand object blessing (including unknown).\nA rule that specifies none of these matches everything.\n\nExample rules as shown in the UI:\n 1. IF name matches \"*lizard*\" AND type is \"food\": < GRAB\n 2. IF name matches \"*corpse*\" AND type is \"food\":   LEAVE >\n 3. IF type is \"food\":                             < GRAB\n\nA newt corpse, for example, will not match rule 1, but rule 2 applies,\nso it won't be picked up and rule 3 won't be considered.","url":"https://api.github.com/repos/DanielT/NetHack/commits/a5bc53bb3a180e87a9fbbc8f9729dabedbc44bf7"},{"author":{"email":"3d0f3b9ddcacec30c4008c5e030e6c13a478cb4f@dthaler.de","name":"Daniel Thaler"},"sha":"46b3235a14bf7836bf459f6a6c6572f95f472494","message":"stretch headings in multicolumn menus to fill the entire column","url":"https://api.github.com/repos/DanielT/NetHack/commits/46b3235a14bf7836bf459f6a6c6572f95f472494"},{"author":{"email":"3d0f3b9ddcacec30c4008c5e030e6c13a478cb4f@dthaler.de","name":"Daniel Thaler"},"sha":"4a7e22ecd0baeae6a49c42e9eeb3cb8475eb892f","message":"autopickup_rules is done","url":"https://api.github.com/repos/DanielT/NetHack/commits/4a7e22ecd0baeae6a49c42e9eeb3cb8475eb892f"},{"author":{"email":"05e896af68d9ff60c4b413a55719fb80907d550e@bham.ac.uk","name":"Alex Smith"},"sha":"ceec20224c913daed337b3ab7d09c586bde5de03","message":"Fix findtravelpath buffer overflow bug (from AceHack)\n\nThe easiest way to recreate the bug is on the UNIX tty version of\nvanilla NetHack; in wizmode, dig out a level (or force the bigroom\nvariant that's already an entirely dug-out level to generate), then fill\nthe entire thing with boulders (it takes a while). Then try to travel\nfrom one corner to the diagonally opposite corner, and you'll get a\nsegfault.\n\nThe bug's in the conditional starting at hack.c:700. The enclosing for\nloop is run once for each direction (8 times total), and sets nx and ny\nfor the next x and y in the direction it's considering. The conditional\non line 700, though, checks Passes_walls (independent of dir/nx/ny),\ncan_ooze (likewise independent), closed_door(x, y) (likewise\nindependent), and sobj_at(BOULDER, x, y) (likewise independent); in\nshort, whether it's true or not has nothing to do with dir, nx, or ny,\nand thus it'll either be true on all 8 iterations, or false on all 8\niterations.\n\nThe case where it's false is the usual case, and the code in that case\nworks correctly. If it's true, though, it counts the square as costing 3\nrather than 1, (\"/* closed doors and boulders usually cause a delay, so\nprefer another path */\"), and the way it does this is to re-add the\ncurrent entry in travelstepx/y to the next step's current entry in\ntravelstepx/y, up to twice more. Although this has the desired effect of\ndelaying considering the step into the future, the step ends up getting\nadded eight times, once for each direction, even though it has nothing\nto do with the direction. So instead of adding 1 step to the buffer, it\nadds 1, then 8, then 64, and evaluates the next move 64 times from\nthere. (However, potential moves /from/ the square are only added once,\nwith the code seeing 1 optimal route and 63 suboptimal routes.)\n\nThe buffer, in theory, has enough room to contain every square on the\nmap once. It /doesn't/ have enough room to contain every square on the\nmap 64 times; but this typically doesn't matter, as there's room for\nCOLNO*ROWNO (80*21 or 1680) steps in the buffer, which holds all the\nsteps at the same distance from the player. (It should be ordinary\nsquares counting 1, boulders/doors counting 1; but due to the bug,\nordinary squares count 1, and boulders/doors count 64.) The easiest way\nto trigger the bug, therefore, is for 27 or more boulders/closed doors\nto be equidistant from the player, leading to 1728 squares being stored\nin the length-1680 travelstepx array.\n\nIn practice, though, considerably more boulders are needed for the\noverflow to have any visible effects, because findtravelpath allocates\nseveral large arrays on the stack, and they tend to give some overflow\nroom. That's why doing something as dramatic as filling the level with\nboulders is needed in order to produce an obvious demonstration of the\nbug.","url":"https://api.github.com/repos/DanielT/NetHack/commits/ceec20224c913daed337b3ab7d09c586bde5de03"}],"head":"ceec20224c913daed337b3ab7d09c586bde5de03","push_id":52247607,"size":5}