It sets the new type, then falls through to setting tech if the new
type requires more than the plane currently has. Two problems with
that:
* If we fall through, the plane is invalid: it has less tech than
required. Its only use before it gets overwritten is pln_set_tech()
calling pln_range_max() to find out whether the range is limited.
Passes a negative number to log(). Not fatal, but pln_set_tech()'s
range adjustment is unlikely to work.
* If we don't fall through, the range may still need adjustment,
either up (to keep it unlimited if the new type has more range), or
down (to keep it within the new type's shorter range).
Screwed up when the key was added in commit 6b0b6f17. Fix by
adjusting tech first, then setting the type, then adjusting the range.
The latter relies on pln_set_tech() coping with ranges exceeding the
type's maximum, which it does.
Change the other type edits similarly for consistency.
When a type edit triggers a tech change, the tech change is now
silent.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
unit_move() is too big and has too many paths through its loop.
Maintenance of the (unspoken) loop invariant isn't obvious. In fact,
it isn't maintained on some paths. I found several bugs:
* We check prerequisite conditions for moving before the first move
and around prompts. When a condition becomes wrong on the move,
movement continues all the same until the next prompt. I believe
the only way this can happen is loss of crew due to hitting a mine.
* We cache ships and land units in a list of struct ulist. When a
ship or land unit gets left behind, its node is removed from the
list and freed.
We keep pointer flg pointing to the flagship in that list for
convenience. However, the pointer isn't updated until the next
prompt. It's referenced for automatic radar and all sub-commands
other than the six directions and 'h'. Use after free when such a
sub-command gets processed after a flagship change without a prompt.
Same for land units. For instance, navigating a pair of ships "jh"
where the flagship has no mobility leaves the flagship behind, then
attempts to radar automatically using the ship in the freed list
node. Likewise, marching a similar pair of land units "jl" examines
the land unit in the freed list node to figure out how to look.
* We cache mobility in the same list to support fractional mobility
during movement. Movement deducts from cached mobility and writes
the result back to the ship or land unit.
If something else charges it mobility while it's in this list, the
cache becomes stale. shp_nav() and lnd_nav() reload stale caches,
but don't run often enough. For instance, when a ship hits mines,
the mine damage makes the cache stale. If a direction or 'h'
follows directly, the stale mobility is written back, clobbering the
mine hit's mobility loss.
This mess dates back to Empire 2, where it replaced a different mess.
There may be more bugs.
unit_move()'s complex control flow makes reasoning about its loop
invariant too error-prone. Rewrite the mess instead, splitting off
sensible subroutines.
Also fixes a couple of minor annoyances:
* White-space can confuse the parser. For instance, "jg l" is
interpreted like "jgll". Fix to reject the space. Broken in commit
0c12d83, v4.3.7.
* The flagship uses radar automatically before any sub-command (since
Chainsaw), and all ships use it automatically after a move (since
4.2.2). Make them all use it before and after each sub-command,
whether it's a move or not.
* Land units don't use radar automatically. Make them use it just
like ships.
* Always report a flagship / leader change right when it happens, not
only before and after a prompt.
Left for another day, marked FIXME: BTU charging is unclean.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
These commands report "sunk!" even when the ship survives the attack
but sinks during retreat. bomb even reports where on the retreat the
ship sinks. Has been that way since retreat was added in Chainsaw.
Report "sunk!" only when the attack sinks the ship directly.
Similar code exists for land units, but it doesn't report killings.
Change it anyway, to keep it consistent with the ship code.
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>
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>
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>
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>
nstr_exec_val() can produce three different error values: NSC_NOTYPE
on invalid category, invalid type with zero val_as.lng on invalid type
(this is a bug), and the wanted type with zero val_s when it can't
coerce. None of these should ever happen.
Fix it to always produce an NSC_NOTYPE error value. Fix up callers to
check for it.
Specify the result's type is promoted on success. Ensure it is even
when the argument is NSC_VAL with an unpromoted type, which is
invalid.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
xditem() needs a buffer that can hold entries of any xdumpable table.
It's been 2048 bytes and marked FIXME since day one. Clean it up so
that if anyone ever goes crazy with entry sizes, we fail an assertion
during startup instead of overrunning the buffer during play.
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>
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>
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>
