Building sectors can make you rate *lower* on the power chart, because
the power factor treats all sectors the same, regardless of build
materials and cost.
To avoid that, replace the term
efficiency / 10.0
by
(power value of materials + power value of cost + 9)
* efficiency/100.0
The value of ordinary sectors, which take no materials and cost $100,
doesn't change. The stock game's fortress is now worth 80% more due
to its materials and higher cost. The stock game's wilderness is
worth 10% less, because it costs nothing.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Give sector types capability flags (dchrstr member d_flags), like
ship, plane, land unit and nuke types have.
Member d_cost is effectively a flag since the previous commit.
Replace it by capability flag "deity". This is an xdump compatibility
break. To provide the customary grace period, we'd have make selector
cost virtual instead, and deprecate it. But we're not bothering with
maintaining xdump compatibility in this release.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Chainsaw 3 added the designate cost along with extra build cost and
materials, and used both to make fortresses expensive. Unlike build
cost and materials, the cost to designate didn't pass the test of
time: it was set to zero in Empire 2. Get rid of it.
sect-chr selector cost and struct dchrstr member d_cost have to stay,
because they're still used to configure whether a sector may be
designated by players (see commit 8d792e1).
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>
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>
struct castr ca_flag NSC_EXTRA was introduced in commit 3e5c064
(v4.2.18) to permit selectors that aren't in xdump.
Flag NSC_CONST was introduced in commit 445dfec, and put to use in
commit d8422ca (both v4.3.0) to protect certain table elements that
should not be changed in customized tables.
Both flags apply only to xdump, not to other uses of struct castr,
such as conditionals.
Combining NSC_EXTRA | NSC_CONST makes no sense.
I'll shortly need a way to keep selectors out of configuration tables
for conditional selector and xdump command forward compatibility.
Doing it as a third flag would add more nonsensical combinations.
Convert the flags to a separate enum ca_dump instead:
neither -> CA_DUMP
NSC_CONST -> CA_DUMP_CONST
NSC_EXTRA -> CA_DUMP_NONE
Bonus: unlike the flags it replaces, ca_dump is not visible in xdump.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
bombcomm[] used to contain the commodities that can be p-bombed. In
BSD Empire 1.1, it contained I_SHELL, I_GUN, I_MILIT, I_PETROL, I_OIL,
I_RAD. In Chainsaw, it contained either everything or everything but
I_BAR, depending on option preprocessor symbol SUPER_BARS. When
Empire 2 replaced the compile time variable SUPER_BARS by the run time
variable opt_SUPER_BARS, bombcomm[] became a redundant indirection.
Eliminate it.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
comm_bomb() first lists commodities that can be bombed and are
present, then prompts for the one to bomb. If the player selects a
bomb-proof one, it rejects it, lists the bombable ones, and prompts
again. This can only happen when option SUPER_BARS is enabled, and
the player selects bars. Looks like this:
Bomb what? (ship, plane, land unit, efficiency, commodities) c
some civilians
some military
commodity to bomb? b
You can't bomb bars of gold!
Bombable: civilians, military, shells, guns, petrol, iron ore, dust (gold), food, oil, light products, heavy products, uncompensated workers, radioactive materials
commodity to bomb?
The list is of marginal value. It was more useful back when
comm_bomb() didn't list commodities before prompting (BSD Empire 1.1).
It's also illegible. Drop it.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
tran_plane() computes a plane's weight from its materials. It
hardcodes lcm weight 1, hcm weight 2, and military weight 0. Use
ichr[].i_lbs instead, which is 1 in the stock game for all three
materials.
While there, support arbitrary materials, even though they aren't yet
possible, just to avoid unnecessary assumptions on possible build
materials.
Since the stock game's planes use fewer military than hcms, they
become up to 15% lighter, except for zep, which becomes 10% heavier.
Missiles use no military and become 20-33% lighter.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Building nukes makes you rate *lower* on the power chart, because the
power factor ignores nukes. Fix that.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Items, ships, planes and land units all contribute to the power
factor, which determines position on the power chart.
Items are worth
amount * item value * (0.5 + nation tech level / 1000.0)
The item values aren't quite right: producing stuff can *hurt* your
position on the power chart. Food, uw and rads are worth nothng.
Reduce the value of oil, and give rads the same value as oil. Tweak
value of iron and oil products so that production's power change is
roughly zero around p.e. 0.9 (tech 110), except for construction
materials, where it's zero at p.e. 0.5 (tech 0). Construction
materials become less valuable, shells, guns and petrol become more
valuable. Increase value of bars to roughly match the other changes.
It may still be too low. Halve the value of civilians, and give the
other half to uw. Results:
old new change
civ 100 50 / 2
mil 100 100
shell 80 125 * 1.5625
gun 400 950 * 2.375
pet 2 7 * 3.5
iron 10 10
dust 200 200
bar 1000 2500 * 2.5
food 0 0
oil 100 50 / 2
lcm 100 20 / 5
hcm 200 40 / 5
uw 0 50 new
rad 0 50 new
Ships, planes and land units are worth
base value * effic/100.0 * (0.5 + unit tech level / 1000.0)
For ships and land units, the base value is
lcm/5.0 + hcm/5.0
Build cost is ignored, but lcms are valued twice as much "loose" ones
(before this commit). Therefore, building stuff can change your
position on the power chart in both directions, depending on the type
of build.
For planes, the base value is
20 * (0.5 + nation tech level / 1000.0)
Build cost and materials are ignored, and tech is squared. This
is plainly absurd.
Unify to
(power value of money and materials to build) * effic/100.0
This formula is chosen so that building stuff doesn't change your
power factor. Bonus: it doesn't assume anything about possible build
materials.
For ships and land units, factoring in build cost overcompensates the
discounted value of construction materials more often than not.
Noteworthy changes for the stock game:
ship type old new change
ss slave ship 20 5.8 * 0.29 largest decrease
cs cargo ship 20 7.8 * 0.39
ts trade ship 60 25.5 * 0.42
frg frigate 12 7.8 * 0.65
bb battleship 24 21.8 * 0.91
cal light carrier 22 30.4 * 1.38
can nuc carrier 30 84.6 * 2.82 largest increase
land unit type old new change
hat hvy artillery 12 9.6 * 0.8 largest decrease
linf light infantry 2.4 3.32 * 1.38
cav cavalry 3 5.4 * 1.8
inf infantry 3 5.4 * 1.8
lar lt armor 3 6.4 * 2.13
com commando 3 15.4 * 5.13
eng engineer 3 30.4 * 10.13
meng mech engineer 3 45.4 * 15.13 largest increase
For planes, the power value change depends on the type. Below a
certain nation tech level, planes of this type become more valuable,
above less.
For the stock game, planes costing at most $1000 become less valuable
at any nation tech level that can build them, and planes costing at
least $1800 become more valuable at any practical tech level,
i.e. under 400. Noteworthy planes:
plane type new
sam Sea Sparrow 2.1 least valuable
f2 P-51 Mustang 4.34
lb TBD-1 Devastator 5.92
jf1 F-4 Phantom 10.6
tr C-56 Lodestar 10.78
jt C-141 Starlifter 15.86
jhb B-52 Strato-Fortress 33.54
ss KH-7 spysat 41.2 most valuable
The old value is a flat 12 at nation tech level 100, 15 at tech level
250, and 18 at tech level 400.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Custom games may want to tweak how items contribute to the power
factor, in particular when products are also customized. Add ichrstr
member i_power and item selector power for that.
"info power" doesn't reflect this change, yet. It'll be updated in
the next commit.
The current item power values are problematic. This will be addressed
later.
For straightforward configurations, reasonable item power values could
perhaps be derived from the configuration automatically. However,
this is surprisingly hard in the general case: since producing things
should not decrease power, the efficiency of processing products into
other products needs to be considered, and estimating these
efficiencies can be difficult.
Deities can create multiple products making the same item, or multiple
sector types with the same product, but different process efficiency
(sect-chr selector peffic). Providing differently efficient ways to
make the same item can be reasonable when the sector types involved
have different terrain. To average them, you'd need to know the map.
The stock game has one example: gold mines produce dust with 100%
process efficiency, mountains produce it with 75%. Mountains are
normally rare enough not to matter.
Level p.e. (product selectors nlmin, nllag) may have to be considered.
In the stock game, level p.e. variations are minor, because it reaches
0.9 pretty quickly. In games where it doesn't, you might have to
increase the power value of the product.
Resources (sect selectors min, gold, fert, ocontent, uran) and
resource depletion (product selectors nrndx and nrdep) further
complicate things: you might want to increase the power value of
products depending on unusually scarce resources, but you can't know
what's scarce without understanding the map.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Actual abilities of ships, planes and land units depend almost
completely on the individual unit's tech, not the nation's tech. The
power factor should reflect that.
The power value of a unit is of the form
base value * (20 + nation's tech level) / 500
Change it to
base value * (20 + unit's tech level) / 500
Note that a plane's base value still depends on the nation's tech
level. This commit merely makes the absurdity stand out a bit more.
To be fixed later.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
In the old times, power didn't consider tech at all. Chainsaw's
option NEWPOWER (mandatory since v4.2.14, on by default before)
changed this dramatically: the power factor gets multiplied by
max(1, tech) / 500.
In the early game, small absolute tech differences yield large power
factor differences. For instance, if country A has tech level 10, and
B has 5, then A gets a factor two boost.
As the game progresses, tech differences between viable countries tend
to grow, but only slowly. The influence on power diminishes. For
instance, if C has tech level 270 and D has 240 (quite a respectable
tech lead), then C gets a modest 1.125x boost over D.
Change the factor to (20 + tech) / 500. Now A's advantage is only
1.2, and C's is 1.115.
You might think that's rather low. However, tech is not power unless
you project it, and then it manifests itself as sectors, population
and other stuff power counts.
The same tech term occurs in plane power, except with just tech
instead of max(1, tech) . Change it there as well, for consistency.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
If option RES_POP is enabled, the power factor is multiplied by a
"research factor" of 1.0 + maxpop / 10000.0, where maxpop is the
maximum population of a mine sector.
Back when this code was written (Chainsaw 3), all sectors had the same
population limit, so using a mine sector was as good as any. Since
then, it has become configurable, and the stock game has both sector
types with lower (mountains, plains) and with higher (cities)
population limits.
Space for people is worth considering for power, but multiplying total
power by a fudge factor based on the most common sector type's maximum
population is silly. Drop it.
Adjusting each sector's value for maximum population would make more
sense, with and without RES_POP. Perhaps later.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Item power value is basically number of items times the item power
weight. For some item types, we add up the item numbers, then apply
the weight. For lcms and hcms, we apply the weight, then add up the
weighted numbers.
Adopt the latter method for all types: change addtopow() to tally the
power value for all types instead of just lcms and hcms, and drop
gen_power()'s item power value computation.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Use a single array member instead of multiple scalar members. Only
the array elements that replace scalar members are can be non-zero for
now.
This is a first step to permitting more build materials.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
The work required for build and repairs is traditionally a function of
build materials: 20 + lcm + 2*hcm for ships, planes and land units,
and (lcm + 2*hcm + oil + rad)/5 for nukes. Make it independently
configurable instead, via new ship-chr, plane-chr, land-chr, nuke-chr
selector bwork, backed by new struct mchrstr member m_bwork, struct
plchrstr member pl_bwork, struct lchrstr member l_bwork, struct
nchrstr member n_bwork. Keep the required work exactly the same for
now.
Clients that compute work from materials need to be updated. Easy,
since build work is now exposed in xdump.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Add edit u keys 'A' for plague stage, and 'b' for plague time.
Admittedly unobvious, but at least they match edit s keys 'a' and 'b'.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
The two "while it is carrying a nuclear weapon" messages lack
newlines. Add them. Screwed up in commit a269cdd, v4.3.23.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
When bombing land units, the bombers get a chance to spot spies. They
can target one even when it wasn't spotted. This makes no sense.
Screwed up when spy units were added in 4.0.0. Hide them completely.
They can still be killed via collateral damage.
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>
quiet_bigdef() runs for each attacker. It lets each eligible defender
fire at most once. The first time a defender is eligible, it fires
and is saved in the list of defenders, along with its firing damage.
If it's eligible again for a later attacker, it's found in the list of
defenders, and the damage is reused. The list of defenders searched
with search_flist(). Unfortunately, search_flist() compares only uid,
not type, and therefore can return a previously found defender of
another type.
If there are multiple attackers and multiple defenders with the same
uid, total damage can be off, damage can be spread to attackers out of
range, and defenders may not be charged shells. Abuse is possible,
but complicated to set up, and probably not worth the trouble.
Broken in commit f89edc7, v4.3.12. Fix by comparing the type as well.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
The "loaded on ship" condition was useless from the start (v4.2.0).
The "loaded on land" condition became useless in commit 45d090b,
v4.3.28.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
The code computing the length of the flight path checks whether the
path ends with 'h'. When getpath() returns an empty path, it accesses
flightpath[-1]. This could set the length to -1 (unlikely), or crash
(even less likely). The former could be abused to gain mobility for
sufficiently inefficient or short-ranged planes. Found with valgrind.
Broken in commit 404a76f7, v4.3.27.
Historically, getpath() could return paths with or without 'h', and
the check was necessary. It returned an empty path only when the
player gave no input, aborting the command. When the player entered
the assembly point's coordinates, it returned "h".
Commit 404a76f7 accidentally changed it to return "" then. Also broke
flying to the assembly point's coordinates. Commit 0f1e14f (v4.3.31)
fixed that part by changing getpath()'s contract: always return paths
without 'h' ("" simply means empty path), and return NULL on invalid
input, including no input.
The flawed check is superfluous since then. Drop it.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
... when referring to a function's parameter or a struct/union's
member.
The idea of using FOO comes from the GNU coding standards:
The comment on a function is much clearer if you use the argument
names to speak about the argument values. The variable name
itself should be lower case, but write it in upper case when you
are speaking about the value rather than the variable itself.
Thus, "the inode number NODE_NUM" rather than "an inode".
Upcasing names is problematic for a case-sensitive language like C,
because it can create ambiguity. Moreover, it's too much shouting for
my taste.
GTK-Doc's convention to prefix the identifier with @ makes references
to variables stand out nicely. The rest of the GTK-Doc conventions
make no sense for us, however.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
This reverts commit f4d8d64bb3.
Breaks retreat after ship got sunk by bombs or missile.
ship_bomb() and launch_missile() pass .shp_own to retreat_ship().
Wrong after putship(), because putship() resets the owner when the
ship got sunk. retreat_ship() then oopses and fails to retreat the
surviving members of the group.
Other callers save the owner before putting the ship, and pass that.
We could change these two to do the same. But since we're trying to
get a release out, simply revert the broken commit instead.
sector_can_build() computes mat[i] * (effic / 100.0). The division is
inexact. The result gets randomly rounded, so errors are vanishingly
unlikely to screw up material consumption.
However, we require the amount rounded up to be present since commit
1227d2c. Errors *can* screw that up. Fix by avoiding inexact
computation for that part.
We should probably review rounding of inexact values in general.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Telling the player his torpedo "slams into land" can give a clue on
the direction to the target. No good when the target is out of range,
because we shouldn't tell the player more than that then.
Screwed up in 4.2.2. Fix by checking range before line of sight.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
This partly reverts a change made in Empire 2.3 to tell a submarine's
opponent only that he's dealing with a "sub" instead of the
submarine's UID and type. Hiding submarines is done by prsub().
Uses:
* Command torpedo: defender depth charges or torpedoes an attacking
submarine
If you can attack a submarine reactively, you should be able to
attack it actively, too. But that requires its UID. Reveal it
again, but keep the type hidden.
* Command fire: defender fires back at a submarine using its deck gun
Submarines need to surface to fire deck guns, so they shouldn't be
treated any different than surface ships. Revert Empire 2.3's
change entirely there, i.e. defender learns type as well as UID.
* Command torpedo: attacking submarine hits its target
Keep the submarine hidden.
* Commands torpedo and fire: attacking ship hits a submarine
The attacker passed the UID as command argument, so it doesn't
matter whether we print it or not. Printing it is simpler to code,
so do that.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Repeated for ship, sector and land unit firing. The latter prints
range only when the sanity check succeeds.
Factor out, changing ship and sector to behave like land unit firing.
When the sanity check fails, print "Jammed!" instead of "Klick!",
because "Klick!" suggests no shells. Used to be printed exactly then,
but the condition first became impossible (Chainsaw), then generalized
to "can't fire for whatever reason" (commit 22c6fd8, v4.3.12).
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
This reverts commit 9b0b0dc772.
The fire command drops depth charges when the target is a submarine in
range and firing ship has the capability. Else, it blindly fires
guns. It used to reject ships that can't use guns, even when they
could use depth charges, but commit 9b0b0dc (v4.3.31) lifted that
restruction. No such ships exist in the stock game.
If the firing ship can't fire guns, shp_fire() returns -1, triggering
an oops. Broken in commit 0757042.
Avoiding dependence of depth charge on gun fire capability is
pleasing, but nevertheless a bad idea without test coverage. Creating
the necessary tests isn't worth it, so put back the traditional
restriction instead.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Meaning of targ_sub changes from "target is a submarine" to "attacking
the target with depth charges".
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Mission is cleared only when firing at a target that is out of range.
Screwed up when missions were added in Chainsaw. Always clear it when
firing. Matches torpedo.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
multifire() writes back the firing sector after applying damage. When
an artillery unit on a bridge span commits suicide by shelling down
the supporting bridge heads, this writeback puts the bridge span right
back (less the land units and planes on it), triggering a seqno oops.
On the next update of the bridge head, the bridge span falls again.
Broken in commit fe5b266, v4.3.14.
The problematic write back is superfluous. Remove it along with a few
equally superfluous ones.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Conversion is easier when land units with capability security are
present. Each such land unit is charged 10 mobility. The mobility
charge is undocumented.
Land unit mobility is charged even when conversion turns out to be
impossible, say because the sector has no mobility. I call this a
bug. Has been that way since security land units were added in
Chainsaw 3.
Except the mobility charge doesn't actually work anymore: the changed
land unit is never written back. Broken in commit 82c9166, v4.3.16.
Fix this bug would be trivial, but would bring back the bug described
above, and fixing that one is harder, and doesn't feel worthwhile.
Remove the broken charging of land unit mobility instead.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
