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>
Traditionally, building up 100% takes 100 work. Make the work to
build configurable, via new sect-chr selector bwork, backed by new
struct dchrstr member d_bwork. Keep the required work exactly the
same for now.
Tearing down sectors remains four times easier than building.
Clients that hardcode sector build work need to be updated. Easy,
since build work is now exposed in xdump.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Sectors require lcms and hcms to build. The build materials are
exposed as sect-chr columns lcms, hcms (struct dchrstr members d_lcms,
d_hcms). They are per point per point of efficiency. In contrast,
unit build materials are defined for 100%.
We want to define build materials for 100% now, for flexibility and
consistency, and we want to optionally support more build materials in
the future. Replace d_lcms and d_hcms by array member d_mat[], and
replace selectors lcms and hcms by selectors l_build and h_build.
This is an xdump compatibility break. To provide the customary grace
period, we'd have to make selectors lcms and hcms virtual instead,
with value l_build / 100 and h_build / 100 rounded up, and deprecate
them. Deities would have to avoid l_build and h_build values that
aren't multiples of 100 for this to work fully. But we're not
bothering with maintaining xdump compatibility in this release.
Provide selectors for all other item types, to help clients prepare
for future additional materials. Use CA_DUMP_ONLY to keep them out of
configuration tables until they actually work.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Sector build cost is defined by sect-chr column build (struct dchrstr
member d_build). It's the cost per point of efficiency. In contrast,
unit build cost is defined for 100%, by ship-chr, plane-chr, land-chr,
nuke-chr column cost.
Switch sectors to cost per 100%, for flexibility and consistency:
replace struct dchrstr member d_build by d_cost, and replace selector
build by selector cost. Naming it cost for consistency with units is
possible only because the previous commit made the name available.
This is an xdump compatibility break. To provide the customary grace
period, we'd have to make selector build virtual instead, with value
bcost / 100 rounded up, and deprecate it. Deities would have to avoid
bcost values that aren't multiples of 100 for this to work fully. But
we're not bothering with maintaining xdump compatibility in this
release.
With bcost values that aren't multiple of 100, the cost of sector
building may have to be rounded. On the one hand, the cost of sector
demolition has always been rounded up. On the other hand, the cost of
producing stuff is rounded randomly. For now, round up, because
rounding randomly would affect subsequent random rounding, and upset
the smoke test.
Fortunately, show se b already shows build costs per 100%, since
commit 48ff096, v4.3.23.
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>
Ship, plane, land unit and nuke types require lcms and hcms to build.
Planes also require military, and nukes also require oil and rads.
These build materials are exposed as ship-chr, plane-chr, land-chr,
nuke-chr selectors l_build, h_build, crew, o_build, r_build.
We want to optionally support more build materials in the future. To
help clients prepare for that, provide selectors for all other item
types. Use CA_DUMP_ONLY to keep them out of configuration tables
until they actually work.
Rename selector crew to m_build for consistency. This is an xdump
compatibility break. We could easily add m_build and deprecate crew
to provide the customary grace period for such breaks. However, more
xdump changes are coming down the pipe, and for some of them providing
a grace period wouldn't be as easy. Ron Koenderink assures us WinACE
doesn't need a grace period. So don't bother with maintaining xdump
compatibility in this release.
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>
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>
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>
A plane with capability missile must have capability VTOL. When it's
missing, global_init() silently adds it.
Drop that. Check for it in ef_verify_config() instead.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
A ship with non-zero nplanes must have capability plane or miss. When
one doesn't, global_init() silently adds capability miss.
Drop that. Check for it in ef_verify_config() instead. Fix up
ship.config accordingly.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
"torped" comes from symbol table retreat_flags. Visible in output of
edit, retreat, lretreat and xdump. Tolerable in edit, but player
commands like retreat should really use proper words.
Fixing it in retreat_flags changes xdump output, thus risks breaking
clients. Do it anyway, since no known client recognizes this
particular symbol value.
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>
TREATIES has issues:
* Treaties can cover attack, assault, paradrop, board, lboard, fire,
build (s|p|l|n) and enlist, but not bomb, launch, torpedo and
enlistment centers.
* Usability is very poor. While a treaty is in effect, every player
action that violates a treaty condition triggers a prompt like this:
This action is in contravention of treaty #0 (with Curmudgeon)
Do you wish to go ahead anyway? [yn]
If you decline, the action is not executed. If you accept, it is.
In both cases, your decision is reported in the news.
You cannot get rid of these prompts until the treaty expires.
* Virtually nobody uses them.
* Virtually unused code is buggy code. There is at least one race
condition: multifire() reads the firing sector, ship or land unit
before the treaty prompt, and writes it back after, triggering a
generation oops. Any updates made by other threads while trechk()
waits for input are wiped out, triggering a seqno mismatch oops.
* The treaty prompts could confuse smart clients that aren't prepared
for them. WinACE isn't, but is reported to work anyway at least
common usage. Ron Koenderink (the WinACE maintainer) suspects there
could be a few situations where it will fail.
This feature is not earning its keep. Remove it. Drop command
treaty, consider treaty, offer treaty, xdump treaty, reject treaties.
Output of accept changed, obviously.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
For now, it just logs "Configured for testing" on startup, and prints
a scary warning on player login.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
So you don't have to micromanage workers to maximize useful work.
The previous commit made the problem a bit worse. If you had a few
workers too many before, you perhaps produced an extra unit. Now, you
get to keep the extra work instead. Useless, unless it rolls over.
For instance, use "127.0.0.1" for IPv4 loopback instead of
"::ffff:127.0.0.1".
Simplifies use of econfig key privip: plain dotted decimal now just
works regardless of IPv6 use, no need to add the IPv4-mapped form.
Also affects how addresses are logged and shown to players, and nation
selector ip. Nicer that way.
Code dealing with money mixes int and long pretty haphazardly.
Harmless, because practical amounts of money fit into int on any
machine capable of running the server. Clean up anyway.
Option GODNEWS controls news reports give's N_GIFT, N_TAKE, and edit's
and setsector's N_AIDS, N_HURTS.
They affect news headlines because of their non-zero r_good_will.
N_TAKE and N_HURTS can downgrade relations because of their negative
r_good_will. All tolerable, except N_TAKE has actor and victim
reverted: the deity running the give command is the victim, and the
sector owner is the actor. Because of that, give with a negative
amount downgrades the deity's relations towards the sector owner.
Inappropriate.
Has always been that way. Chainsaw disabled these news at
compile-time; to enable you had to define GODNEWS (not documented
anywhere). Empire 4.2.0 made GODNEWS a proper option, enabled by
default.
Fix by setting their r_good_will to zero.
Deities can customize which commodities can be sold in table item.
Default is to allow anything but civilians and military. However,
this applies only to the commodity market, not to the unit market:
cargo of ships and land units is not restricted.
Make the two markets consistent: permit selling military by default,
forbid selling units carrying unsalable commodities. This outlaws
selling units carrying civilians by default.
max_idle applies in state PS_PLAYING, login_grace_time before (login,
state PS_INIT) and after (logout, state PS_SHUTDOWN).
Cut login_grace_time to two minutes, from max_idle's 15. Two minutes
is plenty to complete login and logout. Makes swamping the server
with connections slightly harder, as they get dropped faster. While
that makes sense all by itself, the real aim is making increasing
max_idle safe. The next commit will complete that job.
Spy units are now enabled when a land unit type with capability spy
exists. To disable them, deities have to customize table land-chr.
Before, spy units types were ignored when option LANDSPIES was
disabled. Except for xdump land-chr, which happily dumped unusable
spy unit types.
Trade ships are now enabled when a ship type with capability trade
exists. No such type exists by default; to enable trade ships,
deities have to customize table ship-chr.
Before, trade ship types were ignored when option TRADESHIPS was
disabled. Except for xdump ship-chr, which happily dumped unusable
trade ship types.
Configuration table entries not defined by builtin and custom
configuration files remain blank. They get misinterpreted as sentinel
in tables that use one. Affected are tables product, ship-chr,
plane-chr, land-chr and nuke-chr. Tables item, sect-chr and
infrastructure are immune despite using a sentinel, because omitting
entries is not permitted there.
Code relying on the sentinel fails to pick up entries after the first
blank one. They don't get set up correctly, they're invisible to
build and show, and not recognized as symbolic selector values (the
frg in ship ?type=frg). xdump is fine, because it doesn't rely on
sentinels. It dumps blank entries normally.
The bugs don't bite in the stock game, because the builtin
configuration files are all dense.
The sentinels are all null strings. Set them to "" in the affected
tables' oninit callback. Fix up code iterating over the tables to
ignore such entries. This is precisely the code relying on sentinels,
plus xdump's xdvisible().
The C identifier permits looking up the table in the source. The
table name permits lookup with xdump.
Coders should know how to go from table name to C identifier. Deities
aren't all coders; we shouldn't ask them to guess table names from C
identifiers.
A deity can easily break BRIDGETOWERS by reducing etu_per_update
without compensating customization of buil_tower_bh,
rollover_avail_max or bridge span maxpop.
Document the issue in output of pconfig (which is installed as
$prefix/etc/empire/econfig).
To increase the chance deities actually read the documentation,
disable BRIDGETOWERS.
Bridge spans have been unable to produce enough avail for a tower with
default game configuration since we reduced their maximum population
in commit 6bbd7ffd, v4.3.6. This commit reduces required avail from
160 to 120, fixing the stock game: 100 civilians and 100 uws can make
that much in a 60 ETU update.
Why upgrade? I'm not a lawyer, but here's my take on the differences
to version 2:
* Software patents: better protection against abuse of patents to
prevent users from exercising the rights under the GPL. I doubt
we'll get hit with a patent suit, but it's a good move just on
general principles.
* License compatibility: compatible with more free licenses, i.e. can
"steal" more free software for use in Empire. I don't expect to steal
much, but it's nice to have the option.
* Definition of "source code": modernization of some details for today's
networked world, to make it easier to distribute the software. Not
really relevant to us now, as we normally distribute full source code.
* Tivoization: this is about putting GPL-licensed software in hardware,
then make the hardware refuse to run modified software. "Neat" trick
to effectively deny its users their rights under the GPL. Abuse was
"pioneered" by TiVo (popular digital video recorders). GPLv3 forbids
it. Unlikely to become a problem for us.
* Internationalization: more careful wording, to harden the license
outside the US. The lawyers tell us it better be done that way.
* License violations: friendlier way to deal with license violations.
This has come out of past experience enforcing the GPL.
* Additional permissions: Probably not relevant to us.
Also include myself in the list of principal authors.
SLOW_WAR has issues:
* The check whether the attacker old-owns the attacked sector is
broken, because att_abort() uses sect.sct_oldown uninitialized.
Spotted by the Clang Static Analyzer.
* Its implementation in setrel() is somewhat scary. It's actually
okay, because that part of setrel() only runs within decl(). Other
callers don't reach it: update_main() because player->god != 0
there, and the rest because they never pass a rel < HOSTILE.
* Documentation is a bit vague.
SLOW_WAR hasn't been used in a public game in years. Fixing it is not
worth it, so remove it instead.
