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>
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>
Several headers define macros that use ef_ptr() without including
"file.h". Fix that. Drop redundant inclusions elsewhere.
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>
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>
Land unit maintenance and building ignore land units in sanctuary
sectors. Leftovers from undocumented compile-time option START_UNITS,
which is gone since commit dab1f0b, v4.3.0. Feeding, paying military
and fallout don't ignore them. Change maintenance and building to
match.
Sector preparation (except for the fallout part) and production ignore
even non-sanctuary sectors owned by nations in sanctuary. Fallout,
delivery, distribution and mobility growth don't check the sector
owner's status. Change preparation and production to ignore just
sanctuary sectors, without checking the sector owner's status. Except
don't bother for most of fallout, as we already avoid spreading
fallout into sanctuaries; still ignore sanctuaries when doing fallout
damage mostly for completeness.
Delivery and distribution ignore unowned sectors. Ignore sanctuaries,
too.
Feeding and mobility growth ignore sanctuaries. Ignore sea, too.
None of this should matter in sane game states.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Split upd_slmilcosts() into prep_ships() and prep_lands(). Move the
sanity check for dead ships and land units from prod_ships() and
prod_lands() there. Move their call from prepare_sects() to its
caller, along with pay_reserve().
Create prep_planes() for symmetry. Pilots are now paid at the same
time as other military. Can matter only when the country goes broke
during the update.
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>
No maintenance is paid when the sector is stopped or the owner is
broke. Broken in commit 44c36fa, v4.3.23. Fix it.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
update.h is a more logical home for update_running than server.h.
Move the definition and the assignments along, from server/update.c to
lib/update/main.c.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
The do_upd_checking recursion guard is superfluous: do_mob_sect()
doesn't call anything. Has been that way since MOB_ACCESS was added
in Empire 3.
Inline the remaining code of sct_do_upd_mob(), shp_do_upd_mob(),
pln_do_upd_mob(), lnd_do_upd_mob() in their only callers
sct_postread(), shp_postread(), pln_postread(), lnd_postread().
Rename do_mob_sect(), do_mob_ship(), do_mob_plane(), do_mob_land() to
mob_sect, mob_ship(), mob_plane(), mob_land() and give them external
linkage.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
The update uses mob_sect(), mob_ship(), mob_plane() and mob_land() for
two related, but different jobs: to give the previous turn's remaining
MOB_ACCESS mobility, and to give this update's new mobility. The two
were probably conflated in an attempt to share code, but it actually
just complicates things.
Collect the MOB_ACCESS code in new function mob_access_all(), and the
normal mobility update code in new function mob_inc_all().
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
When option TECH_POP is enabled, the cost of tech increases when
civilian population exceeds 50000. Only civilians in old-owned
sectors count. This differs from education and happiness, where
civilians loaded on ships and land units count, too.
The update counts population for TECH_POP with count_pop(). This is
an extra pass over all sectors.
produce also uses count_pop(), once per tech center examined.
Wasteful.
budget avoids count_pop(): it uses tax()'s civilian count. More
efficient, but the difference to the update is ugly.
Change TECH_POP to use the same civilian count as education and
happiness, i.e. count civilians on ships and land units, too.
This count is available in nat_budget[] in time for produce(): it's
computed by tax() and by ship and land unit maintenance. So use it
there. This takes care of the update and budget. produce doesn't run
enough update code to do the same. Keep calling count_pop() there.
Update it to match the update, and give it internal linkage.
Duplicating update's workings there is ugly, so mark it FIXME.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
