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>
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>
This reverts commit c3a839934f.
The commit message's claim that the code never actually retreats
ghosts is wrong: boar() does.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Conflicts:
src/lib/subs/retreat.c
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>
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>
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>
It's only printed for ships. Looks misplaced when it's followed by
"sunk" or other damage reports.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
With offensive support but no defensive support, there's no empty line
separating the support table from the text that follows. Fix that.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
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>
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>
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>
Report "not spotted", like we do for unused ships and land units.
Missed in commit 23d52a4, v4.3,16.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Instead of listing all the ships or land units ordered, just print how
many got ordered, and describe the order, like this:
[0:640] Command : retr 2/3 bg itb
2 ships ordered to retreat along path bg when injured, torpedoed, bombed
[0:640] Command : retr 2 h
1 ship ordered not to retreat
fleetadd doesn't list the ships it reassigns, either. On the other
hand, stop lists the sectors it stops. Perhaps it should be gagged,
too.
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>
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
Compare retreat:
[0:638] Command : retreat
ship(s)? 0
shp# ship type x,y fl path as flt? flags
0 frg frigate 21,-3
1 ship
Arguments are not discoverable this way.
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>
Has no effect now. Before the recent rewrite of automatic retreat, it
could be used to trigger group retreat while staying put.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
"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>
The code to list ships got triplicated in Chainsaw. Empire 2 screwed
up one copy in its global replace of owner by player->owner.
Fix it by de-duplicating.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Rather than after post-yield sanity checking. Just to make it obvious
that we are handling getstarg() failure.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Screwed up when test-suite-only command __cmd was added in commit
e852d45. Should never happen with the intended use. Fix it anyway.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Broken in commit 40ec33b. Mitigating factor: can only happen when the
player gives an empty argument, e.g. retreat 0 "".
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
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>
This reverts commit df8a1ffc1b.
Because it breaks group retreat. Trivial conflicts due to the removal
of option SAIL.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Conflicts:
src/lib/subs/retreat.c
tests/retreat/journal.log
This exposes more bugs. They're marked "BUG:" in the test input. A
few bugs get masked, but I'll unmask them again in the next commit.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
To reduce coupling between test cases.
Lucky dice expose another bug. It's marked "BUG:" in the test input.
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>
These logs are saved in the sandbox to help debugging setup.
Normalize them to make them easier to read.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
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>
Demonstrate bugs: doesn't always preserve unlimited range, and doesn't
always cut range back to maximum.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Most of the remaining callers need to fool around with snprintf() to
use them. Not worthwhile anymore.
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>
