The edit command doesn't support editing plane fortification. Has
always been that way. Implement it as key 'F'.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Planes 7/8 aren't visible in output, because the test neglects to set
their owner. Messed up in commit commit efec441, v4.3.33. Correct
that oversight.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
The edit command doesn't support editing bars on ships and land units.
Has always been that way. The stock game's ships have always been
unable to load bars. Not the case for land units.
Unfortunately, the obvious key 'b' for bars was burned on plague time
in 4.0.17. Use key 'B' instead.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
The test covers only 'c' and 'l' with give, 'm' and 'g' with edit.
Cover the other item types, too.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
print_items() uses field widths between 3 and 5. They go back all the
way to Empire 1, and are fine for the stock game. Widen the narrower
ones to 5, because a consistent field width looks tidier, and can
avoid misaligned columns with customized ships and land units.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Fix the bug demonstrated by the previous commit:
take_casualties_from_lands() limits total casualties to @each. It
should limit each land unit's casualties, and only if !may_kill. This
can lead to fewer casualties than called for; oops in
take_casualties(). Broken in commit 025e9cc25, v4.4.0.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Tweak military in land units to demonstrate that
take_casualties_from_lands() can kill fewer military than it should.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Commit 35ecc008c fixed take_casualties() to destroy land units only
when casualties demand it. This test demonstrated the change: inf#29
no longer dies. Good. However, this lost coverage of land units
dying in a sucessful defense. Bad.
I could tweak inf#29 to get destroyed again, but that would lose
coverage of the bug fixed by commit 35ecc008c. Make linf#28 die
instead.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Since commit 1ec9b94, we derive the version number from git tags with
build-aux/git-version-gen. When a shallow clone doesn't include a
suitable tag, this fails, and make refuses to build anything. Since
Travis uses git-clone --depth=50, it'll break as soon as we've got
more than 50 commits since the last release.
Support arbitrarily shallow clones for limited purposes like testing
by falling back from a proper V.N-H version number to UNKNOWN-H.
To guard against use of such builds for other purposes, log a warning
on server startup, and print one on player login.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Commit 1ec9b94 normalized version numbers in test output to 4.3.34,
because that was thought to be the next version then. 4.3.34 has
become 4.4.0 meanwhile. Update the normalization just to avoid
mention of 4.3.34.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
The choice of "to minesweep" in "`d' to drop mines, and `m' to
minesweep" is obviously intentional. But saying it in standard
English instead is at least as clear, so do that.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Relations state is relatively bulky: it's a big chunk of struct
natstr, and adds 200 bytes per country to xdump nat.
Relations change rarely. Rewriting it to disk on every nation update
and retransmitting it in every xdump nat is wasteful.
To avoid this waste, move relations state to its own struct relatstr.
This is of course an xdump compatibility break. We're not maintaining
xdump compatibility in this release.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
New struct relatstr is basically empty so far. The next commit will
move relations state from struct natstr to struct relatstr.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Reject state is relatively bulky: it's a big chunk of struct natstr,
and adds almost 200 bytes per country to xdump nat.
Reject state changes rarely. Rewriting it to disk on every nation
update and retransmitting it in every xdump nat is wasteful.
To avoid this waste, move reject state to its own struct rejectstr.
This is of course an xdump compatibility break. We're not maintaining
xdump compatibility in this release.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
New struct rejectstr is basically empty so far. The next commit will
move reject state from struct natstr to struct rejectstr.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Contact state is relatively bulky: it's a big chunk of struct natstr,
and adds almost 200 bytes per country to xdump nat for deities.
Contact changes rarely. Since we avoid unnecessary updates, it
doesn't change at all unless option HIDDEN is enabled. Rewriting it
to disk on every nation update and retransmitting it in every deity
xdump nat is wasteful.
To avoid this waste, move contact state to its own struct contactstr.
This is of course an xdump compatibility break. We're not maintaining
xdump compatibility in this release.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
New struct contactstr is basically empty so far. The next commit will
move contact state from struct natstr to struct contactstr.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
A country must always be in contact of itself when option HIDDEN is
enabled. The code ensures this by establishing contact whenever a
player logs in, in init_nats(). This is not the proper place. Game
state should be initialized in empfile's oninit() callback, in this
case nat_oninit(). Do that, and drop the putcontact() from
init_nats().
Note that option LOSE_CONTACT only affects contact to other countries:
agecontact() doesn't age the country's contact to itself.
Use the opportunity to initialize contact so that getcontact() works
even when HIDDEN is disabled. Just cleanup, it isn't actually called
then.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Belatedly update fairland.xdump for commit f4f0482, v4.3.33.
The commit made empdump omit redundant data, shortening the
final.xdump. The matching manual update to fairland.xdump was
forgotten.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Land units with capability security get a combat bonus regardless of
efficiency. This lets players get the benefits of a security unit at
a discount: just don't build it beyond 10%.
Multiply the combat bonus by eff/100. Together with the previous
commit, this closes bug#64.
Note that the the strength of a security unit's commando raid is
already proportional to its efficiency.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Infrastructure requires lcms and hcms to build. The build materials
are exposed as infrastructure columns lcms, hcms (struct sctintrins
members in_lcms, in_hcms). They are per point of efficiency. In
contrast, sector and unit build materials are defined for 100%.
We want to define build materials for 100% now, for flexibility and
consistency, and we want to optionally support more build materials in
the future. Replace members in_lcms and in_hcms by array in_mat[],
and provide selectors l_build and h_build.
Additionally provide selectors for all other item types, with value
zero, to help clients prepare for future additional materials. Use
CA_DUMP_ONLY to keep them out of configuration tables until they
actually work.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Infrastructure build cost is defined by infra column dcost (struct
sctintrins member in_dcost). It's the cost per point of efficiency.
In contrast, sector and unit build cost is defined for 100%, by
sect-chr, ship-chr, plane-chr, land-chr, nuke-chr column cost.
Switch to build cost per 100%, for flexibility and consistency:
replace struct sctintrins member in_dcost by in_cost, and selector
dcost by cost.
With cost values that aren't multiple of 100, the build cost may have
to be rounded. Do this exactly like we round sector build cost: the
amount is limited to money * 100 / cost rounded down, but the money
charged is actual amount * money / 100 rounded randomly.
Do the same for mobility use: replace struct sctintrins member
in_mcost by in_bmobil, and selector mcost by bmobil, with similar
rounding.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Guerrilla are created loyal to the old owner. When the sector
converts, they switch their allegiance to POGO. This is a bit of a
hack.
When guerrilla win their fight for freedom in an old-owned sector, the
old-owner duly changes to POGO. However, the owner doesn't. Broken
in 4.2.6. The "Sector X,Y has been retaken!" message is still sent to
the "new" sector owner.
Simply restoring the owner change lost back then would restore a bug
that goes back to 2.3.7: takeover() doesn't run when an old-owned
sector is liberated. So fix the bug by making that unconditional.
Land units reported captured are actually destroyed, because POGO
can't own any. Oh well.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
take_casualties() first applies casualties without destroying land
units, and if any remain, applies them by destroying land units. This
is wrong, because the remaining casualties may not suffice to actually
kill. Has been that way since land units were added in Chainsaw 3.
Apply remaining casualties more carefully: destroy land units only
when efficiency falls below 10%.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
A land unit with mil military taking N casualties loses N * 100 / mil
points of efficiency. A 50% inf with 20m dies when it loses more than
8m. With 100m, it dies when it loses more than 40m. A land unit
always dies when it loses all military.
In ordinary ground combat, they lose N * 100 / maxmil points of
efficiency, where maxmil is how many military they could load. This
is less damage when the land unit is under-strength. A 50% inf dies
when it loses more than 40m, regardless of how many it has.
An inefficient land unit with a sufficiently high number of military
can die before its military are all killed. A land unit with a
sufficiently low number of military can survive loss of all its
military. Attacking land units return to their starting position.
Defending land units stay put, and get taken over by a victorious
attacker. Neither was possible before 4.0.0 made land unit military
loadable.
The rules for ordinary ground combat may be debatable, but it's better
to be consistent: change land unit damage in guerrilla combat to match
ordinary combat. This reduces damage to under-strength land units.
If che lose, the sector owner profits from the reduced damage. But if
they win, they may take over land units that got all their military
killed.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Land units without military can't contribute to the fight. They can
still get killed, and whether they are depends on their UID.
take_casualties() kills land units in UID order until the required
number of casualties is reached. Killing a land unit without military
provides none, but take_casualties() doesn't care. The land unit
"dies fighting guerrillas", which makes no sense when it's doesn't
have any military.
If the rebels win, they attempt to capture any surviving land units.
Spies hide or get executed instead. Same as for any other violent
sector takeover.
Normal ground combat ignores land units without military. Do the same
here: ignore them in take_casualties(). This protects spies and other
land units without military from the fighting, but exposes them to
capture.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
To spread C casualties among N land units, take_casualties() applies
floor(C/N)+2 to each. Bonkers. Has been that way since land units
were added in Chainsaw 3.
Limit casualties spread to a land unit to their remaining amount.
Should really spread proportionally to military instead of evenly; add
a TODO comment for that.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
take_casualties() applies a number of casualties to sector military
and land units. It is utterly confused about land units.
Consider a land unit with efficiency eff that has mil out of maxmil
military. Issues:
* To apply N casualties without destroying it, take_casualties() tries
to kill N * maxmil / mil military. Makes no sense. It's more than
asked for unless mil equals maxmil. It can even be more than mil.
It reduces efficiency by N * 100 / mil points. Note that ordinary
ground combat reduces by N * 100 / maxmil points. See
lnd_take_casualty().
Example: the update test's inf#25 is 100% efficient and has 20m out
of 100m. take_casualties() tries to apply up to 22 casualties out
of the 60 remaining casualties to apply, but decides to apply only
12 for now, to keep efficiency above to 40%. It reduces efficiency
by 12 * 100 / 20 = 60 to 40%, and tries to kill 12 * 100 / 20 = 60
mil, which kills off the 20 that actually exist. It nevertheless
reduces the number of casualties still to apply only by 12.
Example: the update test's linf#28 is 100% efficient and has 20m out
of 25m. take_casualties() tries to apply up to 8 casualties. It
reduces efficiency by 8 * 100 / 20 = 40 points to 60%, and tries to
kill 8 * 25 / 20 = 10 military.
* When it destroys a land unit, it reduces the number of casualties
still to apply by mil * eff/100.0 instead of mil.
Example: the update test's inf#27 is 10% efficient and has 20m out
of 100m. take_casualties() still has 34 casualties to apply, so it
destroys it, killing all 20m. But it reduces the number of
casualties to apply only by 2.
Broken when 4.0.0 made land unit military loadable. Not sure it fully
worked before that, but it's definitely bonkers since.
Fix it as follows:
* To apply casualties to a land unit without destroying it, limit its
losses to its actual number of military, and so that efficiency
stays above 40%. Then simply kill that number.
* Reduce the number of casualties to apply by the exact number killed.
The update test now kills only 8m in linf#28. Still two more than it
should, but that's separate bug, to be fixed next. The fix has no
visible effect for inf#25, because that one gets destroyed later.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
The body count reflects what take_casualties() should do, not what it
actually does. It can be quite off, as the update test's changed
output shows. Mostly because take_casualties() is utterly confused.
That'll be fixed next.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Both ordinary ground combat and guerrilla combat basically kill
combatants one by one randomly until one side is eliminated. The odds
of each side taking a hit are computed from combat strengths.
Ordinary combat factors bonuses into the odds. It doesn't mess with
the number of men.
Guerrilla combat does the same for the bonus due to relative
happiness. It doesn't for land units with security capability: these
fight as if they had twice as many military. Changes both odds and
number of men. This inflates the body count reported to the sector
owner. Visible in tests/update/journal.log, where rebels kill 110 out
of 70 military. It also complicates take_casualties(). Has been that
way since security land units were added in Chainsaw 3.
To fix the body count and simplify take_casualties(), make capability
security affect only the odds, not the number of men. Without further
adjustments, this would reduce guerrilla losses: fewer men mean fewer
combat rounds mean fewer chances for rebels to die. To compensate,
increase the multiplier from two to four. This should make security
units a bit tougher. Document the bonus in "info Guerrilla".
More body count bugs remain.
Reusing ordinary combat rules and code for guerrilla combat would be
nice, but isn't feasible for me right now.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
makelost() overwrites an existing entry for the same thing, else
creates a new one. It calls findlost() to find existing entries.
findlost() means to look up by coordinates if it's looking for a
sector entry, and by ID if it's looking for a ship, plane, land unit
or nuke entry. It actually does both for sectors. Since callers pass
zero ID for sectors, sector entries always match, so at most one gets
created, and additional ones overwrite it.
Broken since the lost table was introduced in 4.0.7. Fix the flawed
comparison in findlost().
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Version information is in output of commands version, xdump version,
and in program output for option -v. Looks like this:
Wolfpack Empire 4.3.33
The version number is defined in configure.ac, and incremented
manually. It identifies only the base release (here: 4.3.33). Fine
when this is an unmodified released version. Pretty much useless
during development.
Add a suffix to the version number that describes it further:
V Unmodified release V (same as before)
V.N-H Modified release built from a clean git tree
N is the number of additional commits, and
H is the abbreviated commit hash
V.N-H-dirty Same, but the working tree is dirty
V-dirty Modified release built from a tarball
A git tree is clean when the contents of its files are unchanged.
Changing only the their timestamps doesn't count. It does count when
building from a tarball, because tracking contents isn't implemented
there.
Also use this suffixed version for tarball names.
The version reported by configure is fixed at configure generation
time, i.e. it is usually out of date during development. Ensuring a
release tarball contains one with a current version is manual for now.
Running autoconf -f should do the trick.
Elsewhere, the version is determined at build time, so it is always
current.
Dirty tracking isn't implemented in the standalone client build. If
you start with a clean tarball, the version will not change from V to
V-dirty when you build with modifications.
Steal build-aux/git-version-gen from autoconf 2.69 to help with
computing the version string.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
The xdump field data types are abstract symbols "d", "f", "s" and "c".
However, the abstraction leaks: we dump the enum nsc_type ca_type
values verbatim in meta table field "type", and have symbol table
meta-type map all integer types to "d", and both floating-point types
to "f". Not a problem for well-behaved clients, since all they do
with the dumped value is referencing table meta-type. It is a problem
for version-test: since the integer type compatible with an
enumeration type is implementation-defined, the type value of
selectors of enumeration type can vary between compilers. It also
makes table meta-type a somewhat ugly exception to the rule that a
symbol table maps integers to names 1:1.
Virtual selectors let us seal the abstraction: dump the promoted
ca_type value.
The integer types get all promoted to NSC_LONG. This takes care of
version-test.
The floating-point types get all promoted to NSC_DOUBLE. Makes sense.
NSC_STRINGY gets promoted to NSC_STRING. This changes all field data
types "c" to "s". Getting rid of "c" is a welcome simplification,
because now the meaning of meta type field "len" no longer depends on
"type", but always means that the array is dumped as that many fields.
We lose string length limit information, though.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
People in sectors get plagued, then taxed or paid, then fed. People
on ships and land units get paid, then fed, then plagued. Sectors
were messed up when Empire 3 made the update code work for budget.
Change sectors back to how they worked before Empire 3: move do_feed()
from produce_sect() to prepare_sects(), and delay do_plague() until
after do_feed(). People in sectors now get taxed, paid and fed even
when they die of the plague, just like they do on ships and land
units.
Because do_plague() now runs after populace(), the latter's handling
of people dying off doesn't cover plague anymore. Delay it to the
very end of prepare_sects().
Additionally, move feeding and plaguing from upd_ship(), upd_land() to
prep_ship(), prep_land(), for consistency with sectors.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
The update visits sectors in increasing order of country number.
Within a country, it visits in increasing order of sector number,
which is effectively top to bottom, left to right, starting with
absolute 0,0.
The order doesn't actually matter. Before Chainsaw's option BUDGET,
the update simply visited the sectors in sector number order. Go back
to that order, because it's faster. For the update, it's a few
percent in my testing. For budget, it's more than a third.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
The update visits ships, planes and land units in increasing order of
country number. Within a country, it visits first ships, then planes,
then land units, each in increasing order of unit number.
The order is relevant when money, materials and work don't suffice to
build everything.
Money is charged to the owner, so only the relative order for the same
owner matters there. One order is as good as any.
Work and materials come from the sector, so only the relative order in
each sector matters. The current order unfairly prefers countries
with lower country numbers. Mitigating factor: the affected countries
need to be friendly (ships only) or allied.
The unfairness goes back to Chainsaw's option BUDGET. See the commit
before previous for more detailed historical notes.
The update test demonstrates the unfair behavior: sector 14,6 builds
ships 95/97 owned by country#1, but not 96 owned by country#7.
Likewise, planes 95/96/97 and land units 95/96/97.
Go back to the the pre-BUDGET order: first ships, then planes, then
land units, all in increasing order of unit number, regardless of
owner.
The update test now builds ship, plane and land unit 96 instead of 97.
Bonus: speeds up both the update and budget by a similar absolute
amount. For budget, this is roughly a factor of two in my testing.
For the update, which does much more, it's around 10%.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
The budget command simulates an update by running selected parts of
the update code. It skips parts that depend on hidden information
such as guerrilla warfare. For speed, it also skips parts it doesn't
need, such as distribution and foreign sectors, ships, planes and land
units.
Skipping foreign sectors is wrong when any of the player's ships,
planes or land units will be repaired in foreign sectors, because it
makes budget use old materials and work instead of new.
Skipping foreign ships, planes and land units is wrong when they
compete with the player's for materials and work.
The bug goes back to Chainsaw's option BUDGET. See the previous
commit for more detailed historical notes. The update test
demonstrates it in several variations.
Fix it with the sledgehammer: don't skip foreign sectors, ships,
planes and land units. This makes budget almost twenty times slower
in my testing. Probably tolerable on a reasonably beefy machine, but
we can do better; the next few commits will claw back most of the lost
performance.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
