fire: Clean up damage sanity check and printing of range
Repeated for ship, sector and land unit firing. The latter prints
range only when the sanity check succeeds.
Factor out, changing ship and sector to behave like land unit firing.
When the sanity check fails, print "Jammed!" instead of "Klick!",
because "Klick!" suggests no shells. Used to be printed exactly then,
but the condition first became impossible (Chainsaw), then generalized
to "can't fire for whatever reason" (commit 22c6fd8, v4.3.12).
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
The fire command drops depth charges when the target is a submarine in
range and firing ship has the capability. Else, it blindly fires
guns. It used to reject ships that can't use guns, even when they
could use depth charges, but commit 9b0b0dc (v4.3.31) lifted that
restruction. No such ships exist in the stock game.
If the firing ship can't fire guns, shp_fire() returns -1, triggering
an oops. Broken in commit 0757042.
Avoiding dependence of depth charge on gun fire capability is
pleasing, but nevertheless a bad idea without test coverage. Creating
the necessary tests isn't worth it, so put back the traditional
restriction instead.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Mission is cleared only when firing at a target that is out of range.
Screwed up when missions were added in Chainsaw. Always clear it when
firing. Matches torpedo.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
fire: Fix artillery splashing the bridge span under itself
multifire() writes back the firing sector after applying damage. When
an artillery unit on a bridge span commits suicide by shelling down
the supporting bridge heads, this writeback puts the bridge span right
back (less the land units and planes on it), triggering a seqno oops.
On the next update of the bridge head, the bridge span falls again.
Broken in commit fe5b266, v4.3.14.
The problematic write back is superfluous. Remove it along with a few
equally superfluous ones.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
convert: Drop broken code to charge security unit mobility
Conversion is easier when land units with capability security are
present. Each such land unit is charged 10 mobility. The mobility
charge is undocumented.
Land unit mobility is charged even when conversion turns out to be
impossible, say because the sector has no mobility. I call this a
bug. Has been that way since security land units were added in
Chainsaw 3.
Except the mobility charge doesn't actually work anymore: the changed
land unit is never written back. Broken in commit 82c9166, v4.3.16.
Fix this bug would be trivial, but would bring back the bug described
above, and fixing that one is harder, and doesn't feel worthwhile.
Remove the broken charging of land unit mobility instead.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
A bombed plane's mobility is multiplied by dam/100.0, i.e. the higher
the damage, the lower the mobility loss. Has always been broken. Fix
by computing the new mobility with damage(), like we do elsewhere.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
commands: Always put ship or land unit before retreating it
boar() puts before retreating, the other callers afterwards. Subtle
difference, because putting resets the owner of the dead to POGO.
Until the commit before previous, retreat didn't fully work after put.
Now it does. The subtle difference between boar() and the other
callers still exists. It's better to do it the same everywhere, as
subtle differences invite bugs. Since changing boar() is not
practical, change the others.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
The old retreat_ship() took care not to put its ship argument (it
still put other ships in a group retreat). Callers put it
unconditionally to make the change to the ship permanent.
The current retreat code puts all ships it changes, rendering sona()'s
putship() redundant. Drop it.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
retreat: Fix group retreat after failed board sinks ship
Group retreat still doesn't work, because when boar() passes a sunk
ship to retreat_ship(), its owner has been reset to POGO already.
This makes it impossible to find the group to retreat. Instead, it
attempts to retreat ships that sank in the same sector with group
retreat orders and with the same fleet letter assigned. If any exist,
shp_may_nav() oopses, and prevents actual retreat of these ghosts.
The other retreat conditions don't have this problem, because they
call putship(), which resets the owner, only after retreat_ship().
Making boar() work the same is not practical. Instead, add an owner
parameter to retreat_ship(), and for symmetry also to retreat_land().
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
board: Don't retreat ship#0 after failed board sinks ship
The root cause is in put_combat(): after it sinks the ship, it calls
att_get_combat(), which treats a combat object with a dead ship as an
error, tells the attacker "not in the same sector!", and "recovers" by
putting the combat object into an error state. Too hard for me to fix
right now, so put in a FIXME comment.
The error state trips up retreat. boar() uses the victim's ship
number in the combat object to find the ship it may have to retreat.
Putting the combat object into an error state sets this number to
zero. If that ship exists, and isn't owned by the attacker, and has
RET_BOARDED set, it retreats. Oops. Broken when Empire 2 factored
out common combat code.
Fix by saving the ship number while it's still valid.
This uncovers the next bug: we now pass a dead ship to retreat_ship().
Oopses since commit f743f37. Its commit message says "Harmless, but
avoid it anyway." Going to revert.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
torpedo: Fix news on owner of ships sunk by return torpedoes
fire_torp() reads targ->shp_own after putship(). If targ sank, its
owner is POGO by then. Screwed up when return torpedoes were added in
Chainsaw. Fix by reporting news before putship().
torp() is correct, because it gets the owner from a local variable.
Change it like fire_torp() anyway.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
torpedo: Don't disclose uid, type, owner of torpedoed subs
torp() reports target uid and type to the player. Hide for submarine
targets, just like we hide attacking submarine details in bulletins to
the target's owner.
torp() and fire_torp() leak submarine owners through the news.
Suppress news for submarine targets. This is consistent with fire:
mfir() doesn't report depth-charging, and quiet_bigdef() doesn't
report return torpedoes.
Historical note: the code has always hidden submarine uid, type and
owner in places, and leaked them in others. When capability sub-torp
was added in Chainsaw, no attention was paid to hiding. When Empire 2
hid attacking submarines, it did nothing for submarine targets.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
subs: De-duplicate formatting in intelligence_report()
Every piece is formatted either with pr(), or with sprintf() for later
sending with wu(). The output is actually identical. Format with
sprintf() always, and then either pr() or wu() the results.
While there, change the first parameter's type from int to natid.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
subs: Oops when a telegram doesn't end with a newline
Telegrams should always end with a newline. The common cause for a
missing newline is misuse of wu() to print partial lines. Almost
always works, as the read command merges telegrams arriving in quick
succession. But if the telegrams are more than five seconds apart
(clock jumped somehow), we get a telegram header in the middle of a
line.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
subs: Clean up misuse of wu() around mission bomb damage
Don't use multiple calls of wu() to print a single line, because that
creates a separate bulletin for each part. The read command normally
merges the bulletins, but if the bulletins are more than five seconds
apart (clock jumped somehow), we get a bulletin header in the middle
of a line. Unlikely to happen, but it also messes up pln_damage()'s
line wrapping (see commit e002bf2). Clean it up.
The wu() misuse was introduced in Empire 2.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Don't use multiple calls of wu() to print a single line, because that
creates a separate telegram for each part. The read command normally
merges the telegrams, but if they are more than five seconds apart
(clock jumped somehow), we get a telegram header in the middle of a
line. Unlikely to happen, but clean it up anyway.
The misuse has always been there.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
It's redundant; retreat path 'h' cancels orders just fine. Document
that instead. 'c' still works, and I don't plan to break it as long
as it doesn't get in the way, which seems unlikely.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
retreat lretreat: Change query syntax to match mission
Optional arguments can save typing. Mandatory arguments are more
easily discoverable: just run the command and answer its prompts.
Empire traditionally uses optional arguments only for expert features.
Consider mission:
[0:640] Command : mission
Ship, plane or land unit (p,sh,la)? s
ship(s)? 0
Mission (int, sup, osup, dsup, esc, res, air, query, clear)? int
operations point? .
frg frigate Early Bird(#0) on an interdiction mission, centered on 21,-3, radius 0
1 ship
Change retreat to work like mission: make the second argument
mandatory, and if it's 'q', show retreat orders, else treat it as path
and ask for conditions:
[0:637] Command : retreat
ship(s)? 0
Retreat path, or q to query? jj
Retreat conditions ('?' to list available ones)? i
shp# ship type x,y fl path as flt? flags
0 frg frigate 21,-3 jj i
1 ship
To reduce smart client and script breakage, keep retreat with one
argument working as before, but print a deprecation warning.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
retreat lretreat edit xdump: Change "torped" to "torpedoed"
"torped" comes from symbol table retreat_flags. Visible in output of
edit, retreat, lretreat and xdump. Tolerable in edit, but player
commands like retreat should really use proper words.
Fixing it in retreat_flags changes xdump output, thus risks breaking
clients. Do it anyway, since no known client recognizes this
particular symbol value.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
retreat: Rewrite automatic retreat code to fix its many bugs
Much of the retreat code duplicates navigate and march code. Worse,
retreat's version is full of bugs:
* Land units can sometimes retreat when they couldn't march: while on
the trading block (forbidden with march since 4.0.9), crewless
(likewise since 4.0.0), kidnapped in a foreign sector (inconsistent
since land units were added in Chainsaw 3), loaded on a ship
(likewise) or a land unit (inconsistent since trains were added in
4.0.0).
* Ships can retreat while on the trading block (forbidden with
navigate since 4.0.9)
* Land units can't retreat into foreign sectors even though they could
march there, namely when sector is allied or the land unit is a spy.
They can march there since 4.0.0.
* Land units keep their fortification on retreat. Has been that way
since retreat was added in Chainsaw.
Then there's group retreat. It's basically crazy:
* It triggers retreat for everyone in the same fleet or army, one
after the other, regardless of retreat path, conditions (including
group retreat), or even location. The latter is quite abusable
since retreats aren't interdicted. Has been that way since retreat
was added in Chainsaw.
* Group retreat fails to trigger when the originally retreating ship
or land unit has no retreat path left when it's done. Broken in
commit b860123.
Finally, the reporting to the owner is sub-par:
* When a retreat is cut short by insufficient mobility or
obstructions, its end sector isn't reported, leaving the player
guessing.
* Non-retreats can be confusingly reported as retreat to the same
sector. Can happen when the retreat path starts with 'h' (obscure
feature to suppress a single retreat), or when a group retreat
includes a ship or land unit without retreat orders.
* Interaction with mines during retreat is reported before the retreat
itself, which can be quite confusing.
* Sweeping landmines isn't reported at all.
* Much code and much bulletin text is dedicated to reporting what
caused the retreat, even though it should be perfectly obvious.
Rewrite this on top of common navigate and march code. Reuse of
common code fixes the "can retreat when it couldn't navigate/march"
and the "can't retreat into sectors it could navigate or march into"
bugs, and improves the reporting.
One special case isn't a bug fix but a rule change: mountains. The
old code forbids that explicitly, and it's clearly intentional, if
undocumented. The new code allows it by not doing anything special.
Turn group retreat into an actual group retreat: everyone in the same
fleet and sector with the the same retreat path and group retreat
condition joins the group. The group retreats together, just like in
navigate and march.
Take care to always report the end sector. When retreat is
impossible, report "can't retreat". When retreat is partial, report
"and stays in X,Y". When it's complete, report "stopped at X,Y".
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
setup-POGO unintentionally gives dead ships, planes and land units
mobility, which makes them show up in final.xdump. Rearrange to avoid
that, and for clarity. While there, improve comments.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
edit: Fix tech and range adjustment for edit p key 'T'
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>
We stop on mine hits only when they're fatal. Has always been that
way. When interdiction was added in Chainsaw, it worked the same.
Empire 2 changed the commands to stop on any interdiction damage. Now
stop on any mine damage, too.
Interdiction can fail to do damage (all bombs miss), and mines can be
detected without damage (by sweeping). Perhaps we should stop then as
well. Left for another day.
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>
navigate march: Fix "same mob type" and "not on sale" checks
Unlike the other "may move" conditions, "same mobility type
(MOB_MARCH, MOB_RAIL) as leader" and "not on sale" are only checked
when collecting ships and land units.
The former breaks when a deity unwisely edits a land unit's type while
it is being marched. Messed up when the check was added in commit 36e41e5 (v4.3.7). However, editing has become possible only recently,
in commit 6b0b6f1.
The latter would break if a ship could be put on the market while it
is being navigated, but that's not possible, because only the owner
can navigate (see also commit 8c502d4), and only the owner can sell.
Same for land units. Messed up in 4.0.9. Clean it up anyway. Bonus:
nicer error message, even spelled correctly.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
navigate march: Wipe mission and retreat orders less eagerly
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>
bomb fire launch torpedo: Don't disclose ship sinking in retreat
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>
.SY claims all arguments are individually optional. Fix that, and
clarify that omitting the optional arguments shows current orders.
Don't complicate syntax with <SECTS>, <SHIP/FLEET> covers sectors.
The two pages are identical apart from header and footer. They
mention land units briefly, then explain ship retreat. Lazy. Drop
the land unit mention from "info retreat", and rewrite "info lretreat"
for land units.
Update example output for current code.
Don't shout retreat conditions. We've always accepted both lower and
upper case conditions. Help has been advertising lower case since
commit bb5dfd8, v4.3.16.
While there, fix a few misspellings and such.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Documented in commit dc41544, v4.3.16. It actually worked only at the
condition prompt then. No longer recognized elsewhere since commit c699949. The documentation is now misleading. Simply drop it; the
prompt points out how to get help,
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
subs: Report where exactly ships and land units sweep mines
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>
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>
Commit cd8d742 mechanically combined struct mlist's mcp and struct
llist's llp into struct ulist's chrp, adding type casts to every use.
Not necessary, simply use mchr[] and lchr[] directly.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
navigate: Don't disclose whether unfriendly canal is navigable
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>
navigate: Require all ships to start in the same sector
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>
march: Require all land units to start in the same sector
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>
projects / empserver / log