That is, use NetHack's RNG instead of the direct system RNG. This fixes
maps generated with randlines to interact correctly with potential
future RNG system changes e.g. switching PRNG algorithms, supporting
NAO343's RNG reseeding, and even supporting replays like NetHack 4.
Based on DynaHack commit e464f63 (lev_comp: Fix system RNG use in
randline) by me.
This reverts commit 2ff96797a8.
Since this pull request was made to the DevTeam, a commit has appeared
in the official repo's NetHack-3.6.0 branch which effectively does the
same thing: NetHack commit 98b5f58 (tty menu coloring) by PatR.
To test:
1. Get a level layout with two shops facing each other, e.g. minetn-4.
2. Sell a fragile object to one of the shops.
3. Dig a pit in the other shop's door space so its shopkeeper stays out
of the way.
4. Pick up an object in that other shop so it appears on your bill.
5. Zap a wand of striking at the first shop to break the fragile
object.
6. 'p'ay for the object picked up.
Expected result: Object gets the standard prompt to pay for it.
Actual result: "Paid object on bill??" followed by "Program in disorder
perhaps you'd better #quit." followed by the object being given to the
player for free.
The cause? This comment going all the way back to 2002:
> /* FIXME: object handling should be limited to
> items which are on this particular shk's bill */
Originally reported by PaRaD0xx in FreeNode's #NetHack IRC channel
whilst playing NAO343.
Based on DynaHack commit d995ed1 (Fix paid object on bill when angering
another shkp) by me.
It's obviously supposed to be the latter and not the former.
Interesting note: This same bug was found and fixed in NitroHack commit
4973ce4 (static checker day: fixes for scan-build and PVS warnings).
This fixes a bug where the hero could accidentally donate the contents
of their bag to a shopkeeper if they put it in another bag on the shop
floor that also belonged to the hero. To reproduce:
1. Drop a sack on the floor, but don't sell it.
2. Get another sack and put in hero-owned objects.
3. Put the sack with objects into the sack on the shop floor.
4. Take out the sack with the objects from the sack on the shop floor.
The shopkeeper will claim you owe them for the objects in the sack, and
view the contents of the sack will show them as belonging to the
shopkeeper.
This fix is what those previous fixes for `SELL_DONTSELL` were for.
Based on DynaHack commit f91ce0b (Fix billing/credit when hero nests
their containers on a shop floor) by me.
There's no capacity for the shop logic to handle gold without also
changing the credit/debit within it, so gold must always be handled in
`sellobj()`, even when the state of it is set to `SELL_DONTSELL`.
This is needed for an upcoming bug fix.
Based on DynaHack commit b0784c5 (Credit/debit gold in containers even
in sellobj_state SELL_DONTSELL) by me.
For a shop to NOT charge for an object, two conditions apply:
1. The object's `no_charge` flag must be set.
2. That `no_charge` flag must be set regardless of whether or not the
shop typically sells the object in question.
There are two places in `sellobj()` which ignore the second condition,
thus transferring object ownership from the player to the shop without
the player's consent:
1. A container is dropped in a shop that typically sells such
containers and `sellobj_state` is `SELL_DONTSELL`.
2. A zero-cost container holding nothing but gold is dropped in a shop
that typically sells such containers.
Neither occurs currently in NetHack: the latter because NetHack has no
zero-cost containers, but the former is needed for an upcoming bug fix.
This may be related to SC343-21: "Accounting is incorrect for containers
dropped in a shop that does not sell them."
Based on DynaHack commit 4e79b6a (Don't shop-donate non-empty bags
dropped in sellobj_state SELL_DONTSELL) by me.
This fixes a bug where hundreds of turns are wasted by the travel system
moving the player back and forth when the player targets an unreachable
space and sight-blocking obstacles occur in certain formations
in-between. The player will only be stopped if they're interrupted
externally, e.g. growing hungry or being hit by a monster. See the
comment in the code for full details.
Based on DynaHack commit 02da53e (Fix travel moving player back and
forth repeatedly) by me.
Tung Nguyen