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>
Put the new function security_strength() next to military_control(),
because that one does a similar count.
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>
Call callers assign the return value to sp->sct_avail now. Move the
assignment to do_feed() and drop the return value.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Left behind by commit a109de9 and commit dc73207, v4.3.33.
While there, drop a declaration of nonexistent function xedit() that
crept into commit afa65c8, v4.2.20.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
buildeff() rounds work and money up. Until recently, fractions could
only occur on tear-down, but with customized costs they can now also
occur on build-up.
The previous commit changed unit building to round money and work
randomly. Before, money was rounded down, and work was rounded up.
Round them randomly for sectors as well, for consistency.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
If player->simulation, shiprepair(), planerepair(), landrepair() must
use the bp map, and must not change game state.
Copy the sector to a scratch buffer, update it from the bp map, work
on the sector normally, then write back to the bp map. This is
simpler and safer.
Since get_materials() loses its connection to the bp map, move its
declaration out of budg.h.
While there, drop an ancient debugging logerror() from landrepair().
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Update code shared with budget uses the bp map instead of the sector,
so that budget can track materials and work available in sectors for
ship, plane and land unit building without updating the sector file.
Unfortunately, the bp map can become stale during the update.
prepare_sects() doesn't update the bp map for sea sectors, unlike
budget's calc_all(). Instead, we rely on calloc()'s initialization.
Works, but is a bit unclean.
prepare_sects() updates the bp map after fallout, but neglects to
update it for any of the later sector updates (steps 1b to 1f in info
Update-sequence). Che can destroy materials and available work, and
the plague can kill military. The bp map stays out of date until
produce_sect() updates it again.
Since we deal with sector production and countries in increasing order
of country number, foreign ships, planes and land units owned by
countries with lesser numbers get built before their sector produces.
Building uses the stale bp map then, and can use materials and
available work destroyed by che or the plague. The update test
demonstrates the former case.
For stopped sectors or when the owner is broke, produce_sect() updates
only materials in the bp map, not available work. Nothing builds in a
stopped sector, but allies may build in your sectors even when you're
broke. They can use available work destroyed by che then.
Screwed up when Empire 3 made the update code work for budget.
Note that budget bypasses the flawed code: it prepares its bp map
itself instead of calling prepare_sects().
Rather than fixing prepare_sects(), use a null bp map for the update:
writes become no-ops, and reads read from the underlying sector. Not
only does this remove the possibility of the bp map going stale during
the update, it saves a bit of memory, too.
calloc()'s initialization is now dead. Switch to malloc().
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
prepare_sects() caches the sector owner's getnatp() across
guerrilla(), do_plague() and populace(). This is wrong, because the
owner may change. The mistake can be traced back all the way back to
BSD Empire 1.1.
If the sector revolts or reverts to deity, the ex-owner still receives
taxes and bank interest. The update test demonstrates this bug.
If the sector revolts, we use the ex-owner's instead of the owner's
tech and research for plague, and we use the ex-owners happiness and
required happiness instead of the owner's for loyalty update and civil
unrest.
Change do_plague() and populace() to call getnatp() themselves. Call
it in prepare_sects() only after we're done messing with the sector
owner.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
This way, tax() is more focused, and populace() doesn't need to be
guarded with !player->simulation.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
The code to build sectors got quadruplicated in Chainsaw. We've since
fixed numerous inconsistencies, but still have four copies of the
code. Thanks to the recent work on upd_buildeff(), we can now use it
to replace the other three copies. Rename it back to to buildeff()
while there.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
newe() and prod() duplicate parts of the update's do_feed(), except
they round babies down instead of randomly, to get a stable,
conservative forecast. Unlike the update, they assume sufficient
food. Inaccurate for sectors that are going to starve or have
suboptimal population growth. Not documented. Has always been that
way.
Eliminate the undocumented assumption by replacing the duplicate code
by a call of do_feed(). Add a suitable parameter to do_feed() to
preserve the different rounding.
The update test shows the improvement.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Since changing *sp is safe now, we can move the update of
sp->sct_avail into produce(). This frees the return value; use it to
return the amount produced. Drop the parameters.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Since changing *sp is safe now, we can move the update of sp->sct_work
into do_feed(), use the return value for work, and drop parameter
workp.
The sp->sct_avail update looks similar, but there's a subtle
difference: it's skipped when the sector is stopped or its owner is
broke. The caller already checks that, so leave the update there.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Civilians, military and uw work only up to their sector's population
limit. The population limit depends on the sector type's maximum
population, research if RES_POP is enabled, and the sector's
efficiency for big cities.
The population limit may decrease between computation of work in
do_feed() and the end of the update:
* Research declines (only relevant with RES_POP). Work is not
corrected. The declined research will apply at the next update.
Since levels age after production is done, any work corrections
could only affect leftover available work. Wouldn't make sense.
The effect is negligible anyway. Even with an insanely fast decline
of 60% (level_age_rate = 1, etu_per_update = 60), the population
limit decreases by less than 10% in the worst case.
* upd_buildeff() changes sector type and efficiency. Work is
corrected only when this changes the sector type from big city to
not big city.
It isn't corrected on other sector type changes. These can affect
maximum population since the sector type's maximum became
configurable in commit 153527a (v4.2.20). Sane configurations don't
let players redesignate sectors to a type with different maximum
population. The server doesn't enforce this, though.
It isn't corrected when a big city's efficiency decreases, but
sector type change isn't achieved. Harmless, because tearing down a
city takes very little work (25 for 100%), so efficiency decrease
without type change means the work we have must be safely below any
sane population limit's work.
Good enough. However, the code implementing the work correction for
big cities is unclean. Get rid of it by tweaking the rules: a big
city's extra population does not work. City slickers, tsk, tsk, tsk.
At least they still pay their taxes.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
This reverts commit 9b33a4c598.
Parameter only_count was introduced so would_abandon() could use
unitsatxy(), but that was a flawed idea, fixed in the previous commit.
No callers passing non-zero remain, so get rid of it.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
The code to list ships got triplicated in Chainsaw. Empire 2 screwed
up one copy in its global replace of owner by player->owner.
Fix it by de-duplicating.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Unlike the move command, march checks sector abandonment before every
step.
If the player declines, the last land unit stays put and is removed
from the march.
Except when sectors or land units change while we're waiting for the
player's reply. Then the last unit is not removed from the march.
This can scatter land units. Screwed up when checking for abandoning
the sector was added in 4.2.2.
Change march to work like move, and to avoid scattering land units: if
the player declines to abandon the sector, the command simply fails.
Put the check into new lnd_abandon_askyn().
Extend would_abandon() and want_to_abandon() from a single land unit
to many. Rename the latter to abandon_askyn() for consistency.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
SAIL has issues:
* Sail orders are executed at the update. Crafty players can use them
to get around the update window.
* The route is fixed at command time. You can't let the update find
the best route, like it does for distribution.
* The info pages documenting it amount to almost 100 non-blank lines
formatted. They claim you can follow friendly ships. This is
wrong. They also show incorrect follow syntax. Unlikely to be the
only errors.
* Few players use it. Makes it a nice hidey-hole for bugs. Here are
two nice ones:
- If follow's second argument is negative, the code attempts to
follow an uninitialized ship. Could well be a remote hole.
- If ship #1 follows #2 follows #3 follows #2, the update goes into
an infinite loop.
* It's more than 500 lines of rather crufty code nobody wants to
touch. Thanks to a big effort in Empire 2, it shares some code with
the navigation command. It still duplicates other navigation code.
The sharing complicates fixing the bugs demonstrated by
navi-march-test.
Reviewing, fixing and testing this mess isn't worth the opportunity
cost. Remove it instead. Drop commands follow, mquota, sail and
unsail. Drop ship selectors mquota, path, follow.
struct shpstr shrinks some more, on my system from 160 to 120 bytes.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
The autonavigation feature has issues:
* Autonavigation orders are executed at the update. Crafty players
can use them to get around the update window.
* Usability is poor:
- The order command is overly complex, not least because it can do
five different things: clear, suspend, resume, declare route, set
cargo levels.
- Unlike every other command involving movement, order does not let
you specify routes, only destination sectors.
- Setting cargo levels can silently swap start and end point of a
circular route, because "this keeps the load_it() procedure
happy". Maybe it does, but it surely keeps players confused.
- Setting "start" cargo levels actually sets the "end" levels, and
vice versa. Has always been broken that way.
- Predicting what exactly autonavigation will do at the update isn't
easy.
* The info pages documenting it amount to almost 400 non-blank lines
formatted. They claim only merchant ships can be given orders.
This is wrong. Unlikely to be the only error.
* Few players use it, and its workings at the update a fairly opaque.
Makes it a nice hidey-hole for bugs. Here are two:
- Unlike the scuttle command, autonavigation happily scuttles trade
ships while they're on the trading block.
- Unlike the load command, autonavigation can load in friendly and
allied sectors.
* It's more than 700 lines of rather crufty code nobody wants to
touch. Thanks to a big effort in Empire 2, it shares code with the
navigation command. It still duplicates load code. The sharing
complicates fixing the bugs demonstrated by navi-march-test.
Reviewing, fixing and testing this mess isn't worth the opportunity
cost. Remove it instead. Drop commands order, qorder and sorder.
Drop ship selectors xstart, xend, ystart, yend, cargostart, cargoend,
amtstart, amtend, autonav.
xdump ship sheds almost half its columns. struct shpstr shrinks, on
my system from 200 to 160 bytes.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Send bulletin to owner and report news exactly like for key 'o'.
Also print a "sector duplicated" message, just for consistency with
other keys.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Commit 77e95bd7 (v4.3.12) missed the move of log.c there. A few
pointers to other headers are missing.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
