tests: Normalize version numbers to 4.4.0 instead of 4.3.34
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 .NA header promises information on "Clients which communicate well
with the Empire4 Server". The page doesn't really deliver. It talks
about client support for asynchronous notifications. It stopped
listing separate client projects in 4.0.7 (1997). Not mentioning such
clients isn't just outdated, it's actively misleading.
Perhaps an up-to-date info page on clients would be useful, but I
can't write one right now. Delete.
Loses a bit of information for client developers that was tacked on in
4.0.7: pointers to dump commands, and an explanation of timestamps. I
trust client writers can find "info xdump" without this.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
info: Trim .SA of change log pages to just "Server"
Looks like an attempt was made to have .SA point to info pages for
significantly changed things. It wasn't done consistently, though,
and it's impractical for Empire 4. Drop these references, and keep
only "Server".
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
info: Improve .NA and first paragraph of change log pages
The .NA show up in "info Server", like this:
Chainsaw ! Changes from KSU Empire to Chainsaw code
Empire2 ! Changes from the Chainsaw server to the Empire2 Server
Empire3 Changes from the Empire2 server to the Empire3 Server
Empire4 ! Changes from the Empire3 server to the Empire4 Server
[...]
Merc Changes from KSU code to Merc code
Old-empire ! Differences from 1.2 to UCB Empire
Tweak them to look like this:
Chainsaw ! Changes from KSU Empire to Chainsaw (1992-93)
Empire2 ! Changes from Chainsaw to Empire 2 (1995)
Empire3 Changes in Empire 3 (1995-96)
Empire4 ! Changes in Empire 4 (1996-present)
[...]
Merc Changes from KSU code to Merc code (1992)
Old-empire ! Differences from 1.2 to UCB Empire
The first paragraph of Empire2.t refers to "the new Empire 2" server.
Drop "new", because it clearly ain't anymore. Same for Empire3.t.
The first paragraph of Empire4.t claims "several changes/fixes" have
been made. Umm, that's only tenuously connected to reality by now.
Rewrite the paragraph.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
The .TH and .NA header promise information about "Wolfpack Code" and
"The Wolfpack Project", but the body doesn't really deliver. It's
basically the first paragraph of Empire4.t plus pointers to Options.t
and Empire.t. Has been that way since it was added in 4.0.2.
History.t covers the Wolfpack project more usefully, so delete this
one.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
navigate march: Say "to sweep mines" instead of "to minesweep"
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>
show: Clean up long vs. int in fmttime2822() for Windows
fmttime2822() prints long with format %d, and passes long to abs().
Harmless, because both int and long are 32 bits in the Windows API.
Clean it up anyway.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Most uses of getrel() have been replaced by the safer relations_with()
in commit 0c60e57..67b9135, v4.3.27. Eliminate the remaining ones:
* Convert rela() to use relations_with(). The case of relations to
self, where the two differ, doesn't occur. The code becomes more
easier to understand, even.
* relations_with() is then getrel()'s last user. Inline.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Communications from deities can't be rejected, but the accept command
fails to consider that detail. Should not normally matter, because
the reject command doesn't let you reject deities. Fix it anyway.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
When sending a telegram, typed_wu() checks whether the recipient is
rejecting telegrams. The check tacitly assumes from == player->cnum.
Happens to be the case, but clean it up anyway.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
wire: Fix announcement rejection for and from deities
Announcement rejection is completely broken for deities.
Additionally, deity announcements aren't exempted from rejection, but
that should not normally matter, because the reject command doesn't
let you reject deities.
Broken when announcements were separated from telegrams in Empire 3.
Fix to test the sender's instead of the player's divinity.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
reject: Exempt bulletins on relation change with deity
Bulletins notifying on a relations change can be rejected just like a
telegram from the country initiating the change, except for one
inconsistency: telegrams from deities are exempt, but bulletins on a
relation change by a deity aren't. Inconsistent since rejecting was
added in Merc Empire.
Change setrel() to treat relation change bulletins the same as tele()
treats telegrams.
Should not normally matter, because the reject command doesn't let you
reject deities.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Instead of enumerating all eight combinations of the three flags in a
table, simply print each flag on its own, and drop the table. The old
table depends on the flag encoding, the new code doesn't.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
contact: Move contact state from struct natstr to contactstr
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>
The next commit will create a contact file, and the macro to get a
contact entry will be named getcontact(). Rename the existing
getcontact() out of the way.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Make setcont() update the nation only when it actually changes the
contact value. For added benefit, map all non-zero values to one when
option LOSE_CONTACT is disabled.
This saves I/O, in particular xdump bandwidth.
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>
When option LOSE_CONTACT is enabled, contact is lost after a few
updates. The remaining number of updates is to be decremented by one
each update. However, it's actually decremented every time an active
nation is updated. This makes countries lose contact much too fast,
typically every update. Broken in commit ac25058, v4.3.0.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Interactive edit shows what can be edited, with edit keys and current
values. When option HIDDEN is enabled, "edit c" additionally shows
contact information like "Countries contacted: 1(6) 2(6) 4(5) ".
Lists the numbers of contacted countries and, in parenthesis, how many
updates contact is going to last if option LOSE_CONTACT is enabled.
The line was added along with option HIDDEN in Empire 2. As long as
editing contact isn't implemented, it doesn't belong here. Drop it.
If deities need contact information, we'll have to show it elsewhere.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Grant land units with security capability the same bonus as in convert
and shoot: multiply by (1 + eff/100).
military_control()'s code to count military is now functionally
equivalent to security_strength(), except it has no use for its second
parameter. Change security_strength() to permit a null argument, and
reuse it in military_control().
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Moving stuff out of an occupied sector generally requires "military
control", i.e. you need at least one military for every ten civilians.
Military in land units count. Even when the land unit is loaded on a
ship or land unit. Questionable, because unload need not be possible.
Checking whether unload would be possible is not worth the trouble
here, simply ignore embarked land units.
This affects commands move, explore, sell, set and transport, as well
as the update's distribution and delivery.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
update/revolt: Make security bonus proportional to efficiency
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>
convert shoot: Make security bonus proportional to efficiency
Land units with capability security reduce the mobility cost and have
their military count double, regardless of efficiency. This lets
players get the benefits of a security unit at a discount: just don't
build it beyond 10%.
Count security unit's military times 1 + eff/100 instead of double.
Change the mobility bonus term from number of security units to sum of
security unit efficiency / 100. Partial fix for bug#64.
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>
config: Define infra build cost and mobility use per 100%
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>
lboard: Don't permit boarding of embarked land units
You can board land units loaded on a ship or land unit. This makes no
sense. Reject attempts to board land units on a ship or land unit
exactly like attempts to board land units that don't exist.
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>
update/revolt: Destroy land units only when casualties demand it
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>
update/revolt: Reduce under-strength land unit damage
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>
update/revolt: Don't kill land units without military
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>
update/revolt: Spread only actual casualties to land units
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>
update/revolt: Fix mil count for che move after getting caught
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>
update/revolt: Change security unit bonus to fix body count
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:
attack assault board: Fix message when attacking land unit dies
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>
projects / empserver / log