navi() uses shp_sel() to collect ships, then shp_nav() to drop
ineligible ships. shp_sel() wipes mission and retreat orders. Stupid
when shp_nav() will drop them right away.
Avoid that by having shp_sel() check shp_nav()'s conditions, too.
navi()'s shp_nav() call won't find anything to drop now. The call
will be removed shortly.
This drops "& stays in" from some failure reports, since shp_nav()'s
reject messages end with "& stays in X,Y", and shp_sel()'s don't.
Likewise for marc(), lnd_sel(), lnd_mar().
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Don't wipe it in lnd_sel(), rely on lnd_mar_one_sector() and
lnd_sweep() to wipe it when the land unit actually moves.
Closes FRE#43.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
torp() applies torpedo damage after retreat. Wrong, because mobility
cost increases with damage. Broken since retreat was added in
Chainsaw.
Fix by applying damage before retreat. Bonus: bulletins make more
sense.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
shp_sweep() and lnd_sweep() print only a couple of "Sweep...".
Sometimes, the sector isn't obvious, e.g. when you march multiple
sectors in one go, sweeping along the way.
Print "Approaching minefield at X,Y..." right before the first sweep
in a sector.
Note that retreat.c duplicates the sweeping code. Retreating ships
report sweeping with coordinates since commit dcd0794, v4.2.21.
Retreating land units still sweep silently. Left for another day.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Don't report every incapable ship or land unit. Complain only when
there are no capable ships or land units available.
The ships are all in the same sector, so complain about the sector
type just once instead of once per capable ship or land unit.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
When ships enter a sector with sea mines, any minesweepers sweep, then
hit mines, and finally all ships (including the minesweepers) hit
mines. Sweeping in a sector (navigate sub-command 'm') works the same
without the final step.
When land units enter a sector with land mines, any engineers sweep,
and then all land units (including the engineers) hit mines. Sweeping
in a sector (march sub-command 'm') works the same, which means
non-engineers can hit mines then. Broken in Empire 2.
Actually broken for ships too then. 4.0.17 fixed ships, but neglected
to fix land units.
Change the land unit code to work like the ship code. Fixes march
sub-command 'm' not to expose non-engineers to mines. Changes march,
attack and assault with option INTERDICT_ATT enabled to expose
engineers twice.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
When lnd_sweep() rejects an engineer for want of mobility, it removes
it from the list of units.
Can happen only when sweeping for march sub-command 'm'. Any engineer
without mobility is dropped from the march immediately. Broken in
Empire 2.
Fix lnd_sweep() to handle this case just like the others, and like
shp_sweep(): report and continue with the next list member.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
When you try to navigate a ship without canal capability into an
unfriendly canal, you get "can't go" when it's below 2%, else "too
large to fit". Always report "can't go" for unfriendly sectors.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
The capability to navigate ships spread over several sectors is
obscure and rarely useful. Accidental use is probably more frequent
than intentional use. Issues:
* Interactive prompts show only the flagship's position, and give no
clue that some ships are actually elsewhere.
* Path finding is supported only when all navigating ships are in
the same sector.
* Interdiction becomes rather complex. For each movement, every
sector entered is interdicted independently. This means the same
fort, ship, land unit or plane can interdict multiple times.
Interdiction order depends on the order the code examines
ships. which the player can control. This is all pretty much
undocumented.
* Complicates the code and its maintenance. Multiplies the number of
test cases needed to cover navigate.
I feel we're better off without this feature.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
The capability to march land units spread over several sectors is
obscure and rarely useful. Accidental use is probably more frequent
than intentional use. Issues:
* Interactive prompts show only the leader's position, and give no
clue that some land units are actually elsewhere.
* Path finding is supported only when all marching land units are in
the same sector.
* In each step, the bmap is updated for the leader's radar. The bmap
is not updated around other marching land units. Already odd when
all units are in the leader's sector, and odder still when some are
elsewhere.
* Interdiction becomes rather complex. For each movement, every
sector entered is interdicted independently. This means the same
ship, land unit or plane can interdict multiple times. Interdiction
order depends on the order the code examines land units. which the
player can control. This is all pretty much undocumented.
* Complicates the code and its maintenance. Multiplies the number of
test cases needed to cover march.
I feel we're better off without this feature.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Unlike the move command, march checks sector abandonment before every
step.
If the player declines, the last land unit stays put and is removed
from the march.
Except when sectors or land units change while we're waiting for the
player's reply. Then the last unit is not removed from the march.
This can scatter land units. Screwed up when checking for abandoning
the sector was added in 4.2.2.
Change march to work like move, and to avoid scattering land units: if
the player declines to abandon the sector, the command simply fails.
Put the check into new lnd_abandon_askyn().
Extend would_abandon() and want_to_abandon() from a single land unit
to many. Rename the latter to abandon_askyn() for consistency.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
When attempting to enter a sector with a land unit that can't go there
while the marching land units are all in the same sector, march stops
and prompts without removing the incapable land unit from the group.
If another land unit has already entered the sector, the group becomes
scattered.
This can happen when marching a mixed group of spies and non-spies
into a non-allied sector. Same for marching a mixed group of trains
and non-trains into a sector without rail, except such groups have
been disallowed since commit 36e41e5 (v4.3.7). Both screwed up when
spies and trains were added in 4.0.0
Remove the incapable land unit from the group when another land unit
can enter the sector. This avoids scattering land units.
Don't remove incapable land units when no land unit can enter the
sector. Without this, march would remove everyone and end then.
It can also happen when sectors or land units change while we're
sitting at the "Do you really want to abandon X,Y" prompt. I'm going
to fix that differently.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
When attempting to enter a sector with a ship that can't go there
while the navigating ships are all in the same sector, navigate stops
and prompts without removing the incapable ship from the group. If
another ship has already entered the sector, the group becomes
scattered.
This can happen only when navigating a mixed group of ships with and
without canal capability into a canal. Broken in commit 74e4e281,
v4.3.0.
Remove the incapable ship from the group when another ship can enter
the sector. This avoids scattering ships.
Don't remove incapable ships when no ship can enter the sector.
Without this, navigate would remove everyone and end then.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
SAIL has issues:
* Sail orders are executed at the update. Crafty players can use them
to get around the update window.
* The route is fixed at command time. You can't let the update find
the best route, like it does for distribution.
* The info pages documenting it amount to almost 100 non-blank lines
formatted. They claim you can follow friendly ships. This is
wrong. They also show incorrect follow syntax. Unlikely to be the
only errors.
* Few players use it. Makes it a nice hidey-hole for bugs. Here are
two nice ones:
- If follow's second argument is negative, the code attempts to
follow an uninitialized ship. Could well be a remote hole.
- If ship #1 follows #2 follows #3 follows #2, the update goes into
an infinite loop.
* It's more than 500 lines of rather crufty code nobody wants to
touch. Thanks to a big effort in Empire 2, it shares some code with
the navigation command. It still duplicates other navigation code.
The sharing complicates fixing the bugs demonstrated by
navi-march-test.
Reviewing, fixing and testing this mess isn't worth the opportunity
cost. Remove it instead. Drop commands follow, mquota, sail and
unsail. Drop ship selectors mquota, path, follow.
struct shpstr shrinks some more, on my system from 160 to 120 bytes.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
The autonavigation feature has issues:
* Autonavigation orders are executed at the update. Crafty players
can use them to get around the update window.
* Usability is poor:
- The order command is overly complex, not least because it can do
five different things: clear, suspend, resume, declare route, set
cargo levels.
- Unlike every other command involving movement, order does not let
you specify routes, only destination sectors.
- Setting cargo levels can silently swap start and end point of a
circular route, because "this keeps the load_it() procedure
happy". Maybe it does, but it surely keeps players confused.
- Setting "start" cargo levels actually sets the "end" levels, and
vice versa. Has always been broken that way.
- Predicting what exactly autonavigation will do at the update isn't
easy.
* The info pages documenting it amount to almost 400 non-blank lines
formatted. They claim only merchant ships can be given orders.
This is wrong. Unlikely to be the only error.
* Few players use it, and its workings at the update a fairly opaque.
Makes it a nice hidey-hole for bugs. Here are two:
- Unlike the scuttle command, autonavigation happily scuttles trade
ships while they're on the trading block.
- Unlike the load command, autonavigation can load in friendly and
allied sectors.
* It's more than 700 lines of rather crufty code nobody wants to
touch. Thanks to a big effort in Empire 2, it shares code with the
navigation command. It still duplicates load code. The sharing
complicates fixing the bugs demonstrated by navi-march-test.
Reviewing, fixing and testing this mess isn't worth the opportunity
cost. Remove it instead. Drop commands order, qorder and sorder.
Drop ship selectors xstart, xend, ystart, yend, cargostart, cargoend,
amtstart, amtend, autonav.
xdump ship sheds almost half its columns. struct shpstr shrinks, on
my system from 200 to 160 bytes.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
When a player moves more than 1023 sectors in a single navigate
command, we overrun the buffer holding the path taken. Remote hole,
but it requires a ship that can go that far, and even a ship with
speed 1000 would need a tech level well in excess of 1000 for that.
Thus, the hole is purely theoretical for even remotely sane game
configurations.
First known version with the flaw is 4.0.0.
Fix by going back the older behavior: don't print the total path
taken, but do print what the path finder does. Context diff of an
example:
[0:634] Command : nav 3 6,0
Flagship is od oil derrick (#3)
+Using path 'n'
h =
k . .
j d
<67.2:67.2: 6,0> h
od oil derrick (#3) stopped at 6,0
-Path taken: n
This is how march works.
Removes the only use of shp_nav_one_sector()'s unusual return value 2.
Return 1 instead.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Does not cover scattered navigate and march, RAILWAYS 0, enemy action
while sitting at the prompt, and interdiction.
The test exposes bugs. They're marked "BUG:" in the test input.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Cuts size of export files in test suite by a factor of four. Not a
big deal for disk usage, as export files compress very well, and disk
space is cheap anyway. Export files are simply easier to work with
when they aren't full of redundant crap.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
The code needs it first so it can store field values into the object
right away. Save the values instead, and store them when the row is
complete.
The improvement is hardly worth the trouble by itself, but it'll
simplify supporting keys consisting of multiple fields, like sector
xloc, yloc or realm cnum, realm, so we can omit rows in those tables,
too.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
We currently require all rows to be present for tables item, sect-chr,
infrastructure, sect, realm.
The first three make sense: the code hard-codes indexes for them, and
malfunctions when entries are blank, so we want to make it hard to
leave any blank by accident.
The last two don't: blank sectors and realms work fine. There, the
restriction is arbitrary. Drop it.
Sectors and realms still can't be omitted "in the middle" (can do that
only with an ID selector), but that's coming soon.
See also commit 4a4ec91.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Each part of a split table needs to supply rows for the same objects.
We currently require each part to name its objects explicitly, with an
object ID field, and don't support splitting tables that don't have
such IDs. These restrictions became arbitrary when commit 4e23c45
implemented checking each partial table supplies the same rows. Relax
them.
Affects tables sect, news, lost, realm, game, infrastructure.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
New helper run_and_cmp to automate the job: run a program capturing
its standard output, standard error and exit status, then compare the
actual with the expected results.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
When cmp_out detects a test failure, it returns non-zero status, which
terminates the test script unless caught.
Accumulate failures in a global variable checked at exit instead, so
running it multiple times in a test script just works.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Feeding other test output files (right now tests/files/files.out
tests/fairland/fairland.out fairland/newcap_script) works, but it's
odd, and might not work as well for all future output files. Only
strip trailing white space there.
There used to be other output files that required normalize.pl: client
output. Gone since commit 9ca3fa9.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Its value has always been "", unless the deity recompiled with
RESOLVE_IPADDRESS defined, or imported another value with empdump.
I'm going to drop the RESOLVE_IPADDRESS code, including struct natstr
member nat_hostname. To prepare for that, fix the selector's value to
"", so it doesn't need nat_hostname, and deprecate it.
This changes its "len" in xdump meta nat from 512 to 0. Unlikely to
upset clients.
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>
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>
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>
