]> git.pond.sub.org Git - empserver/commit - tests/update/journal.log
update: Saner rounding of unit building money and work
authorMarkus Armbruster <armbru@pond.sub.org>
Tue, 7 Jun 2016 19:10:07 +0000 (21:10 +0200)
committerMarkus Armbruster <armbru@pond.sub.org>
Sun, 6 Aug 2017 17:59:58 +0000 (19:59 +0200)
commitae2ae938b59056734ef706fe18334816c9b05ade
tree4605e69e9525ebefa4f6ef61b404a9fd5127d84c
parentcb32c60294089e5a1188cb4d4c5dfad67ba72c61
update: Saner rounding of unit building money and work

shiprepair() limits the efficiency gain to how much the workers can
build, rounding randomly.  It charges work, money and materials for
the efficiency actually gained, rounding work up, money down, and
materials randomly.  Same for planerepair() and landrepair().  Has
always been that way.

If you get lucky with the random rounding, you may get a bit of extra
work done for free.

The budget command runs the update code, and can be off by one due to
different random rounding.

Sector production used to have the same issue, only more serious,
because a single unit of tech production matters much more for the
budget than a single point of unit efficiency gain.  I fixed it in
commit 6f7c93c, v4.3.31.

Fix it for unit building the same way: limit efficiency gain to the
amount the workers can produce (no rounding).  Work becomes a hard
limit, not subject to random fluctuations.  Randomly round work and
money charged for actual gain, like we do for materials.  On average,
this charges exactly the work and money that's used.

This lets budget predict how much gets built a bit more accurately.
It's still not exact, as the amount of work available for building
remains slightly random, and the build cost is randomly rounded.

The old rounding of work for ships carries the comment "I didn't use
roundavg here, because I want to penalize the player with a large
number of ships."  Likewise for planes.  Rounding work up rather than
randomly increases the work cost by 0.5 per ship, plane or land unit
on average.  I could keep the penalty by adding 0.5 before random
rounding.  Not worth it, since the effect is actually pretty trivial.
Let's examine a fairly extreme case: an airfield with 600 available
work repairing a huge number of lightly damaged planes, say f2 with
81% average efficiency.  The old code lets the airfield repair roughly
600 / 6.5 = ~92 planes, the new code 600 / 6 = 100.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
src/lib/update/land.c
src/lib/update/plane.c
src/lib/update/ship.c
tests/smoke/final.xdump
tests/smoke/journal.log
tests/update/final.xdump
tests/update/journal.log
tests/update/setup-POGO