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>
Since the previous commit fixed the update of mc, mc + taken remain
invariant. Don't bother changing mc, use mc - taken instead.
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>
When military catch che, their their count isn't updated for their
losses. The count is later used when che consider moving to an
adjacent sector. This could conceivably make them move instead of
stay. Broken when Chainsaw 3 added land units. Fix it.
Note that the sector's military count includes land units, but the
adjacent sectors' doesn't. Should be improved some day; add a TODO
comment.
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>
When an attacking land unit fails its morale check and retreats, the
retreat message needs to be prefixed with a newline to separate it
from the casualty characters. However, the code also prints the
newline when a defending land unit retreats, leaking the retreat to
the attacker. For instance, a fight that forces three defending to
retreat could look like this:
!!!!!!!!!!!!!!!!!!
!@!!!!!!!!!!!!!@!
!
- Casualties -
Yours: 2
Theirs: 34
Messed up in Empire 3. Fix by printing the newline only when an
attacking land unit retreats. The example becomes:
!!!!!!!!!!!!!!!!!!!@!!!!!!!!!!!!!@!!
- Casualties -
Yours: 2
Theirs: 34
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Loss of an attacking land is reported like this:
@linf light infantry #1 dies assault 21,-3!
Bad grammar and newline missing between the "@" casualty character and
the message. Messed up in Empire 2. Affects only attackers, because
the code special-cases defense to avoid the bad grammar there (close,
but no cigar), and defenders don't get casualty characters printed.
Fix it to
@
linf light infantry #1 dies assaulting 21,-3!
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
The server doesn't let you send land units without offensive strength
into combat: ask_olist() simply doesn't offer them. Good.
However, it needs to offer spies for assault, because assault is how
they sneak ashore. To make it offer spies, which have no offensive
strength, attack_val() artificially sets their offensive strength to
one for assault. Dirt effect: spies fight (and die) in assaults, even
though they can't otherwise attack. Lame. Has been that way since
spies were added in 4.0.0.
Make ask_olist() offer spies regardless of offensive strength when
assaulting, and drop the special case from attack_val(). They get
offered exactly as before. However, since their offensive strength is
now zero, they won't enter actual combat (see the previous commit).
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
The server doesn't let you send land units without offensive strength
into combat: ask_olist() doesn't offer them. But if their strength
gets somehow destroyed between ask_olist() and the actual fight, they
go anyway.
Check again before the fight, and leave land units without offensive
strength behind.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Defending spies get spotted like any other defending land unit. They
don't contribute to the defense (their defense value is zero), and
they always survive the fight unscathed (lacking mil, they take no
casualties). If the sector is lost, they either hide or get executed.
Before the previous commit, they could also be damaged and captured.
Possible outcomes:
* Spy isn't spotted, attack fails
* Spy isn't spotted, attack succeeds, spy gets executed
* Spy isn't spotted, attack succeeds, spy hides
* Spy is spotted, attack fails
This lets players use probing attacks to spot spies with a much
better chance than spy or llook have. But they can already repeat
spy or llook to increase their detection chances as close to 100% as
they want, so this doesn't make things materially worse.
* Spy is spotted, attack succeeds, spy gets executed
* Spy is spotted, attack succeeds, spy hides
Since the spy has already been spotted, hiding is largely useless.
The attacker can board the spy as soon as he has mobility.
This obviously hasn't been thought through.
Get rid of the "spy is spotted" cases by skipping spies when
collecting the list of defending land units.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
When the attacker takes a sector, spies try to hide. If they fail,
they're treated like any other land unit: they attempt to
self-destruct, and if the damage isn't lethal, they get captured.
Successful self-destruct is reported as "blown up by the crew", which
makes no sense for spies. Spies surviving self-destruct is odd, as
any damage is normally fatal for them.
Extend the special case for spies: summarily execute the ones that
fail to hide.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Spies assaulting a foreign sector have only a 10% chance to evade
detection, regardless of efficiency. With odds like that, players
basically don't bother.
All the other spy detection checks use LND_SPY_DETECT_CHANCE(eff),
which gives 100% spies a 90% chance to evade detection. That's
perhaps a bit to good here, so let's try LND_SPY_DETECT_CHANCE(eff/2).
A 100% spy now has a 40% chance to sneak ashore undetected.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Since the previous commit, sneak_ashore() doesn't depend on a previous
get_oland() anymore, so the att_get_offense() is unnecessarily. Move
it across att_get_offense() next to the other special case "assault
own sector".
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Assaulting a foreign sector with nothing but spies is special: the
spies sneak ashore. It is, however, more special than it should be:
the spies use no mobility and ignore landmines. They do use mobility
and hit landmines in other assaults. Assaulting your own sector with
nothing but spies is more costly and more risky than assaulting a
foreign one. This makes no sense. Has been that way since spies were
added in 4.0.0.
It's that way because sneaking ashore uses its own code to move the
spies instead of move_in_land() via att_move_in_off(). It can't use
move_in_land(), because that prints an unwanted "now occupies"
message, and destroys the list of assaulting units, which we still
need to catch and shoot spies.
Factor the code to move attacking land units to the target sector out
of move_in_land() into att_move_land(), and use that for sneaking
ashore. This makes the spies use mobility and hit landmines even when
they sneak.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
The rules for spy units make little sense unless spies carry no
military. For instance, spies die when they take casualties in ground
combat. There seems to be a tacit assumption that spies have no
military. I don't trust the code to behave unless this assumption is
met. Require it before an overly adventurous deity finds out the
painful way that spies with military don't work.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
A ship just read from the ship file exists unless its owner is zero.
Check that instead of whether efficiency is below minimum.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Ships with efficiency below the minimum have their owner set to zero
on write to the ship file. Therefore, a ship just read from the ship
file exists unless its owner is zero. Additionally checking
efficiency is redundant. Same for planes and land units. Drop
obviously redundant efficiency checks.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
get_dland() tests efficiency to find out whether the defending land
unit is gone. Doesn't work when somebody else has since built a new
one with the same UID. Not sure that can happen. Check for a change
of owner instead. Matches get_oland().
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
do_defdam() iterates over the list firing ships, applies return fire
to each, and frees its list element. When it finds a ship that has
been sunk already, it skips it. This also skips the free, leaking the
list element. The leak goes back to flawed bug fix in Empire 2.
As far as I can see, missile defense is the only way a ship can be
sunk there.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
The die roll was added in 4.0.17 to hide spies from bombers. However,
players could roll dice as often as they wanted, by typing '?' at the
target prompt. The broken die roll is unreachable since commit
7688aed disallowed bombing of spies. Drop it.
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>
News reporting merges news items into recent items with same actor,
action and victim, as long as the merged number of times doesn't
exceed 65535 (127 before the previous commit).
This complicates incremental xdump a bit: when the client sees a row,
it's not obvious which of the previously dumped rows it replaces.
Actually, rows with the same actor, action, victim and time replace in
xdump order.
Merge news item regardless of the number of times; saturate the number
at 65535. Now the replacement is obvious, because there can only be
one news item with the same actor, action, victim and time.
This also rate-limits floods of identical news should they happen for
some reason.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
News reporting merges news items into recent items with same contents,
until their count reaches 127. Raise that limit to 65535, by making
struct nwsstr member nws_ntm unsigned short. Size of struct nwsstr
stays the same on all common machines.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
This is one of the lamest ways to sort I've seen in my career: find
the maximum, then for each value from the maximum down, search for
that value. O(max * MAXNOC^2). Dates back to Empire 2.
The one advantage this contraption has is it "sorts" in place. But
memory's cheap. Fill an array with the data to sort, and sort it with
qsort(). To avoid overtaxing the stack in the (unlikely!) worst case
of everybody taking sectors from everybody, allocate it dynamically.
Also flip sectors_taken[] from short to unsigned short. Aside: in
theory, the count can overflow, but sector deltas exceeding 65535
don't occur in practice, and if news misreported them, we'd live. Not
worth complicating the code.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Duplicated to detect empty pages in Empire 2. Easy enough to fold
into the other loop, so do that.
While there, oops on invalid struct nwsstr member nws_ntm.
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>
Table version selector version shows the version string stored in
version[]. Its implementation is a bit of a hack:
empfile[EF_VERSION].cache is set to version[], so it gets passed as
context object to nstr_eval(). This permits reading version[] with an
NSC_STRINGY selector at offset 0, which is what nsc_init()'s
version_ca0 is.
Both empfile[] and version_ca need the size of version[]. Since
version.h provides only an incomplete type for version[], they use
sizeof(PACKAGE_STRING), which isn't exactly clean.
Redo version_ca0 as virtual selector. Takes a bit more code, but it's
easier to understand.
The context object is now unused. Setting empfile[EF_VERSION].cache
to a null pointer would trip assertions, so make it point to a dummy.
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>
verify_table() skips verify_row() when the table doesn't have
selectors. But verify_row()'s test for corrupt headers in EFF_TYPED
tables doesn't require selectors. Harmless, since the two tables that
don't have selectors (EF_MAP and EF_BMAP) aren't EFF_TYPED. Clean it
up anyway.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Virtual selectors can't be used in xundump, since we lack a setter to
go with ca_get(). verify_ca() verifies they don't occur in tables
that can be xundumped.
When I restricted xundump to tables with a file name (commit 029d929,
v4.3.28), I neglected to update the test in verify_ca().
Factor out the correct test into xundumpable(). Use it to fix
verify_ca().
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
mksubj.pl neglects to terminate info/toc's last line with a newline.
info-test doesn't care. Tidy up anyway.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Deliver fails to abandon sectors when it ships out all civilians and
military. The sector remains owned until the next non-update sector
update abandons it. Has always been broken.
Distribution had the same bug until commit d0f3847 (v4.3.20) fixed it.
Fix it the same way for delivery: adjust the amount moved to avoid
moving out the last civilian, or the last military if there are no
civilians.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>