Move clearing of retreat flags from retreat_ship(), retreat_land() to
retreat_ship1(), retreat_land1(), so it's where the retreat path is
shortened.
Move putship(), putland() from retreat_ship1(), retreat_land1() to
retreat_ship(), retreat_land(), so it's where the nxtitem() is, and
doesn't need a "if (!orig)" guard. Requires making retreat_ship1()
and retreat_land() return non-zero when they modified their argument.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
When a retreating ship or land unit runs into a sector it can't enter,
it stops. The direction character that led it there is consumed, even
though it could not be followed. The next retreat will then attempt
to follow the rest of the path. Don't do that.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Undocumented misfeature: retreat and lretreat accept anything as
retreat path. The paths' actual consumers retreat_ship1() and
retread_land1() silently ignore invalid direction characters.
The retreat paths are in xdump, and invalid ones could conceivably
confuse smart clients.
Change the commands to reject invalid paths, and the consumers to oops
on invalid direction characters.
Note that invalid paths get rejected even when they're not actually
used because the conditions argument contains a "c" for "cancel".
Requiring the user give a new path so he can cancel the old one is
comically bad design.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Return RET_SYN instead of RET_FAIL then. Also drop the error message;
the usage help printed for RET_SYN should do.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Broken in commit bb5dfd8, v4.3.16. Fix by recognizing '?' only when
getting the argument interactively.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Obscure feature: 'h' in a retreat path stops the current retreat. The
code treats that as entering the current sector again, thus charges
mobility for staying put. It also reports "could not retreat to" for
a ship or land unit that can retreat out of, but could not retreat
into its current sector, e.g. a ship in an unfriendly harbor.
Fix by cleaning up the tortuous control flow.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
The retreat code happily retreats anything, without considering who
owns it. It reports retreat to the owner by bulletin, even when the
owner is the current player.
Commands shouldn't report to the current player by bulletin, they
should print directly. Fixable. However, your ships and land units
retreating from your own actions makes little sense. Suppress it.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Code never actually retreated them, but it could zap their mission and
retreat flags. Harmless, but avoid it anyway.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Some callers have to second-guess shp_check_nav() to figure out
whether CN_LANDLOCKED means "too big to fit into the canal" or "can't
go there at all".
Fix that by returning d_navigation. CN_LANDLOCKED becomes either
NAV_CANAL or NAV_NONE, CN_CONSTRUCTION becomes either NAV_02 or
NAV_60, and CN_NAVIGABLE becomes NAVOK.
The CN_NAVIGABLE, ... codes are now unused. Drop them.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
A group retreat is executed in increasing UID order. The resulting
bulletin can be confusing.
Instead, retreat the ship that had its retreat conditions satisfied
first, and only then its group, if any.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
The mission gets cleared whenever a retreat is triggered, even for
ships and land units that are unable to retreat.
Clear it only when the ship or land unit actually retreats.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
retreat_land() reads ships instead of land units, overrunning local
variable land. On lucky systems such as mine, this clobbers ni, and
triggers an oops. On unlucky systems, it crashes. On really unlucky
systems, it corrupts the land units file.
Broken since land unit retreat was added in Chainsaw 3.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Copying the ship copies the ship to follow. When the source ship
doesn't follow a ship, the target ship is made to follow the source.
Screwed up since Chainsaw added the means to copy a ship. Fix it.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Copying the sector copies its distribution center. When the source
sector has none, the target sector is made to distribute to the
source. Unexpected. Zap the distribution center then.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Let deities build in any sector. If the deity's tech level is too
low, use the required tech level instead. Don't require or use
materials, work or money. Bridge spans still require support.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
With EASY_BRIDGES off, bridge spans need to be next to a bridge tower
or a bridge head that is at least 20% efficient to remain standing.
When a bridge tower or head gets damaged below 20%, adjacent spans may
lose support. Bug: they don't fall when they're next to another
bridge head below 20%.
Has always been broken.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
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>
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>
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>
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>
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>
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>
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>
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>
Two bugs. First, multifire() checks the condition only for surface
ships, not for submarines. Second, multifire() neglects to write back
the ship after retreating it. The player is told the ship retreats,
but it actually stays where it is.
Broken since retreat was added in Chainsaw. Previous fixes (commit
8065fe8, v4.3.1 and commit de2651e, v4.3.19) "fixed" only the
bulletin.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
It's not firing, yet.
While there, trim an unwanted blank line before reporting the first
sector ready.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Can't actually happen with the current damage formulas. If it could,
then the special treatment would be inconsistent with sectors and land
units.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
We check all necessary conditions for being able to fire before
prompting for a target. Except for land unit guns. Clean that up.
fort_fire(), shp_fire() or lnd_fire() fail only when the fort, ship or
land unit can't fire. If that happens, our checking is incomplete.
Oops then.
We recheck some of the necessary conditions after getting the target.
However, because the command fails when the firing sector, ship or
land unit has changed since the first check, these rechecks can't
fail. Drop them.
Note that the rechecks were just as useless before commit 66165f3
fixed fire to fail on change, because they rechecked the unchanged
cached copy instead of the possibly changed original.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Adding or removing a command to/from a test has unfortunate effects:
* Before the previous commit: if the command consumes pseudorandom
numbers, all subsequent users of pseudorandom numbers get different
ones. This has always been a major headache.
* Since the previous commit: all subsequent users of pseudorandom
numbers get different ones whether the command consumes any or not.
That's even worse.
* If the command uses BTUs, subsequent prompts are changed. Not
nearly as bad as the above, but still annoying.
Create a new command __cmd to allow compensating for adding/removing
commands for tests. Throw in the ability to compensate treasury
changes for good measure. Three arguments: command count, BTU use,
money use.
Usage example: say you add a convert command to a test, and it uses 3
BTUs and $15. Then you compensate by adding "__cmd added 1 3 15"
right after it.
The command must not be available unless running_test_suite is on, of
course. Make it require the new player command capability TESTING,
and give that to all players when running_test_suite is on.
The command is intentionally not documented in info. Switch
running_test_suite off for info-test, to hide it (and any future
TESTING commands) from info-test.
Suppress the command counter increment for TESTING commands, so they
can be used without upsetting pseudorandom numbers
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Tests need repeatable pseudorandom numbers to yield repeatable
results. We seed the pseudorandom number generator with a fixed value
(emp_server -R) to make it produce the same sequence of numbers every
time. But whenever code exercised by a test is changed to consume
fewer or more of them, all subsequent users get different numbers
regardless. The ensuing test result changes are extremely tedious to
review.
To address this problem, reseed the PRNG with the count of commands
right before executing a command when running_test_suite is on. This
way, the effect of perturbing the PRN sequence lasts only until the
next command.
Note that the next command could be another player's. Doesn't matter.
Adding or removing commands now upsets the PRN sequence even for
commands that don't consume PRNs. The next commit will take care of
that.
Perturbs test results across the board. Hopefully, that'll happen
much less frequently now.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
For now, it just logs "Configured for testing" on startup, and prints
a scary warning on player login.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Empire 2 settled on this formula for the stack size:
stacksize = 100000 +
/* finish_sects */ WORLD_X * WORLD_Y * (2 * sizeof(double) +
sizeof(char *));
Obviously attempts to provide space for a known configuration-
dependent stack hog. The hog went away when finish_sects()'s arrays
became dynamically allocated in 4.2.0.
Adjusting for that by dropping the extra term might well do (I observe
only a few KiB of stack used on my system). But let's set it to 512
KiB instead to be on the safe side.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
