Telling the player his torpedo "slams into land" can give a clue on
the direction to the target. No good when the target is out of range,
because we shouldn't tell the player more than that then.
Screwed up in 4.2.2. Fix by checking range before line of sight.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Claims the victim of a torpedo attack gets told the attacking ship's
number. This hasn't been the case for submarines since Empire 2.3.
Recent commits again reveal the attacking submarine's number, but only
when it gets hit by return fire. Update info accordingly.
Reported-by: Neeraj Jain <thisisfranz@gmail.com>
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
This partly reverts a change made in Empire 2.3 to tell a submarine's
opponent only that he's dealing with a "sub" instead of the
submarine's UID and type. Hiding submarines is done by prsub().
Uses:
* Command torpedo: defender depth charges or torpedoes an attacking
submarine
If you can attack a submarine reactively, you should be able to
attack it actively, too. But that requires its UID. Reveal it
again, but keep the type hidden.
* Command fire: defender fires back at a submarine using its deck gun
Submarines need to surface to fire deck guns, so they shouldn't be
treated any different than surface ships. Revert Empire 2.3's
change entirely there, i.e. defender learns type as well as UID.
* Command torpedo: attacking submarine hits its target
Keep the submarine hidden.
* Commands torpedo and fire: attacking ship hits a submarine
The attacker passed the UID as command argument, so it doesn't
matter whether we print it or not. Printing it is simpler to code,
so do that.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
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>
This reverts commit 9b0b0dc772.
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>
Meaning of targ_sub changes from "target is a submarine" to "attacking
the target with depth charges".
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>
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>
The cost is meant to be proportional to efficiency / 100, but the code
truncates the fraction to zero. Broken in Empire 2.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
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>
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>
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>
