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>
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>
The code needs it first so it can store field values into the object
right away. Save the values instead, and store them when the row is
complete.
The improvement is hardly worth the trouble by itself, but it'll
simplify supporting keys consisting of multiple fields, like sector
xloc, yloc or realm cnum, realm, so we can omit rows in those tables,
too.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
We currently require all rows to be present for tables item, sect-chr,
infrastructure, sect, realm.
The first three make sense: the code hard-codes indexes for them, and
malfunctions when entries are blank, so we want to make it hard to
leave any blank by accident.
The last two don't: blank sectors and realms work fine. There, the
restriction is arbitrary. Drop it.
Sectors and realms still can't be omitted "in the middle" (can do that
only with an ID selector), but that's coming soon.
See also commit 4a4ec91.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
Each part of a split table needs to supply rows for the same objects.
We currently require each part to name its objects explicitly, with an
object ID field, and don't support splitting tables that don't have
such IDs. These restrictions became arbitrary when commit 4e23c45
implemented checking each partial table supplies the same rows. Relax
them.
Affects tables sect, news, lost, realm, game, infrastructure.
Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
