accept: rejectname() makes no sense outside acce(); inline

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
consider: Clean up recovery from an impossible error

Drop the unhelpful message to the player, and fail the command.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
consider: Clean up "either treaty or loan" assumptions

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Remove option TREATIES

TREATIES has issues:

* Treaties can cover attack, assault, paradrop, board, lboard, fire,
  build (s|p|l|n) and enlist, but not bomb, launch, torpedo and
  enlistment centers.

* Usability is very poor.  While a treaty is in effect, every player
  action that violates a treaty condition triggers a prompt like this:

    This action is in contravention of  treaty #0 (with Curmudgeon)
    Do you wish to go ahead anyway? [yn]

  If you decline, the action is not executed.  If you accept, it is.
  In both cases, your decision is reported in the news.

  You cannot get rid of these prompts until the treaty expires.

* Virtually nobody uses them.

* Virtually unused code is buggy code.  There is at least one race
  condition: multifire() reads the firing sector, ship or land unit
  before the treaty prompt, and writes it back after, triggering a
  generation oops.  Any updates made by other threads while trechk()
  waits for input are wiped out, triggering a seqno mismatch oops.

* The treaty prompts could confuse smart clients that aren't prepared
  for them.  WinACE isn't, but is reported to work anyway at least
  common usage.  Ron Koenderink (the WinACE maintainer) suspects there
  could be a few situations where it will fail.

This feature is not earning its keep.  Remove it.  Drop command
treaty, consider treaty, offer treaty, xdump treaty, reject treaties.
Output of accept changed, obviously.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
tests: Don't leak telegram counters from setup into test

Moving the telegram files away isn't enough, we also have to reset
nat_tgms.  actofgod/setup-POGO does it already, but fire/setup-POGO
doesn't.  Do it in begin_test instead, right where the telegram files
are moved away.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
tests/build: New; exercises build command

drnuke_const is not covered, yet.

Random rounding causes some complications: sometimes build succeeds
without materials.  Troublesome spots are clearly marked in the test
input.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
tests/fire: Rename test scripts for clarity

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
build: Factor code out of build_ship(), build_plane(), build_land()

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
build: Stop abuse of construction material random rounding

Construction materials required for building a ship, plane or land
unit are rounded randomly.  Crafty players exploit this to save
materials: they put just enough materials there so that build succeeds
when it rounds down.  Then they simply keep trying until it succeeds.

Planes and land units are built at 10%, so rounding happens when
materials for 100% aren't multiples of ten.  If they're below ten, you
can even build without materials.  In the stock game, this is the case
for linf, and many plane types.

Ships are built at 20%, so multiples of five aren't rounded.  Ship
building never rounds in the stock game.

Prevent the abuse of random rounding by requiring the required
fractional amount rounded up to be present.  Don't change the actual
charging of materials; that's still randomly rounded.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
build: Report missing stuff more nicely for ship, plane, land units

If both materials and avail are missing, report missing avail instead
of materials, to avoid tempting the player to move in materials only
to discover avail is lacking, too.

Report what materials are missing instead of just "Not enough
materials".  Does not yet include military for planes, but that's
next.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
build scrap: Redo 4.2.3's fix for manufacturing military

scrap has always returned the scrapped planes' full crew, regardless
of efficiency.  build, however, charged only 10%.  If you built ten
planes with one crew each, you used up one military.  Or none, if you
abused random rounding.  If you scrapped them again, you got ten back.
Pretty pricey way to manufacture military, but wrong all the same.

4.2.3 plugged this hole by making build never round military to zero.
Ugly special case, and not documented.  Also doesn't prevent abuse of
random rounding for planes requiring more than 10 crew, but such
planes don't exist in the stock game.

Redo this fix:

1. Make scrap return crew proportional to efficiency, randomly
rounded.  Note that scrap returns only two thirds of the other
materials, rounded down.  Recycling materials isn't perfect, but
recycling aircrew is.

2. Drop the special case from build: treat military just like other
materials.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
build: Report missing stuff more nicely for nukes

By switching build_nuke() to sector_can_build(), build_charge().
Changes reporting of missing stuff to be like for ships, planes and
land units:

* Report missing available work, or else missing materials, or else
  missing money instead of materials, or else money, or else work.

* Report what materials are missing instead of how much materials have
  to be there.

* Clean up stray ';' in reporting of missing work.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
build: Report missing stuff more nicely for bridges

By switching build_nuke() to sector_can_build(), build_charge().

Report missing available work, or else missing materials, or else
missing money, for consistency with the other things you can build.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
tests: Zap setup's news and lost items, like telegrams

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
edit: Fix reporting of no-op unit location change

Report "unchanged" instead of "changed from X,Y to X,Y".  Screwed up
in v4.3.32.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
tests/bridgefall: New; exercising splashing of bridges

Stuff sitting on bridges isn't covered, yet.  tests/fire has some.  To
be moved here eventually.

The test exposes bugs.  They're marked "BUG:" in the test input.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
path: New DIR_BACK()

Actually pathfind.c's rev_dir() turned into a macro, to make it
available elsewhere.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
bridgefall: Fix harmless coordinate normalization bug

bridgefall() wants to do this:

    for all possible pairs of directions (i, j)
        if i and j cancel out
	    continue
	do stuff

It does it by adding direction offsets to start coordinates, and
comparing the resulting coordinates to the start coordinates.  Fine,
except it neglects to normalize the resulting coordinates.

Harmless in practice, because you can get an incorrect result only
when the path goes around the world, which it can do only in a 4x2
world.

Fix it anyway, by testing "directions cancel out" directly.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Revert "Remove dead EASY_BRIDGES code from bridgefall()"

This reverts commit df62b8604d7607947131a9d4c04a92d08954ca34.

The next commit will revive that code.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
bridgefall: Fix support loss with EASY_BRIDGES and BRIDGETOWERS on

With EASY_BRIDGES on, bridge spans need to be next to land or a bridge
tower to remain standing.

Land can't go away, but a bridge tower can fall.  Bridge spans next to
it may lose support then.  Bug: they don't fall when they lose support
that way.  Fix that.

Broken in commit 40eb78e, v4.3.12.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>