This reverts commit b1a0ff2fbd.
Land units with capability heavy can't be loaded on anything, and land
units carrying land units can't be loaded regardless of capabilities.
Commit b1a0ff2fbd additionally outlawed loading of trains on land
units, but not on ships. Bad idea, because it complicates matters for
no good reason. Revert it.
Doesn't affect the stock game, because its only train is heavy.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Text after the first space is missing in the formatted output. That's
because .L takes just one argument, but we pass several. Broken in
commit 4e0d02b, v4.3.33. Fix by quoting the argument text.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Sectors, ships, planes and land units are always visited in the same
order, but it doesn't hurt to be explicit.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
"info Empire4" has become unwieldy: more than 4000 lines, almost a
quarter of a Megabyte. Split it up.
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>
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>
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>
Ken Stevens stopped maintaining Empire many years ago, but "info
Empire2" and "info Empire3" still direct users to him. Drop that.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
check_trade() sets plane and land unit mobility to zero on trade.
Even when it's negative. Fix to leave it alone then.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Forgotten in commit 6157b6c. While there, fix the references to "show
ship stats" headings, and say "to paradrop" instead of "to paratroop".
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>
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>
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>
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>
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>
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>
Ship, plane and land unit repairs depend on and change the state of
the sector. To predict repairs, we need to predict the state of the
sector before repairs. The obvious way to do that is to simulate the
sector update and all ship, plane and land unit updates there in the
correct order.
Until recently, we simulated only own sectors, ships, planes and land
units. Wrong when foreign sectors, ships, planes or land units are
involved. The fix (commit 70f6964) makes budget simulate all
countries. Correct, but does much more work than necessary. With a
little effort, we can track what needs to be simulated.
Use the bp map for tracking. We need to mark the player's sectors and
all sectors where he has ships, planes or land units. Do the former
in bp_alloc(), and the latter in prep_ships(), prep_planes(),
prep_lands().
Skip sectors not so marked. This requires delaying prepare_sects()
until after prep_ships(), prep_planes(), prep_lands(). Their order
doesn't actually matter: prep_ships() & friends only spend money, and
nothing in preparation depends on whether the country is still
solvent.
Skip ships, planes and land units in sectors not so marked.
This speeds up budget by around a third in my testing, more for small
countries. Roughly 15% slower than before the fix for repairs abroad.
The update has to do a bit more work than before, but the performance
difference is lost in the noise.
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>
Ship, plane and land unit repair uses new work, except in sectors
owned by countries with a higher country number.
This inconsistency is an artifact of how the update is sequenced: we
work on countries one after the other. A country's ships, planes and
land units get repaired before higher-numbered countries' sectors
produce. Any ship, plane and land unit repairs in such sectors use
old work instead of new work.
Repair work use changed several times during Empire's history.
In BSD Empire, repairs use old work, because it updates ships and
planes before sectors.
Chainsaw added budget priorities and the budget command as option
BUDGET. Budget priorities let players choose separately for ships,
planes and land units whether to use old or new work for repairs.
The option also changed the update to work on countries one after the
other, presumably to permit a more efficient implementation of the
budget command.
Chainsaw also introduced repairs in foreign sectors under option
ALLYHARBORWORK.
With BUDGET disabled, all repairs still use old work, whether at home
or abroad. With BUDGET enabled, work use of repairs at home depends
on budget priorities, but work use abroad depend on country numbers.
Both options became standard in Empire 2.
Since v4.3.6, repairs at home always use new work (commit 967299a and
commit 520446e).
To make repairs abroad always use new work as well, we need to update
all sectors before any ship repair. This is straightforward: split
the loop over countries between sectors and unit building. For
symmetry, also split it between unit maintenance and sectors.
The budget command is differently broken, and will be fixed next.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
People in sectors first eat, then build the sector, then produce.
People in ships produce, eat, then build.
The starvation command can be off for fishing vessels, because it
doesn't consider the food they produce.
Change ships to match sectors. "Fixes" starvation. Fishing boats and
oil derricks being repaired at sea become a bit more productive.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
prod() duplicates the update's sector production code, except it
computes both output with present materials ("make" output) and output
not limited by lack of materials or production backlog ("max" output).
It also rounds materials consumed up instead of randomly.
Factor prod_output() out of produce() for reuse by prod(). prod()
runs it twice: once for "make" output and once for "max" output.
Test output changes are due to random rounding.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
The collection value of a sector is
sector value = sector type value * (sector efficiency + 100)
+ sum of item values
item value = item type value * amount
The sector and item type values are configurable.
The item type collect values aren't too far off the power values:
uid mnem pow val pow/val
0 "c" 50 1 50
1 "m" 100 0 inf
2 "s" 125 5 25
3 "g" 950 60 15.8
4 "p" 7 4 1.75
5 "i" 10 2 5
6 "d" 200 20 10
7 "b" 2500 280 8.9
8 "f" 0 0 NaN
9 "o" 50 8 6.25
10 "l" 20 2 10
11 "h" 40 4 10
12 "u" 50 1 50
13 "r" 50 150 0.33
The power value is very roughly ten times the collect value, except
for civilians and uw it's 50, for rads its 0.33, and military are free
to collect. The latter two make no sense.
Replace the item type collect value by the power value / 50 for
people, and by the power value / 10 for everything else. This makes
collecting military, shells, guns and uw more expensive, and petrol,
bars, iron, oil and rads cheaper.
The sector type values are basically arbitrary. For instance, an iron
mine costs five times as much as a wilderness, but a third of an
uranium mine, regardless of actual resource contents.
Replace this by different arbitrary values:
sector value = (item value of materials necessary to build it
+ build cost) * efficiency / 100
+ sector type maximum population
+ sum of item values
Some sector types become cheaper, some more expensive.
Drop sect-chr and item selector value.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
The whole idea of a sector acquiescing to takeover by lawyers waving
loan documents "proving" it's rightfully theirs is pretty
preposterous. But a capital giving itself up that way (and then
paying out half the nation's treasury on top) beggars belief.
Disallow it.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
