Why upgrade? I'm not a lawyer, but here's my take on the differences
to version 2:
* Software patents: better protection against abuse of patents to
prevent users from exercising the rights under the GPL. I doubt
we'll get hit with a patent suit, but it's a good move just on
general principles.
* License compatibility: compatible with more free licenses, i.e. can
"steal" more free software for use in Empire. I don't expect to steal
much, but it's nice to have the option.
* Definition of "source code": modernization of some details for today's
networked world, to make it easier to distribute the software. Not
really relevant to us now, as we normally distribute full source code.
* Tivoization: this is about putting GPL-licensed software in hardware,
then make the hardware refuse to run modified software. "Neat" trick
to effectively deny its users their rights under the GPL. Abuse was
"pioneered" by TiVo (popular digital video recorders). GPLv3 forbids
it. Unlikely to become a problem for us.
* Internationalization: more careful wording, to harden the license
outside the US. The lawyers tell us it better be done that way.
* License violations: friendlier way to deal with license violations.
This has come out of past experience enforcing the GPL.
* Additional permissions: Probably not relevant to us.
Also include myself in the list of principal authors.
SLOW_WAR has issues:
* The check whether the attacker old-owns the attacked sector is
broken, because att_abort() uses sect.sct_oldown uninitialized.
Spotted by the Clang Static Analyzer.
* Its implementation in setrel() is somewhat scary. It's actually
okay, because that part of setrel() only runs within decl(). Other
callers don't reach it: update_main() because player->god != 0
there, and the rest because they never pass a rel < HOSTILE.
* Documentation is a bit vague.
SLOW_WAR hasn't been used in a public game in years. Fixing it is not
worth it, so remove it instead.
Before, they were stored as short. Wider uids use more space, but the
next commit will recover it by narrowing other members.
The use of short has always limited the number of ships, planes, land
units and nukes to SHRT_MAX (commonly 32768). Only the most extreme
games ever came close.
Commit 49780e2c (v4.3.12) added struct sctstr member sct_uid to make
struct empobj member uid work for sectors. This made the limit apply
to sectors as well. We've had games with more than 32768 sectors.
Pinpointed assignments within if conditionals with spatch -sp_file
tests/bad_assign.cocci (from coccinelle-0.1.4). Cherry-picked diff
hunks affecting conditionals split over multiple lines, and cleaned
them up.
When a ship is shelled, retreat condition 'i' (injured) applies. When
there's no return fire, 'h' (helpless) applies as well. Ships
retreated twice in that case. Fix that.
Failing a command with code RET_SYN prints help and doesn't charge
BTUs. Failing with code RET_FAIL doesn't print help and charges BTUs.
A couple of command failures were changed or added recently to fail
with RET_SYN, because they're due to invalid player input. Some of
them, however, can happen after the command already did something, so
BTUs must be charged, or else players can deliberately fail the
command to save BTUs:
* Commit 9eda5f87 adds RET_SYN failures when getting player input
fails for:
- arm third argument
- deliver fourth argument
- fire third argument
- lmine second argument
- order d fourth argument
- range second argument
- sail second argument
- tend third argument
* Commit be41e70f likewise for:
- designate second argument
- morale second argument
- set third argument
- tend fourth argument
* Commit d000bf92 likewise (with a bogus commit message) for bdes
second argument.
* Commit 9f4ce71a likewise for ltend third and fourth argument.
* Commit 9031b03b changes failure code from RET_FAIL when getting
player input fails for threshold third argument. It adds RET_SYN
failure when the argument is bad. Some bad arguments already failed
that way before.
* Commit a7cf69af changes it from RET_FAIL when designate second
argument is bad.
Change them all to fail with RET_FAIL.
Many other places have the same bug, but those are left for another
day.
The old code used getstarg() to get an argument with a different
prompt than snxtitem() uses, then passed the value to snxtitem()
unchecked. If the player aborts, getstarg() returns a null pointer,
and snxtitem() prompts again. Affected:
* load/lload plane/land third argument; load_plane_ship(),
load_land_ship(), load_plane_land(), load_land_land()
* bomb, drop, fly, paradrop, recon and sweep second argument;
get_planes()
* tend and ltend second and fourth argument; ltend(), tend(),
tend_land()
* mission second argument; mission()
Fix by making snxtitem() taking a prompt argument, null pointer
requests the old prompt.
Use that to simplify multifire() and torp(). Change the other callers
to pass NULL.
The old code didn't honor command abortion at the following prompts:
* arm third argument
* deliver fourth argument (also simplify)
* fire third argument
* fly and recon prompt for carrier to land on: pln_onewaymission()
treated abort like empty input, which made planes attempt landing in
the sector.
* lmine second argument
* order d fourth argument
* power c nat(s) argument
* range second argument
* sail second argument
* shutdown both arguments (first one was broken in commit 84cfd670,
v4.3.10, second one never worked).
* tend third argument
Firing damage reduction for range is a feature that was always there
and never really documented. Different ways to fire reduced damage
differently for range, or not at all. Fix that by dropping the
reduction everywhere.
The reduction happened randomly, with probability p = (d/m)^2, where d
is the distance to the target, and m is the maximum firing range. The
fire command printed "Wind deflects shells" when it happened.
The old fire command (before MULTIFIRE) either halved damage (50%
chance), or reduced it by a factor of 1-p.
MULTIFIRE's fire command halved damage. v4.0.2 reduced that loss to
10-20%.
Interdiction halved damage, but only when firing from ships.
Other ways to fire (support, return fire, interdiction from forts and
land units) did not reduce damage for range.
multifire() clobbered any changes to the target ship or sector made by
defend(). This let the target fire back for free.
multifire() retreated the target ship before reporting its location to
the player. This disclosed its new location.
Fix by damaging and retreating the target after calling defend().
multifire() drops depth charges if the target is a submarine, else it
fires guns. It fails if the target is out of range. But players
could still find out whether the target is a sub then, because depth
charge shell use differs from gun fire shell use. This loophole
existed before 4.0.6, and was reopened by commit a3ad623b (v4.3.12).
Change multifire() to always use guns if the target is out of range.
While there, treat failure from shp_dchrg() and shp_fire() the same,
so that the player can't distinguish the two cases. Failure there
should not happen.
multifire() failed to take into account that the firing firing sector,
ship or land unit can change while it is getting the target argument.
It thus clobbered any updates made to the firing object while it was
sleeping for the target argument. Abusable. Broken when Chainsaw
introduced MULTIFIRE.
Planes normally sit in their base (sector or carrier), where they can
be spied, damaged, captured, loaded, unloaded, upgraded and so forth.
All this must not be possible while they fly. There are two kinds of
flying planes: satellites in orbit, and planes flying a sortie.
Satellites in orbit have always been marked with flag PLN_LAUNCHED.
Works. What didn't work was tracking planes flying a sortie.
If you look at one sortie in isolation, up to three groups of planes
can be flying at any point of time: the primary group, which carries
out the sortie's mission (bomb, transport, ...), their escorts, and a
group of hostile planes flying interception or air defense.
The old code attempted to track these planes by passing those groups
to the places that need to know whether a plane is flying. This was
complex and incomplete, and broke down completely for the pin-bombing
command.
It was complex, because the plane code needs to keep track of all the
call chains that can lead to a place that needs to know whether a
plane flies, and pass the groups down the call chains. This leads to
a rather ugly passing of plane groups all over the place.
It was incomplete, because it generally failed to pass the escorts.
And the whole scheme broke down for the pin-bombing command. That's
because pin-bombing asks the player for targets while his planes are
loitering above the target sector. This yields the processor and lets
other code run. Which does not get the flying planes passed.
The new code marks planes and SAMs (but not other missiles) flying a
sortie with flag PLN_LAUNCHED (the previous commit laid the groundwork
for that), and does away with passing around groups of flying planes.
This fixes the following bugs:
* Many commands could interact with foreign planes flying for a
pin-bombing command as if they were sitting in their base. This
includes spying, damaging, capturing, loading, or upgrading them,
and even getting intercepted by them. Any changes to those planes
were wiped out when they landed. Abusable.
* The bomb command could bomb its own escorts, directly (pin-bomb
planes) or through collateral damage, strategic sector damage,
collapsing bridges or nuke damage. The damage to the escorts was
wiped out when they landed.
* If you asked for a plane to fly both in the primary group and the
escort group, you got charged fuel for two sorties instead of one.
* pln_put1() and pln_put() now recognize planes that didn't take off,
and refrain from making them land. Intercept (since commit
c64e2149) and air defense can do that. Making them land had no
ill-effects, but it was still wrong.
There's one new problem: if PLN_LAUNCHED doesn't get reset properly,
due to game crash during flight or some other bug, the plane gets
stuck in the air. Catch and fix that on game start in ef_verify().
multifire() used shots to print either shell or shells. 4.2.3 removed
its initialization for land unit fire, and commit 22c6fd8b removed it
for ship fire. Fix by just printing shells always.
The old code let each defender fire on each target separately. To
avoid charging ammo multiple times, it didn't update the defenders
after fire; it charged them in use_ammo() instead. Bugs: not updating
the defender lost any shells fetched by automatic resupply, and
use_ammo() always charged one shell for gun fire, which was wrong for
most ships and land units.
Rewrite to let each defender fire once, updating it normally. Reuse
the damage for the other targets. This also yields the proper
probability distribution for damage.
add_to_fired_queue() adds a defender at most once. It neglects to
free the defender flist nodes it doesn't add. Broken since option
MULTIFIRE appeared in Chainsaw.
New lnd_att(), lnd_def(), lnd_vul(), lnd_spd(), lnd_vis(), lnd_frg(),
lnd_acc(), lnd_dam(), lnd_aaf() replace the struct lndstr members with
the same names.
Make land unit selectors att, def, vul, spd, vis, frg, acc, dam, aaf
virtual.
This takes care of a number of bugs / inconsistencies:
* Resupply before fire: fire command did not require unit to be in
supply, and resupplied shells. Everywhere else (return fire,
support and interdiction) the land unit had to be in supply after
resupply of everything. Unify not to resupply anything and not to
require being in supply. This is consistent with ships and sectors.
* Resupply after fire: fire command resupplied shells after active
fire. Unify not to do that. This is consistent with ships and
sectors.
* When a land unit returned fire to multiple attackers, quiet_bigdef()
charged it ammo for each one. Finally, it was charged one shell
more by use_ammo(). Except only the first land unit got charged
there in fact, because buggy add_to_fired_queue() entered only the
first land unit into the defender list. Fix add_to_fired_queue()
and change quiet_bigdef() not to charge ammo, just like for ships
and sectors. This charges only one shell instead of the true ammo
use, which is wrong, but consistent with ships.
* lnd_support() tallied support damage unrounded. Unify to round
before tally.
This takes care of a number of bugs / inconsistencies:
* Submarines with zero mobility could interdict. Change to require
positive mobility.
* Submarines with zero firing range could not interdict. Fix by
dropping the test from perform_mission(). No ships in the stock
game are affected.
* Submarines without capability torp could fire return torpedoes and
interdict. Stock sbc, nm and msb were affected by the return fire
bug. Closes bug#950936.
* Shell resupply bugs: quiet_bigdef(), fire_torp() and
perform_mission() resupplied before checking all other requirements
and could thus get more shells than actually needed.
torp() no longer resupplies shells. It's hardly worth the bother, and
fire doesn't do it either.
This takes care of a number of bugs / inconsistencies:
* Ships with zero firing range could return fire and fire support, but
not fire actively or interdict. Fix by testing for gun limit
instead in multifire() and mission(). No ships in the stock game
are affected.
* Required gun crew was inconsistent: multifire() let N military fire
max(1,floor(N/2)) guns for active fire. Ditto perform_mission() for
interdiction. quiet_bigdef() let them fire N guns for returning gun
fire. Ditto sd() for firing support and firing at boarding parties.
fire_dchrg() let them fire floor(N/2) for returning fire to
torpedoes. Unify to let N military fire floor((N+1)/2) guns.
* Shell use was inconsistent: sd() and perform_mission() used one
shell per gun, everything else one per two guns. Unify to one shell
per two guns.
* Shell resupply bugs: multifire() got two shells regardless of actual
ammo use. quiet_bigdef() got one shell (but use_ammo() uses only
one, which is a bug). sd() and perform_mission() resupplied before
checking all other requirements and could thus get more shells than
actually needed.
Before 4.0.6, depth charges required no guns, one military, did damage
like shell fire from two guns, and used two shells. Missions were not
quite consistent with that (bug). 4.0.6 changed depth charges to work
exactly like shell fire (but without updating documentation
accordingly): require guns and gun crew, non-zero firing range, scale
damage and ammunition use with guns.
Go back to the old model, but with damage like three guns, to avoid
changing the stock game's dd now (three gun damage for two shells).
Stock game's af changes from two gun damage for one shell, and nas
from four gun damage for two shells.
Factor out common depth-charging code into shp_dchrg().
This takes care of a number of bugs / inconsistencies:
* sb() fired support even when there were not enough mil.
* Shell resupply bugs: multifire() and quiet_bigdef() resupplied
shells before checking all other requirements and could thus get
more shells than actually needed.
Rename landgun() to fortgun() for consistency.
